Re: adding a syscall to libc?

[Oliver Pinter]

On Saturday, June 8, 2019, Konstantin Belousov  wrote:

> On Sat, Jun 08, 2019 at 02:57:27AM +, Rick Macklem wrote:
> > Hi,
> >
> > I've started working of a copy_file_range() syscall for FreeBSD. I think
> I have the
> > kernel patched and ready for some testing.
> > However, I'm confused about what I need to do in src/lib/libc/sys?
> > - Some syscalls have little .c files, but other ones do not.
> >   When is one of these little .c files needed and, when not needed, what
> else
> >   needs to be done? (I notice that syscall.mk in src/sys/sys
> automagically, but
> >   I can't see what else, if anything, needs to be done?)
> Most important is to add the new syscall public symbol to sys/Symbol.map
> into the correct version, FBSD_1.6 for CURRENT-13.  Do no bother with
> __sys_XXX and __XXX aliases.
>
> 'Tiny .c files' are typically used for one of two purposes:
> - Convert raw kernel interface into something expected by userspace,
>   often this coversion uses more generic and non-standard interface to
>   implement more usual function.  Examples are open(2) or waitid(2)
>   which are really tiny wrappers around openat(2) and wait6(2) in
>   today libc.
> - Allow libthr to hook into libc to provide additional services.  Libthr
>   often has to modify semantic of raw syscall, and libc contains the
>   tables redirecting to implementation, the tables are patched on libthr
>   load.  Since tables must fill entries with some address in case libthr
>   is not loaded, tiny functions which wrap syscalls are created for
>   use in that tables.
>
> I think you do not need anything that complications for start, in which
> case adding new syscall consists of the following steps:
> - Add the syscall to sys/kern/syscalls.master, and if reasonable,
>   to sys/compat/freebsd32/syscalls.master.
> - Consider if the syscall makes sense in capsicumized environment,
>   and if yes, list the syscall in sys/kern/capabilities.conf.  Typically,
>   if syscall provides access to the global files namespace, it must be not
>   allowed.  On the other hand, if syscall only operates on already opened
>   file descriptors, then it is suitable (but of course there are lot of
>   nuances).
> - Add syscall prototype to the user-visible portion of header,
>   hiding it under the proper visibility check.
> - Add syscall symbol to lib/libc/sys/Symbol.ver.
> - Implement the syscall.  There are some additional details that might
>   require attention:
> - If compat32 syscall going to be implemented, or you know
>   that Linuxolator needs to implement same syscall and would
>   like to take advantage of the code, provide
> int kern_YOURSYSCALL();
>   wrapper and declare it in sys/syscallsubr.h.  Real
> implementations
>   of host-native and compat32 sys_YOURSYSCALL() should be just
>   decoding of uap members and call into kern_YOURSYSCALL.
> - Consider the need to add auditing for new syscall.
> - Add man page for the syscall, at lib/libc/sys/YOURSYSCALL.2, and connect
>   it to the build in lib/libc/sys/Makefile.inc.
> - When creating review for the change, do not include diff for generated
>   files after make sysent.  Similarly, when doing the commit, first commit
>   everything non-generated, then do make -C sys/kern sysent (and
>   make sysent -C sys/compat/freebsd32 sysent if appropriate) and commit
>   the generated files in follow-up.


The best place for this little writeup would be in the wiki. ;)



>
> >
> > Thanks in advance for your help, rick
> > ps: I am using the Linux man pages for the syscall ABI. At some point,
> I'll put this
> >   in phabricator and post here for comments/review.
> > ___
> > 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"
>
___
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: Switching fb backend back to default

[Oliver Pinter]

On Sunday, March 17, 2019, Johannes Lundberg  wrote:

> On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot 
> wrote:
>
> > On Sun, 17 Mar 2019 16:32:43 +
> > Johannes Lundberg  wrote:
> >
> > >
> > > On 3/17/19 3:34 PM, Greg V wrote:
> > > >
> > > >
> > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg
> > > >  wrote:
> > > >> Hi
> > > >>
> > > >> I'm working on making i915kms unload properly. I've come to what I
> > think
> > > >> is the last issue. The drm driver unloads ok, the "efifb" backend is
> > > >> restored (according to logs) and vt_efifb_init() is being called but
> > the
> > > >> screen (laptop built in display) stays black. The system seems
> > > >> operational otherwise. If I load i915kms again in this state I get
> > back
> > > >> a visible (i915kms) framebuffer.
> > > >>
> > > >> Did we ever have this working so it's known to work?
> > > >
> > > > Recently on the linux kernel mailing list:
> > > >
> > > > http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html
> > > >
> > > > > Of course, once native drivers like i915 or radeon take over, such
> a
> > > > framebuffer is toast... [6]
> > > >
> > > > > [6]
> > linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()
> > > > > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe()
> > > >
> > > > So it seems like efifb is not supposed to work after a driver has
> been
> > > > loaded at least once.
> > > >
> > > >
> > > Hmm, well the code is there to handle switching back to the boot time
> > > fb. What I think is happening is that i915 powers off the displays at
> > > unload and vt doesn't know how to power on (or that it should).
> > >
> >
> >  That and if the display pipeline is de-configured or the resolution
> > changed you cannot reset it to the original state.
> >  Unloading drm modules is only useful for testing (and finding leaks).
>
>
> Yeah a normal user would never unload it. Since I mostly ssh to my test
> machines I think I’m fine personally with losing the display while
> unloading.
>
> Keyboard input still works though and at least it doesn’t crash anymore :)



 As workaround, can't you turn on the display with intel_backlight?

>
>
> >
> > >
> > > ___
> > > 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"
> >
> >
> > --
> > Emmanuel Vadot  
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
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: dwarf2 today on 13-CURRENT

[Oliver Pinter]

On 1/12/19, Oliver Pinter  wrote:
> On 1/12/19, Dimitry Andric  wrote:
>> On 12 Jan 2019, at 19:40, Oliver Pinter 
>> wrote:
>>> According the following comment in ${SRCTOP}/sys/conf/kern.mk:
>>>
>>> #
>>> # Add -gdwarf-2 when compiling -g. The default starting in clang v3.4
>>> # and gcc 4.8 is to generate DWARF version 4. However, our tools don't
>>> # cope well with DWARF 4, so force it to genereate DWARF2, which they
>>> # understand. Do this unconditionally as it is harmless when not needed,
>>> # but critical for these newer versions.
>>> #
>>> .if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == ""
>>> CFLAGS+=-gdwarf-2
>>> .endif
>>>
>>> this dwarf2 limitation still exists in today's HEAD?
>>>
>>> I mean the FreeBSD project switched to elftoolchain and mostly to LLVM
>>> tools. LLDB is compiled by default on 13-CURRENT (~ HEAD) and the kgdb
>>> has moved under the libexec directory, to hide them from the common
>>> usage.
>>
>> See https://reviews.freebsd.org/D17930, where there is a proposed patch
>> for this very topic.
>
> Thanks!
>
> From the other side, is there any result from the GSoC14's klldb?
> I can't really find any info in the project's github branch, but I've found
> this
> patch: https://reviews.llvm.org/rLLDB314672 .

And probably found them: https://reviews.llvm.org/D10216 .

>
>
>
>>
>> -Dimitry
>>
>>
>
___
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: dwarf2 today on 13-CURRENT

[Oliver Pinter]

On 1/12/19, Dimitry Andric  wrote:
> On 12 Jan 2019, at 19:40, Oliver Pinter 
> wrote:
>> According the following comment in ${SRCTOP}/sys/conf/kern.mk:
>>
>> #
>> # Add -gdwarf-2 when compiling -g. The default starting in clang v3.4
>> # and gcc 4.8 is to generate DWARF version 4. However, our tools don't
>> # cope well with DWARF 4, so force it to genereate DWARF2, which they
>> # understand. Do this unconditionally as it is harmless when not needed,
>> # but critical for these newer versions.
>> #
>> .if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == ""
>> CFLAGS+=-gdwarf-2
>> .endif
>>
>> this dwarf2 limitation still exists in today's HEAD?
>>
>> I mean the FreeBSD project switched to elftoolchain and mostly to LLVM
>> tools. LLDB is compiled by default on 13-CURRENT (~ HEAD) and the kgdb
>> has moved under the libexec directory, to hide them from the common
>> usage.
>
> See https://reviews.freebsd.org/D17930, where there is a proposed patch
> for this very topic.

Thanks!

>From the other side, is there any result from the GSoC14's klldb?
I can't really find any info in the project's github branch, but I've found this
patch: https://reviews.llvm.org/rLLDB314672 .



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

dwarf2 today on 13-CURRENT

[Oliver Pinter]

Hi all!

According the following comment in ${SRCTOP}/sys/conf/kern.mk:

#
# Add -gdwarf-2 when compiling -g. The default starting in clang v3.4
# and gcc 4.8 is to generate DWARF version 4. However, our tools don't
# cope well with DWARF 4, so force it to genereate DWARF2, which they
# understand. Do this unconditionally as it is harmless when not needed,
# but critical for these newer versions.
#
.if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == ""
CFLAGS+=-gdwarf-2
.endif

this dwarf2 limitation still exists in today's HEAD?

I mean the FreeBSD project switched to elftoolchain and mostly to LLVM
tools. LLDB is compiled by default on 13-CURRENT (~ HEAD) and the kgdb
has moved under the libexec directory, to hide them from the common
usage.

Thanks,
Oliver
___
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: config files break after mergemaster -Ui

[Oliver Pinter]

Hi!

Before you do anything take a look in /var/db/backup directory - or just
try to find the backups with find /var -name "group*" command.

On Sunday, January 6, 2019, White Wizard  wrote:

> Hi,
> i break my config file, peraps /etc/group when un mergemaster.
> No concentrate to that i do and ask bad anwsers.
>
> How can i re-install défault config files ? Now i just single user's
> access. When i try to login root, before pass's ask the system say me
> invalid login...
>
> BR,
> White Wizard.
>
> ___
> 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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Oliver Pinter]

On 11/4/18, Rebecca Cran  wrote:
> On Sunday, 4 November 2018 14:36:13 MST Toomas Soome wrote:
>
>> it is reasonable to have efi/freebsd directory, the efi/boot/bootx64.efi
>> is
>> hard one of course. But then again, it is problem only when we can not
>> setup EFI bootmanager variables ? the bootx64.efi is default when bootmgr
>> is not set up.
>
> Yes, I think we should only create efi/boot/boot{x64,ia32,aa64,arm}.efi if
> it
> doesn't already exist in which case we're likely the only OS on the system.

It's a totally working scenario to create OS specific directories on the ESP:

root@opn ~# efibootmgr -v
BootCurrent: 
Timeout : 0 seconds
BootOrder : , 0003, 0001
Boot0003* Windows Boot Manager
HD(1,GPT,86fcd8f6-3db7-11e8-ad9f-34e6d749b944,0x28,0x20)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

ada0p1:/EFI/Microsoft/Boot/bootmgfw.efi
/boot/esp//EFI/Microsoft/Boot/bootmgfw.efi
Boot* HardenedBSD 11-STABLE
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x1,0x,0x0)/HD(1,GPT,86fcd8f6-3db7-11e8-ad9f-34e6d749b944,0x28,0x20)/File(\efi\hardenedbsd\boot1.efi)
ada0p1:/efi/hardenedbsd/boot1.efi
/boot/esp//efi/hardenedbsd/boot1.efi
Boot0001* UEFI: TOSHIBA MQ02ABF050H
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x1,0x,0x0)/HD(1,GPT,86fcd8f6-3db7-11e8-ad9f-34e6d749b944,0x28,0x20)

VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,20002000200020002000200020002000200020003100200053003800500054003500460054004b00)

The above is how my esp looks like. In EFI I have two entry: one for
HardenedBSD  and one for Windows. This functionality isn't yet
implemented in the installer, but it's possible to made them by hand.


>
> --
> 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"
>
___
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: Sound issues with Dell Latitude 7490 (kabylake)

[Oliver Pinter]

On 10/16/18, Oliver Pinter  wrote:
> On 10/6/18, David Wolfskill  wrote:
>> On Wed, Oct 03, 2018 at 03:28:45PM +0200, Jakob Alvermark wrote:
>>> ...
>>> This is probably not a proper fix, but it helps to understand the
>>> problem.
>>>
>>> Could you post the output of 'sysctl dev.hdaa' with and without the
>>> patch so we can see what's different?
>>> .
>>
>> I have run:
>>
>>  uname -a && sysctl dev.pcm dev.hdaa
>>
>> for each of stable/11 and head, both unpatched and patched.  (The
>> "unpatched" versions were a bit older -- almost a week, for stable/11;
>> from back in August, for head -- but that does not appear to be
>> significant in the present case.)
>>
>> The files are accessible from
>> <http://www.catwhisker.org/~david/FreeBSD/m4800/sound/>.
>>
>> The sysctl output is the same for stable/11 & head:
>>
>> g1-215(11.2-S)[9] foreach f ( sound_info_* )
>> foreach? echo -n "${f}: " && tail +2 $f | md5
>> foreach? end
>> sound_info_11_patched: 90c26fbae2031174656207f66e1a39ec
>> sound_info_11_unpatched: cb9239fb33901086f56527c22576097f
>> sound_info_12_patched: 90c26fbae2031174656207f66e1a39ec
>> sound_info_12_unpatched: cb9239fb33901086f56527c22576097f
>> g1-215(11.2-S)[12]
>>
>> A unidiff for the "head" versions:
>>
>> g1-215(11.2-S)[12] diff -u sound_info_12_{un,}patched
>> --- sound_info_12_unpatched 2018-10-06 04:04:36.041741000 -0700
>> +++ sound_info_12_patched   2018-10-06 04:00:26.68135 -0700
>> @@ -1,4 +1,4 @@
>> -FreeBSD g1-215.catwhisker.org 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #276
>> r338043M/338043:1200078: Sun Aug 19 04:32:07 PDT 2018
>> r...@g1-215.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY
>> amd64
>> +FreeBSD g1-215.catwhisker.org 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #131
>> r339212M/339212: Sat Oct  6 03:52:20 PDT 2018
>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
>> amd64
>>  dev.pcm.3.bitperfect: 0
>>  dev.pcm.3.buffersize: 65536
>>  dev.pcm.3.rec.vchanformat: s16le:2.0
>> @@ -111,7 +111,7 @@
>>   Widget cap: 0x00400781 PWR DIGITAL UNSOL STEREO
>>  Pin cap: 0x0014 PDC OUT
>>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None
>> ctype=1/8
>> loc=Rear color=Black misc=1
>> -Pin control: 0x
>> +Pin control: 0x0040 OUT
>>  Connections: 1
>>+ <- nid=6 [audio output] [DISABLED]
>>
>> @@ -134,7 +134,7 @@
>>   Widget cap: 0x0040058f PWR UNSOL STEREO
>>  Pin cap: 0x3734 PDC OUT IN VREF[ 50 80 100 GROUND HIZ ]
>>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None
>> ctype=1/8
>> loc=Rear color=Black misc=1
>> -Pin control: 0x
>> +Pin control: 0x0020 IN
>>   Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
>>Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
>>  Connections: 2
>> @@ -147,7 +147,7 @@
>>   Widget cap: 0x0040048b PWR UNSOL STEREO
>>  Pin cap: 0x3724 PDC IN VREF[ 50 80 100 GROUND HIZ ]
>>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None
>> ctype=1/8
>> loc=Rear color=Black misc=1
>> -Pin control: 0x
>> +Pin control: 0x0020 IN
>>Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
>>
>>  dev.hdaa.1.nid25_original: 0x01a1903e as=3 seq=14 device=Mic conn=Jack
>> ctype=1/8 loc=Rear color=Pink misc=0
>> g1-215(11.2-S)[13]
>>
>> Peace,
>> david
>
> Is there any chance to get these workarounds / fixes for dell machines
> in the main tree?

With Jakob's workaround - to comment out the cleaning of hda pin
states - my laptop's sound started to work.
It's a Dell E5440. So thanks Jakob! :)

>
>
>> --
>> David H. Wolfskill   da...@catwhisker.org
>> Women (and decent men): vote against supporters of Trump's misogyny!
>>
>> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>>
>
___
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: Sound issues with Dell Latitude 7490 (kabylake)

[Oliver Pinter]

On 10/6/18, David Wolfskill  wrote:
> On Wed, Oct 03, 2018 at 03:28:45PM +0200, Jakob Alvermark wrote:
>> ...
>> This is probably not a proper fix, but it helps to understand the
>> problem.
>>
>> Could you post the output of 'sysctl dev.hdaa' with and without the
>> patch so we can see what's different?
>> .
>
> I have run:
>
>   uname -a && sysctl dev.pcm dev.hdaa
>
> for each of stable/11 and head, both unpatched and patched.  (The
> "unpatched" versions were a bit older -- almost a week, for stable/11;
> from back in August, for head -- but that does not appear to be
> significant in the present case.)
>
> The files are accessible from
> .
>
> The sysctl output is the same for stable/11 & head:
>
> g1-215(11.2-S)[9] foreach f ( sound_info_* )
> foreach? echo -n "${f}: " && tail +2 $f | md5
> foreach? end
> sound_info_11_patched: 90c26fbae2031174656207f66e1a39ec
> sound_info_11_unpatched: cb9239fb33901086f56527c22576097f
> sound_info_12_patched: 90c26fbae2031174656207f66e1a39ec
> sound_info_12_unpatched: cb9239fb33901086f56527c22576097f
> g1-215(11.2-S)[12]
>
> A unidiff for the "head" versions:
>
> g1-215(11.2-S)[12] diff -u sound_info_12_{un,}patched
> --- sound_info_12_unpatched 2018-10-06 04:04:36.041741000 -0700
> +++ sound_info_12_patched   2018-10-06 04:00:26.68135 -0700
> @@ -1,4 +1,4 @@
> -FreeBSD g1-215.catwhisker.org 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #276
> r338043M/338043:1200078: Sun Aug 19 04:32:07 PDT 2018
> r...@g1-215.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY
> amd64
> +FreeBSD g1-215.catwhisker.org 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #131
> r339212M/339212: Sat Oct  6 03:52:20 PDT 2018
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> amd64
>  dev.pcm.3.bitperfect: 0
>  dev.pcm.3.buffersize: 65536
>  dev.pcm.3.rec.vchanformat: s16le:2.0
> @@ -111,7 +111,7 @@
>   Widget cap: 0x00400781 PWR DIGITAL UNSOL STEREO
>  Pin cap: 0x0014 PDC OUT
>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
> loc=Rear color=Black misc=1
> -Pin control: 0x
> +Pin control: 0x0040 OUT
>  Connections: 1
>+ <- nid=6 [audio output] [DISABLED]
>
> @@ -134,7 +134,7 @@
>   Widget cap: 0x0040058f PWR UNSOL STEREO
>  Pin cap: 0x3734 PDC OUT IN VREF[ 50 80 100 GROUND HIZ ]
>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
> loc=Rear color=Black misc=1
> -Pin control: 0x
> +Pin control: 0x0020 IN
>   Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
>Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
>  Connections: 2
> @@ -147,7 +147,7 @@
>   Widget cap: 0x0040048b PWR UNSOL STEREO
>  Pin cap: 0x3724 PDC IN VREF[ 50 80 100 GROUND HIZ ]
>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
> loc=Rear color=Black misc=1
> -Pin control: 0x
> +Pin control: 0x0020 IN
>Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
>
>  dev.hdaa.1.nid25_original: 0x01a1903e as=3 seq=14 device=Mic conn=Jack
> ctype=1/8 loc=Rear color=Pink misc=0
> g1-215(11.2-S)[13]
>
> Peace,
> david

Is there any chance to get these workarounds / fixes for dell machines
in the main tree?


> --
> David H. Wolfskillda...@catwhisker.org
> Women (and decent men): vote against supporters of Trump's misogyny!
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>
___
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"

drm / drm2 removal in 12

[Oliver Pinter]

On Sunday, August 26, 2018, blubee blubeeme  wrote:

> On Sun, Aug 26, 2018 at 4:32 PM Hans Petter Selasky 
> wrote:
>
> > On 8/26/18 3:20 AM, blubee blubeeme wrote:
> > > Have you or anyone working on this drm-legacy-kmod stuff done any
> > testings
> > > of how this will affect current users?
> >
> > Hi Blubee,
> >
> > Are you here to try to stir a conflict?
> > If so that is not appreciated.
> >
> > --HPS
> >
> Hans, you of all people should know that's not true.
>
> I would think that trying to sneak in code during a code freeze that would
> break the release. Forcing the core devs to revert those changes and having
> to dust off old policies to try to keep you guys in check is what's
> stirring up conflicts, but hey; what do I know?


Please use git pull or svn up. They are already reverted and you get back
your old drivers.

https://github.com/freebsd/freebsd/commit/ae526637c4a79045579abc632ffbfd
b368c66ea8#diff-6ee1ee279be0fe8a84e853198b2b4c43

Please try to learn how to use development tools.

https://github.com/freebsd/freebsd/commits/master/sys/dev/drm2

I think the latest binary snapshot from 12.0-ALPHA3 contains the old state
of code if not, next should be.


> It's really sad state when capable engineers are so obsessed with something
> that they cannot see the forest for the trees. Try to step away from the
> canvas and look at the big picture.


Let's do some more step backwards, and see how the graphics driver
developments works from the corporation side.
They not bother about any of the BSDs, they focus only to Windows and
Linux. If you want to use a recent (haha recent, something after  2014) you
are forced to use new drivers from linux.
The fore/advantage on the Linux side are the zillions of corporately paid
kernel developers.
They can just focus on a new hw supports, on freebsd side, there are no
corporately paid drm driver developer. Sadly.
In linux word their internal KPI (try a Google for a "stable API nonsense"
words) moves so fastly, that porting of these drivers gets non trivial
without a dedicated paid team.

If you want to change on this situation, try to learn for you could help or
send directed donations to freebsd foundation. ;)


>
> If you don't mind me asking, Hans care to answer these questions below?
> 1) Take a [test] system with the current graphics stack installed and
> working.
> 2) Apply your patches to remove the drm from base to create a port
> 3) update the working [test] system after applying your changes
>
>
With the latest 12, nothing special. Only a deprecation notice gets
printed, once the driver is loaded.


> How does your changes affect a [test] system that is already up and
> running?
>
> Have any of you guys tried that? Do you have any documentation on how it'll
> affect users.
>
> You guys want to remove things from the current system but you come with;
> it works for us hobbyists.
> Where do users go to get steps to do all of this stuff?
>
> You've repeatedly said what you want to do sure, but have you tested it?
> ___
> 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: EFIRT on machines with pcid after r337773

[Oliver Pinter]

Hi!

Seems like this patch fixed the boot issue on Dell e5440 with UEFI.

Once you get to MFC, please X-MFC-with the following patch:

commit dfe1112fa878c5d8fa0605d1de10c96ecc993569
Author: rlibby 
Date:   Fri Jul 21 17:11:36 2017 +

__pcpu: gcc -Wredundant-decls

Pollution from counter.h made __pcpu visible in amd64/pmap.c.  Delete
the existing extern decl of __pcpu in amd64/pmap.c and avoid referring
to that symbol, instead accessing the pcpu region via PCPU_SET macros.
Also delete an unused extern decl of __pcpu from mp_x86.c.

Reviewed by:kib
Approved by:markj (mentor)
Sponsored by:   Dell EMC Isilon
Differential Revision:  https://reviews.freebsd.org/D11666

Notes:
svn path=/head/; revision=321335

On 8/15/18, Konstantin Belousov  wrote:
> If you use UEFI boot, have EFIRT compiled in kernel (the case of
> GENERIC) or pre-loaded as module, and efirt is not disabled by a tunable,
> and the machine resets during kernel initialization, try this.
>
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index d5d795ab502..c9334eab916 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -1188,7 +1188,7 @@ pmap_bootstrap(vm_paddr_t *firstaddr)
>   kernel_pmap->pm_pcids[i].pm_pcid = PMAP_PCID_KERN;
>   kernel_pmap->pm_pcids[i].pm_gen = 1;
>   }
> - PCPU_SET(pcid_next, PMAP_PCID_KERN + 1);
> + PCPU_SET(pcid_next, PMAP_PCID_KERN + 2);
>   PCPU_SET(pcid_gen, 1);
>   /*
>* pcpu area for APs is zeroed during AP startup.
> @@ -2651,8 +2651,8 @@ pmap_pinit0(pmap_t pmap)
>   bzero(>pm_stats, sizeof pmap->pm_stats);
>   pmap->pm_flags = pmap_flags;
>   CPU_FOREACH(i) {
> - pmap->pm_pcids[i].pm_pcid = PMAP_PCID_NONE;
> - pmap->pm_pcids[i].pm_gen = 0;
> + pmap->pm_pcids[i].pm_pcid = PMAP_PCID_KERN + 1;
> + pmap->pm_pcids[i].pm_gen = 1;
>   if (!pti) {
>   __pcpu[i].pc_kcr3 = PMAP_NO_CR3;
>   __pcpu[i].pc_ucr3 = PMAP_NO_CR3;
> ___
> 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: Restart at boot with new kernel

[Oliver Pinter]

On 8/14/18, Matthias Gamsjager  wrote:
> Hi list,
>
> just compiled current and after reboot into the new kernel the machine
> reboots itself at the marked line below. No further info as the reset is
> sudden. Reboot with the old kernel from 12 aug works. Removed all kernel
> modules but with no result.
>
> Any pointers how to approach this?
>
> Aug 14 21:35:19 workstation kernel: ---<>---
> Aug 14 21:35:19 workstation kernel: Copyright (c) 1992-2018 The FreeBSD
> Project.
> Aug 14 21:35:19 workstation kernel: Copyright (c) 1979, 1980, 1983, 1986,
> 1988, 1989, 1991, 1992, 1993, 1994
> Aug 14 21:35:19 workstation kernel: The Regents of the University of
> California. All rights reserved.
> Aug 14 21:35:19 workstation kernel: FreeBSD is a registered trademark of
> The FreeBSD Foundation.
> Aug 14 21:35:19 workstation kernel: FreeBSD 12.0-ALPHA1 #9
> 8501082ee8a(master): Tue Aug 14 21:13:15 CEST 2018
> Aug 14 21:35:19 workstation kernel:
> root@workstation:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
> amd64
> Aug 14 21:35:19 workstation kernel: FreeBSD clang version 6.0.1
> (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
> Aug 14 21:35:19 workstation kernel: VT(efifb): resolution 1024x768
> Aug 14 21:35:19 workstation kernel: CPU: Intel(R) Core(TM) i7-2600K CPU @
> 3.40GHz (3410.09-MHz K8-class CPU)
> Aug 14 21:35:19 workstation kernel:   Origin="GenuineIntel"  Id=0x206a7
> Family=0x6  Model=0x2a  Stepping=7
> Aug 14 21:35:19 workstation kernel:
> Features=0xbfebfbff
> Aug 14 21:35:19 workstation kernel:
> Features2=0x1f9ae3bf
> Aug 14 21:35:19 workstation kernel:   AMD
> Features=0x28100800
> Aug 14 21:35:19 workstation kernel:   AMD Features2=0x1
> Aug 14 21:35:19 workstation kernel:   XSAVE Features=0x1
> Aug 14 21:35:19 workstation kernel:   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> Aug 14 21:35:19 workstation kernel:   TSC: P-state invariant, performance
> statistics
> Aug 14 21:35:19 workstation kernel: real memory  = 34359738368 (32768 MB)
> Aug 14 21:35:19 workstation kernel: avail memory = 3342208 (31789 MB)
> Aug 14 21:35:19 workstation kernel: Event timer "LAPIC" quality 600
> Aug 14 21:35:19 workstation kernel: ACPI APIC Table: 
> Aug 14 21:35:19 workstation kernel: FreeBSD/SMP: Multiprocessor System
> Detected: 8 CPUs
> Aug 14 21:35:19 workstation kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) x
> 2 hardware threads
> Aug 14 21:35:19 workstation kernel: random: unblocking device.
> Aug 14 21:35:19 workstation kernel: ioapic0  irqs 0-23 on
> motherboard
>>> REBOOT Aug 14 21:35:19 workstation kernel: Launching APs: 1 7 3 6 4 5
> ---<>---
> Aug 14 21:35:19 workstation kernel: Copyright (c) 1992-2018 The FreeBSD
> Project

I observed the same with the MFC'd back r337773 to 11-STABLE.

So CC kib@ and @kevans.

My system is a Dell Latitude e5440 with 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"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Linux process causes kernel panic

[Oliver Pinter]

On 8/3/18, Johannes Lundberg  wrote:
> On Fri, Aug 3, 2018 at 9:34 PM Oliver Pinter
> 
> wrote:
>
>> Hi!
>>
>> On 8/3/18, Johannes Lundberg  wrote:
>> > Hi
>> >
>> > After install new kernel+world built from today's checkout I keep
>> > getting
>> > the same crash over and over. Never had this problem before. The
>> > previous
>> > kernel was from 3 weeks ago.
>> >
>> > Looks familiar to anyone?
>>
>> Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP
>> support?
>>
>
> This is Intel Broadwell, Core i5.

The smapification of amd64/linux/linux_support.s is missing from the SMAP patch.
CC kib@.

>
>
>> >
>> > Fatal trap 12: page fault while in kernel mode
>> > cpuid = 0; apic id = 00
>> > fault virtual address= 0xfffe665c
>> > fault code= supervisor write data, protection violation
>> > instruction pointer= 0x20:0x82282db3
>> > stack pointer= 0x0:0xfe004c74c8c8
>> > frame pointer= 0x0:0xfe004c74c980
>> > code segment= base 0x0, limit 0xf, type 0x1b
>> > = DPL 0, pres 1, long 1, def32 0, gran 1
>> > processor eflags= interrupt enabled, resume, IOPL = 0
>> > current process= 1579 (wcgrid_zika_vina_7.)
>> > trap number= 12
>> > panic: page fault
>> > cpuid = 0
>> > time = 1533327428
>> > KDB: stack backtrace:
>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> > 0xfe004c74c580
>> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
>> > panic() at panic+0x43/frame 0xfe004c74c640
>> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
>> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
>> > trap() at trap+0x2ba/frame 0xfe004c74c7f0
>> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
>> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
>> > 0xfe004c74c980 ---
>> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
>> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
>> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
>> > Uptime: 7m29s
>> > Dumping 411 out of 8056
>> > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
>> > Dump complete
>> > ___
>> > 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: Linux process causes kernel panic

[Oliver Pinter]

Hi!

On 8/3/18, Johannes Lundberg  wrote:
> Hi
>
> After install new kernel+world built from today's checkout I keep getting
> the same crash over and over. Never had this problem before. The previous
> kernel was from 3 weeks ago.
>
> Looks familiar to anyone?

Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP support?

>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address= 0xfffe665c
> fault code= supervisor write data, protection violation
> instruction pointer= 0x20:0x82282db3
> stack pointer= 0x0:0xfe004c74c8c8
> frame pointer= 0x0:0xfe004c74c980
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process= 1579 (wcgrid_zika_vina_7.)
> trap number= 12
> panic: page fault
> cpuid = 0
> time = 1533327428
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe004c74c580
> vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> panic() at panic+0x43/frame 0xfe004c74c640
> trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> trap() at trap+0x2ba/frame 0xfe004c74c7f0
> calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> 0xfe004c74c980 ---
> futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> Uptime: 7m29s
> Dumping 411 out of 8056
> MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> Dump complete
> ___
> 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: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Oliver Pinter]

On Sunday, July 8, 2018, Ian Lepore  wrote:

> On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
> > Hi!
> >
> > Have you or Warner any update on this code?
> >
> > On Thursday, April 12, 2018, Eric McCorkle 
> > wrote:
> >
>
> Are you aware of https://reviews.freebsd.org/D15743 ?
>
> That's my changes to add geli support to loader(8) in an architecture-
> agnostic way, so that "it just works" for all platforms and flavors of
> loader. It has been succesfully tested on armv6/7 (ubldr) and on x86
> using qemu.  The x86 tests cover ufs and zfs, legacy bios and uefi. The
> only variations that aren't tested yet are the uefi flavors, because
> the current rootgen.sh script for assembling test images is still using
> boot1.efi and I don't know enough about efi myself to update the script
> to make it assemble images the new way Warner envisions.
>
>
Not yet, but thanks for the link!


> -- Ian
>
> > >
> > > I'm in the middle of moving to a new apartment right now.  It's
> > > going to
> > > be a bit before I can get to this.
> > >
> > > On 04/11/2018 20:31, Warner Losh wrote:
> > > >
> > > > OK. I've pushed in the main part of it. The additional work I
> > > > have
> > > > shouldn't affect any of this stuff.  I was going to look at what
> > > > part(s)
> > > > of your open reviewed needed to be redone tomorrow and send you
> > > > feedback, but if you wanted to get a start before then, I'm happy
> > > > to
> > > > answer questions. All the rest of my work is going to be
> > > > selecting the
> > > > root partition when we're told to us a specific partition, so
> > > > will be
> > > > very constrained.
> > > >
> > > > Warner
> > > >
> > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle  > > > net
> > > > <mailto:e...@metricspace.net>> wrote:
> > > >
> > > > I think the thing to do at this point is to wait for the
> > > > current
> > > work on
> > > >
> > > >     loader.efi to land, then adapt my patches to apply against
> > > > that work.
> > > >
> > > > On 04/11/2018 15:06, Warner Losh wrote:
> > > > > Still reviewing the code. I'm worried it's too i386
> > > > specific and it
> > > > > conflicts with some work I'm doing. I'll have a list of
> > > > actionable
> > > > > critiques this week.
> > > > >
> > > > > Warner
> > > > >
> > > > > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
> > > > >  > > > <mailto:oliver.pin...@hardenedbsd.org>
> > > > <mailto:oliver.pin...@hardenedbsd.org
> > > > <mailto:oliver.pin...@hardenedbsd.org>>>
> > > > > wrote:
> > > > >
> > > > > Hi!
> > > > >
> > > > > Is there any update regarding the rebase or the
> > > > inclusion to
> > > base
> > > >
> > > > > system?
> > > > > On 3/28/18, Eric McCorkle  > > >  > > e...@metricspace.net>
> > > >
> > > > > <mailto:e...@metricspace.net <mailto:eric@metricspace.n
> > > > et>>>
> > > wrote:
> > > >
> > > > > > I'll do another rebase from head just to be sure
> > > > > >
> > > > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh <
> > > i...@bsdimp.com <mailto:i...@bsdimp.com>
> > > >
> > > > > <mailto:i...@bsdimp.com <mailto:i...@bsdimp.com>>> wrote:
> > > > > >>It's on my list for nexr, finally. I have an
> > > > alternate patch
> > > for
> > > >
> > > > > >>loader.efi
> > > > > >>from ESP, but i don't think it will affect the GELI
> > > > stuff. I
> > > have some
> > > >
> > > > > >>time
> > > > > >>slotted for integration issues though.
> > > > > >>
> > > > > >>I am quite mindful of the freeze dates I  have
> > > > some uefi
> > > boot
> > > >
> > > > > 

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Oliver Pinter]

Hi!

Have you or Warner any update on this code?

On Thursday, April 12, 2018, Eric McCorkle  wrote:

> I'm in the middle of moving to a new apartment right now.  It's going to
> be a bit before I can get to this.
>
> On 04/11/2018 20:31, Warner Losh wrote:
> > OK. I've pushed in the main part of it. The additional work I have
> > shouldn't affect any of this stuff.  I was going to look at what part(s)
> > of your open reviewed needed to be redone tomorrow and send you
> > feedback, but if you wanted to get a start before then, I'm happy to
> > answer questions. All the rest of my work is going to be selecting the
> > root partition when we're told to us a specific partition, so will be
> > very constrained.
> >
> > Warner
> >
> > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle  > <mailto:e...@metricspace.net>> wrote:
> >
> > I think the thing to do at this point is to wait for the current
> work on
> > loader.efi to land, then adapt my patches to apply against that work.
> >
> > On 04/11/2018 15:06, Warner Losh wrote:
> > > Still reviewing the code. I'm worried it's too i386 specific and it
> > > conflicts with some work I'm doing. I'll have a list of actionable
> > > critiques this week.
> > >
> > > Warner
> > >
> > > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
> > >  > <mailto:oliver.pin...@hardenedbsd.org>
> > <mailto:oliver.pin...@hardenedbsd.org
> > <mailto:oliver.pin...@hardenedbsd.org>>>
> > > wrote:
> > >
> > > Hi!
> > >
> > > Is there any update regarding the rebase or the inclusion to
> base
> > > system?
> > > On 3/28/18, Eric McCorkle  e...@metricspace.net>
> > > <mailto:e...@metricspace.net <mailto:e...@metricspace.net>>>
> wrote:
> > > > I'll do another rebase from head just to be sure
> > > >
> > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh <
> i...@bsdimp.com <mailto:i...@bsdimp.com>
> > > <mailto:i...@bsdimp.com <mailto:i...@bsdimp.com>>> wrote:
> > > >>It's on my list for nexr, finally. I have an alternate patch
> for
> > > >>loader.efi
> > > >>from ESP, but i don't think it will affect the GELI stuff. I
> have some
> > > >>time
> > > >>slotted for integration issues though.
> > > >>
> > > >>I am quite mindful of the freeze dates I  have some uefi
> boot
> > > >>loader
> > > >>protocol changes that I need to get in.
> > > >>
> > > >>Warner
> > > >>
> > > >>On Feb 21, 2018 11:18 PM, "Tommi Pernila" <
> tommi.pern...@iki.fi <mailto:tommi.pern...@iki.fi>
> > > <mailto:tommi.pern...@iki.fi <mailto:tommi.pern...@iki.fi>>>
> wrote:
> > > >>
> > > >>> Awesome, thanks for the update and the work that you have
> done!
> > > >>>
> > > >>> Now we just need some more reviewers eyes on the code :)
> > > >>>
> > > >>> Br,
> > > >>>
> > > >>> Tommi
> > > >>>
> > > >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle <
> e...@metricspace.net <mailto:e...@metricspace.net>
> > > <mailto:e...@metricspace.net <mailto:e...@metricspace.net>>>
> > > >>wrote:
> > > >>>
> > > >>>> FYI, I just IFC'ed everything, and the current patches
> > are still
> > > >>fine.
> > > >>>>
> > > >>>> Also, the full GELI + standalone loader has been deployed
> > on one of
> > > >>my
> > > >>>> laptops for some time now.
> > > >>>>
> > > >>>> On 02/21/2018 18:15, Eric McCorkle wrote:
> > > >>>> > The GELI work could be merged at this point, though it
> > won't be
> > > >>usable
> > > >>>> > witho

Re: Ryzen public erratas (and Epyc ?)

[Oliver Pinter]

On Thursday, June 14, 2018, Mike Tancsa  wrote:

> On 6/14/2018 11:03 AM, Konstantin Belousov wrote:
> > I am not sure about only microcode update.  Depending on the BIOS
> > vendor and current BIOS, you may need all three: BIOS update, microcode
> > update using cpucontrol/devcpu-data, and running the script I posted.
> > In the best case, some of this is just redundand.
>
> OK, before and after shows the same microcode rev
>
> CPU: AMD EPYC 7281 16-Core Processor (2100.06-MHz
> K8-class CPU)
>   Origin="AuthenticAMD"  Id=0x800f12  Family=0x17  Model=0x1  Stepping=2
>
> Features=0x178bfbff APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
>
> Features2=0x7ed8320b SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
>   AMD Features=0x2e500800
>   AMD
> Features2=0x35c233ff Prefetch,OSVW,SKINIT,WDT,TCE,Topology,PCXC,PNXC,DBE,PL2I,MWAITX>
>   Structured Extended
> Features=0x209c01a9 ADX,SMAP,CLFLUSHOPT,SHA>
>   XSAVE Features=0xf
>   AMD Extended Feature Extensions ID EBX=0x1007
>   SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>   TSC: P-state invariant, performance statistics
>
>  # x86info -a | grep -i micro
> Microcode patch level: 0x8001227
>  #
>
> I then ran the fix script.  I will let the box grind away over the
> weekend to see if it survives. Previously, a couple of hours would lock
> it up. I am running it now.  One thing I did notice is a bunch of these
> showing up
>
> Jun 14 17:11:18 r11epyc kernel: fpudna: fpcurthread == curthread


This is a side effect of enabled eager FPU switch, it's orthogonal and
already fixed - the printf has been removed - in current.


>
>
> ---Mike
>
> --
> ---
> Mike Tancsa, tel +1 519 651 3400 x203
> Sentex Communications, m...@sentex.net
> Providing Internet services since 1994 www.sentex.net
> Cambridge, Ontario Canada
> ___
> 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: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

On Friday, June 1, 2018, Pete Wright  wrote:

>
>
> On 05/31/2018 15:34, Oliver Pinter wrote:
>
>> On Thursday, May 31, 2018, Johannes Lundberg  wrote:
>>
>> On Thu, May 31, 2018 at 4:34 PM Joe Maloney 
>>> wrote:
>>>
>>> I personally wish that more drivers, and firmware were separated from
>>>> base.
>>>>
>>>>
>>>> I'm not a committer
>>>
>>
>>
>>> If you are not a committer,  how and why want to remove drm2 from the
>> base
>> system?
>>
> Johannes did not start this threat.  A committer, Niclas Zeising, did.
> Johannes has stepped up and done a ton of work (along with many others,
> some committers and some not) to get modern intel and amd GPU's working
> under freebsd.


>
True. Yes I agree that their work is hard and it's a very big step forward
for supporting modern hardwares. And it's required modern desktops, but
please don't break the existing ones. This is my only request, probably it
was expressed in a harsh way, sorry.



>
>
> this was something that was a gaping hole in freebsd when this work
> started a bit over a year ago, and i'm not sure why more committers weren't
> embarrassed by this gap nor motivated to chip in.
>
> regardless - not sure why you'd take his comment out of context :/ the
> full quote was:
> "I'm not a committer but as I understand there's not pre-commit
> integration tests.. If one had that, plus that it would test build kmod
> ports against the pre-commit state of head as well, then maybe this would
> work."
>
> not really sure what's controversial about that statement which would
> prompt your reply - but i guess people dedicating their spare time to help
> create useful things for others shouldn't go unpunished.
>
> well i guess i broke my promise to ignore this bikeshed :(
>
> -p
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
>
___
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: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

On Thursday, May 31, 2018, Johannes Lundberg  wrote:

> On Thu, May 31, 2018 at 4:34 PM Joe Maloney 
> wrote:
>
> > I personally wish that more drivers, and firmware were separated from
> > base.
> >
> >
> I'm not a committer


>
>
If you are not a committer,  how and why want to remove drm2 from the base
system?

>From other side, how you want to maintain VM and other KPI changes in
unmaintained and abandoned port? ;) Or how you can guarantee to everyone
who breaks KPI to follow these breaks in an external abandoned port?


>
> but as I understand there's not pre-commit integration
> tests.. If one had that, plus that it would test build kmod ports against
> the pre-commit state of head as well, then maybe this would work.
>
>
> > For example wireless firmware:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
> >
> > That was a ticket which I chimed in on about a firmware I needed to make
> > my wireless adapter work.  I went through numerous efforts on IRC, and
> > elsewhere to try to bring attention that ticket in order to attempt to
> get
> > that firmware backported for several 10.x releases in a row without
> > success.  The firmware worked perfectly fine in PC-BSD where it was
> cherry
> > picked for numerous 10.x releases.
> >
> > Technically since I was using PC-BSD, and was a committer for that
> project
> > I had no real dire need to reach out to FreeBSD about the issue.  I was
> > simply trying to help anyone else who might be encountering the same
> issue
> > trying to use stock FreeBSD because it was a simple backport.  If my
> effort
> > had turned out to be more fruitful I would have spent more time pursuing
> > tickets, diffs, or whatever to get more things back-ported when I found
> > them.  I am not sure where the breakdown was which did not allow that to
> > happen.  Anyways I don't want to bikeshed, or anything but I just wanted
> to
> > point out how I think having more drivers, and firmware in ports could be
> > helpful to enhance compatibility for end users.
> >
> > Having a separate port for legacy drm could definitely make things easier
> > to providing installation options for end users, and automating the post
> > install action chosen in TrueOS, GhostBSD, and future derivative projects
> > tailored for the desktop use case.  For example for TrueOS we boot the
> > installer in failsafe mode with either VESA, or SCFB depending on whether
> > or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
> > legacy intel, or skylake + to install the correct package then the module
> > path for either driver can more or less remain the same.  Eventually with
> > something like devmatch maybe that can even be fully automatic.
> >
> > Joe Maloney
> >
> > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen 
> > wrote:
> >
> >> On Thu, 31 May 2018, Konstantin Belousov wrote:
> >>
> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
> >>>
> >>> We're not replacing anything. We are moving the older drm1 and drm2
> from
>  kernel to ports to make it easier for the majority of the users to
> load
>  the
>  correct driver without conflicts.
> 
> >>>
> >>> You do understand that you increase your maintainence load by this
> move.
> >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in
> stable
> >>> branches, so you will need to chase these updates.
> >>>
> >>
> >> I agree.  One argument previously made was that it's easier
> >> to maintain in ports.  One data point from me - I rarely
> >> update my ports, I update my OS much more frequently.  In
> >> fact, some times my ports get so out of date I just
> >> (take off and) nuke /usr/local (from orbit, it's the only
> >> way to be sure).
> >>
> >> Also, are we trying to solve a problem by moving drm[2] to
> >> ports that won't be a problem when base is pkg'ized?  If
> >> drm[2] is a package unto itself, then you don't have this
> >> problem of ports conflicting with it, at least not so
> >> much.  You can either not install the base drm[2] package
> >> or deinstall it to make way for a conflicting port.  Once
> >> drm[2] is pkg rm'd, it's not going to be reinstalled
> >> again when you update the base OS.
> >>
> >> And don't we have the same problem with sendmail and a
> >> few other base services?
> >>
> >> --
> >> DE
> >>
> >> ___
> >> 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"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To 

Re: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

On 5/21/18, Oliver Pinter <oliver.pin...@hardenedbsd.org> wrote:
> On 5/21/18, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
>> On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote:
>>>
>>> On 05/21/2018 10:07, Steve Kargl wrote:
>>> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
>>> >> On Sun, 20 May 2018 21:10:28 +0200
>>> >> Oliver Pinter <oliver.pin...@hardenedbsd.org> wrote:
>>> >>
>>> >>>> One of the reasons for the deprecation and removal of the drm2 bits
>>> >>>> is that they prevent us from automatically loading the
>>> >>>> drm-next/stable-kmod kernel modules, since the two collide.
>>> >>>> Regards
>>> >>>
>>> >>> Then it wold be better to resolve this problem, rather then removing
>>> >>> a
>>> >>> working solution. What's about module versioning what in other cases
>>> >>> works?
>>> >>>
>>> >> May be just move old drm2 to ports?
>>> > Why?  "If it isn't broken, why fix it?"
>>> >
>>> > The conflict affects x86_64-*-freebsd aka amd64.  The
>>> > conflict does not affect any other architecture.  The
>>> > Makefile infrastructure can use MACHINE_ARCH to exclude
>>> > drm2 from build of amd64.
>>> >
>>> > I don't use netgraph or any of the if_*.ko modules.
>>> > Can we put all of that into ports?  I don't use any
>>> > scsi controllers, so those can go too.  Why make it
>>> > insanely fun for users to configure a FreeBSD system.
>>> to play devils advocate - why include a kernel module that causes
>>> conflicts for a vast majority of the laptop devices that you can
>>> purchase today (as well as for the foreseeable future), while forcing
>>> the up to date and actively developed driver to not work out of the box?
>>
>> Poor advocacy.  I stated old drm2 can be excluded by the
>> Makefile infrastructure and I've already provided a barebones
>> patch.
>>
>> Index: sys/modules/Makefile
>> ===
>> --- sys/modules/Makefile(revision 333609)
>> +++ sys/modules/Makefile(working copy)
>> @@ -112,7 +112,9 @@
>> ${_dpms} \
>> ${_dpt} \
>> ${_drm} \
>> +.if ${MACHINE_ARCH} != amd64
>> ${_drm2} \
>> +.endif
>> dummynet \
>> ${_ed} \
>> ${_efirt} \
>
> I prefer something like this:
>
> op@opn src# git diff
> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
> index 195b66daab51..034e2f8126fd 100644
> --- a/sys/amd64/conf/GENERIC
> +++ b/sys/amd64/conf/GENERIC
> @@ -23,6 +23,7 @@ ident GENERIC
>
>  makeoptionsDEBUG=-g# Build kernel with gdb(1) debug
> symbols
>  makeoptionsWITH_CTF=1  # Run ctfconvert(1) for DTrace
> support
> +makeoptionsWITHOUT_MODULES="drm drm2" # by default disable the
> building of DRM* for GENERIC
>
>  optionsSCHED_ULE   # ULE scheduler
>  optionsPREEMPTION  # Enable kernel thread preemption
>

Or make the function in this file smarter:
"./hw/xfree86/os-support/bsd/bsd_kmod.c"

#ifdef HAVE_XORG_CONFIG_H
#include 
#endif

#include 
#include 
#include 
#include 
#include 

#include "xf86_OSproc.h"

/*
 * Load a FreeBSD kernel module.
 * This is used by the DRI/DRM to load a DRM kernel module when
 * the X server starts.  It could be used for other purposes in the future.
 * Input:
 *modName - name of the kernel module (Ex: "tdfx")
 * Return:
 *0 for failure, 1 for success
 */
int
xf86LoadKernelModule(const char *modName)
{
if (kldload(modName) != -1)
return 1;
else
return 0;
}

>
>>
>> Those interested in killing old drm2 on amd64 can add the
>> requisite .if ... .endif to remove obsolscent *.ko.
>>
>>> IMHO it is issues like this (having out of date code that supports some
>>> edge cases) which makes it harder for developers to dog-food the actual
>>> OS they are developing on.
>>
>> You're talking to 1 of the 3 contributors that has tried over
>> the last 2 decades to improve libm (both its quality and
>> conformance to standards).  The development and testing is
>> done on my old i386 laptop (which happily uses drm2), my
>> amd64 systems, and at one time sparc64 (flame.freebsd.org).
>> So, yeah, i386 and sparc64 allowed me to dog-food my code.
>>
>> BTW, there are uncountable many integers.  How about avoiding
>> the conflict by using, say, '3' as in drm3.
>>
>> --
>> 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: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

On 5/21/18, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote:
>>
>> On 05/21/2018 10:07, Steve Kargl wrote:
>> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
>> >> On Sun, 20 May 2018 21:10:28 +0200
>> >> Oliver Pinter <oliver.pin...@hardenedbsd.org> wrote:
>> >>
>> >>>> One of the reasons for the deprecation and removal of the drm2 bits
>> >>>> is that they prevent us from automatically loading the
>> >>>> drm-next/stable-kmod kernel modules, since the two collide.
>> >>>> Regards
>> >>>
>> >>> Then it wold be better to resolve this problem, rather then removing
>> >>> a
>> >>> working solution. What's about module versioning what in other cases
>> >>> works?
>> >>>
>> >> May be just move old drm2 to ports?
>> > Why?  "If it isn't broken, why fix it?"
>> >
>> > The conflict affects x86_64-*-freebsd aka amd64.  The
>> > conflict does not affect any other architecture.  The
>> > Makefile infrastructure can use MACHINE_ARCH to exclude
>> > drm2 from build of amd64.
>> >
>> > I don't use netgraph or any of the if_*.ko modules.
>> > Can we put all of that into ports?  I don't use any
>> > scsi controllers, so those can go too.  Why make it
>> > insanely fun for users to configure a FreeBSD system.
>> to play devils advocate - why include a kernel module that causes
>> conflicts for a vast majority of the laptop devices that you can
>> purchase today (as well as for the foreseeable future), while forcing
>> the up to date and actively developed driver to not work out of the box?
>
> Poor advocacy.  I stated old drm2 can be excluded by the
> Makefile infrastructure and I've already provided a barebones
> patch.
>
> Index: sys/modules/Makefile
> ===
> --- sys/modules/Makefile(revision 333609)
> +++ sys/modules/Makefile(working copy)
> @@ -112,7 +112,9 @@
> ${_dpms} \
> ${_dpt} \
> ${_drm} \
> +.if ${MACHINE_ARCH} != amd64
> ${_drm2} \
> +.endif
> dummynet \
> ${_ed} \
> ${_efirt} \

I prefer something like this:

op@opn src# git diff
diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
index 195b66daab51..034e2f8126fd 100644
--- a/sys/amd64/conf/GENERIC
+++ b/sys/amd64/conf/GENERIC
@@ -23,6 +23,7 @@ ident GENERIC

 makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols
 makeoptionsWITH_CTF=1  # Run ctfconvert(1) for DTrace support
+makeoptionsWITHOUT_MODULES="drm drm2" # by default disable the
building of DRM* for GENERIC

 optionsSCHED_ULE   # ULE scheduler
 optionsPREEMPTION  # Enable kernel thread preemption


>
> Those interested in killing old drm2 on amd64 can add the
> requisite .if ... .endif to remove obsolscent *.ko.
>
>> IMHO it is issues like this (having out of date code that supports some
>> edge cases) which makes it harder for developers to dog-food the actual
>> OS they are developing on.
>
> You're talking to 1 of the 3 contributors that has tried over
> the last 2 decades to improve libm (both its quality and
> conformance to standards).  The development and testing is
> done on my old i386 laptop (which happily uses drm2), my
> amd64 systems, and at one time sparc64 (flame.freebsd.org).
> So, yeah, i386 and sparc64 allowed me to dog-food my code.
>
> BTW, there are uncountable many integers.  How about avoiding
> the conflict by using, say, '3' as in drm3.
>
> --
> 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: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

On Sunday, May 20, 2018, Niclas Zeising  wrote:

> On 05/20/18 18:40, Steve Kargl wrote:
>
>> On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote:
>>
>>> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
>>> s...@troutmask.apl.washington.edu> wrote:
>>>
>>> On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:

> On Fri, May 18, 2018, 20:00 Niclas Zeising 
> wrote:
>
> I propose that we remove the old drm2 driver (sys/dev/drm2) from
>> FreeBSD.  I suggest the driver is marked as deprecated in 11.x and
>> removed from 12.0, as was done for other drivers recently.  Some
>> background and rationale:
>>
>>
> Sounds good ( deprecate resp remove ). It causes more confusion and
> problems and it solves nothing.
>
>
 Check the Makefiles

 % more /usr/ports/graphics/drm-next-kmod/Makefile

 ONLY_FOR_ARCHS= amd64
 ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on
 amd64

 Not to ia32 friendly.


>>> So do people use i386 for desktop? And need the latest KMS stuff?
>>>
>>>
>> Just a data point.  I had to replace the dead disk in my laptop,
>> and after 2 days of doing a re-install and update of -current
>> on a shiny new SSD.
>>
>> Before loading Xorg.
>>
>> % kldstat
>> Id Refs AddressSize Name
>>   17 0x80 1ac31d4  kernel
>>   21 0x1e9ae000 5000 ums.ko
>>   31 0x1e9b9000 4000 uhid.ko
>>
>> After starting Xorg without an xorg.conf in /etc/X11.
>>
>> Id Refs AddressSize Name
>>   1   27 0x80 1ac31d4  kernel
>>   21 0x1e9ae000 5000 ums.ko
>>   31 0x1e9b9000 4000 uhid.ko
>>   41 0x1eaa9000 96000i915kms.ko
>>   51 0x1eb4 4a000drm2.ko
>>   64 0x1eb8b000 5000 iicbus.ko
>>   71 0x1ebc9000 3000 iic.ko
>>   81 0x1ebcf000 4000 iicbb.ko
>>
>> So, drm2.ko and i915kms.ko are loaded automatically.  It is
>> unclear why functionality that works should be removed.
>>
>> xwininfo shows
>>
>>Width: 1400
>>Height: 1050
>>Depth: 24
>>Visual: 0x21
>>
>>
> One of the reasons for the deprecation and removal of the drm2 bits is
> that they prevent us from automatically loading the drm-next/stable-kmod
> kernel modules, since the two collide.
> Regards


Then it wold be better to resolve this problem, rather then removing a
working solution. What's about module versioning what in other cases works?


> --
> Niclas
> ___
> 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: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

On Friday, May 18, 2018, Konstantin Belousov  wrote:

> On Fri, May 18, 2018 at 09:33:40PM +0100, Johannes Lundberg wrote:
> > On Fri, May 18, 2018 at 9:22 PM, Ben Widawsky  wrote:
> >
> > > On 18-05-18 14:15:03, Warner Losh wrote:
> > > > On Fri, May 18, 2018 at 2:12 PM, Johannes Lundberg <
> johal...@gmail.com>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > On Fri, May 18, 2018 at 9:03 PM, Warner Losh 
> wrote:
> > > > >
> > > > >> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> > > > >> s...@troutmask.apl.washington.edu> wrote:
> > > > >>
> > > > >> > On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
> > > > >> > > On Fri, May 18, 2018, 20:00 Niclas Zeising <
> zeis...@freebsd.org>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > > I propose that we remove the old drm2 driver (sys/dev/drm2)
> from
> > > > >> > > > FreeBSD.  I suggest the driver is marked as deprecated in
> 11.x
> > > and
> > > > >> > > > removed from 12.0, as was done for other drivers recently.
> Some
> > > > >> > > > background and rationale:
> > > > >> > > >
> > > > >> > > > The drm2 driver was the original port of a KMS driver to
> > > FreeBSD.
> > > > >> It
> > > > >> > > > was done by Konstantin Belousov to support Intel graphics
> > > cards, and
> > > > >> > > > later extended by Jean-S??bastien P??dron as well as
> Konstantin to
> > > > >> match
> > > > >> > > > what's in Linux 3.8.  This included unstable support from
> > > Haswell,
> > > > >> but
> > > > >> > > > nothing newer than that.
> > > > >> > > >
> > > > >> > > > For quite some time now we have had the
> > > graphics/drm-stable-kmod and
> > > > >> > > > graphics/drm-next-kmods which provides support for modern
> AMD
> > > and
> > > > >> Intel
> > > > >> > > > graphics cards.  These ports, together with the linuxkpi, or
> > > lkpi,
> > > > >> has
> > > > >> > > > made it significantly easier to port and update our graphics
> > > > >> drivers.
> > > > >> > > > Further, these new drivers cover the same drivers as the old
> > > drm2
> > > > >> > driver.
> > > > >> > > >
> > > > >> > > > What does the community think?  Is there anyone still using
> the
> > > drm2
> > > > >> > > > driver on 12-CURRENT?  If so, what is preventing you from
> > > switching
> > > > >> to
> > > > >> > > > the port?
> > > > >> > > >
> > > > >> > > > Thank you
> > > > >> > > > Regards
> > > > >> > > > --
> > > > >> > > > Niclas Zeising
> > > > >> > > > FreeBSD x11/graphics team
> > > > >> > > > ___
> > > > >> > > > freebsd-current@freebsd.org mailing list
> > > > >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > >> > > > To unsubscribe, send any mail to
> "freebsd-current-unsubscribe@
> > > > >> > freebsd.org"
> > > > >> > > >
> > > > >> > >
> > > > >> > > Sounds good ( deprecate resp remove ). It causes more
> confusion
> > > and
> > > > >> > > problems and it solves nothing.
> > > > >> > >
> > > > >> >
> > > > >> > Check the Makefiles
> > > > >> >
> > > > >> > % more /usr/ports/graphics/drm-next-kmod/Makefile
> > > > >> >
> > > > >> > ONLY_FOR_ARCHS= amd64
> > > > >> > ONLY_FOR_ARCHS_REASON=  the new KMS components are only
> supported on
> > > > >> amd64
> > > > >> >
> > > > >> > Not to ia32 friendly.
> > > > >> >
> > > > >>
> > > > >> So do people use i386 for desktop? And need the latest KMS stuff?
> > > > >>
> > > > >
> > > > > Yeah I was wondering the same.. If you're running i386, do you
> need drm
> > > > > drivers? Will scfb work an i386? (probably has legacy bios and if I
> > > > > remember correctly, scfb is UEFI only)
> > > > > I do feel sorry for anyone who would have to revert back to VESA...
> > > > >
> > > > > Would it be too much trouble to move it to a port?
> > > > >
> > > >
> > > > If there's someone who needs it for i386, and wants to do the work
> and
> > > > maintain it, we should allow it. But the drm2 maintainers have said
> its
> > > > likely totally broken anyway.
> > > >
> > > > Warner
> > >
> > > As a long time developer in drm/i915, and newly interested in FreeBSD
> (ie.
> > > no
> > > history on the matter), is there some upside and/or desire to have
> native
> > > support, or is the drm-next-kmod solution good enough?
> > >
> >
> > Given the fast evolution of graphics hardware and the amount of code in
> > only the AMD and Intel drivers, keep several native implementations seems
> > impossible, if not wasteful.
> > If you are referring to drm2 in the kernel, that's not much more native
> > than the drm kmods, it still uses a linux compatibility layer (but not as
> > sophisticated).
> Drm2 does not use linux compat layer.
>
> drm2 is probably better on older chipsets which use AGP emulation, i.e.
> everything up to SandyBridge-1. Does drm-next run on gen3 and gen4 at
> all ? In particular, I did obtained real bug reports from people running
> gen 3 hardware. E.g. you cannot run amd64 kernel on T60, but you can run
> i386 

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Oliver Pinter]

Hi!

Is there any update regarding the rebase or the inclusion to base system?
On 3/28/18, Eric McCorkle  wrote:
> I'll do another rebase from head just to be sure
>
> On March 28, 2018 3:23:23 PM EDT, Warner Losh  wrote:
>>It's on my list for nexr, finally. I have an alternate patch for
>>loader.efi
>>from ESP, but i don't think it will affect the GELI stuff. I have some
>>time
>>slotted for integration issues though.
>>
>>I am quite mindful of the freeze dates I  have some uefi boot
>>loader
>>protocol changes that I need to get in.
>>
>>Warner
>>
>>On Feb 21, 2018 11:18 PM, "Tommi Pernila"  wrote:
>>
>>> Awesome, thanks for the update and the work that you have done!
>>>
>>> Now we just need some more reviewers eyes on the code :)
>>>
>>> Br,
>>>
>>> Tommi
>>>
>>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle 
>>wrote:
>>>
 FYI, I just IFC'ed everything, and the current patches are still
>>fine.

 Also, the full GELI + standalone loader has been deployed on one of
>>my
 laptops for some time now.

 On 02/21/2018 18:15, Eric McCorkle wrote:
 > The GELI work could be merged at this point, though it won't be
>>usable
 > without an additional patch to enable loader-only operation.  The
 > patches are currently up for review:
 >
 > This is the order in which they'd need to be merged:
 >
 >
 > https://reviews.freebsd.org/D12732
 >
 > This one changes the efipart device.  Toomas Soome identified some
 > problems, which I have addressed.  He has not re-reviewed it,
>>however.
 >
 >
 > https://reviews.freebsd.org/D12692
 >
 > This adds some crypto code needed for GELI.  It simply adds new
>>code,
 > and doesn't conflict with anything.
 >
 >
 > https://reviews.freebsd.org/D12698
 >
 > This adds the EFI KMS interface code, and has the EFI loader pass
>>keys
 > into the keybuf interface.
 >
 >
 > I can't post the main GELI driver until those get merged, as it
>>depends
 > on them.  It can be found on the geli branch on my github freebsd
 > repository, however.
 >
 >
 > Additionally, you need this patch, which allows loader.efi to
>>function
 > when installed directly to the ESP:
 >
 > https://reviews.freebsd.org/D13497
 >
 > On 02/20/2018 22:56, Tommi Pernila wrote:
 >> Hi Eric,
 >>
 >> could you provide a brief update how the work is going?
 >>
 >>
 >> Br,
 >>
 >> Tommi
 >>
 >>
 >> On Nov 16, 2017 04:29, "Eric McCorkle" > > wrote:
 >>
 >> Right, so basically, the remaining GELI patches are against
 loader, and
 >> most of them can go in independently of the work on removing
>>boot1.
 >> There's a unanimous consensus on getting rid of boot1 which
 includes its
 >> original author, so that's going to happen.
 >>
 >>
 >> For GELI, we have the following (not necessarily in order):
 >>
 >> a) Adding the KMS interfaces, pseudo-device, and kernel
>>keybuf
 >> interactions
 >> b) Modifications to the efipart driver
 >> c) boot crypto
 >> d) GELI partition types (not strictly necessary)
 >>
 >> Then there's the GELI driver itself.  (a) and (c) are good to
 land, (b)
 >> needs some more work after Toomas Soome pointed out a
>>legitimate
 >> problem, and (d) actually needs a good bit more code (but
>>again,
 it's
 >> more cosmetic).  Additionally, the GELI driver will need
>>further
 mods to
 >> efipart to be written (nothing too big).  But we could go
>>ahead
 with (a)
 >> and (c), as they've already been proven to work.
 >>
 >> I'd wanted to have this stuff shaped up sooner, but I'm
 preoccupied with
 >> the 7th RISC-V workshop at the end of the month.
 >>
 >> Once this stuff is all in, loader should handle any GELI
>>volumes it
 >> finds, and it should Just Work once boot1 is gone.
 >>
 >>
 > ___
 > freebsd-current@freebsd.org mailing list
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current
 > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
 freebsd.org"
 >

>>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> 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 

Re: LLD: man pages missing?

[Oliver Pinter]

On Monday, December 25, 2017, Dimitry Andric  wrote:

> On 25 Dec 2017, at 21:16, O. Hartmann  wrote:
> >
> > I have installed most recent CURRENT as of r327219 with LLD_IS_LD=YES set
> > via /etc/src.conf.
> >
> > I try to find some options and tried "man ld", "man lld" and "ld.lld".
> In the the latter
> > two cases there can nothing be found on the system and man ld always
> seems to refer to
> > the GNU linker - which is, I believe, the linker reached by
> /usr/bin/ld.bfd. There is
> > also a linker "ld" in /usr/local/bin/ld from binutils-2.28,1.
>
> There is no manpage yet.  Upstream provides a bit of Sphinx-based
> documentation (e.g. in .rst format), but there is no specific manpage.
>
> Since lld is now approaching a quite usable state, maybe it is time for
> a request to upstream to provide one. ;)


The same would be nice for clang too. Its default man page is poor.


>
> -Dimitry
>
>
___
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: UEFI booting survey

[Oliver Pinter]

On Tuesday, December 19, 2017, Warner Losh  wrote:

> On Dec 18, 2017 6:06 PM, "Rodney W. Grimes" <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
>
> > On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard 
> wrote:
> >
> > > Warner Losh imp at bsdimp.com wrote on
> > > Mon Dec 18 20:29:45 UTC 2017 :
> > >
> > > > The specific thing we will stop doing is that in the absence of
> > > > instructions to the contrary, we will no longer search for root on a
> > > device
> > > > other than the one the loader.efi came from.
> > >
> > > Warner Losh imp at bsdimp.com wrote on
> > > Sun Dec 17 19:52:07 UTC 2017 :
> > >
> > > > In the coming months, we're looking at dropping boot1.efi and instead
> > > > installing /boot/loader.efi onto the ESP (most likely as
> > > > \efi\freebsd\loader.efi).
> > >
> > >
> > > Combining the two statements would appear to have consequences
> > > not obvious from the separate statements in isolation. Rewording
> > > the first to substitute where loader.efi comes from based on
> > > the second (if I interpret right):
> > >
> > > MISQUOTE
> > > The specific thing we will stop doing is that in the absence of
> > > instructions to the contrary, we will no longer search for root
> > > on other than the device for the ESP used (which will hold
> > > loader.efi).
> > > END MISQUOTE
> > >
> >
> > The specific thing we will stop doing is that in the absence of
> > instructions to the contrary, we will no longer search for root on other
> > than the device for the ESP used (which will hold now loader.efi as
> > boot1.efi will shortly be eliminated).
>
> Yes please, that is the correct behavior, our searching can lead to
> problems, and as you have pointed out, often more problems than it
> ever really fixed.
>
> >
> > Or the following pseudo-code with all the weird special cases removed for
> > clarity
> >
> > load loader.efi from ESP
> > if Boot uefi variable holds a second path, use that for root/kernel
> > otherwise if an override variable holds a kernel/root path, use that
> > otherwise scan for a usable ZFS pool, use that if it exists
> > otherwise use the same partition loader.efi was booted from for
> root/kernel
> > if it's usable
> > otherwise use the first UFS partition on the ESP that's usable.
>
> use the ACTIVE ufs partition, not the first, I can have more than 1 slice,
> only 1 of them can be set active.  Do not use any ufs partitions if they
> are not in active slices, it is possible to have 0 partitions set active.
>
>
> Active is not a GPT concept. UEFI makes it hard to implement since there is
> no good API to get and set the flags FreeBSD's gptboot uses to hack this
> concept in. Active is done via BootOrder UEFI variable. Loader.efi and
> boot.efi completely ignore this today. I have no plans on changing that.


And what's about the bootme and bootonce flags in gpart?  They are
freebsdism? Or they are the equivalent of active in the UEFI standard?


>
> >
> > A partition is usable if /boot/loader.rc exists on that path.
>
> A partition is usable if it is in an active slice, and ^above
>
>
> Active isn't a got thong. So no.
>
> Is there any fallback to skip loader and go direct to
> /boot/kernel/kernel, back to /kernel any more?
>
>
> You are thinking about this wrong. We are loader.efi, not boot2. This is
> one of the big advantages of loading directly. We don't have the space
> limitations that forced that design, so we should simplify.
>
> Warner
>
> > What is being deleted is one final step: "otherwise use the first UFS
> > partition on any drive in a random order that's usable." which used to be
> > at the end of the boot1.efi psuedo code. It's my belief that no such
> > installations actually use this due to the random factor today (plug in a
> > new USB drive and it might take over). If my belief is wrong, it's my
> > belief that efibootmgr will solve it, and failing that, the fallback
> > mechanism (for platforms that use u-boot + EFI where UEFI variables don't
> > work) will allow the two or three people that are doing this today.
> >
> > 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"
>
> --
> 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"
>
___
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: cve-2017-13077 - WPA2 security vulni

[Oliver Pinter]

Hi Adrian!

How big effort is to update he in-tree wpa_supplicant/hostapd to the
latest supported version?
Is there any known regression / feature loss when do the upgrade?

On 10/16/17, Adrian Chadd  wrote:
> Right, there are backported patches against 2.6, but we're running 2.5
> in contrib/ .
>
> This is all "I'm out of time right now", so if someone wants to do the
> ports work and/or the contrib work with the patches for this vuln then
> please do. I should be able to get to it in the next few days but I'm
> busy with family and employment.
>
>
>
> -adrian
>
>
> On 16 October 2017 at 10:19, Kevin Oberman  wrote:
>> On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd 
>> wrote:
>>>
>>> hi,
>>>
>>> I got the patches a couple days ago. I've been busy with personal life
>>> stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If
>>> someone beats me to it, great, otherwise I'll try to do it in the next
>>> couple days.
>>>
>>> I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update
>>> everything to but so far nope. It should be easy enough to update the
>>> port for now as it's at 2.6.
>>>
>>>
>>>
>>> -adrian
>>>
>>>
>>> On 16 October 2017 at 06:04, Cy Schubert 
>>> wrote:
>>> > In message <44161b4d-f834-a01d-6ddb-475f20876...@freebsd.org>, Lev
>>> > Serebryakov
>>> > writes:
>>> >> On 16.10.2017 13:38, blubee blubeeme wrote:
>>> >>
>>> >> > well, that's a cluster if I ever seen one.
>>> >>  It is really cluster: CVE-2017-13077, CVE-2017-13078,
>>> >> CVE-2017-13079,
>>> >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084,
>>> >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088.
>>> >
>>> > The gory details are here:
>>> > https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt
>>> >
>>> > The announcement is here:
>>> > https://www.krackattacks.com/
>>> >
>>> >
>>> > --
>>> > Cheers,
>>> > Cy Schubert 
>>> > FreeBSD UNIX:     Web:  http://www.FreeBSD.org
>>> >
>>> > The need of the many outweighs the greed of the few.
>>> >
>>
>>
>> While I do not encourage waiting, it is quite likely that the upstream
>> patch
>> wil show up very soon now that the vulnerability is public.
>>
>> It's also worth noting that fixing either end of the connection is all
>> that
>> is required, as I understand it. So getting an update for your AP is not
>> required. That is very fortunate as the industry has a rather poor record
>> of
>> getting out firmware updates for hardware more than a few months old.
>> Also,
>> it appears that Windows and iOS are not vulnerable due to flaws in their
>> implementation of the WPA2 spec. (Of course, if you update your AP(s),
>> you
>> no longer need to worry about your end devices.
>> --
>> Kevin Oberman, Part time kid herder and retired Network Engineer
>> E-mail: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> 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: ZFS ABD Panic

[Oliver Pinter]

On Monday, June 26, 2017, Shawn Webb  wrote:

> This is on the latest HardenedBSD 12-CURRENT on one of my servers:
>
> [141] panic: sleepq_add: td 0xf80008d20560 to sleep on wchan
> 0xf803b7d4e810 with sleeping prohibited
> [141] cpuid = 5
> [141] time = 1498436043
> [141] KDB: stack backtrace:
> [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe2fc8b0
> [141] vpanic() at vpanic+0x19c/frame 0xfe2fc930
> [141] kassert_panic() at kassert_panic+0x126/frame 0xfe2fc9a0
> [141] sleepq_add() at sleepq_add+0x34f/frame 0xfe2fc9f0
> [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfe2fcaa0
> [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfe2fcae0
> [141] refcount_remove_many() at refcount_remove_many+0x2a/frame
> 0xfe2fcb20
> [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfe2fcb50
> [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame
> 0xfe2fcb70
> [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfe2fcba0
> [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfe2fcbb0
> [141] fork_exit() at fork_exit+0x84/frame 0xfe2fcbf0
> [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfe2fcbf0
>
>   pool: rpool
>  state: ONLINE
>   scan: none requested
> config:
>
> NAME STATE READ WRITE CKSUM
> rpoolONLINE   0 0 0
>   mirror-0   ONLINE   0 0 0
> mfid0p3  ONLINE   0 0 0
> mfid1p3  ONLINE   0 0 0
>   mirror-1   ONLINE   0 0 0
> mfid2ONLINE   0 0 0
> mfid3ONLINE   0 0 0
>
> errors: No known data errors


What's the corresponding git note?



>
> 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: Please test EARLY_AP_STARTUP

[Oliver Pinter]

On 11/25/16, John Baldwin  wrote:
> I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD.  Some folks
> have been testing it for the last week or so which has exposed some
> additional things to fix.  I think I've resolved most of those in one
> way or another, but it will make things smoother if other folks can
> start testing this over the next few days before it is enabled by default.
>
> (To enable, add 'options EARLY_AP_STARTUP' to your kernel config.)

Working fine with HardenedBSD's HARDENEDBSD kernel config + EARLY_AP_STARTUP
(it's a FreeBSD's GENERIC + some additional HardenedBSD specific
stuff) on Gigabyte GA-87N-Wifi board + i5-4670 + 3x HDD + Ati VGA.

>
> Note that non-x86 platforms should eventually adopt this, but I don't
> think any of them are ready yet.
>
> --
> John Baldwin
> ___
> 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: WLAN hardware not recognized

[Oliver Pinter]

On 3/1/16, Carsten Kunze  wrote:
> Conrad Meyer  wrote:
>
>> "[1] iwn0:  mem 0xf7b0-0xf7b01fff
>> irq 18 at device 0.0 on pci3" is fine; "module iwn already present!"
>> is fine.
>>
>> What makes you say it isn't recognized or doesn't work?
>
> ifconfig iwn0  says "interface iwn0 does not exist".  Also starting
> wpa_supplicant doesn't work (I use a wpa setup that did work on my previous
> laptop on FreeBSD 10).

The wireless subsystem changed a lot since 10-STABLE, and there are no
more iwn interfaces shown via ifconfig.

You could query them as Adrian mentioned.

If you successfully upgraded your base system _too_ and not just the
kernel, then you should put a similar lines into rc.conf:

wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP country HU -wme -powersave"

And you should put the relevant firmware module's loading request into
/boot/loader.conf, this was mentioned in one mail before.




>
> At install time I only "configured" ethernet, iwn0 I skipped since I
> intented to configure that later.  But that may not be relevant.
> ___
> 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: Broken suspend-resume (suspend to RAM) with enabled INVARIANTS on 11-CURRENT - with workaround

[Oliver Pinter]

On 2/6/16, Konstantin Belousov <kostik...@gmail.com> wrote:
> On Fri, Feb 05, 2016 at 07:34:02PM +0100, Oliver Pinter wrote:
>> Not yet tested, but possible fix:
>>
>> diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c
>> index cb952da..25bae84 100644
>> --- a/sys/kern/init_main.c
>> +++ b/sys/kern/init_main.c
>> @@ -482,7 +482,7 @@ proc0_init(void *dummy __unused)
>> session0.s_leader = p;
>>
>> p->p_sysent = _sysvec;
>> -   p->p_flag = P_SYSTEM | P_INMEM;
>> +   p->p_flag = P_SYSTEM | P_INMEM | P_KTHREAD;
>> p->p_flag2 = 0;
>> p->p_state = PRS_NORMAL;
> So did you tested this ?  Did you do an audit to see whether P_KTHREAD
> other usages possibly conflict with the proc0 specifics ?

Tested and working as expected.
Other uses would not conflict, since the codes already checks for
P_SYSTEM and the P_KTHREAD flag is almost kern_kthread.c's "private"
flag.

And this change probably fixes one issue with hwpmc too, in the kernel case:

--
dev/hwpmc/hwpmc_mod.c-
dev/hwpmc/hwpmc_mod.c-  /* issue an attach event to a configured log file */
dev/hwpmc/hwpmc_mod.c-  if (pm->pm_owner->po_flags & PMC_PO_OWNS_LOGFILE) {
dev/hwpmc/hwpmc_mod.c:  if (p->p_flag & P_KTHREAD) {
dev/hwpmc/hwpmc_mod.c-  fullpath = kernelname;
dev/hwpmc/hwpmc_mod.c-  freepath = NULL;
dev/hwpmc/hwpmc_mod.c-  } else {
dev/hwpmc/hwpmc_mod.c-  pmc_getfilename(p->p_textvp,
, );
dev/hwpmc/hwpmc_mod.c-  pmclog_process_pmcattach(pm,
p->p_pid, fullpath);
dev/hwpmc/hwpmc_mod.c-  }


If you want to commit this change, then please add this line: "This
work was sponsored by HardenedBSD."

>
>>  #ifdef PAX
>
___
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: Broken suspend-resume (suspend to RAM) with enabled INVARIANTS on 11-CURRENT - with workaround

[Oliver Pinter]

On 2/5/16, Oliver Pinter <oliver.pin...@hardenedbsd.org> wrote:
> Hi all!
>
> I used this gdb macro, to traverse the proc list, and print out the
> relevant p_flag's flags:
>
> set $curr_proc=0
> def next_proc
> if $curr_proc == 0
> set $curr_proc = allproc.lh_first
> else
> set $curr_proc = $curr_proc.p_list.le_next
> end
> set $curr_p_flag = $curr_proc->p_flag
> set $curr_name = $curr_proc->p_comm
> p $curr_name
> p/x $curr_p_flag
> if ($curr_p_flag & 0x4) != 0
> printf "is P_KTHREAD\n"
> else
> printf "isn't P_KTHREAD\n"
> end
> if ($curr_p_flag & 0x00200) != 0
> printf "is P_SYSTEM\n"
> else
> printf "isn't P_SYSTEM\n"
> end
> end
>
> And seems like the "kernel" process don't have the P_KTHREAD flag,
> which fires the KASSERT in sys/kern/kern_proc.c's stop_all_proc(void)
> function.
>
> The relevant part of the code is:
> 2986 void
> 2987 stop_all_proc(void)
> 2988 {
> 2989 struct proc *cp, *p;
> 2990 int r, gen;
> 2991 bool restart, seen_stopped, seen_exiting, stopped_some;
> 2992
> 2993 cp = curproc;
> 2994 /*
> 2995  * stop_all_proc() assumes that all process which have
> 2996  * usermode must be stopped, except current process, for
> 2997  * obvious reasons.  Since other threads in the process
> 2998  * establishing global stop could unstop something, disable
> 2999  * calls from multithreaded processes as precaution.  The
> 3000  * service must not be user-callable anyway.
> 3001  */
> *3002 KASSERT((cp->p_flag & P_HADTHREADS) == 0 ||
> *3003 (cp->p_flag & P_KTHREAD) != 0, ("mt stop_all_proc"));
> 3004
> 3005 allproc_loop:
>
> If I comment out this KASSERT or just whitelist the "kernel" process,
> then I get a completely working suspend to ram and resume on my laptop
> (which is a HP 430G1) with one additional small tweak
> (hw.acpi.reset_video=1).
>
> So the question is that the KASSERT is bogus or too strict, or the
> P_KTHREAD flags is missing from "kernel" process?
>
> The gdb macros output is:
> [...]
> (kgdb)
> $139 = 0xf800029773c8 "rand_harvestq"
> $140 = 0x1204
> is P_KTHREAD
> is P_SYSTEM
> (kgdb)
> $141 = 0xf80002977940 "init"
> $142 = 0x10004200
> isn't P_KTHREAD
> is P_SYSTEM
> (kgdb)
> $143 = 0xf800029783c8 "audit"
> $144 = 0x1204
> is P_KTHREAD
> is P_SYSTEM
> (kgdb)
> $145 = 0x80f1b4d0 "kernel"
> $146 = 0x1280
> isn't P_KTHREAD
> is P_SYSTEM
>
> I've CC-ed Konstantin to this discussion, because he added this
> functionality to the kernel.
>
> Additional info:
> If I try to trigger the KASSERT with the debug.stop_all_proc=1 sysctl,
> then it's never fires, but when I try to put my machine to S3 with
> ctrl+alt+space then it fires.
>

Not yet tested, but possible fix:

diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c
index cb952da..25bae84 100644
--- a/sys/kern/init_main.c
+++ b/sys/kern/init_main.c
@@ -482,7 +482,7 @@ proc0_init(void *dummy __unused)
session0.s_leader = p;

p->p_sysent = _sysvec;
-   p->p_flag = P_SYSTEM | P_INMEM;
+   p->p_flag = P_SYSTEM | P_INMEM | P_KTHREAD;
p->p_flag2 = 0;
p->p_state = PRS_NORMAL;
 #ifdef PAX
___
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"

Broken suspend-resume (suspend to RAM) with enabled INVARIANTS on 11-CURRENT - with workaround

[Oliver Pinter]

Hi all!

I used this gdb macro, to traverse the proc list, and print out the
relevant p_flag's flags:

set $curr_proc=0
def next_proc
if $curr_proc == 0
set $curr_proc = allproc.lh_first
else
set $curr_proc = $curr_proc.p_list.le_next
end
set $curr_p_flag = $curr_proc->p_flag
set $curr_name = $curr_proc->p_comm
p $curr_name
p/x $curr_p_flag
if ($curr_p_flag & 0x4) != 0
printf "is P_KTHREAD\n"
else
printf "isn't P_KTHREAD\n"
end
if ($curr_p_flag & 0x00200) != 0
printf "is P_SYSTEM\n"
else
printf "isn't P_SYSTEM\n"
end
end

And seems like the "kernel" process don't have the P_KTHREAD flag,
which fires the KASSERT in sys/kern/kern_proc.c's stop_all_proc(void)
function.

The relevant part of the code is:
2986 void
2987 stop_all_proc(void)
2988 {
2989 struct proc *cp, *p;
2990 int r, gen;
2991 bool restart, seen_stopped, seen_exiting, stopped_some;
2992
2993 cp = curproc;
2994 /*
2995  * stop_all_proc() assumes that all process which have
2996  * usermode must be stopped, except current process, for
2997  * obvious reasons.  Since other threads in the process
2998  * establishing global stop could unstop something, disable
2999  * calls from multithreaded processes as precaution.  The
3000  * service must not be user-callable anyway.
3001  */
*3002 KASSERT((cp->p_flag & P_HADTHREADS) == 0 ||
*3003 (cp->p_flag & P_KTHREAD) != 0, ("mt stop_all_proc"));
3004
3005 allproc_loop:

If I comment out this KASSERT or just whitelist the "kernel" process,
then I get a completely working suspend to ram and resume on my laptop
(which is a HP 430G1) with one additional small tweak
(hw.acpi.reset_video=1).

So the question is that the KASSERT is bogus or too strict, or the
P_KTHREAD flags is missing from "kernel" process?

The gdb macros output is:
[...]
(kgdb)
$139 = 0xf800029773c8 "rand_harvestq"
$140 = 0x1204
is P_KTHREAD
is P_SYSTEM
(kgdb)
$141 = 0xf80002977940 "init"
$142 = 0x10004200
isn't P_KTHREAD
is P_SYSTEM
(kgdb)
$143 = 0xf800029783c8 "audit"
$144 = 0x1204
is P_KTHREAD
is P_SYSTEM
(kgdb)
$145 = 0x80f1b4d0 "kernel"
$146 = 0x1280
isn't P_KTHREAD
is P_SYSTEM

I've CC-ed Konstantin to this discussion, because he added this
functionality to the kernel.

Additional info:
If I try to trigger the KASSERT with the debug.stop_all_proc=1 sysctl,
then it's never fires, but when I try to put my machine to S3 with
ctrl+alt+space then it fires.
___
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: Hot-Plug PCIe Support

[Oliver Pinter]

On 1/26/16, Eric van Gyzen  wrote:
> FreeBSD Folks:
>
> I am currently scoping the effort to add hot-plug PCIe support to
> FreeBSD.  Is anyone else currently working on this or aware of any
> design, code, or other effort available outside the tree?
>
> FYI, here are perhaps the most interesting references I could find:
>
> https://wiki.freebsd.org/PCIHotplug
>
> https://wiki.freebsd.org/IdeasPage#Implementing_PCI-Hotplug_and_ExpressCard_support
>
> https://lists.freebsd.org/pipermail/freebsd-current/2015-April/055290.html
>
> https://lists.freebsd.org/pipermail/freebsd-ia32/2010-February/date.html
>
> Please reply on freebsd-hack...@freebsd.org to minimize cross-posting.
>
> Thanks in advance.

Hi!

Added John-Mark to the CC, if I'm not wrong, I stared to play with them.

>
> Eric
> ___
> 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: Need help with New Build -- Skylake

[Oliver Pinter]

On 12/24/15, Konstantin Belousov  wrote:
> On Thu, Dec 24, 2015 at 08:29:20AM -0700, Ian Lepore wrote:
>> We had exactly this symptom -- long delay with spincursor before
>> loading the kernel -- on arm systems when we first enabled forth in
>> loader.  The problem turned out to be the fact that loader was running
>> with instruction and data caches disabled, and it took about 90-100
>> seconds to parse the 547 lines of text (almost all useless) in
>> /boot/defaults/loader.conf.  We stripped that file down to the dozen or
>> so lines that actually needed to be there and booting became much
>> faster.  Eventually we got the caches enabled in the prior-stage
>> bootloader and it became really fast.
>
> It is highly unlikely that caches are the source of the slowness. On
> x86, we rely on the firmware (BIOS or EFI) to properly configure both
> DRAM controllers and caches. More, Intel considers the corresponding
> controllers configuration recipes as highly secret and, even for BIOS
> vendors, Intel provides the binary blob of code which does the config
> magic, instead of the documentation.
>
> That said, loader runs in the unpaged protected mode but reflects BIOS
> calls into the real mode. Quite possible, either the real mode is
> slow on SkyLakes, or even more possible, the switch between real and
> protected mode is slow, or the protected mode without paging enabled is
> slow. Or might be the PCH lacks the ISA timer.

Seem like the issue is affects the legacy boot mode, in UEFI mode the
system boots blazingly fast.
When I have more time, I try to figure out what's the problem behind this issue.

>
> A developer needs the real machine to diagnose the cause.
>
___
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: TCP Stack: Challenge ACKs and Timestamps

[Oliver Pinter]

On Monday, December 28, 2015, Sam Kumar  wrote:

> Hello,
> I am working with the code for the TCP Stack. I noticed that support for
> Challenge Acks have been added since the latest release (10.2.0), and I
> think I may have found a bug in how they relate to TCP timestamps. All line
> numbers below are those in commit e66e064c45687b5d294565dbd829b419848f7992.
>
> Looking at tcp_input.c, at lines 1594 to 1604, I see code that expects a
> timestamp to be in every segment during the session, if they were
> negotiated when the connection was being established.
> (
>
> https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L1595
> )
>
> Looking at tcp_input.c, at lines 2161 and 2188, I see that Challenge ACKs
> are sent via calls to tcp_respond().
> (
>
> https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L2161
> and
>
> https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_input.c#L2188
> )
>
> Looking at tcp_subr.c, at line 978, I see that the segment sent by
> tcp_respond() never contains TCP options.
> (
> https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_subr.c#L978
> )
>
> Therefore, it seems to me that Challenge ACKs will never contain any TCP
> options. This violates the condition that once timestamps are negotiated,
> they must be present in every segment.
>
> Please let me know if I am mistaken, or if this is actually a bug.


Cc hiren and gnn


>
> Sam Kumar
> ___
> 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: panic while booting the official ISO 11-CUR-amd64-20151217-r292413

[Oliver Pinter]

On Monday, December 28, 2015, Matthias Apitz  wrote:

>
> Hello,
>
> I downloaded the ISO for the above version and when I boot it in a
> VMWare it panics reproduceable after trying to mount the root; see the
> message captured in the last screens:
>
> http://www.unixarea.de/panic-01.jpg
> http://www.unixarea.de/panic-02.jpg
>
> Any comments or hints?


Fixed in
https://github.com/freebsd/freebsd/commit/6cbc48de82fcf894c69c41588fd14c5c4f410244
commit.



>
> matthias
> --
> Matthias Apitz, ✉ g...@unixarea.de , 
> http://www.unixarea.de/  ☎ +49-176-38902045
> ___
> 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: panic while booting the official ISO 11-CUR-amd64-20151217-r292413

[Oliver Pinter]

On 12/28/15, Matthias Apitz  wrote:
> El día Monday, December 28, 2015 a las 02:12:29PM +0100, Matthias Apitz
> escribió:
>
>>
>> Hello,
>>
>> I downloaded the ISO for the above version and when I boot it in a
>> VMWare it panics reproduceable after trying to mount the root; see the
>> message captured in the last screens:
>>
>> http://www.unixarea.de/panic-01.jpg
>> http://www.unixarea.de/panic-02.jpg
>>
>> Any comments or hints?
>
> The downloaded VMWare image .vmdk of the same revision r292413 boots
> fine;

Yes, because the isofs triggers the problem, and the vmdk image don't
contains isofs.


>
>   matthias
> --
> Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎
> +49-176-38902045
> ___
> 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: Need help with New Build -- Skylake

[Oliver Pinter]

On 12/24/15, Vijay Rajah  wrote:
>
>
> On 12/24/15 12:22 PM, Ian Smith wrote:
>>   ~2 minutes delay there.  sendmail (mta and msp both) at least
>> are unhappy about your hostname, and sleep on it.  I don't know whether
>> that's significant or related to the longer delay you report.  I just
>> skimmed through your dmesg, but didn't spot anything glaringly obvious.
>>
>> FWIW, cheers, Ian
> Ian,
>
> Thanks for taking the time to help me.
>
> The delay is (mostly) before the boot loader menu is presented. Once the
> system starts to boot.. It is pretty fast...
>
> When the system boots, after the BIOS hands over the control to the OS..
> there are 6-7 lines, which give boot loader version etc.. (the last of
> this gives the details of the build host etc..)
>
> Then there is a spinning wheel, an the system just sits there for some
> time.. (even the wheel spins slowly). after 3-4 mins I see it loads the
> /boot/default/loader.conf . After this the menu is loaded..

Confirmed this issue, seems like the forth parser or something forth
related code in slow.
Loading the modules takes ~30 sec, and the kernel takes once more 30 sec.

This is a Gigabyte GA-H170N-WIFI board. I can test some change after Christmas.

>
> so, the issue is long before this dmesg even begins... Unfortunately, I
> do not know how to force a verbose boot before the boot menu...
>
> -Thanks
> Vijay
>
> ___
> 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: fork_findpid() - Fatal trap 12: page fault while in kernel mode

[Oliver Pinter]

Yes, it's a HardenedBSD commit. Currently only a workaround, because I have
now lesser time for the real fix in this month.

Are you running on ZFS?

On Wednesday, December 16, 2015, Fabian Keil <freebsd-lis...@fabiankeil.de>
wrote:

> Oliver Pinter <oliver.pin...@hardenedbsd.org <javascript:;>> wrote:
>
> > Is this with latest 11-CURRENT or 10-STABLE?
> >
> > Or contains the ad578c311ef commit?
>
> The panic is from a system based on 11-CURRENT r290926.
>
> Is ad578c311ef a HardenedBSD commit? It doesn't seem to
> exist in https://github.com/freebsd/freebsd.git.
>
> Fabian
>
___
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: fork_findpid() - Fatal trap 12: page fault while in kernel mode

[Oliver Pinter]

Hi!

Is this with latest 11-CURRENT or 10-STABLE?

Or contains the ad578c311ef commit?

On Tuesday, December 15, 2015, Shawn Webb <shawn.w...@hardenedbsd.org>
wrote:

> On Tue, Dec 15, 2015 at 05:42:38PM +0100, Fabian Keil wrote:
> > I've seen the following panic a couple of times in the last three
> > months, usually while poudriere was running and with sh being the
> > current process.
> >
> > This one is from a system based on r290926 running with
> > kern.randompid=9001 and forking frequently (>1000 forks/second)
> > due to poudriere and afl-fuzz:
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 04
> > fault virtual address   = 0x618b00a8
> > fault code  = supervisor read data, page not present
> > instruction pointer = 0x20:0x80909158
> > stack pointer   = 0x28:0xfe011e03b940
> > frame pointer   = 0x28:0xfe011e03b960
> > 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 = 71325 (sh)
> > trap number = 12
> > panic: page fault
> > cpuid = 1
> > KDB: stack backtrace:
> > [...]
> > Uptime: 13d20h43m20s
> > [...]
>
> Hey Fabien,
>
> I'm glad you've seen this, too. We've observed this in HardenedBSD,
> especially when running Poudriere and Jenkins. I think Oliver Pinter
> might have a potential patch to fix this. I've CC'd him on this thread.
>
> Thanks,
>
> --
> Shawn Webb
> 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"

unable to select wireless interface during install time on 11-CURRENT after the wireless subsystem rewrite

[Oliver Pinter]

Hi all!

After the "recent" wireless rewrite from Gleb, the enumeration of
wireless interfaces has gone from the bsdinstall.

This line: 
https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/master/usr.sbin/bsdinstall/scripts/netconfig#L52
return no entry, because the wlan interface not exists.
___
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: buildkernel failure

[Oliver Pinter]

On 11/16/15, Shawn Webb  wrote:
> Hey All,
>
> I'm experiencing a buildkernel failure only when doing a multi-job build
> (-jN). Doing a single-job build works fine. Below is the error I'm
> getting.
>
>  Begin Log 
> In file included from
> /usr/src/sys/modules/tests/framework/../../../tests/framework/kern_testfrwk.c:34:
> /usr/src/sys/sys/bus.h:655:10: fatal error: 'device_if.h' file not found
> #include "device_if.h"
>  ^
> 1 error generated.
> mkdep: compile failed
> --- .depend ---
> *** [.depend] Error code 1
>
> make[4]: stopped in /usr/src/sys/modules/tests/framework
>  End Log 

And some more occurrence:
http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/299/console
http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/298/console
http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/297/console

And when building fine:
http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/300/console
>
> Thanks,
>
> --
> Shawn Webb
> 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: FYI: SVN to GIT converter currently broken, github is falling behind

[Oliver Pinter]

On Sun, Nov 8, 2015 at 12:06 PM, Ulrich Spörlein  wrote:
> 2015-11-08 11:32 GMT+01:00 Ulrich Spörlein :
>> 2015-11-08 2:51 GMT+01:00 Alfred Perlstein :

>>> Uli,
>>>
>>> One of the biggest concerns I've heard from folks using FreeBSD's git mirror
>>> is that the hashes can change.
>>>
>>> I have a question about this.   Is it possible to keep track of what the
>>> "official" git mirror (on github) is doing and keep that as a log.  Then
>>> that log can be used to replay commits when there is a divergence problem.
>>>
>>> What I'm basically saying is that let's take this small example:
>>>
>>> importer is working fine @rev 1
>>> imports 1
>>> imports 10001
>>> imports 10002
>>> something happens to importer to give indeterminate shas.
>>> imports 10003 - sha is "unstable" sha3
>>> imports 10004 - sha is "unstable" sha4
>>> imports 10005 - sha is "unstable" sha5
>>> imports 10006 - sha is "unstable" sha6
>>> importer is fixed
>>>
>>>
>>> At this point normally we'd rewind the importer to 10002 and then force
>>> update the affected branches.
>>>
>>> My question is... can the imports of 10003, 10004, 10005 and 10006 be put
>>> into the importer such that any "mirror site" that re-does the import using
>>> the most up to date importer will get the same shas.
>>>
>>> That would allow to proceed with 10007, etc without force pushing.
>>>
>>> This should be possible based on querying "git" for the meta data associated
>>> with sha3..sha6 and then forcing those commits to have the same meta data.
>>>
>>> This would eliminate the concern about shas in the mirror changing that I've
>>> heard.
>>
>> The goal of the conversion is that everyone can re-do the conversion
>> in their basement and come up with the same history and checksums.
>> This was not the case when I first started, as there was some
>> non-deterministic hash structure being used in svn2git. This was fixed
>> in the code and then all converter runs produced the very same
>> results.
>>
>> The scenario that we have right now, is that one of the merge commits
>> done about two weeks ago is being handled different by svn2git w/ svn
>> v1.8 vs. svn v1.9 and I haven't investigated yet how the API's
>> behavior changed to cause this. I'm afraid I also swapped out all my
>> knowledge about svn2git internals and will have to redo this all from
>> scratch :/
>>
>> Your suggestion could only work, if we hard-code this svn revision
>> special handling into svn2git, either in the code or by providing more
>> mappings and rules to the process. svn2git should run hermetic and not
>> poke at github's commits to see how things were handled in the past.
>> It has to be self-sufficient and must not depend on github.
>>
>> This would also only work, if the "breakage" window was very small,
>> but it is already about two weeks long and will surely increase till I
>> find the proper fix.
>>
>> So, to take a stand here: this sort of kludge is unlikely to ever
>> happen. Git commit hashes *might* change in the future. I really don't
>> see how this is a big deal anyway.  It happened once and I'm trying to
>> have it never happen again. But why are people afraid of this
>> happening? Every "official" git commit is tagged with a SVN revision
>> and the contents of those revisions are obviously correct (just not
>> the ancestry and the commit objects, possibly). So it would be easy to
>> write a script that replays VendorA's git history and swaps out the
>> new official commits for the old official commits. There would be no
>> merge conflicts.
>>
>> I can see how this would be annoying if you have 100 developers and
>> dozens of branches that are far from mainline FreeBSD. But I'm sure
>> these companies that depend on git will come forward and donate some
>> of their developer manpower to help me with keeping the converter
>> stable/deterministic. Right? Right? :) :)
>>
>> Cheers,
>> Uli
>


Hi Uli!

I can not find your original svn2git repo in gitorius
(https://gitorious.org/ is down) , could you please the source code
somewhere to git-repo? For example github.com/freebsd/svn2git?

> Quick update: doc is so far unaffected by svn 1.9, but for ports, the
> drift happened as of Jul 18, so you'd need to special case a lot of
> commits.
>
> Here's the same commit, and the difference between 1.8 and 1.9:
>
> % git cat-file commit 803795d
> tree 7fc83aba022834da5c218114b09ad4640735bcc0
> parent c96fb0418e545a569b5975b4d878a30a948c29d5
> author olgeni  1437203525 +
> committer olgeni  1437203525 +
>
> Upgrade to version 0.4.1.
> % git cat-file commit 61ca43b
> tree 7fc83aba022834da5c218114b09ad4640735bcc0
> parent c96fb0418e545a569b5975b4d878a30a948c29d5
> author olgeni  1437203529 +
> committer olgeni  1437203529 +
>
> Upgrade to version 0.4.1.
>
>
> In case you don't see it, there's a 4s difference in the timestamps
> 

Re: Make installworld fails on file not found (Error code 71)

[Oliver Pinter]

On Tue, Oct 20, 2015 at 10:07 AM, Thomas Mueller
 wrote:
> I was trying to test the new i915 graphics driver but got stuck in building 
> and installing the userland:
>
> /usr/share/man/man2/mknodat.2 -> /usr/share/man/man2/mknod.2
> /usr/share/man/man2/munlock.2 -> /usr/share/man/man2/mlock.2
> /usr/share/man/man2/munlockall.2 -> /usr/share/man/man2/mlockall.2
> /usr/share/man/man2/modfnext.2 -> /usr/share/man/man2/modnext.2
> /usr/share/man/man2/nmount.2 -> /usr/share/man/man2/mount.2
> /usr/share/man/man2/unmount.2 -> /usr/share/man/man2/mount.2
> /usr/share/man/man2/mq_timedreceive.2 -> /usr/share/man/man2/mq_receive.2
> /usr/share/man/man2/mq_timedsend.2 -> /usr/share/man/man2/mq_send.2
> /usr/share/man/man2/ntp_gettime.2 -> /usr/share/man/man2/ntp_adjtime.2
> /usr/share/man/man2/numa_setaffinity.2 -> 
> /usr/share/man/man2/numa_getaffinity.2
> install: link /usr/share/man/man2/numa_getaffinity.2 -> 
> /usr/share/man/man2/numa_setaffinity.2: No such file or directory
> *** Error code 71
>
> Stop.
> make[5]: stopped in /usr/src/lib/libc
> *** Error code 1
>
> Stop.
> make[4]: stopped in /usr/src/lib
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
>
> Now I have a new kernel on a userland dating to last April 27.
>
> I got this same result with "make installworld" also on previous attempt just 
> a day previous.
>
> Do I need to clean out old build directory tree?  Build runs cleandir 
> automatically, but do I need more, like rm -R /usr/obj/* ?
>
> If this happened in NetBSD, I would use -r with build.sh which gets rid of 
> outdated stuff in build directories, and will get a chance to try this as I 
> try to update a system last built 14 months ago.
>
> What do I need to do in FreeBSD?

If you like to test the i915kms driver from "binary source", you could
fine them in our (HardenedBSD) ISOs:
http://jenkins.hardenedbsd.org/builds/HardenedBSD-i915kms-amd64-LATEST/ISO-IMAGES/

>
> Tom
>
> ___
> 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: ZFS panic

[Oliver Pinter]

CC+= swills

On 9/17/15, Oliver Pinter <oliver.pin...@hardenedbsd.org> wrote:
> Hi All!
>
> We got this panic on modified FreeBSD (we not touched the ZFS part).
>
> panic: solaris assert: error || lr->lr_length <= zp->z_blksz, file:
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
> line: 1355
> cpuid = 6
> KDB: stack backtrace:
> #0 0x80639527 at kdb_backtrace+0x67
> #1 0x805fd509 at vpanic+0x189
> #2 0x805fd593 at panic+0x43
> #3 0x802ce3aa at assfail+0x1a
> #4 0x8039c391 at zfs_get_data+0x391
> #5 0x803afeac at zil_commit+0x94c
> #6 0x803a39d8 at zfs_freebsd_fsync+0xc8
> #7 0x8089a8a7 at VOP_FSYNC_APV+0xf7
> #8 0x806afc40 at sys_fsync+0x170
> #9 0x808311bc at amd64_syscall+0x2bc
> #10 0x8081285b at Xfast_syscall+0xfb
> Uptime: 7d5h19m13s
> Dumping 8207 out of 32742
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> Dump complete
> Automatic reboot in 15 seconds - press a key on the console to abort
> Rebooting...
> cpu_reset: Restarting BSP
> cpu_reset_proxy: Stopped CPU 6
>
>
> (kgdb) bt
> #0  doadump (textdump=) at pcpu.h:221
> #1  0x805fcf70 in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:329
> #2  0x805fd548 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:626
> #3  0x805fd593 in panic (fmt=0x0) at
> /usr/src/sys/kern/kern_shutdown.c:557
> #4  0x802ce3aa in assfail (a=, f= optimized out>, l=) at
> /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81
> #5  0x8039c391 in zfs_get_data (arg=,
> lr=, buf=,
> zio=0xf8019eeb1760) at
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1355
> #6  0x803afeac in zil_commit (zilog=0xf8001d518800,
> foid=) at
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:1107
> #7  0x803a39d8 in zfs_freebsd_fsync (ap=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2797
> #8  0x8089a8a7 in VOP_FSYNC_APV (vop=,
> a=) at vnode_if.c:1328
> #9  0x806afc40 in sys_fsync (td=0xf8001d0429c0, uap= optimized out>) at vnode_if.h:549
> #10 0x808311bc in amd64_syscall (td=0xf8001d0429c0,
> traced=0) at subr_syscall.c:139
> #11 0x8081285b in Xfast_syscall () at
> /usr/src/sys/amd64/amd64/exception.S:394
> #12 0x0058d23a in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
> (kgdb) f 5
> #5  0x8039c391 in zfs_get_data (arg=,
> lr=, buf=,
> zio=0xf8019eeb1760) at
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1355
> 1355ASSERT(error || lr->lr_length <=
> zp->z_blksz);
> (kgdb) l
> 1350ASSERT(db->db_offset == offset);
> 1351ASSERT(db->db_size == size);
> 1352
> 1353error = dmu_sync(zio,
> lr->lr_common.lrc_txg,
> 1354zfs_get_done, zgd);
> 1355ASSERT(error || lr->lr_length <=
> zp->z_blksz);
> 1356
> 1357/*
> 1358 * On success, we need to wait for the write
> I/O
> 1359 * initiated by dmu_sync() to complete
> before we can
> (kgdb) p *lr
> Cannot access memory at address 0xa5a5a5a5a5a5a5a5
> (kgdb) p *zp
> Cannot access memory at address 0xa5a5a5a5a5a5a5a5
> (kgdb)
>
>
> Undefined info command: "regs".  Try "help info".
> (kgdb) info registers
> rax0x0  0
> rbx0xf804aab14e00   -8776049406464
> rcx0x0  0
> rdx0x0  0
> rsi0x0  0
> rdi0x0  0
> rbp0xfe085f78e8f0   0xfe085f78e8f0
> rsp0xfe085f78e890   0xfe085f78e890
> r8 0x0  0
> r9 0x0  0
> r100x0  0
> r110x0  0
> r120x0  0
> r130xfe034cecd0b8   -2184847765320
> r140x2  131072
> r150x0  0
> rip0x8039c391   0x8039c391
> <zfs_get_data+913>
> eflags 0x0  0
> cs 0x0  0
> ss 0x0  0
> ds 0x0  0
> es 0x0  0
> fs 0x0  0
> gs 0x0  0
>
> [...]
> 8039c2f9:   48 8b 7d b0 mov-0x50(%rbp),%rdi
> 8039

Re: FreeBSD 11.0-CURRENT Single User Keymap

[Oliver Pinter]

On 9/16/15, Gary Jennejohn  wrote:
> On Tue, 15 Sep 2015 19:32:35 +0900
> Brendan Sechter  wrote:
>
>> When compiling a FreeBSD 11.0-CURRENT kernel, what is required to change
>> the keymap used in single user mode? __I originally asked this question on
>> the FreeBSD forums, but was bounced to the mailing list because CURRENT is
>> an unsupported version.
>>
>> I have read an old forum thread on this topic. I have also read
>> the__atkbd(4)__and__ukbd(4)__man pages. The relevant parts of my kernel
>> configuration are as follows:
>>
>> #__--__--__--__--
>> include GENERIC
>> ident MY_KERNEL
>>
>> # AT Keyboard
>> device atkbdc
>> options ATKBD_DFLT_KEYMAP
>> makeoptions ATKBD_DFLT_KEYMAP=jp.106
>> device atkbd
>>
>> # USB Keyboard
>> device ukbd
>> options UKBD_DFLT_KEYMAP
>> makeoptions UKBD_DFLT_KEYMAP=jp.106
>>
>> # everything else
>> # ...
>> #__--__--__--__--
>>
>> So far as I can tell, these options should be working. I am using a 106
>> key Japanese keyboard. Single user mode appears to use the keymap for a
>> 101 key standard US layout. I have tried the following values:
>> - jp
>> - jp.106
>> - jp.106.kbd (not tried recently)
>>
>> Finally, this is a FreeBSD VM running in VirtualBox on OSX. I am 99% sure
>> I am having the same problem on my physical machines. The specific driver
>> almost certainly depends on the hardware.
>>
>
> Try setting keymap in /etc/rc.conf to the entry you want.  Just
> putting keymap="jp.106" there should work.
>
> Umm, but this is for syscons.  Not sure what you may need for vt,
> which I don't use.

See this patch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865

>
> --
> Gary Jennejohn
> ___
> 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: Intel Haswell support - Any updates?

[Oliver Pinter]

On 9/17/15, Michael Gmelin  wrote:
>
>
>> On 17 Sep 2015, at 20:23, Russell L. Carter  wrote:
>>
>>
>>
>>> On 09/17/15 10:40, Matthias Apitz wrote:
>>> El día Thursday, September 17, 2015 a las 11:02:07AM -0400, Kris Moore
>>> escribió:
>>>
 On 09/17/2015 09:48, Matthias Apitz wrote:
> El día Thursday, September 17, 2015 a las 10:41:43PM +0900, Lundberg,
> Johannes escribió:
>
>> Same here. I would personally definitely buy new hardware from Intel
>> if
>> FreeBSD worked on it (not vesa...)
>> ...
> What dow you have against vesa? I run CURRENT on some Acer C720
> Chromebooks with Haswell chipset in Vesa mode. And you will not note
> it.
> I have never ever had such a fast desktop (KDE4) before. I can live
> fine
> with Vesa until Haswell suport is there.
>
>matthias

 BTW, have you tried the xf86-video-scfb driver? It works much better
 than vesa here. The only catch is you have to be booted UEFI with CSM
 disabled. Using it on my X1 Carbon, gets 3k resolution properly and
 everything. Thanks to Glen Barber for bringing that to my attention.
>>>
>>> The Chromebook Acer C720 does not has UEFI; it runs Coreboot with
>>> SeaBIOS as payload.
>>>
>>> The Xorg runs fine without any xorg.conf file, just detects the video as
>>> Vesa with 1366x768 resolution, the max of the 11" screen of this
>>> netbook.
>>
>> Do you have 802.11n and hibernate working on that c720?  I put linux on
>> mine for that reason.  Although despite immense efforts I can't get
>> the trackpad to be detected.  I tried bringing up 10.2 on it but
>> couldn't get it to boot.  These things are just awesome.  4G memory
>> + i3 + 6hr battery for $240 delivered.
>>
>
> It's all in CURRENT, see http://blog.grem.de/pages/c720.html.
>
> Brightness control is done through graphics/intel-backlight (should work on
> other Intel GPUs as well). Auto-brightness control works as well (using the
> new isl driver).

Wow! Thank you very much for this info!

>
> HDMI works in VESA mode (mirrors the internal display). It suspends but
> won't resume, probably due to video, I was never able to really figure that
> one out. Tried an early version of 915i about half a year ago with limited
> success, will try again at/after EuroBSDCon.
>
> There are a couple of people who helped me testing and most of them seem
> quite happy with the results (no suspend/resume being the only real caveat).
>
> - Michael
>
>> Russell
>>
>>>matthias
>> ___
>> 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"
___
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 panic

[Oliver Pinter]

Hi All!

We got this panic on modified FreeBSD (we not touched the ZFS part).

panic: solaris assert: error || lr->lr_length <= zp->z_blksz, file:
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
line: 1355
cpuid = 6
KDB: stack backtrace:
#0 0x80639527 at kdb_backtrace+0x67
#1 0x805fd509 at vpanic+0x189
#2 0x805fd593 at panic+0x43
#3 0x802ce3aa at assfail+0x1a
#4 0x8039c391 at zfs_get_data+0x391
#5 0x803afeac at zil_commit+0x94c
#6 0x803a39d8 at zfs_freebsd_fsync+0xc8
#7 0x8089a8a7 at VOP_FSYNC_APV+0xf7
#8 0x806afc40 at sys_fsync+0x170
#9 0x808311bc at amd64_syscall+0x2bc
#10 0x8081285b at Xfast_syscall+0xfb
Uptime: 7d5h19m13s
Dumping 8207 out of 32742 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset: Restarting BSP
cpu_reset_proxy: Stopped CPU 6


(kgdb) bt
#0  doadump (textdump=) at pcpu.h:221
#1  0x805fcf70 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:329
#2  0x805fd548 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:626
#3  0x805fd593 in panic (fmt=0x0) at
/usr/src/sys/kern/kern_shutdown.c:557
#4  0x802ce3aa in assfail (a=, f=, l=) at
/usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81
#5  0x8039c391 in zfs_get_data (arg=,
lr=, buf=,
zio=0xf8019eeb1760) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1355
#6  0x803afeac in zil_commit (zilog=0xf8001d518800,
foid=) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:1107
#7  0x803a39d8 in zfs_freebsd_fsync (ap=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2797
#8  0x8089a8a7 in VOP_FSYNC_APV (vop=,
a=) at vnode_if.c:1328
#9  0x806afc40 in sys_fsync (td=0xf8001d0429c0, uap=) at vnode_if.h:549
#10 0x808311bc in amd64_syscall (td=0xf8001d0429c0,
traced=0) at subr_syscall.c:139
#11 0x8081285b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:394
#12 0x0058d23a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb) f 5
#5  0x8039c391 in zfs_get_data (arg=,
lr=, buf=,
zio=0xf8019eeb1760) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1355
1355ASSERT(error || lr->lr_length <= zp->z_blksz);
(kgdb) l
1350ASSERT(db->db_offset == offset);
1351ASSERT(db->db_size == size);
1352
1353error = dmu_sync(zio, lr->lr_common.lrc_txg,
1354zfs_get_done, zgd);
1355ASSERT(error || lr->lr_length <= zp->z_blksz);
1356
1357/*
1358 * On success, we need to wait for the write I/O
1359 * initiated by dmu_sync() to complete
before we can
(kgdb) p *lr
Cannot access memory at address 0xa5a5a5a5a5a5a5a5
(kgdb) p *zp
Cannot access memory at address 0xa5a5a5a5a5a5a5a5
(kgdb)


Undefined info command: "regs".  Try "help info".
(kgdb) info registers
rax0x0  0
rbx0xf804aab14e00   -8776049406464
rcx0x0  0
rdx0x0  0
rsi0x0  0
rdi0x0  0
rbp0xfe085f78e8f0   0xfe085f78e8f0
rsp0xfe085f78e890   0xfe085f78e890
r8 0x0  0
r9 0x0  0
r100x0  0
r110x0  0
r120x0  0
r130xfe034cecd0b8   -2184847765320
r140x2  131072
r150x0  0
rip0x8039c391   0x8039c391 
eflags 0x0  0
cs 0x0  0
ss 0x0  0
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0

[...]
8039c2f9:   48 8b 7d b0 mov-0x50(%rbp),%rdi
8039c2fd:   48 89 d9mov%rbx,%rcx
8039c300:   e8 db 50 f6 ff  callq
803013e0 
8039c305:   41 89 c4mov%eax,%r12d
8039c308:   41 83 fc 25 cmp$0x25,%r12d
8039c30c:   75 53   jne
8039c361 
8039c30e:   49 c7 45 00 14 00 00movq   $0x14,0x0(%r13)
8039c315:   00
8039c316:   45 31 e4xor%r12d,%r12d
8039c319:   eb 29   jmp
8039c344 
8039c31b:   48 8b 3c 25 38 a4 c1mov0x80c1a438,%rdi
8039c322:   80
8039c323:   41 bc 02 00 00 00   mov$0x2,%r12d
8039c329:   

Re: panic: Stray timeout

[Oliver Pinter]

On 8/31/15, Jean-Sébastien Pédron <dumbb...@freebsd.org> wrote:
> On 30.08.2015 21:05, Andriy Gapon wrote:
>> On 30/08/2015 21:37, Oliver Pinter wrote:
>>> You have a running Xorg with radeonkms driver, and this issue
>>> occurrence under high load (for example parallel buildworld)?
>>
>> I use radonkms indeed and judging from ta_func = ttm_bo_delayed_workqueue
>> it was
>> involved.  But there was no steady system load before the crash, perhaps
>> there
>> was a spike though.
>
> I get this panic several times a week since around February this year.
> It appeared without any commit to TTM or the Radeon driver. It happens
> no matter the load for me.

I got this panic, and I have somewhere a kernel and a coredump on my
other machine. I got this panic only when I put my machine under heavy
load and use X with randonkms driver.
When I didn't use X and start the build under vt, I newer got this panic.

>
> So far, I never found the cause, even though I spent a lot of time
> reading TTM, subr_taskqueue.c and kern_timeout.c.
>
> So, this is a simple "me too" :-/
>
> --
> Jean-Sébastien Pédron
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Stray timeout

[Oliver Pinter]

On 8/30/15, Andriy Gapon a...@freebsd.org wrote:

 I've got the following kernel panic seemingly at random.
 I have been using the kernel for about a week without any issues and I
 wasn't
 doing anything special when the panic occurred.
 Does this panic ring any bells?  Could the problem be already fixed by more
 recent changes?

 r286985

 panic: Stray timeout

 (kgdb) bt
 #0  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:260
 #1  0x8063236f in kern_reboot (howto=260) at
 /usr/src/sys/kern/kern_shutdown.c:328
 #2  0x806329d4 in vpanic (fmt=value optimized out, ap=value
 optimized
 out) at /usr/src/sys/kern/kern_shutdown.c:508
 #3  0x806326d3 in panic (fmt=0x0) at
 /usr/src/sys/kern/kern_shutdown.c:441
 #4  0x80677dea in taskqueue_timeout_func (arg=value optimized out)
 at
 /usr/src/sys/kern/subr_taskqueue.c:269
 #5  0x8064858d in softclock_call_cc (c=0xfe000241cb50,
 cc=0x81066000, direct=0) at /usr/src/sys/kern/kern_timeout.c:722
 #6  0x80648917 in softclock (arg=value optimized out) at
 /usr/src/sys/kern/kern_timeout.c:851
 #7  0x805fe47f in intr_event_execute_handlers
 (p=0xf800059b0548,
 ie=0xf8000599d900) at /usr/src/sys/kern/kern_intr.c:1262
 #8  0x805fefac in ithread_execute_handlers (p=0xf800059b0548,
 ie=0xf8000599d900) at /usr/src/sys/kern/kern_intr.c:1275
 #9  0x805fee1b in ithread_loop (arg=value optimized out) at
 /usr/src/sys/kern/kern_intr.c:1356
 #10 0x805fba9b in fork_exit (callout=0x805fedc0
 ithread_loop,
 arg=0xf800059adb60, frame=0xfe01dc55bc00) at
 /usr/src/sys/kern/kern_fork.c:1006
 #11 0x808073de in fork_trampoline () at
 /usr/src/sys/libkern/explicit_bzero.c:28
 #12 0x in ?? ()

 (kgdb) fr 5
 #5  0x8064858d in softclock_call_cc (c=0xfe000241cb50,
 cc=0x81066000, direct=0) at /usr/src/sys/kern/kern_timeout.c:722
 722 c_func(c_arg);
 (kgdb) p *c
 $1 = {c_links = {le = {le_next = 0x0, le_prev = 0x81066108}, sle =
 {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x81066108}},
 c_time
 = 171699241227799, c_precision = 2684354, c_arg = 0xfe000241cb28,
   c_func = 0x80677db0 taskqueue_timeout_func, c_lock =
 0xf80013d66d30, c_flags = 2, c_iflags = 144, c_cpu = 0}

 c_flags = CALLOUT_ACTIVE
 c_iflags = CALLOUT_RETURNUNLOCKED | CALLOUT_PROCESSED

 (kgdb) p *cc
 $2 = {cc_lock = {lock_object = {lo_name = 0x809a0177 callout,
 lo_flags
 = 720896, lo_data = 0, lo_witness = 0xfe0001fd1400}, mtx_lock = 4},
 cc_exec_entity = 0x81066080, cc_next = 0x0,
   cc_callout = 0xfe0002116000, cc_callwheel = 0xfe0002238000,
 cc_expireq
 = {tqh_first = 0x0, tqh_last = 0x81066108}, cc_callfree = {slh_first
 =
 0xfe00022372c0}, cc_firstevent = 171699349138844,
   cc_lastscan = 171699243988142, cc_cookie = 0xf800059a9b00, cc_bucket
 =
 10456, cc_inited = 1, cc_ktr_event_name = 0x81066140 callwheel cpu
 0}
 (kgdb) p c_arg
 $3 = (void *) 0xfe000241cb28

 (kgdb) down
 #4  0x80677dea in taskqueue_timeout_func (arg=value optimized out)
 at
 /usr/src/sys/kern/subr_taskqueue.c:269
 269 KASSERT((timeout_task-f  DT_CALLOUT_ARMED) != 0, (Stray
 timeout));
 (kgdb) p *(struct timeout_task *)0xfe000241cb28
 $4 = {q = 0xf80013d66d00, t = {ta_link = {stqe_next = 0x0}, ta_pending =
 0,
 ta_priority = 0, ta_func = 0x82197220 ttm_bo_delayed_workqueue,
 ta_context = 0xfe000241c5c0}, c = {c_links = {le = {le_next = 0x0,
 le_prev = 0x81066108}, sle = {sle_next = 0x0}, tqe =
 {tqe_next =
 0x0, tqe_prev = 0x81066108}}, c_time = 171699241227799, c_precision
 =
 2684354, c_arg = 0xfe000241cb28,
 c_func = 0x80677db0 taskqueue_timeout_func, c_lock =
 0xf80013d66d30, c_flags = 2, c_iflags = 144, c_cpu = 0}, f = 0}
 (kgdb) p *$4.q
 $5 = {tq_queue = {stqh_first = 0x0, stqh_last = 0xf80013d66d00},
 tq_enqueue
 = 0x80678c30 taskqueue_thread_enqueue, tq_context =
 0x811130d8, tq_active = {tqh_first = 0x0, tqh_last =
 0xf80013d66d20},
   tq_mutex = {lock_object = {lo_name = 0x809a52a1 taskqueue,
 lo_flags
 = 16973824, lo_data = 0, lo_witness = 0xfe0001fd7200}, mtx_lock =
 18446735277710583024}, tq_threads = 0xf80013dd1bd0, tq_tcount = 1,
   tq_spin = 0, tq_flags = 5, tq_callouts = 1, tq_callbacks =
 0xf80013d66d68,
 tq_cb_contexts = 0xf80013d66d78}

 BTW, I see the following potential problem.  taskqueue_cancel_timeout()
 unconditionally resets DT_CALLOUT_ARMED, so that happens even if
 callout_stop()
 signals that the callout is going to be called.  In that case, when
 taskqueue_timeout_func() gets called it's going to run into the assertion.

You have a running Xorg with radeonkms driver, and this issue
occurrence under high load (for example parallel buildworld)?


 --
 Andriy Gapon
 ___
 

Re: 11-CURRENT build fail with base gcc

[Oliver Pinter]

On 8/20/15, Dimitry Andric d...@freebsd.org wrote:
 On 20 Aug 2015, at 00:56, Oliver Pinter oliver.pin...@hardenedbsd.org
 wrote:
 I got this error, when I try to build recent 11-CURRENT with gcc on amd64
 box:

 --- delay.o ---
 cc   -O2 -pipe   -fPIC -mno-red-zone
 -I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../include
 -I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../include/amd64
 -I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../../../../lib/libstand
 -I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../../common
 -fformat-extensions -ffreestanding -Wformat -msoft-float -fshort-wchar
 -mno-red-zone -mno-mmx -mno-sse -mno-aes -mno-avx -std=gnu99 -c
 /usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/delay.c -o
 delay.o
 cc1: error: unrecognized command line option -mno-avx

 You can access a full build log here:
 http://jenkins.hardenedbsd.org/~op/11-current-with-gcc-fail.log .

 Seems like the build environment passed a wrong COMPILER_TYPE to
 bsd.sys.mk: clang instead of gcc, and that's why the -mno-avx occurs
 in the compiler options.

 I use the following options in src.conf to build the system with gcc:
 WITHOUT_CLANG_BOOTSTRAP=
 WITHOUT_CLANG_IS_CC=
 WITHOUT_CLANG=
 WITH_GCC_BOOTSTRAP=
 WITH_GCC=

 and the host system is a 11-CURRENT system, which builded with clang.

 At what build stage is this error occuring?

At 4.4 build everything:

op@opn /tmp grep '' 11-current-with-gcc-fail.log
 World build started on Thu Aug 20 00:32:24 CEST 2015
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything


 -Dimitry


___
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: 11-CURRENT build fail with base gcc

[Oliver Pinter]

On 8/20/15, Warner Losh i...@bsdimp.com wrote:

 On Aug 20, 2015, at 9:38 AM, Oliver Pinter oliver.pin...@hardenedbsd.org
 wrote:

 On 8/20/15, Dimitry Andric d...@freebsd.org wrote:
 On 20 Aug 2015, at 00:56, Oliver Pinter oliver.pin...@hardenedbsd.org
 wrote:
 I got this error, when I try to build recent 11-CURRENT with gcc on
 amd64
 box:

 --- delay.o ---
 cc   -O2 -pipe   -fPIC -mno-red-zone
 -I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../include
 -I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../include/amd64
 -I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../../../../lib/libstand
 -I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../../common
 -fformat-extensions -ffreestanding -Wformat -msoft-float -fshort-wchar
 -mno-red-zone -mno-mmx -mno-sse -mno-aes -mno-avx -std=gnu99 -c
 /usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/delay.c -o
 delay.o
 cc1: error: unrecognized command line option -mno-avx

 You can access a full build log here:
 http://jenkins.hardenedbsd.org/~op/11-current-with-gcc-fail.log .

 Seems like the build environment passed a wrong COMPILER_TYPE to
 bsd.sys.mk: clang instead of gcc, and that's why the -mno-avx occurs
 in the compiler options.

 I use the following options in src.conf to build the system with gcc:
 WITHOUT_CLANG_BOOTSTRAP=
 WITHOUT_CLANG_IS_CC=
 WITHOUT_CLANG=
 WITH_GCC_BOOTSTRAP=
 WITH_GCC=

 and the host system is a 11-CURRENT system, which builded with clang.

 At what build stage is this error occuring?

 At 4.4 build everything:

 op@opn /tmp grep '' 11-current-with-gcc-fail.log
 World build started on Thu Aug 20 00:32:24 CEST 2015
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything

 I think you are wrong about the cause. -mno-avx is bogusly listed
 unconditionally
 in efi/Makefile.inc. I’m working on a patch now…

Sure, you have right. Thanks Warner!


 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

11-CURRENT build fail with base gcc

[Oliver Pinter]

Hi All!

I got this error, when I try to build recent 11-CURRENT with gcc on amd64 box:

--- delay.o ---
cc   -O2 -pipe   -fPIC -mno-red-zone
-I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../include
-I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../include/amd64
-I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../../../../lib/libstand
-I/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/../../common
-fformat-extensions -ffreestanding -Wformat -msoft-float -fshort-wchar
-mno-red-zone -mno-mmx -mno-sse -mno-aes -mno-avx -std=gnu99 -c
/usr/data/source/git/opBSD/opBSD.git/sys/boot/efi/libefi/delay.c -o
delay.o
cc1: error: unrecognized command line option -mno-avx

You can access a full build log here:
http://jenkins.hardenedbsd.org/~op/11-current-with-gcc-fail.log .

Seems like the build environment passed a wrong COMPILER_TYPE to
bsd.sys.mk: clang instead of gcc, and that's why the -mno-avx occurs
in the compiler options.

I use the following options in src.conf to build the system with gcc:
WITHOUT_CLANG_BOOTSTRAP=
WITHOUT_CLANG_IS_CC=
WITHOUT_CLANG=
WITH_GCC_BOOTSTRAP=
WITH_GCC=

and the host system is a 11-CURRENT system, which builded with clang.

Thanks,
Oliver
___
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: duration of buildworld

[Oliver Pinter]

Hi!

On 7/27/15, Matthias Apitz g...@unixarea.de wrote:

 Hello,

 Yesterday I grabbed r285885 from SVN and launched a

 # make -j2 buildworld

 which is still running after 19 hours on a server of 2 CPU of the type
 Intel(R) Core(TM)2 Extreme CPU X9100  @ 3.06GHz and 4 GByte memory.

 Last time in January with r276659 on the same host it took only some 8
 hours, IIRC.

On my desktop system (Core i5-4670) takes only 50 minutes the
buildworld + buildkernel with DEBUG kernel.


 Is there anything wrong of what could cause this change of the build
 time?

 Thanks

   matthias

 --
 Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/  ☎
 +49-176-38902045
 No! Nein! ¡No! Όχι! -- Ευχαριστούμε!
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[Oliver Pinter]

On 7/9/15, NGie Cooper yaneurab...@gmail.com wrote:
 On Thu, Jul 9, 2015 at 1:41 AM, Konstantin Belousov kostik...@gmail.com
 wrote:
 On Thu, Jul 09, 2015 at 08:27:17AM +1000, Peter Jeremy wrote:
 I'm not sure if we want to explicitly document the conditions under
 which
 gettimeofday() (or clock_gettime()) are implemented in userland vs
 syscalls
 because that is guaranteed to get stale over time.  How about stating
 that
 Of course, we don't.  There is no guarantee that the set of conditions
 is stable even on the stable branch.

 these functions are implemented as syscalls only if the AT_TIMEKEEP
 value
 reported by procstat -x is NULL.
 Mere presence of AT_TIMEKEEP does not imply the use of the fast path.
 E.g. the fast path can be disabled dynamically, or timecounter could be
 changed, or libc might be of the wrong version.  My imagination stops
 there.

 IMO the point of this discussion is to note that test suite tests useless

 useless - inapplicable

Btw, I have found this is atf's documantation:
atf_tc_expect_signal(SIGSEGV, reaseon), with this, we could mark the
specific test case could fail / or expect to coredump.


 things.

 things. - things [for FreeBSD].

 If somebody run the test suite for libc, she would immediately note
 another failing test for the stack protector, which is similar to the
 gettimeofday nonsense.

 Perhaps, but that's assuming that NetBSD implemented gettimeofday in
 userland, which is doesn't.

 I agree that this is less applicable for FreeBSD than NetBSD. Please
 keep in mind that contrib/netbsd-tests came from NetBSD, not FreeBSD.
 Peter Holm and I tried our best to vet out the issues with the test
 suite before integrating it in, but there might be issues due to
 implementation discrepancies between FreeBSD and NetBSD.

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

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

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[Oliver Pinter]

On 7/8/15, Konstantin Belousov kostik...@gmail.com wrote:
 On Wed, Jul 08, 2015 at 11:53:39AM +0200, Oliver Pinter wrote:
 On 7/8/15, O'Connor, Daniel dar...@dons.net.au wrote:
 
  On 8 Jul 2015, at 08:11, Garrett Wollman
  woll...@hergotha.csail.mit.edu
  wrote:
  Perhaps the test was (erroneously) written to assume that
  gettimeofday() was a system call, and could therefore detect invalid
  pointers and return [EFAULT].  This has not been the case for some
  time.  (In HEAD, not since r237434, which is three years ago.)
 
  In defence of the test, the man page says it can return EFAULT.

 That's fine, but why changed the behaviour since 2015. May 27.? I have
 an older FreeBSD/HardenedBSD install, where this test passing. See
 some previous email in this thread.
 Current implemention detail is that gettimeofday(-1) causes SIGSEGV
 if kern.timecounter.hardware=TSC-low and kern.timecounter.fast_gettime=1.
 If you timecounter changed for whatever reason, the result of that
 call would fluctuate between EFAULT and signal.

Thanks Konstantin! Yes, the systems defaults to TSC-low.

root@nyi-01 ~# sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC-low
root@nyi-01 ~# sysctl kern.timecounter.fast_gettime
kern.timecounter.fast_gettime: 1
root@nyi-01 ~# sysctl kern.timecounter.choice
kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950)
i8254(0) dummy(-100)

Changing to HPET solves the problem:

root@nyi-01 ~# sysctl kern.timecounter.hardware=HPET
kern.timecounter.hardware: TSC-low - HPET
root@nyi-01 ~# cd /usr/tests/lib/libc/sys
root@nyi-01 sys# kyua test gettimeofday_test


gettimeofday_test:gettimeofday_err  -  passed  [0.011s]
gettimeofday_test:gettimeofday_mono  -  passed  [0.012s]

Results file id is usr_tests_lib_libc_sys.20150708-103338-126124
Results saved to
/root/.kyua/store/results.usr_tests_lib_libc_sys.20150708-103338-126124.db

2/2 passed (0 failed)



 This is not the only test in the test set which checks something that
 cannot be reasonably explained.


 
  (IMO the man page and test should change..)
 
  --
  Daniel O'Connor
  The nice thing about standards is that there
  are so many of them to choose from.
   -- Andrew Tanenbaum
  GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
 
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org

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

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[Oliver Pinter]

On 7/8/15, O'Connor, Daniel dar...@dons.net.au wrote:

 On 8 Jul 2015, at 08:11, Garrett Wollman woll...@hergotha.csail.mit.edu
 wrote:
 Perhaps the test was (erroneously) written to assume that
 gettimeofday() was a system call, and could therefore detect invalid
 pointers and return [EFAULT].  This has not been the case for some
 time.  (In HEAD, not since r237434, which is three years ago.)

 In defence of the test, the man page says it can return EFAULT.

That's fine, but why changed the behaviour since 2015. May 27.? I have
an older FreeBSD/HardenedBSD install, where this test passing. See
some previous email in this thread.


 (IMO the man page and test should change..)

 --
 Daniel O'Connor
 The nice thing about standards is that there
 are so many of them to choose from.
  -- Andrew Tanenbaum
 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


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

gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[Oliver Pinter]

Hi all!

We discovered that one of the kyua test failing from gettimeofday tests.
The error is reproducible on recent snapshot from 11-CURRENT:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso

root@freebsd:~ # cat test-gtod.c
#include sys/time.h
#include stdio.h

int
main(int argc, char **argv)
{

return (gettimeofday((void *)-1, NULL));
}
root@freebsd:~ # make test-gtod
cc -O2 -pipetest-gtod.c  -o test-gtod
root@freebsd:~ # uname -a
FreeBSD freebsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r284969: Tue Jun
30 22:05:35 UTC 2015
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@freebsd:~ # ./test-gtod
Segmentation fault (core dumped)

root@freebsd:~ # gdb ./test-gtod
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...(no debugging
symbols found)...
(gdb) r
Starting program: /root/test-gtod
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x000800958fbd in bcopy () from /lib/libc.so.7
(gdb) bt
#0  0x000800958fbd in bcopy () from /lib/libc.so.7
#1  0x559c1291 in ?? ()
#2  0xf9fde38df0174b80 in ?? ()
#3  0x in ?? ()
#4  0x in ?? ()

And this is the original kyua test:
op@opn sys kyua test gettimeofday_test
gettimeofday_test:gettimeofday_err  -  broken: Premature exit; test
case received signal 11 (core dumped)  [0.987s]
gettimeofday_test:gettimeofday_mono  -  passed  [0.014s]

Results file id is usr_tests_lib_libc_sys.20150707-215959-750045
Results saved to
/usr/home/op/.kyua/store/results.usr_tests_lib_libc_sys.20150707-215959-750045.db

1/2 passed (1 failed)
op@opn sys pwd
/usr/tests/lib/libc/sys
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[Oliver Pinter]

On Wed, Jul 8, 2015 at 12:09 AM, Garrett Cooper yaneurab...@gmail.com wrote:

 On Jul 7, 2015, at 15:00, Oliver Pinter oliver.pin...@hardenedbsd.org 
 wrote:

 Hi all!

 We discovered that one of the kyua test failing from gettimeofday tests.
 The error is reproducible on recent snapshot from 11-CURRENT:
 ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso

 root@freebsd:~ # cat test-gtod.c
 #include sys/time.h
 #include stdio.h

 int
 main(int argc, char **argv)
 {

return (gettimeofday((void *)-1, NULL));
 }
 root@freebsd:~ # make test-gtod
 cc -O2 -pipetest-gtod.c  -o test-gtod
 root@freebsd:~ # uname -a
 FreeBSD freebsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r284969: Tue Jun
 30 22:05:35 UTC 2015
 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
 root@freebsd:~ # ./test-gtod
 Segmentation fault (core dumped)

 root@freebsd:~ # gdb ./test-gtod
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...(no debugging
 symbols found)...
 (gdb) r
 Starting program: /root/test-gtod
 (no debugging symbols found)...(no debugging symbols found)...
 Program received signal SIGSEGV, Segmentation fault.
 0x000800958fbd in bcopy () from /lib/libc.so.7
 (gdb) bt
 #0  0x000800958fbd in bcopy () from /lib/libc.so.7
 #1  0x559c1291 in ?? ()
 #2  0xf9fde38df0174b80 in ?? ()
 #3  0x in ?? ()
 #4  0x in ?? ()

 And this is the original kyua test:
 op@opn sys kyua test gettimeofday_test
 gettimeofday_test:gettimeofday_err  -  broken: Premature exit; test
 case received signal 11 (core dumped)  [0.987s]
 gettimeofday_test:gettimeofday_mono  -  passed  [0.014s]

 Results file id is usr_tests_lib_libc_sys.20150707-215959-750045
 Results saved to
 /usr/home/op/.kyua/store/results.usr_tests_lib_libc_sys.20150707-215959-750045.db

 1/2 passed (1 failed)
 op@opn sys pwd
 /usr/tests/lib/libc/sys

 Please file a bug.

Will do.

Btw, here is one of the know good state:

op@robot sys# kyua test gettimeofday_test
gettimeofday_test:gettimeofday_err  -  passed  [0.026s]
gettimeofday_test:gettimeofday_mono  -  passed  [0.004s]

Results file id is usr_tests_lib_libc_sys.20150707-221532-875455
Results saved to
/root/.kyua/store/results.usr_tests_lib_libc_sys.20150707-221532-875455.db

2/2 passed (0 failed)
op@robot sys# uname -a
FreeBSD robot.hardenedbsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #100
6ab779a(HEAD): Wed May 27 02:04:09 EDT 2015
jenk...@nyi-01.build.hardenedbsd.org:/usr/obj/jenkins/workspace/HardenedBSD-master-amd64/sys/HARDENEDBSD
 amd64
op@robot sys#




 I have no idea where this broke because the Jenkins runs have been unreliable 
 over the past few weeks ;(...

Do you have died executors too?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Parallel release failed on pwd_mkdb

[Oliver Pinter]

Hi All!

We got this build failure, when two release make release running in parallel:

10-STABLE:
-

--
 stage 4.4: building everything
--
pwd_mkdb: /var/tmp/temproot/etc/pwd.db.tmp to
/var/tmp/temproot/etc/pwd.db: No such file or directory
*** Error code 1

Stop.
make[4]: stopped in /jenkins/workspace/HardenedBSD-10-STABLE-amd64/etc
*** Error code 1

Stop.
make[3]: stopped in /jenkins/workspace/HardenedBSD-10-STABLE-amd64
*** Error code 1

Stop.
make[2]: stopped in /jenkins/workspace/HardenedBSD-10-STABLE-amd64

  *** FATAL ERROR: Cannot 'cd' to
/jenkins/workspace/HardenedBSD-10-STABLE-amd64/release/.. and install
files to
  the temproot environment

*** Error code 1

Stop.
make[1]: stopped in /jenkins/workspace/HardenedBSD-10-STABLE-amd64/release
*** Error code 1


11-CURRENT:


pwd_mkdb -i -p -d /var/tmp/temproot/etc /var/tmp/temproot/etc/master.passwd
pwd_mkdb: /var/tmp/temproot/etc/pwd.db.tmp: File exists
*** Error code 1

Stop.
make[4]: stopped in /jenkins/workspace/HardenedBSD-master-amd64/etc
*** Error code 1

Stop.
make[3]: stopped in /jenkins/workspace/HardenedBSD-master-amd64
*** Error code 1

Stop.
make[2]: stopped in /jenkins/workspace/HardenedBSD-master-amd64

  *** FATAL ERROR: Cannot 'cd' to
/jenkins/workspace/HardenedBSD-master-amd64/release/.. and install
files to
  the temproot environment

*** Error code 1

Stop.
make[1]: stopped in /jenkins/workspace/HardenedBSD-master-amd64/release
*** Error code 1

I could work it around with build order dependency or with chrooted builds...

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

Re: Parallel release failed on pwd_mkdb

[Oliver Pinter]

On Mon, Jul 6, 2015 at 10:26 PM, Simon J. Gerraty s...@juniper.net wrote:
 Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 We got this build failure, when two release make release running in parallel:

 Can you elaborate what you mean by two release make release ?

Two concurrent make release would be the previous statement.

 Do you mean two separate builds running in the same tree at the same
 time using the same DESTDIR?

We building from separated git repos. Every target has an it's own,
and we don't specify custom DESTDIR, just issue a simple make
real-release in the ${SRCTOP}/release directory.


  stage 4.4: building everything
 --
 pwd_mkdb: /var/tmp/temproot/etc/pwd.db.tmp to
 /var/tmp/temproot/etc/pwd.db: No such file or directory
 *** Error code 1

 The pwd_mkdb command in etc uses $DESTDIR/etc - it obviously assumes
 that is unique.


I tracked down the issue to the ${SRCTOP}/release/scripts/mm-mtree.sh
file, which called without release specific temproot argument.

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

kernel build warning - XEN related

[Oliver Pinter]

Hi all!

I got this build warning with ~recent 11-CURRENT:

--- xen-locore.o ---
/usr/data/source/git/opBSD/opBSD.git/sys/amd64/amd64/xen-locore.S:45:1:
warning: DWARF2 only supports one section per compilation unit
.section __xen_guest
^
/usr/data/source/git/opBSD/opBSD.git/sys/amd64/amd64/xen-locore.S:46:2:
warning: DWARF2 only supports one section per compilation unit
 .pushsection .note.Xen ; .align 4 ; .long 2f - 1f ; .long 4f - 3f ;
.long 6 ; 1:.asciz Xen ; 2:.align 4 ; 3:.asciz FreeBSD ; 4:.align
4 ; .popsection
 ^
ctfconvert -L VERSION -g xen-locore.o
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: broken release generation when

[Oliver Pinter]

On 6/13/15, Glen Barber g...@freebsd.org wrote:
 [re@ CC'd]

 On Sat, Jun 13, 2015 at 02:34:37PM +0200, Oliver Pinter wrote:
 Hi all!

 We got build error with custom BRANCH= in newvers.sh. The release
 process unable to generate the ISO files but they not stopped with
 error, just ignore them, and continue with memstick images.


 cp /jenkins/workspace/HardenedBSD-stable-master-amd64/release/rc.local
 bootonly/etc
 sh
 /jenkins/workspace/HardenedBSD-stable-master-amd64/release/amd64/mkisoimages.sh
 -b 11_0_CURRENT_HARDENEDBSD_amd64_BO bootonly.iso bootonly
 100+0 records in
 100+0 records out
 409600 bytes transferred in 0.007822 secs (52361998 bytes/sec)
 newfs_msdos: cannot get number of sectors per track: Operation not
 supported
 newfs_msdos: cannot get number of heads: Operation not supported
 newfs_msdos: trim 44 sectors to adjust to a multiple of 63
 /dev/md0: 717 sectors in 717 FAT12 clusters (512 bytes/cluster)
 BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512
 Sectors=756 Media=0xf8 FATsecs=3 SecPerTrack=63 Heads=1 HiddenSecs=0
 makefs: error: The Disk Label must be at most 32 characters long
 usage: makefs [-t fs-type] [-o fs-options] [-d debug-mask] [-B endian]
  [-S sector-size] [-M minimum-size] [-m maximum-size] [-s image-size]
  [-b free-blocks] [-f free-files] [-F mtree-specfile] [-xZ]
  [-N userdb-dir] image-file directory | manifest [extra-directory ...]


 I think at this point either:

 1) VOLUME_LABEL should be removed; or
 2) VOLUME_LABEL should be only set if 'uname -s' returns 'FreeBSD'.

 There have been multiple reports of issues with this, and the workaround
 for edge cases is getting far too ugly at this point, so I prefer option
 (1).


Hmm, and seems like the memstick builds are affected too: try to boot
this: 
http://jenkins.hardenedbsd.org/builds/HardenedBSD-master-amd64/build-127/ISO-IMAGES/HardenedBSD-11-CURRENT_hardenedbsd-master-amd64-mini-memstick.img

 Glen


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

broken release generation when

[Oliver Pinter]

Hi all!

We got build error with custom BRANCH= in newvers.sh. The release
process unable to generate the ISO files but they not stopped with
error, just ignore them, and continue with memstick images.


cp /jenkins/workspace/HardenedBSD-stable-master-amd64/release/rc.local
bootonly/etc
sh 
/jenkins/workspace/HardenedBSD-stable-master-amd64/release/amd64/mkisoimages.sh
-b 11_0_CURRENT_HARDENEDBSD_amd64_BO bootonly.iso bootonly
100+0 records in
100+0 records out
409600 bytes transferred in 0.007822 secs (52361998 bytes/sec)
newfs_msdos: cannot get number of sectors per track: Operation not supported
newfs_msdos: cannot get number of heads: Operation not supported
newfs_msdos: trim 44 sectors to adjust to a multiple of 63
/dev/md0: 717 sectors in 717 FAT12 clusters (512 bytes/cluster)
BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512
Sectors=756 Media=0xf8 FATsecs=3 SecPerTrack=63 Heads=1 HiddenSecs=0
makefs: error: The Disk Label must be at most 32 characters long
usage: makefs [-t fs-type] [-o fs-options] [-d debug-mask] [-B endian]
[-S sector-size] [-M minimum-size] [-m maximum-size] [-s image-size]
[-b free-blocks] [-f free-files] [-F mtree-specfile] [-xZ]
[-N userdb-dir] image-file directory | manifest [extra-directory ...]

More info: 
http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-stable-master-amd64/59/console
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

[Oliver Pinter]

On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff gleb...@freebsd.org wrote:
   Hi!

 I've converted the ath(4), probably the most complex ieee80211 driver.

 The updated diff is uploaded to https://reviews.freebsd.org/D2655.

 Pretty sure it will panic or fail on first try :) Nevertheless,
 asking for your help. Please try to run it and report any problems
 to me.

Hi!

Do you have compile tested the code? I got this build error:

--- if_ath.o ---
/usr/src/sys/dev/ath/if_ath.c:5732:26: error: no member named 'ic_ifp'
in 'struct ieee80211com'; did you mean 'ic_dfs'?
struct ifnet *ifp = ic-ic_ifp;
^~
ic_dfs
/usr/src/sys/net80211/ieee80211_var.h:197:29: note: 'ic_dfs' declared here
struct ieee80211_dfs_state ic_dfs;  /* DFS state */
   ^
/usr/src/sys/dev/ath/if_ath.c:5732:16: error: initializing 'struct
ifnet *' with an expression of incompatible type 'struct
ieee80211_dfs_state'
struct ifnet *ifp = ic-ic_ifp;
  ^


 --
 Totus tuus, Glebius.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

[Oliver Pinter]

On Mon, Jun 1, 2015 at 9:55 PM, Oliver Pinter
oliver.pin...@hardenedbsd.org wrote:
 On Mon, Jun 1, 2015 at 9:47 PM, Oliver Pinter
 oliver.pin...@hardenedbsd.org wrote:
 On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff gleb...@freebsd.org wrote:
   Hi!

 I've converted the ath(4), probably the most complex ieee80211 driver.

 The updated diff is uploaded to https://reviews.freebsd.org/D2655.

 Pretty sure it will panic or fail on first try :) Nevertheless,
 asking for your help. Please try to run it and report any problems
 to me.

 Hi!

 Do you have compile tested the code? I got this build error:

 --- if_ath.o ---
 /usr/src/sys/dev/ath/if_ath.c:5732:26: error: no member named 'ic_ifp'
 in 'struct ieee80211com'; did you mean 'ic_dfs'?
 struct ifnet *ifp = ic-ic_ifp;
 ^~
 ic_dfs
 /usr/src/sys/net80211/ieee80211_var.h:197:29: note: 'ic_dfs' declared here
 struct ieee80211_dfs_state ic_dfs;  /* DFS state */
^
 /usr/src/sys/dev/ath/if_ath.c:5732:16: error: initializing 'struct
 ifnet *' with an expression of incompatible type 'struct
 ieee80211_dfs_state'
 struct ifnet *ifp = ic-ic_ifp;
   ^


 diff --git a/sys/dev/ath/if_ath.c b/sys/dev/ath/if_ath.c
 index 53763a6..b719ed4 100644
 --- a/sys/dev/ath/if_ath.c
 +++ b/sys/dev/ath/if_ath.c
 @@ -5729,8 +5729,7 @@ ath_scan_end(struct ieee80211com *ic)
  static void
  ath_update_chw(struct ieee80211com *ic)
  {
 -   struct ifnet *ifp = ic-ic_ifp;
 -   struct ath_softc *sc = ifp-if_softc;
 +   struct ath_softc *sc = ic-ic_softc;

 DPRINTF(sc, ATH_DEBUG_STATE, %s: called\n, __func__);
 ath_set_channel(ic);
 diff --git a/sys/dev/ath/if_ath_tdma.c b/sys/dev/ath/if_ath_tdma.c
 index fd23db1..d4c9ccd 100644
 --- a/sys/dev/ath/if_ath_tdma.c
 +++ b/sys/dev/ath/if_ath_tdma.c
 @@ -359,7 +359,7 @@ ath_tdma_update(struct ieee80211_node *ni,
  #defineTU_TO_TSF(_tu)  (((u_int64_t)(_tu))  10)
 struct ieee80211vap *vap = ni-ni_vap;
 struct ieee80211com *ic = ni-ni_ic;
 -   struct ath_softc *sc = ic-ic_ifp-if_softc;
 +   struct ath_softc *sc = ic-ic_softc;
 struct ath_hal *ah = sc-sc_ah;
 const HAL_RATE_TABLE *rt = sc-sc_currates;
 u_int64_t tsf, rstamp, nextslot, nexttbtt, nexttbtt_full;


And the same test against my atheros seems like working fine, both the
secondary VAP creation and destruction. I'm able to run kismet without
panic, and that seems too working fine.

In ath case I got some LOR during boot and during kismet, see the
attached dmesgs.

One confusing thing, that the underlaying devices (ath0 and iwn0) has
gone from ifconfig, and that's a little confusing, when you have
multiple pci card and try to create multiple VAP to specific device.

op@opn ~ ifconfig wlan0 scan
SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
IRA f4:ec:38:e4:48:b81   54M -91:-96  100 EPS  RSN
Fridel  38:60:77:d4:6b:811   54M -83:-96  100 EP   RSN HTCAP WPA WME
B4  f8:1a:67:38:9d:d86   54M -86:-96  100 EPS  RSN
HTCAP WPA WME ATH WPS
fagif8:d1:11:bd:f9:f66   54M -92:-96  100 EPS  RSN
HTCAP WPA WME ATH WPS
Koka10:fe:ed:b5:c7:6a   11   54M -77:-96  100 EPS  RSN
HTCAP WPA WME ATH WPS
Otti-home   b0:c5:54:86:16:9a   11   54M -93:-96  100 EPS  HTCAP
WPA RSN WME WPS
teszt   f8:1a:67:40:1d:b0   13   54M -93:-96  100 EPS  RSN
HTCAP WPA WME ATH WPS
Linksys7038520:aa:4b:78:31:e42   54M -96:-96  100 EPS  RSN HTCAP WME WPS
teszt2  20:e5:2a:5d:30:2a3   54M -93:-96  100 EP   HTCAP RSN WME WPS
hellooo c0:4a:00:ea:5a:ea5   54M -74:-96  100 EPS  RSN HTCAP ATH
op@opn ~ ifconfig wlan0 list ap
SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
IRA f4:ec:38:e4:48:b81   54M -91:-96  100 EPS  RSN
Fridel  38:60:77:d4:6b:811   54M -83:-96  100 EP   RSN HTCAP WPA WME
B4  f8:1a:67:38:9d:d86   54M -86:-96  100 EPS  RSN
HTCAP WPA WME ATH WPS
fagif8:d1:11:bd:f9:f66   54M -92:-96  100 EPS  RSN
HTCAP WPA WME ATH WPS
Koka10:fe:ed:b5:c7:6a   11   54M -77:-96  100 EPS  RSN
HTCAP WPA WME ATH WPS
Otti-home   b0:c5:54:86:16:9a   11   54M -93:-96  100 EPS  HTCAP
WPA RSN WME WPS
teszt   f8:1a:67:40:1d:b0   13   54M -93:-96  100 EPS  RSN
HTCAP WPA WME ATH WPS
Linksys7038520:aa:4b:78:31:e42   54M -96:-96  100 EPS  RSN HTCAP WME WPS
teszt2  20:e5:2a:5d:30:2a3   54M -93:-96  100 EP   HTCAP RSN WME WPS
hellooo c0:4a:00:ea:5a:ea5   54M -74:-96  100 EPS  RSN HTCAP ATH
op@opn ~ ifconfig wlan0 list sta
ADDR   AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS FLAG
c0:4a:00:ea:5a:ea45 135M 20.00  7 64 EPS  AEHTRS+
RSN HTCAP ATH


 --
 Totus tuus, Glebius.
 ___
 freebsd-current@freebsd.org

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

[Oliver Pinter]

On Mon, Jun 1, 2015 at 9:47 PM, Oliver Pinter
oliver.pin...@hardenedbsd.org wrote:
 On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff gleb...@freebsd.org wrote:
   Hi!

 I've converted the ath(4), probably the most complex ieee80211 driver.

 The updated diff is uploaded to https://reviews.freebsd.org/D2655.

 Pretty sure it will panic or fail on first try :) Nevertheless,
 asking for your help. Please try to run it and report any problems
 to me.

 Hi!

 Do you have compile tested the code? I got this build error:

 --- if_ath.o ---
 /usr/src/sys/dev/ath/if_ath.c:5732:26: error: no member named 'ic_ifp'
 in 'struct ieee80211com'; did you mean 'ic_dfs'?
 struct ifnet *ifp = ic-ic_ifp;
 ^~
 ic_dfs
 /usr/src/sys/net80211/ieee80211_var.h:197:29: note: 'ic_dfs' declared here
 struct ieee80211_dfs_state ic_dfs;  /* DFS state */
^
 /usr/src/sys/dev/ath/if_ath.c:5732:16: error: initializing 'struct
 ifnet *' with an expression of incompatible type 'struct
 ieee80211_dfs_state'
 struct ifnet *ifp = ic-ic_ifp;
   ^


diff --git a/sys/dev/ath/if_ath.c b/sys/dev/ath/if_ath.c
index 53763a6..b719ed4 100644
--- a/sys/dev/ath/if_ath.c
+++ b/sys/dev/ath/if_ath.c
@@ -5729,8 +5729,7 @@ ath_scan_end(struct ieee80211com *ic)
 static void
 ath_update_chw(struct ieee80211com *ic)
 {
-   struct ifnet *ifp = ic-ic_ifp;
-   struct ath_softc *sc = ifp-if_softc;
+   struct ath_softc *sc = ic-ic_softc;

DPRINTF(sc, ATH_DEBUG_STATE, %s: called\n, __func__);
ath_set_channel(ic);
diff --git a/sys/dev/ath/if_ath_tdma.c b/sys/dev/ath/if_ath_tdma.c
index fd23db1..d4c9ccd 100644
--- a/sys/dev/ath/if_ath_tdma.c
+++ b/sys/dev/ath/if_ath_tdma.c
@@ -359,7 +359,7 @@ ath_tdma_update(struct ieee80211_node *ni,
 #defineTU_TO_TSF(_tu)  (((u_int64_t)(_tu))  10)
struct ieee80211vap *vap = ni-ni_vap;
struct ieee80211com *ic = ni-ni_ic;
-   struct ath_softc *sc = ic-ic_ifp-if_softc;
+   struct ath_softc *sc = ic-ic_softc;
struct ath_hal *ah = sc-sc_ah;
const HAL_RATE_TABLE *rt = sc-sc_currates;
u_int64_t tsf, rstamp, nextslot, nexttbtt, nexttbtt_full;


 --
 Totus tuus, Glebius.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Race VT+X11 on -current

[Oliver Pinter]

Hi Hans!

On 5/10/15, Hans Petter Selasky h...@selasky.org wrote:
 On 05/10/15 18:53, Wolfgang Zenker wrote:
 Hi,

 * Hans Petter Selasky h...@selasky.org [150510 14:47]:
 On 05/09/15 23:05, Wolfgang Zenker wrote:
 * Allan Jude allanj...@freebsd.org [150508 16:29]:
 [..]
 My experience is a little different.

 When suspend/resuming my laptop (Lenovo T530 with nVidia gpu)

 Sometimes when I resume, it seems like the keyboard is frozen. If I
 alt+f1, then alt+f9, it seems to work fine after that. I'd never
 though
 of trying just alt+f9 right away, as I could already see my X session.

 Not sure if this is related, but it sounds very similar.

 Similar problem on 10-STABLE: I usually start X by running startx
 on ttyv0. After exiting X screen shows ttyv0 again but keyboard
 appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to
 ttyv1 and back unfreezes keyboard.

 Can you try applying to 10-stable:

 https://svnweb.freebsd.org/changeset/base/282645

 Patch needs a little tweaking to apply in vt_resume() on 10-stable
 (vd is main_vd here), but appears to fix the problem.


 Hi,

 Sounds good. I'll MFC the patch sometime next week. Seems like more
 people need it for daily FreeBSD use :-)

I have this fix or enhancements in our HardenedBSD codebase:
https://github.com/HardenedBSD/hardenedBSD/commit/18058137da01598403b6ffa40c37b0a907441530
Please review them, and if you feel this required in FreeBSD too, and
cherry-pick them.


 --HPS

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

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

Re: CTF: wpa_supplicant/hostapd 2.4 import

[Oliver Pinter]

On 4/26/15, Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 On 4/23/15, Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 Rui, FYI:
 http://w1.fi/security/2015-1/wpa_supplicant-p2p-ssid-overflow.txt

 On Sun, Apr 19, 2015 at 9:41 PM, Rui Paulo rpa...@me.com wrote:
 Hi,

 Please test the new wpa_supplicant/hostapd.  Here's the patch against
 FreeBSD
 HEAD:

 https://people.freebsd.org/~rpaulo/wpa-2.4.diff

 Thanks,

 Hi Rui!

 Could you please cherry-pick / merge this commit from DragonflyBSD:
 https://github.com/DragonFlyBSD/DragonFlyBSD/commit/584c4a9f0c9071cb62abe9c870a2b08afe746a88
 ?

 This fixes the CVE-2015-1863 .

And this is the original commit:
http://w1.fi/cgit/hostap/commit/src/p2p/p2p.c?id=9ed4eee345f85e3025c33c6e20aa25696e341ccd



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


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

Re: CTF: wpa_supplicant/hostapd 2.4 import

[Oliver Pinter]

On 4/23/15, Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 Rui, FYI: http://w1.fi/security/2015-1/wpa_supplicant-p2p-ssid-overflow.txt

 On Sun, Apr 19, 2015 at 9:41 PM, Rui Paulo rpa...@me.com wrote:
 Hi,

 Please test the new wpa_supplicant/hostapd.  Here's the patch against
 FreeBSD
 HEAD:

 https://people.freebsd.org/~rpaulo/wpa-2.4.diff

 Thanks,

Hi Rui!

Could you please cherry-pick / merge this commit from DragonflyBSD:
https://github.com/DragonFlyBSD/DragonFlyBSD/commit/584c4a9f0c9071cb62abe9c870a2b08afe746a88
?

This fixes the CVE-2015-1863 .

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

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

Re: CTF: wpa_supplicant/hostapd 2.4 import

[Oliver Pinter]

Rui, FYI: http://w1.fi/security/2015-1/wpa_supplicant-p2p-ssid-overflow.txt

On Sun, Apr 19, 2015 at 9:41 PM, Rui Paulo rpa...@me.com wrote:
 Hi,

 Please test the new wpa_supplicant/hostapd.  Here's the patch against FreeBSD
 HEAD:

 https://people.freebsd.org/~rpaulo/wpa-2.4.diff

 Thanks,
 --
 Rui Paulo
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Kernel build failed in sys/x86/acpica @r281433

[Oliver Pinter]

On 4/11/15, David Wolfskill da...@catwhisker.org wrote:
 Running:
 FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1565
 r281363M/281366:1100068: Fri Apr 10 05:41:13 PDT 2015
 r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386

 World builds OK; kernel is OK up to:

 ...
 stage 3.2: building everything
 ...
 --- legacy.o ---
 cc  -c -O -pipe  -g -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
 -Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas
 -Wno-error-tautological-compare -Wno-error-empty-body
 -Wno-error-parentheses-equality -Wno-error-unused-function
 -Wno-error-pointer-sign -nostdinc  -I. -I/usr/src/sys
 -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL
 -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -mno-mmx -mno-sse
 -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2
 -Wno-error-tautological-compare -Wno-error-empty-body
 -Wno-error-parentheses-equality -Wno-error-unused-function
 -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
 -Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unkno---
 OsdEnvironment.o ---
 /usr/src/sys/x86/acpica/OsdEnvironment.c:73:39: error: incompatible pointer
 types passing 'ACPI_SIZE *' (aka 'unsigned int *') to parameter of type
 'ACPI_PHYSICAL_ADDRESS *' (aka 'unsigned long long *')
 [-Werror,-Wincompatible-pointer-types]
 if (ACPI_SUCCESS(AcpiFindRootPointer(acpi_root)))
  ^~
 /usr/src/sys/contrib/dev/acpica/include/acexcep.h:94:44: note: expanded from
 macro 'ACPI_SUCCESS'
 #define ACPI_SUCCESS(a) (!(a))
^
 /usr/src/sys/contrib/dev/acpica/include/acpixf.h:506:30: note: passing
 argument to parameter 'RsdpAddress' here
 ACPI_PHYSICAL_ADDRESS   *RsdpAddress))
  ^
 /usr/src/sys/contrib/dev/acpica/include/acpixf.h:96:5: note: expanded from
 macro 'ACPI_EXTERNAL_RETURN_STATUS'
 Prototype;
 ^
 1 error generated.
 ...
 --- OsdEnvironment.o ---
 *** [OsdEnvironment.o] Error code 1

 make[2]: stopped in /common/S4/obj/usr/src/sys/CANARY
 


Confirmed, jenkins build log is here:
http://nyi-01.build.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-i386/56/console

 and things tend to go downhill from that point.

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

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

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

WARNING: FOO.c: enum pmc_event has too many values: 1930 1023

[Oliver Pinter]

Hi all!

I just found the line in the subject in our jenkinsbuild  log in both
amd64 and i386 case (we don't modified these files):

http://nyi-01.build.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-i386/56/console
http://nyi-01.build.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/58/consoleFull

And more similar lines:

WARNING: kern_pmc.c: enum pmc_event has too many values: 1930  1023
WARNING: kern_rwlock.c: enum pmc_event has too many values: 1930  1023
WARNING: kern_sx.c: enum pmc_event has too many values: 1930  1023
WARNING: kern_clock.c: enum pmc_event has too many values: 1930  1023
WARNING: kern_mutex.c: enum pmc_event has too many values: 1930  1023
WARNING: trap.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_soft.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_intel.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_amd.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_tsc.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_x86.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_logging.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_piv.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_uncore.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_core.c: enum pmc_event has too many values: 1930  1023
WARNING: hwpmc_mod.c: enum pmc_event has too many values: 1930  1023
WARNING: kern_lock.c: enum pmc_event has too many values: 1930  1023

and some other hwpmc related warnings too:
--- kern_pmc.o ---
/jenkins/workspace/HardenedBSD-master-amd64/sys/kern/kern_pmc.c:290:32:
warning: comparison of constant 131072 with expression of type 'enum
pmc_event' is always false
[-Wtautological-constant-out-of-range-compare]
KASSERT(ps-ps_ev.pm_ev_code = PMC_EV_SOFT_FIRST 
 ^  ~
/jenkins/workspace/HardenedBSD-master-amd64/sys/sys/systm.h:84:24:
note: expanded from macro 'KASSERT'
if (__predict_false(!(exp)))\
  ^
/jenkins/workspace/HardenedBSD-master-amd64/sys/sys/cdefs.h:453:51:
note: expanded from macro '__predict_false'
#define __predict_false(exp)__builtin_expect((exp), 0)
  ^
/jenkins/workspace/HardenedBSD-master-amd64/sys/kern/kern_pmc.c:291:28:
warning: comparison of constant 135167 with expression of type 'enum
pmc_event' is always true
[-Wtautological-constant-out-of-range-compare]
ps-ps_ev.pm_ev_code = PMC_EV_SOFT_LAST,
 ^
/jenkins/workspace/HardenedBSD-master-amd64/sys/sys/systm.h:84:24:
note: expanded from macro 'KASSERT'
if (__predict_false(!(exp)))\
  ^
/jenkins/workspace/HardenedBSD-master-amd64/sys/sys/cdefs.h:453:51:
note: expanded from macro '__predict_false'
#define __predict_false(exp)__builtin_expect((exp), 0)
  ^
--- kern_prot.o ---
--- kern_pmc.o ---
/jenkins/workspace/HardenedBSD-master-amd64/sys/kern/kern_pmc.c:307:13:
warning: comparison of constant 131072 with expression of type 'enum
pmc_event' is always false
[-Wtautological-constant-out-of-range-compare]
KASSERT(ev = PMC_EV_SOFT_FIRST 
~~ ^  ~
/jenkins/workspace/HardenedBSD-master-amd64/sys/sys/systm.h:84:24:
note: expanded from macro 'KASSERT'
if (__predict_false(!(exp)))\
  ^
/jenkins/workspace/HardenedBSD-master-amd64/sys/sys/cdefs.h:453:51:
note: expanded from macro '__predict_false'
#define __predict_false(exp)__builtin_expect((exp), 0)
  ^
/jenkins/workspace/HardenedBSD-master-amd64/sys/kern/kern_pmc.c:308:9:
warning: comparison of constant 135167 with expression of type 'enum
pmc_event' is always true
[-Wtautological-constant-out-of-range-compare]
ev = PMC_EV_SOFT_LAST,
~~ ^
/jenkins/workspace/HardenedBSD-master-amd64/sys/sys/systm.h:84:24:
note: expanded from macro 'KASSERT'
if (__predict_false(!(exp)))\
  ^
/jenkins/workspace/HardenedBSD-master-amd64/sys/sys/cdefs.h:453:51:
note: expanded from macro '__predict_false'
#define __predict_false(exp)__builtin_expect((exp), 0)
  ^
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Call For Testers: Synaptics touchpads

[Oliver Pinter]

Is there any special settings / requirements for xorg.conf to enable
the palm detection and similar features?

On Wed, Apr 8, 2015 at 3:13 PM, Shawn Webb shawn.w...@hardenedbsd.org wrote:
 On Wed, 2015-04-08 at 00:19 -0700, Rui Paulo wrote:
 Hi,

 The attached patch adds support for newer touchpad features and implements 
 two
 finger scrolling.  This is such a common feature these days that I think we
 should enable it by default and disable edge scrolling.  I've implemented 
 some
 detection code to keep edge scrolling enabled when the touchpad has a
 dedicated area for scrolling.

 Please test it and report back your experience.  To enable synaptics support,
 you need:

 hw.psm.synaptics_support=1

 in loader.conf.

 Hey Rui,

 I'm excited to have this and will test this out this week. Do I need to
 recompile any ports (namely, the xf86-input-synaptics port) after
 applying this patch?

 Thanks,

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

Re: Dual booting FreeBSD and Win95

[Oliver Pinter]

As dirty hack, try to save two state of MBR, one when FreeBSD selected
(MBR.FBSD) , and one when Win95 selected (MBR.W95).
When the windows booted up properly, then write the MBR.FBSD to the
disc, on the same schema do the reverse on freebsd with dd.

http://www.fccps.cz/download/adv/frr/wipembr.html

Or just do what Adrian has said, flip the active bits with a custom tool.

On Wed, Apr 8, 2015 at 9:30 PM, Ryan Stone ryst...@gmail.com wrote:
 No, this isn't a late April Fools joke. :(

 I find myself in a situation where I need to integrate my employer's
 manufacturing process with a third-party OEM's process.  My employer's
 hardware tests are all FreeBSD-based while the OEM is Windows 95 based.  I
 need to come up with a way to integrate them together.

 We're looking at dual-booting FreeBSD and Win95.  We're thinking of booting
 into Win95, the OEM can do their thing, switch to booting FreeBSD, run our
 tests and produce a .csv file with the results, and then boot back into
 Win95 for them to finish up.  Ideally we would like to switch the boot
 slice without human interaction.

 I've been playing around with trying to set one only slice as active to
 make the loader boot it, but it appears that doesn't actually work.
 boot0cfg would cover half of the use case (switching from FreeBSD back to
 Win95), but I'm not sure how I could do the original switch from Win95 to
 FreeBSD.

 We've discussed just switching hard drives, but we really want to shoot for
 a 100% automated process.  Anybody have any ideas?
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Broadwell Support FreeBSD 10.1

[Oliver Pinter]

On Mon, Mar 23, 2015 at 12:32 AM, Marek Novotny
marek.novo...@marspolar.com wrote:
 Hi group,

 New to this group, and new to FreeBSD via PC-BSD. Really like it so far.
 Sorry if this has been asked to death already. Levono has their new T450
 with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of
 running PC-BSD latest version on it. It uses intel 5500 graphics as well.
 Any potential issues using this??

Not really, FreeBSD neither have haswell (Gen 4) support.

https://wiki.freebsd.org/Graphics


 --
 Marek Novotny
 https://github.com/marek-novotny

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

Re: atkbd.c not compiling?

[Oliver Pinter]

On Sat, Feb 28, 2015 at 10:25 PM, Ryan Stone ryst...@gmail.com wrote:
 I updated my source tree this morning and now I'm seeing this compile
 error in make tinderbox;

 /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:382:26: error: use of 
 undecla
 red identifier 'key_map'; did you mean 'keymap'?
 keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT);
^~~
keymap
 /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:358:12: note: 'keymap' 
 declar
 ed here
 keymap_t *keymap;
 /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:383:26: error: use of 
 undecla
 red identifier 'accent_map'; did you mean 'accentmap_t'?
 accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT);
^
 /repos/users/rstone/freebsd/sys/sys/kbio.h:210:26: note: 'accentmap_t' 
 declared
 here
 typedef struct accentmap accentmap_t;


Hi!

See these PRs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193817
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744



 (By the way, this is the second time in two days that make tinderbox
 has been broken for me.  It's extremely frustrating that I can't test
 my pending commits because others haven't done me the same courtesy)
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: atkbd.c not compiling?

[Oliver Pinter]

On Sat, Feb 28, 2015 at 11:19 PM, Garrett Cooper yaneurab...@gmail.com wrote:
 On Feb 28, 2015, at 14:15, Garrett Cooper yaneurab...@gmail.com wrote:

 On Feb 28, 2015, at 13:56, Ryan Stone ryst...@gmail.com wrote:

 On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper yaneurab...@gmail.com 
 wrote:
 I’m not sure about key_map — are you building with syscons or vt?

 I have no idea.  I'm just running make tinderbox.  So far
 _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed,
 among others.

 i386.LINT and sparc64.LINK have both device sc and device vt from
 what I can see

 I think I figured it out. Is it because MK_VT != “no” and MK_LEGACY_CONSOLE 
 == “no”?

 … or because MK_SYSCONS == no?

No, when you try to compile vt enabled kernel on system which running
on syscons, or the versa, then you got this problem.
Try to compile with the us.pc-ctrl or us.ctrl keyboard layout.

In bugzilla exists some patch, that fixes this issue, by altering the
font search path.

The other remaining problem is, when use try to use the VT, and it
required the kbdmux layer. The kbdmux layer then discards the custom
keyboard layout, which is configured at ukbd or atkbd level. Fix
already exists in bugzilla too.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC] load network config file from netif init script

[Oliver Pinter]

On Wed, Feb 25, 2015 at 9:34 PM, John Baldwin j...@freebsd.org wrote:
 On Monday, February 02, 2015 12:21:19 PM Roger Pau Monné wrote:
 Hello,

 r272959 broke compatibility with mfsBSD that stores the default network
 config file in /etc/rc.conf.d/network. In order to fix that load the
 network config file from netif also.

 I'm attaching a patch to restore previous functionality, but since I'm
 not an expert on rc.d init scripts I would like some feedback on whether
 this is the right approach or not.

 Thanks, Roger.

 If you are still looking for review, you can try freebsd-rc@ perhaps?

This patch was already committed to CURRENT.


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

Re: URGENT: RNG broken for last 4 months

[Oliver Pinter]

On Tue, Feb 17, 2015 at 11:19 PM, Fabian Keil
freebsd-lis...@fabiankeil.de wrote:
 John-Mark Gurney j...@funkthat.com wrote:

 If you are running a current kernel r273872 or later, please upgrade
 your kernel to r278907 or later immediately and regenerate keys.

 I tried ...

 start_init: trying /sbin/init
 118[20] Setting hostuuid: [...]
 118[20] Setting hostid: [...
 [20]
 [20]
 [20] Fatal trap 12: page fault while in kernel mode
 [20] cpuid = 1; apic id = 01
 [20] fault virtual address  = 0xf7ff1defb51c
 [20] fault code = supervisor read data, page not present
 [20] instruction pointer= 0x20:0x819eaed5
 [20] stack pointer  = 0x28:0xfe009397b890
 [20] frame pointer  = 0x28:0xfe009397b8d0
 [20] code segment   = base 0x0, limit 0xf, type 0x1b
 [20]= DPL 0, pres 1, long 1, def32 0, gran 1
 [20] processor eflags   = interrupt enabled, resume, IOPL = 0
 [20] current process= 43 (zfs)
 [...]
 ) at pcpu.h:219
 219 pcpu.h: No such file or directory.
 in pcpu.h
 (kgdb) where
 #0  doadump (textdump=Unhandled dwarf expression opcode 0x93
 ) at pcpu.h:219
 #1  0x8031539e in db_dump (dummy=value optimized out, 
 dummy2=Unhandled dwarf expression opcode 0x93
 ) at /usr/src/sys/ddb/db_command.c:533
 #2  0x80314e7c in db_command (cmd_table=0x0) at 
 /usr/src/sys/ddb/db_command.c:440
 #3  0x80314be4 in db_command_loop () at 
 /usr/src/sys/ddb/db_command.c:493
 #4  0x803177a0 in db_trap (type=value optimized out, code=Unhandled 
 dwarf expression opcode 0x93
 ) at /usr/src/sys/ddb/db_main.c:251
 #5  0x805ff8ee in kdb_trap (type=Unhandled dwarf expression opcode 
 0x93
 ) at /usr/src/sys/kern/subr_kdb.c:654
 #6  0x80889db9 in trap_fatal (frame=0xfe009397b7e0, eva=value 
 optimized out) at /usr/src/sys/amd64/amd64/trap.c:856
 #7  0x8088a131 in trap_pfault (frame=0xfe009397b7e0, 
 usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:678
 #8  0x8088976e in trap (frame=0xfe009397b7e0) at 
 /usr/src/sys/amd64/amd64/trap.c:426
 #9  0x8086cd82 in calltrap () at 
 /usr/src/sys/amd64/amd64/exception.S:235
 #10 0x819eaed5 in vdev_mirror_dva_select (zio=0xf80006549398, 
 p=-974039959) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:317
 #11 0x819eae4a in vdev_mirror_preferred_child_randomize 
 (zio=0xf80006549398) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:334
 #12 0x819eaba1 in vdev_mirror_child_select (zio=0xf80006549398) 
 at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:404
 #13 0x819ea177 in vdev_mirror_io_start (zio=0xf80006549398) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:460
 #14 0x81a1d73d in zio_vdev_io_start (zio=0xf80006549398) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2680
 #15 0x81a19c14 in zio_execute (zio=0xf80006549398) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1499
 #16 0x81a18945 in zio_wait (zio=0xf80006549398) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1523
 #17 0x81938db2 in arc_read (pio=0x0, spa=0xf8000634e000, 
 bp=0xf800065c5048, done=0x81937ae0 arc_getbuf_func, 
 private=0xf800065c9410, priority=ZIO_PRIORITY_SYNC_READ,
 zio_flags=128, arc_flags=0xfe009397c004, zb=0xfe009397bfe0) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3610
 #18 0x81964326 in dmu_objset_open_impl (spa=0xf8000634e000, 
 ds=0x0, bp=0xf800065c5048, osp=0xf800065c5008) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:307
 #19 0x81991404 in dsl_pool_init (spa=0xf8000634e000, 
 txg=1056266109, dpp=0xf8000634e2e8) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:282
 #20 0x819c8b08 in spa_load_impl (spa=0xf8000634e000, 
 pool_guid=4830954193867998892, config=0xf80002599ee0, 
 state=SPA_LOAD_OPEN, type=SPA_IMPORT_EXISTING, mosconfig=0,
 ereport=0xfe009397c4e0) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:2406
 #21 0x819c0987 in spa_load (spa=0xf8000634e000, 
 state=SPA_LOAD_OPEN, type=SPA_IMPORT_EXISTING, mosconfig=0) at 
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:2178
 #22 0x819bfda9 in spa_load_best (spa=0xf8000634e000, 
 state=SPA_LOAD_OPEN, mosconfig=0, max_request=18446744073709551615, 
 rewind_flags=1)
 at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:2903
 #23 0x819babe9 in spa_open_common (pool=0xfe0003232000 tank, 
 spapp=0xfe009397c6f0, tag=0x81ade789, nvpolicy=0x0, config=0x0)
 at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3026
 #24 0x819bafcb 

Re: Will all kernel functions be loaded into memory, in the same address space with kernel modules?

[Oliver Pinter]

On Tue, Jan 27, 2015 at 6:21 AM, Yue Chen ycyc...@gmail.com wrote:
 My purpose is to modify kernel function instructions directly through
 memory at runtime.

 First I use objdump -S kernel to see the function names and their
 addresses. And then I use pointers to peek into the content at certain
 function address area (.text segment). However, their content is different
 from the result from objdump -S kernel. I use a FreeBSD 10.1 kernel,
 which has no ASLR supported as I know.

 Is it because that the kernel function addresses are relocated? Or some
 kernel functions are not loaded into memory? Or is it not suitable to peek
 kernel .text content from a kernel module?

 I only objdump -S the built kernel with debug symbols, not .ko files.

Take a look at this branch:
https://github.com/HardenedBSD/hardenedBSD/tree/hardened/current/intel-smap

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

Re: sendmail make distribution error and fix

[Oliver Pinter]

On 1/7/15, Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 Hi!

 I got this error, when I try to make distribution*:

 cd /target/usr/src/etc/sendmail; make distribution
 install -o root -g wheel -m 644
 /target/usr/src/etc/sendmail/freebsd.mc freebsd.cf /target/etc/mail
 install: freebsd.cf: No such file or directory
 *** Error code 71

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

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

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

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

 The attached patch fixed the problem.

 *:
 #!/usr/bin/env csh

 set MAKEOBJDIRPREFIX=/target/usr/obj
 set SRC_DIR=/target/usr/src
 set DESTDIR=/target

 cd ${SRC_DIR}

 make -j5 buildworld MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}
 make -j5 kernel MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}

 make installworld DESTDIR=${DESTDIR} MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}
 make distribution DESTDIR=${DESTDIR} MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}

 cp /etc/make.conf /target/etc/
 cp /etc/src.conf /target/etc/
 cp /etc/rc.conf /target/etc/


please ignore this report, I found the bug elsewhere...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

sendmail make distribution error and fix

[Oliver Pinter]

Hi!

I got this error, when I try to make distribution*:

cd /target/usr/src/etc/sendmail; make distribution
install -o root -g wheel -m 644
/target/usr/src/etc/sendmail/freebsd.mc freebsd.cf /target/etc/mail
install: freebsd.cf: No such file or directory
*** Error code 71

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

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

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

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

The attached patch fixed the problem.

*:
#!/usr/bin/env csh

set MAKEOBJDIRPREFIX=/target/usr/obj
set SRC_DIR=/target/usr/src
set DESTDIR=/target

cd ${SRC_DIR}

make -j5 buildworld MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}
make -j5 kernel MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}

make installworld DESTDIR=${DESTDIR} MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}
make distribution DESTDIR=${DESTDIR} MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}

cp /etc/make.conf /target/etc/
cp /etc/src.conf /target/etc/
cp /etc/rc.conf /target/etc/


0001-HBSD-fix-make-distribution.patch
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

[Oliver Pinter]

I checked in amd64 case on my desktop machine, and building fine.
After that, I looked again into build log, and I found this:

make[2]: stopped in
/usr/obj/i386.i386/jenkins/workspace/HardenedBSD_Master/sys/HARDENEDBSD
1 error

make[2]: stopped in
/usr/obj/i386.i386/jenkins/workspace/HardenedBSD_Master/sys/HARDENEDBSD
*** [buildkernel] Error code 2

Seems like, the error affected the i386 case.


On Thu, Jan 1, 2015 at 6:53 PM, Dimitry Andric d...@freebsd.org wrote:
 On 01 Jan 2015, at 18:35, Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 We at  HardenedBSD got this error, with out jenkins instance:

 --- dis_tables.o ---
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3025:25:
 error: '' within '||' [-Werror,-Wlogical-op-parentheses]
if (cpu_mode == SIZE64  dp-it_invalid64 ||
~~~^~~ ~~
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3025:25:
 note: place parentheses around the '' expression to silence this
 warning
if (cpu_mode == SIZE64  dp-it_invalid64 ||
   ^
( )
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3026:25:
 error: '' within '||' [-Werror,-Wlogical-op-parentheses]
cpu_mode != SIZE64  dp-it_invalid32)
~~~^~~
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3026:25:
 note: place parentheses around the '' expression to silence this
 warning
cpu_mode != SIZE64  dp-it_invalid32)
   ^
( )
 --- all_subdir_ed ---

 I can't reproduce this warning here, at least not with pristine head.

 Did you change any of the -Wno-xxx flags in your customized source tree?

 -Dimitry

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

Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

[Oliver Pinter]

No, we don't touch them. Only added -DHARDEBEDBSD into make
environment.  I will schedule a new round of build to recheck them,

On Thu, Jan 1, 2015 at 6:53 PM, Dimitry Andric d...@freebsd.org wrote:
 On 01 Jan 2015, at 18:35, Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 We at  HardenedBSD got this error, with out jenkins instance:

 --- dis_tables.o ---
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3025:25:
 error: '' within '||' [-Werror,-Wlogical-op-parentheses]
if (cpu_mode == SIZE64  dp-it_invalid64 ||
~~~^~~ ~~
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3025:25:
 note: place parentheses around the '' expression to silence this
 warning
if (cpu_mode == SIZE64  dp-it_invalid64 ||
   ^
( )
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3026:25:
 error: '' within '||' [-Werror,-Wlogical-op-parentheses]
cpu_mode != SIZE64  dp-it_invalid32)
~~~^~~
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3026:25:
 note: place parentheses around the '' expression to silence this
 warning
cpu_mode != SIZE64  dp-it_invalid32)
   ^
( )
 --- all_subdir_ed ---

 I can't reproduce this warning here, at least not with pristine head.

 Did you change any of the -Wno-xxx flags in your customized source tree?

 -Dimitry

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

Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

[Oliver Pinter]

No difference between FreeBSD's and our dis_tables.c file, and we
added the following modification to master Makefile:

op@robot hardenedBSD.git.opntr git diff origin/master
origin/hardened/current/master -- sys/cddl/dev/dtrace/x86/dis_tables.c
op@robot hardenedBSD.git.opntr git diff origin/master
origin/hardened/current/master -- us
usr.bin/  usr.sbin/
op@robot hardenedBSD.git.opntr git diff origin/master
origin/hardened/current/master -- share/mk
mk/   mklocale/
op@robot hardenedBSD.git.opntr git diff origin/master
origin/hardened/current/master -- share/mk
diff --git a/share/mk/Makefile b/share/mk/Makefile
index cd69ca8..7e1b51f 100644
--- a/share/mk/Makefile
+++ b/share/mk/Makefile
@@ -13,6 +13,7 @@ FILES=\
bsd.doc.mk \
bsd.endian.mk \
bsd.files.mk \
+   bsd.hardenedbsd.mk \
bsd.incs.mk \
bsd.info.mk \
bsd.init.mk \
diff --git a/share/mk/bsd.hardenedbsd.mk b/share/mk/bsd.hardenedbsd.mk
new file mode 100644
index 000..9d5bcd3
--- /dev/null
+++ b/share/mk/bsd.hardenedbsd.mk
@@ -0,0 +1,2 @@
+CFLAGS+=   -DHARDENEDBSD
+CXXFLAGS+= -DHARDENEDBSD
diff --git a/share/mk/sys.mk b/share/mk/sys.mk
index f691820..1edb4d8 100644
--- a/share/mk/sys.mk
+++ b/share/mk/sys.mk
@@ -368,3 +368,5 @@ SHELL=  ${__MAKE_SHELL}
 .include bsd.cpu.mk

 .endif # ! Posix
+
+.include bsd.hardenedbsd.mk

and our origin/master is a vanilla copy of FreeBSD's master:

op@robot hardenedBSD.git.opntr git fetch freebsd
remote: Counting objects: 2753, done.
remote: Compressing objects: 100% (1653/1653), done.
remote: Total 2753 (delta 1379), reused 1987 (delta 1088)
Receiving objects: 100% (2753/2753), 6.19 MiB | 556.00 KiB/s, done.
Resolving deltas: 100% (1379/1379), done.
From https://github.com/freebsd/freebsd
   1daffcf..16bfeff  master - freebsd/master
   4ce956b..2786226  projects/arm_intrng - freebsd/projects/arm_intrng
   8afde97..e891a45  projects/building-blocks -
freebsd/projects/building-blocks
   ae94017..79b9044  projects/clang350-import -
freebsd/projects/clang350-import
 * [new branch]  projects/elftoolchain-update-r3130 -
freebsd/projects/elftoolchain-update-r3130
   191c3a1..ef329bf  projects/ifnet - freebsd/projects/ifnet
 + f39bd7c...33c47ad projects/ino64 - freebsd/projects/ino64  (forced update)
 * [new branch]  projects/paravirt - freebsd/projects/paravirt
   fdb4571..637702c  projects/routing - freebsd/projects/routing
   e3732e9..6970b8a  projects/sendfile - freebsd/projects/sendfile
   73a106c..4bbc2e1  releng/10.0 - freebsd/releng/10.0
   29f4af5..8bdb2f8  releng/10.1 - freebsd/releng/10.1
   93a7c22..6c98ecd  releng/8.4 - freebsd/releng/8.4
   18b185b..42bd402  releng/9.1 - freebsd/releng/9.1
   62fc296..81febb2  releng/9.2 - freebsd/releng/9.2
   587e3b5..825bd30  releng/9.3 - freebsd/releng/9.3
   f3fce3a..f0fc25a  stable/10  - freebsd/stable/10
   038c20d..2a2bb65  stable/7   - freebsd/stable/7
   ab2b3fb..4ece3be  stable/8   - freebsd/stable/8
   cd6870d..4c08e33  stable/9   - freebsd/stable/9
   dab26aa..b4e212b  svn_head   - freebsd/svn_head
   947b121..2d9be08  user/cperciva/freebsd-update-build -
freebsd/user/cperciva/freebsd-update-build
   e94160d..f74291e  user/marcel/libvdsk - freebsd/user/marcel/libvdsk
   aeef35a..7a5b8d5  user/pho/stress2 - freebsd/user/pho/stress2
op@robot hardenedBSD.git.opntr git diff freebsd/master origin/master
op@robot hardenedBSD.git.opntr



And I started a new instance of build/

On Thu, Jan 1, 2015 at 7:20 PM, Oliver Pinter
oliver.pin...@hardenedbsd.org wrote:
 No, we don't touch them. Only added -DHARDEBEDBSD into make
 environment.  I will schedule a new round of build to recheck them,

 On Thu, Jan 1, 2015 at 6:53 PM, Dimitry Andric d...@freebsd.org wrote:
 On 01 Jan 2015, at 18:35, Oliver Pinter oliver.pin...@hardenedbsd.org 
 wrote:
 We at  HardenedBSD got this error, with out jenkins instance:

 --- dis_tables.o ---
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3025:25:
 error: '' within '||' [-Werror,-Wlogical-op-parentheses]
if (cpu_mode == SIZE64  dp-it_invalid64 ||
~~~^~~ ~~
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3025:25:
 note: place parentheses around the '' expression to silence this
 warning
if (cpu_mode == SIZE64  dp-it_invalid64 ||
   ^
( )
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3026:25:
 error: '' within '||' [-Werror,-Wlogical-op-parentheses]
cpu_mode != SIZE64  dp-it_invalid32)
~~~^~~
 /jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3026:25:
 note: place parentheses around the '' expression to silence this
 warning
cpu_mode != SIZE64  dp-it_invalid32

Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

[Oliver Pinter]

Hi!

We at  HardenedBSD got this error, with out jenkins instance:

--- dis_tables.o ---
/jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3025:25:
error: '' within '||' [-Werror,-Wlogical-op-parentheses]
if (cpu_mode == SIZE64  dp-it_invalid64 ||
~~~^~~ ~~
/jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3025:25:
note: place parentheses around the '' expression to silence this
warning
if (cpu_mode == SIZE64  dp-it_invalid64 ||
   ^
( )
/jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3026:25:
error: '' within '||' [-Werror,-Wlogical-op-parentheses]
cpu_mode != SIZE64  dp-it_invalid32)
~~~^~~
/jenkins/workspace/HardenedBSD_Master/sys/cddl/dev/dtrace/x86/dis_tables.c:3026:25:
note: place parentheses around the '' expression to silence this
warning
cpu_mode != SIZE64  dp-it_invalid32)
   ^
( )
--- all_subdir_ed ---


full log: 
http://nyi-01.build.hardenedbsd.org:8180/jenkins/job/HardenedBSD_Master/109/consoleText

On Thu, Jan 1, 2015 at 12:50 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
 Am Wed, 31 Dec 2014 21:41:34 +0100
 Dimitry Andric d...@freebsd.org schrieb:

 Hi,

 I just committed an upgrade of clang, llvm and lldb to 3.5.0 to head, in
 r276479.

 Please note that this version now requires C++11 support to build; see
 UPDATING for more information.

 Release notes for llvm and clang can be found here:
 http://llvm.org/releases/3.5.0/docs/ReleaseNotes.html
 http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes.html

 Thanks to Ed Maste, Roman Divacky, Andrew Turner, Justin Hibbits and
 Antoine Brodin for their invaluable help with this import.

 -Dimitry


 This is great news, thank you very much.

 I gave it a try, but my system's drop out at the error shown below. I use 
 non-standard
 optimisation flags (/etc/src.conf), but even with those switched off, I 
 receive the error
 shown below.

 Regards,

 Oliver

 [...]

 === lib/atf/libatf-c++ (all)
 c++-O2 -pipe -O3 -O3 -pipe -march=native -DHAVE_CONFIG_H 
 -I/usr/src/contrib/atf
 -I/usr/src/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H 
 -fstack-protector
 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
 -Wpointer-arith
 -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int 
 -Wno-unused-const-variable
 -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
 -Wno-unused-function -Wno-enum-conversion -Qunused-arguments -std=c++11
 -Wno-c++11-extensions -c /usr/src/contrib/atf/atf-c++/detail/application.cpp 
 -o
 application.o In file included
 from /usr/src/contrib/atf/atf-c++/detail/application.cpp:26: In file included
 from /usr/src/contrib/atf/atf-c++/detail/application.hpp:29: In file included
 from /usr/obj/usr/src/tmp/usr/include/c++/v1/ostream:131: In file included
 from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included
 from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: In file included
 from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:439: In file included
 from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:624: 
 /usr/obj/usr/src/tmp/usr/include/c++/v1/type_traits:2033:8:
 error: keyword '__is_constructible' will be made available as an identifier 
 for the
 remainder of the translation unit [-Werror,-Wkeyword-compat] struct 
 __is_constructible //
 false, _Tp is not a scalar ^ 
 /usr/obj/usr/src/tmp/usr/include/c++/v1/type_traits:2584:51:
 error: keyword '__is_nothrow_constructible' will be made available as an 
 identifier for
 the remainder of the translation unit [-Werror,-Wkeyword-compat] template 
 bool, class
 _Tp, class... _Args struct __is_nothrow_constructible;
 ^ /usr/obj/usr/src/tmp/usr/include/c++/v1/type_traits:2746:47: error: keyword
 '__is_nothrow_assignable' will be made available as an identifier for the 
 remainder of
 the translation unit [-Werror,-Wkeyword-compat] template bool, class _Tp, 
 class _Arg
 struct __is_nothrow_assignable; ^ 3 errors generated. *** Error code 1

 Stop.
 make[6]: stopped in /usr/src/lib/atf/libatf-c++
 *** Error code 1

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

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

Re: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail

[Oliver Pinter]

On 11/15/14, Dominik Zajac ba...@banym.de wrote:
 Hi,

 I am trying to change the default keymap for my keyboard therefore I
 added the following options to my kernel configuration which leads to
 the error bellow.

 Added options:

 options KBD_INSTALL_CDEV

 options UKBD_DFLT_KEYMAP

 makeoptions UKBD_DFLT_KEYMAP=de.iso


 I tried it with this, too:

 makeoptions UKBD_DFLT_KEYMAP=german.iso


 Both leads to the following problem:


 /usr/src/sys/dev/usb/input/ukbd.c:1209:18: error: use of undeclared
 identifier 'key_map'

  sc-sc_keymap = key_map;

  ^

 /usr/src/sys/dev/usb/input/ukbd.c:1210:18: error: use of undeclared
 identifier 'accent_map'

  sc-sc_accmap = accent_map;

  ^

 2 errors generated.

 *** Error code 1

Hi!

See this ticket:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 and the
related bugs.


 Is there a dynamic way to change the keyboard layout at boot time to typ
 the zfs passphrase on my default keyboardlayout?

 Regards,

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

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

Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support

[Oliver Pinter]

On 10/8/14, Yonghyeon PYUN pyu...@gmail.com wrote:
 On Thu, Oct 02, 2014 at 02:07:30PM +0900, Yonghyeon PYUN wrote:
 On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote:
  On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote:
   Hi,
   I've added support for QAC AR816x/AR817x ethernet controllers.  It
   passed my limited testing and I need more testers.  You can find
   patches from the following URLs.
  
   http://people.freebsd.org/~yongari/alc/pci.quirk.diff
   and
   http://people.freebsd.org/~yongari/alc/alc.diff.20140930
  
   pci.qurik.diff is to workaround silicon bug of AR816x. Without it
   MSI/MSIX interrupt wouldn't work.  If you just want to use
   legacy INTx interrupt you don't have to apply it but you have to
   tell alc(4) not to use MSI/MSIX interrupt with tunables(
   hw.alc.msi.disable and hw.alc.msix_disable).
  
   alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172
   and E2200 controllers.  It supports all hardware features except
   RSS.  If you have any QAC AR816x/AR817x or old AR813x/AR815x
   controllers please test and report how the diff works for you.
   Thanks.
 
  http://people.freebsd.org/~yongari/alc/pci.quirk.diff
  http://people.freebsd.org/~yongari/alc/alc.diff.20141001
 
  Patch updated to address link establishment issue.

 http://people.freebsd.org/~yongari/alc/alc.diff.20141002
 Patch updated again to correct wrong lock assertion.

 FYI: I've committed all the changes required to support
 AR816x/AR817x.

Cool! Working fine with AR8161 on Gigabyte H87N-Wifi Mobo! Thanks!

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

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

memo: Re: [PATCH] Fix integer overflow handling in dd(1)

[Oliver Pinter]

pick

On 9/20/14, William Orr w...@worrbase.com wrote:
 Hey,

 I've submitted this patch before, and it's gotten comments and fixes,
 but still hasn't been merged. Any thoughts? Does it need more work?

 Thanks,
 William Orr

 Index: args.c
 ===
 --- args.c(revision 270645)
 +++ args.c(working copy)
 @@ -41,6 +41,7 @@

   #include sys/types.h

 +#include ctype.h
   #include err.h
   #include errno.h
   #include inttypes.h
 @@ -171,8 +172,7 @@
*/
   if (in.offset  OFF_MAX / (ssize_t)in.dbsz ||
   out.offset  OFF_MAX / (ssize_t)out.dbsz)
 -errx(1, seek offsets cannot be larger than %jd,
 -(intmax_t)OFF_MAX);
 +errx(1, seek offsets cannot be larger than %jd, OFF_MAX);
   }

   static int
 @@ -186,37 +186,28 @@
   static void
   f_bs(char *arg)
   {
 -uintmax_t res;

 -res = get_num(arg);
 -if (res  1 || res  SSIZE_MAX)
 -errx(1, bs must be between 1 and %jd, (intmax_t)SSIZE_MAX);
 -in.dbsz = out.dbsz = (size_t)res;
 +in.dbsz = out.dbsz = get_num(arg);
 +if (out.dbsz  1 || out.dbsz  SSIZE_MAX)
 +errx(1, bs must be between 1 and %jd, SSIZE_MAX);
   }

   static void
   f_cbs(char *arg)
   {
 -uintmax_t res;

 -res = get_num(arg);
 -if (res  1 || res  SSIZE_MAX)
 -errx(1, cbs must be between 1 and %jd, (intmax_t)SSIZE_MAX);
 -cbsz = (size_t)res;
 +cbsz = get_num(arg);
 +if (cbsz  1 || cbsz  SSIZE_MAX)
 +errx(1, cbs must be between 1 and %jd, SSIZE_MAX);
   }

   static void
   f_count(char *arg)
   {
 -intmax_t res;

 -res = (intmax_t)get_num(arg);
 -if (res  0)
 -errx(1, count cannot be negative);
 -if (res == 0)
 -cpy_cnt = (uintmax_t)-1;
 -else
 -cpy_cnt = (uintmax_t)res;
 +cpy_cnt = get_num(arg);
 +if (cpy_cnt == 0)
 +cpy_cnt = -1;
   }

   static void
 @@ -225,7 +216,7 @@

   files_cnt = get_num(arg);
   if (files_cnt  1)
 -errx(1, files must be between 1 and %jd, (uintmax_t)-1);
 +errx(1, files must be between 1 and %ju, SIZE_MAX);
   }

   static void
 @@ -241,14 +232,11 @@
   static void
   f_ibs(char *arg)
   {
 -uintmax_t res;

   if (!(ddflags  C_BS)) {
 -res = get_num(arg);
 -if (res  1 || res  SSIZE_MAX)
 -errx(1, ibs must be between 1 and %jd,
 -(intmax_t)SSIZE_MAX);
 -in.dbsz = (size_t)res;
 +in.dbsz = get_num(arg);
 +if (in.dbsz  1 || in.dbsz  SSIZE_MAX)
 +errx(1, ibs must be between 1 and %ju, SSIZE_MAX);
   }
   }

 @@ -262,14 +250,11 @@
   static void
   f_obs(char *arg)
   {
 -uintmax_t res;

   if (!(ddflags  C_BS)) {
 -res = get_num(arg);
 -if (res  1 || res  SSIZE_MAX)
 -errx(1, obs must be between 1 and %jd,
 -(intmax_t)SSIZE_MAX);
 -out.dbsz = (size_t)res;
 +out.dbsz = get_num(arg);
 +if (out.dbsz  1 || out.dbsz  SSIZE_MAX)
 +errx(1, obs must be between 1 and %jd, SSIZE_MAX);
   }
   }

 @@ -378,11 +363,17 @@
   uintmax_t num, mult, prevnum;
   char *expr;

 +while (isspace(val[0]))
 +val++;
 +
 +if (val[0] == '-')
 +errx(1, %s: cannot be negative, oper);
 +
   errno = 0;
 -num = strtouq(val, expr, 0);
 +num = strtoull(val, expr, 0);
   if (errno != 0)/* Overflow or underflow. */
   err(1, %s, oper);
 -
 +
   if (expr == val)/* No valid digits. */
   errx(1, %s: illegal numeric value, oper);

 Index: conv.c
 ===
 --- conv.c(revision 270645)
 +++ conv.c(working copy)
 @@ -133,7 +133,7 @@
*/
   ch = 0;
   for (inp = in.dbp - in.dbcnt, outp = out.dbp; in.dbcnt;) {
 -maxlen = MIN(cbsz, in.dbcnt);
 +maxlen = MIN(cbsz, (size_t)in.dbcnt);
   if ((t = ctab) != NULL)
   for (cnt = 0; cnt  maxlen  (ch = *inp++) != '\n';
   ++cnt)
 @@ -146,7 +146,7 @@
* Check for short record without a newline.  Reassemble the
* input block.
*/
 -if (ch != '\n'  in.dbcnt  cbsz) {
 +if (ch != '\n'  (size_t)in.dbcnt  cbsz) {
   (void)memmove(in.db, in.dbp - in.dbcnt, in.dbcnt);
   break;
   }
 @@ -228,7 +228,7 @@
* translation has to already be done or we might not recognize the
* spaces.
*/
 -for (inp = in.db; in.dbcnt = cbsz; inp += cbsz, in.dbcnt -= cbsz) {
 +for (inp = in.db; (size_t)in.dbcnt = cbsz; inp += cbsz, in.dbcnt
 -= cbsz) {
   for (t = inp + cbsz - 1; t = inp  *t == ' '; --t)
   ;
   if (t = inp) {
 Index: dd.c
 ===
 --- dd.c(revision 270645)
 +++ dd.c(working copy)
 @@ -168,10 +168,10 @@
* 

Re: libdevattr

[Oliver Pinter]

On 7/15/14, Bruno Lauzé brunola...@msn.com wrote:
 I was looking at dragonfly and why they have libdevattr and we don'tI really
 think having udev compatible api would open the door to a lot of software,
 imho.I feel it wouldn't be so complicated to port dragonfly kern_udev,
 libprop and libdevattr from dragonfly bsd.
 Am i missing a point or is this in contradiction witch any of freebsd
 objectives?
 Let me know your thoughts...  
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


In FreeBSD exists similar utility like udev, the so called devd. In
github is there a project, which would improve the compatibility or
completely change the udev like brain-damage.
https://github.com/freebsd/libdevq
Other problem with udev is, that moving so fast, and every time
changed their API, and udev's future are not clear, possibly merged
with systemd.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: building i386 kernel on amd64 host

[Oliver Pinter]

On 6/15/14, Warner Losh i...@bsdimp.com wrote:

 On Jun 14, 2014, at 3:57 PM, Oliver Pinter oliver.p...@gmail.com wrote:

 On 6/13/14, John Baldwin j...@freebsd.org wrote:
 On Friday, June 13, 2014 6:21:28 am Oliver Pinter wrote:
 Hi All!

 When I try to build i386 kernel on amd64 host running compile error
 due wrong cpufunc.h picked up by build system.

 I used the attached script to build the kernel, and I attached a build
 log.

 Any suggestion how can I fix this?

 To build an i386 kernel on an amd64 host do this:

 cd /usr/src (or some other tree)
 make TARGET=i386 kernel-toolchain
 make TARGET=i386 buildkernel
 make TARGET=i386 installkernel DESTDIR=/some/place

 And your i386 kernel will end up in /some/place/boot/kernel/kernel.
 (You
 can
 set things like KERNCONF to pick an alternate kernel config just as with
 normal 'make buildkernel'.)

 (Your attachment was size zero for me btw)

 --
 John Baldwin


 I used this script to build the kernel:
 http://svnweb.freebsd.org/socsvn/soc2014/op/tools/build_kernel_32bit.csh?view=log

 And the error log are there:
 https://gist.github.com/opntr/cf8aa0e404c0c5ed6f90 .
 I get this error, when I first build kernel for amd64 system, and
 after that i386 kernel, and only the kernel.

 Now seems like I can build the whole system with buildworld
 buildkernel on vanilla master, I removed the objdir and do a clean
 buildworld. Now I test the modified kernel build, after the
 buildworld.

 It is broken too. When I do only make kernel-toolchain buildkernel,
 than this are broken for vanilla freebsd source and for my version to.

 summary:
 OK: make buildworld buildkernel
 BROKEN: make kernel-toolchain buildkernel

 On the same line? O?r is that just a summary?

 Seems like someone in build environment bootstrapping are broken.

 I've not been able to reproduce this.

 rm -rf $OBJDIR
 make TARGET=i386 kernel-toolchain
 make TARGET=i386 buildkernel

 works just fine on current with a clean tree and an empty/missing make.conf
 and src.conf.

 As for your script, don't define MACHINE and MACHINE_ARCH. That's almost
 always wrong since that overrides things on the command line, which is what
 make buildkernel winds up translating to. You never need to define those
 yourself in any supported environment, and likely most unsupported ones.

 Also, I'd strongly recommend doing it as two invocations to make, not one.
 kernel-toolchain likely doesn't have all the right guards in place for it
 that buildworld likely does. Or you can dive in and figure that out. You
 can't really do anything *kernel* related until kernel-toolchain finishes...

 Warner

Warner, thanks!

Splitting up to two part the build script, working fine!

https://github.com/HardenedBSD/tools/blob/f98ec30cbe6f155c9f15c0d4b1ecbf74fc970e32/build_kernel_32bit.csh




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

Re: building i386 kernel on amd64 host

[Oliver Pinter]

On 6/13/14, John Baldwin j...@freebsd.org wrote:
 On Friday, June 13, 2014 6:21:28 am Oliver Pinter wrote:
 Hi All!

 When I try to build i386 kernel on amd64 host running compile error
 due wrong cpufunc.h picked up by build system.

 I used the attached script to build the kernel, and I attached a build
 log.

 Any suggestion how can I fix this?

 To build an i386 kernel on an amd64 host do this:

 cd /usr/src (or some other tree)
 make TARGET=i386 kernel-toolchain
 make TARGET=i386 buildkernel
 make TARGET=i386 installkernel DESTDIR=/some/place

 And your i386 kernel will end up in /some/place/boot/kernel/kernel.  (You
 can
 set things like KERNCONF to pick an alternate kernel config just as with
 normal 'make buildkernel'.)

 (Your attachment was size zero for me btw)

 --
 John Baldwin


I used this script to build the kernel:
http://svnweb.freebsd.org/socsvn/soc2014/op/tools/build_kernel_32bit.csh?view=log

And the error log are there:
https://gist.github.com/opntr/cf8aa0e404c0c5ed6f90 .
I get this error, when I first build kernel for amd64 system, and
after that i386 kernel, and only the kernel.

Now seems like I can build the whole system with buildworld
buildkernel on vanilla master, I removed the objdir and do a clean
buildworld. Now I test the modified kernel build, after the
buildworld.

It is broken too. When I do only make kernel-toolchain buildkernel,
than this are broken for vanilla freebsd source and for my version to.

summary:
OK: make buildworld buildkernel
BROKEN: make kernel-toolchain buildkernel

Seems like someone in build environment bootstrapping are broken.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

building i386 kernel on amd64 host

[Oliver Pinter]

Hi All!

When I try to build i386 kernel on amd64 host running compile error
due wrong cpufunc.h picked up by build system.

I used the attached script to build the kernel, and I attached a build log.

Any suggestion how can I fix this?

Thanks,
Oliver


cc-log-opBSD.git-20140613030335.txt.xz
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

[Oliver Pinter]

On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote:
 Oliver Pinter oliver.p...@gmail.com writes:
   PAX LOG: implement new logging subsystem
   PAX LOG: fix pax_ulog_segvguard
   PAX LOG: added sysctl's and tunables
   PAX ASLR: use PAX LOG
   PAX LOG: fix pax_ulog_##name()
   PAX LOG: fix prison init
   PAX LOG: fixed log and ulog sysctl

 What exactly is the purpose of PAX LOG?  Have you considered using
 ktrace instead?

pax_log will be in future a generic pax related logging framework,
with ratelimiting and other features.
It will log user, IP, binary name, path, checksum, and others.


   PAX: blacklist clang and related binaries from PIE support

 Why?  Performance, or do they actually break?

No. If you definded WITH_CLANG_EXTRAS= in src.conf, the breaked the build.
(added dim@ to CC)

--- usr.bin.all__D ---
/usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/../../../lib/clang/libllvmirreader/libllvmirreader.a:
could not read symbols: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [bugpoint] Error code 1

bmake[5]: stopped in
/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint
1 error

bmake[5]: stopped in
/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint
*** [all_subdir_bugpoint] Error code 2

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang
--- usr.sbin.all__D ---
A failure has been detected in another branch of the parallel make

bmake[5]: stopped in
/usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi/iasl
*** [all] Error code 2

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi
1 error

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi
*** [all_subdir_acpi] Error code 2

bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin
1 error

bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin
*** [usr.sbin.all__D] Error code 2

bmake[2]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git
--- usr.bin.all__D ---
--- all_subdir_tblgen ---
A failure has been detected in another branch of the parallel make

bmake[5]: stopped in
/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/tblgen
*** [all_subdir_tblgen] Error code 2

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang
2 errors

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang
*** [all_subdir_clang] Error code 2

bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin


   PAX ASLR: Blacklist the applications that don't support being built
 as a position-independent executable

 don't support as in you have tested them and confirmed that they break
 in some way?  Could you post your test methodology so people can
 replicate the failures and look into fixing them?

   PAX ASLR: Use a full kernel config for LATT-ASLR

 What is the difference between LATT-ASLR and OP-ASLR, and why not just
 include GENERIC?  You know about nooptions, right?

In upstreamed patch will be removed this kernel configs. These are
Shawn's and my kernel config.


   Revert PAX: blacklist clang and related binaries from PIE support
   Revert Revert PAX: blacklist clang and related binaries from PIE
 support

 Hmm...

See above.


 DES
 --
 Dag-Erling Smørgrav - d...@des.no

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

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

[Oliver Pinter]

On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote:
 Oliver Pinter oliver.p...@gmail.com writes:
 pax_log will be in future a generic pax related logging framework,
 with ratelimiting and other features.  It will log user, IP, binary
 name, path, checksum, and others.

 What are you using this for?  Are you sure you can't use ktrace?  It's a
 lot more flexible and powerful than you probably realize.

Logging to system log, The feature will similar to this in grsecurity:
http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Kernel_Auditing


 DES
 --
 Dag-Erling Smørgrav - d...@des.no

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

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

[Oliver Pinter]

On 5/24/14, Shawn Webb latt...@gmail.com wrote:
 On May 23, 2014 07:53 PM +, Wojciech A. Koszek wrote:
 On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote:
  Hey All,
 
  [NOTE: crossposting between freebsd-current@, freebsd-security@, and
  freebsd-stable@. Please forgive me if crossposting is frowned upon.]
 
  Address Space Layout Randomization, or ASLR for short, is an exploit
  mitigation technology. It helps secure applications against low-level
  exploits. A popular secure implementation is known as PaX ASLR, which
  is
  a third-party patch for Linux. Our implementation is based off of
  PaX's.
 
  Oliver Pinter, Danilo Egea, and I have been working hard to bring more
  features and robust stability to our ASLR patches. We've done extensive
  testing on amd64. We'd like to get as many people testing these
  patches.
  Given the nature of them, we'd also like as many eyeballs reviewing the
  code as well.
 
  I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on
  the RPI), when a parent forks a child, and the child gracefully exits,
  the parent segfaults with the pc register pointing to 0xc000. That
  address is always the same, no matter the application. If anyone knows
  the ARM architecture well, and how FreeBSD ties into it, I'd like a
  little guidance.
 
  I also have a sparc64 box, but I'm having trouble getting a vanilla
  11-current system to be stable on it. I ought to file a few PRs.
 
  You can find links to the patches below.
 
  Patch for 11-current:
  http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff
 
  Patch for 10-stable:
  http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff
 

 Shawn

 I appreciate you working on this. We must have this in FreeBSD.

 I looked at the patch and I read, but not run it.  Comments below.

 My personal opinion is that kern_pax.c should be compiled in by default.
 If
 it adds a lot of size, it'd be better to provide empty stub calls instead
 of
 #ifdef'ing everything. But security is very important especially in
 embeddded systems, so you can imagine you're writing the code that
 everybody
 wants and must have enabled for decent level of security.

 All modern systems run with ASLR turned on.

 I skipped user-space stuff. I don't think it's necessary in this commit
 and
 should be separated.

 There's a lot of lines of code for status showing. Not sure if we care
 that
 much: ASLR is either on or off. Not sure about more granularity. More
 below.

 We provide the level of granularity because there are a lot of
 applications that might exhibit weird behaviors or even crash if we
 randomize too many bits. We provide sane defaults, but allow each user
 to choose the level of security versus the level of stability they
 desire.

Two idea here:
a) create a tunable security.pax.expert_mode, and create sysctls at
boot time depending from expert mode
  ( 
https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/aslr/sys/kern/kern_sysctl.c#L460
)
b) just add CTLFLAG_SKIP and hide the sysctl from normal user
  ( 
https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/aslr/sys/kern/kern_sysctl.c#L739
)



 Lots of files:

 You conditionally make .sv_pax_aslr_init method point to something else.
 I'd
 assume PAX function _pax_aslr_init32() always gets called and based on
 whether ASLR is on or not, it does something or not. This will simplify
 the
 code a lot, and the difference probably won't be measurable.

 You have:

  int a;
  int b;

 instead of:

  int a, b;

 And you miss spaces around = sometimes.

 Cleaning up the code and make style changes are a high priority on my
 list. Once I get a few more pieces of code locked down, I'm going to go
 over every line with a comb to make sure I'm adhering to the FreeBSD
 coding style. des@ has made a lot of suggestions in that regard and has
 even provided me with a sample vimrc. Prior to talking with des@, I was
 re-using the same vimrc that I use for ClamAV (which, admittedly, has a
 much different coding style than FreeBSD).


 kern_jail.c:

 something looks wrong here. Sounds like you need pr-pax.  But I don't
 understand why you need to have these pr_* values here. It seems
 unnecessary.

 I've made it possible to have per-jail ASLR settings. If you have an
 application that misbehaves, you can jail it with ASLR turned off just
 for that jail. My BSDCan presentation talks about this. The recording
 isn't up, yet, though.


 kern_pax.c:

 I can't quickly tell what locking is using. Some ASSERTS() in pax_
 function
 would help.

 pax_aslr_active():

 I don't see why you need to pass td and proc (I looked at usage: you
 pass proc only once). I think you could always pass proc to it, with
 td-td_proc passed typically.
 kern_pax_*:

 There's so many SYSCTLs I think people will have problem configuring it.
 Pick reasonable value for all

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

[Oliver Pinter]

On 5/14/14, Shawn Webb latt...@gmail.com wrote:
 Hey All,

 [NOTE: crossposting between freebsd-current@, freebsd-security@, and
 freebsd-stable@. Please forgive me if crossposting is frowned upon.]

 Address Space Layout Randomization, or ASLR for short, is an exploit
 mitigation technology. It helps secure applications against low-level
 exploits. A popular secure implementation is known as PaX ASLR, which is
 a third-party patch for Linux. Our implementation is based off of PaX's.

 Oliver Pinter, Danilo Egea, and I have been working hard to bring more
 features and robust stability to our ASLR patches. We've done extensive
 testing on amd64. We'd like to get as many people testing these patches.
 Given the nature of them, we'd also like as many eyeballs reviewing the
 code as well.

 I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on
 the RPI), when a parent forks a child, and the child gracefully exits,
 the parent segfaults with the pc register pointing to 0xc000. That
 address is always the same, no matter the application. If anyone knows
 the ARM architecture well, and how FreeBSD ties into it, I'd like a
 little guidance.

 I also have a sparc64 box, but I'm having trouble getting a vanilla
 11-current system to be stable on it. I ought to file a few PRs.

 You can find links to the patches below.

 Patch for 11-current:
 http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

 Patch for 10-stable:
 http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

 Thanks,

 Shawn Webb


New round of patches are there:

11-CURRENT: 
http://www.crysys.hu/~op/freebsd/patches/20140524011327-freebsd-current-aslr-segvguard-SNAPSHOT.diff

10-STABLE: 
http://www.crysys.hu/~op/freebsd/patches/20140524011327-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff



What's changed related to previous tag:
11-CURRENT:
Oliver Pinter (17):
  PAX ASLR: update license in kern_pax_aslr.c
  PAX: update license in kern_pax.c
  PAX SEGVGUARD: update license in kern_pax_segvguard.c
  PAX: update license in pax.h
  PAX ASLR: remove unneeded parameter from pax_aslr_stack function
  PAX LOG: implement new logging subsystem
  PAX LOG: fix pax_ulog_segvguard
  PAX LOG: added sysctl's and tunables
  PAX ASLR: use PAX LOG
  PAX LOG: fix pax_ulog_##name()
  PAX LOG: fix prison init
  PAX LOG: fixed log and ulog sysctl
  PAX ASLR: fixed debug sysctl
  PAX: blacklist clang and related binaries from PIE support
  PAX ASLR: make ASLR by default opt-out
  Merge remote-tracking branch 'freebsd/master' into hardened/current/aslr
  Merge branch 'hardened/current/aslr' of
github.com:HardenedBSD/hardenedBSD into hardened/current/aslr

Shawn Webb (10):
  Remove CAN_PIE in preparation for NO_PIE
  Merge remote-tracking branch 'upstream/master' into hardened/current/aslr
  PAX ASLR: Blacklist the applications that don't support being
built as a position-independent executable
  Merge remote-tracking branch 'upstream/master' into hardened/current/aslr
  Disable PAX_SEGVGUARD in LATT-ASLR kernel
  PAX ASLR: Lock the jail when initializing PAX per-jail PAX settings
  PAX ASLR: Fix bug with pax_aslr_active()
  PAX ASLR: Use a full kernel config for LATT-ASLR
  Revert PAX: blacklist clang and related binaries from PIE support
  Revert Revert PAX: blacklist clang and related binaries from
PIE support


10-STABLE:
Oliver Pinter (20):
  PAX ASLR: update license in kern_pax_aslr.c
  PAX: update license in kern_pax.c
  PAX SEGVGUARD: update license in kern_pax_segvguard.c
  PAX: update license in pax.h
  PAX ASLR: remove unneeded parameter from pax_aslr_stack function
  PAX LOG: implement new logging subsystem
  PAX LOG: fix pax_ulog_segvguard
  PAX LOG: added sysctl's and tunables
  PAX ASLR: use PAX LOG
  PAX LOG: fix pax_ulog_##name()
  PAX LOG: fix prison init
  PAX LOG: fixed log and ulog sysctl
  PAX ASLR: fixed debug sysctl
  Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr
  Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr
  added OPN-ASLR kernel config
  PAX: Remove CAN_PIE in preparation for NO_PIE from /bin/sh
  PAX: blacklist clang and related binaries from PIE support
  PAX ASLR: make ASLR by default opt-out
  Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr

Shawn Webb (4):
  PAX: Remove CAN_PIE in preparation for NO_PIE
  PAX ASLR: Blacklist the applications that don't support being
built as a position-independent executable
  PAX ASLR: Lock the jail when initializing PAX per-jail PAX settings
  PAX ASLR: Fix bug with pax_aslr_active()
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo

[RFC] remove dead code from link_elf.c

[Oliver Pinter]

Hi all!

I found that the SPARSE_MAPPING used only in sys/kern/link_elf.c file,
and no other place in kernel, nor in generated codes in /usr/obj/...

op@pandora-d opBSD.git git grep -i SPARSE_MAPPING
sys/kern/link_elf.c:#ifdef SPARSE_MAPPING
sys/kern/link_elf.c:#ifdef SPARSE_MAPPING
sys/kern/link_elf.c:#ifdef SPARSE_MAPPING
sys/kern/link_elf.c:#ifdef SPARSE_MAPPING
sys/kern/link_elf.c:#ifdef SPARSE_MAPPING
sys/kern/link_elf.c:#ifdef SPARSE_MAPPING
sys/kern/link_elf.c:#ifdef SPARSE_MAPPING

I proposed to remove the old/dead codes. Patch attached. Tested on amd64.


0001-link_elf-remove-SPARSE_MAPPING-and-related-code.patch
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org