Re: gptboot rewrite, bootonce, etc.

[Oliver Pinter]

Hi PJD!

Can you this patcheset release for 7-STABLE?

On 9/19/10, Boris Samorodov  wrote:
> Hi!
>
> On Sat, 18 Sep 2010 01:45:42 +0200 Pawel Jakub Dawidek wrote:
>
>> My company was in need for functionality similar to nextboot(8), but on
>> boot loader level, so we can have two partitions we boot from where one
>> is known to be good and the other is used for upgrades. We upgrade by
>> dd(1)ing entire partition image onto unused partition, we mark it as
>> try-to-boot-from-it-but-only-once, reboot and if we fail to boot from
>> the new partition, we fall back to the old, good partition. If we
>> succeed on the other hand, we mark the new partition as our boot
>> partition and mark the other one as unused.
>
>> Well, how hard can it be?
>
>> After around two weeks of work, I ended up rewriting gptboot in large
>> parts, reorganizing a lot of code, improving and extending gpart a bit
>> and implementing desire functionality.
>
>> Here is the patch for review and test:
>
>>  http://people.freebsd.org/~pjd/patches/gptboot.patch
>
> Great! Since I need to have both i386 and amd64 at my box
> here are my test results:
> -
> [~]b...@alya% uname -a
> FreeBSD alya 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r212758M: Sat Sep 18
> 16:13:38 MSD 2010
> b...@alya:/space/FreeBSD/base/head/obj/space/FreeBSD/base/head/src/sys/ALYA
> amd64
>
> [~]b...@alya% glabel status
>   Name  Status  Components
> gptid/c6053c9b-abcc-11df-b740-00251124aff4 N/A  ad4p1
>  label/9-amd64 N/A  ad4p2
> label/swap N/A  ad4p3
>label/space N/A  ad4p4
>   label/9-i386 N/A  ad4p5
> [~]b...@alya% mount
> /dev/label/9-amd64 on / (ufs, local)
> devfs on /dev (devfs, local, multilabel)
> /dev/label/space on /space (ufs, local)
> /dev/md0 on /tmp (ufs, local, nosuid, soft-updates)
> procfs on /proc (procfs, local)
> linprocfs on /compat/linux/proc (linprocfs, local)
> linsysfs on /compat/linux/sys (linsysfs, local)
> fdescfs on /dev/fd (fdescfs)
>
> [~]b...@alya% gpart show
> =>   34  490234685  ad4  GPT  (234G)
>  341281  freebsd-boot  (64K)
> 162   419430402  freebsd-ufs  (20G)
>4194320283886083  freebsd-swap  (4.0G)
>50331810  2097152004  freebsd-ufs  (100G)
>   260047010   419430405  freebsd-ufs  (20G)
>   301990050  188244669   - free -  (90G)
>
> [~]b...@alya% gpart set -a bootme -i 2 ad4
> bootme set on ad4p2
> [~]b...@alya% gpart set -a bootonce -i 5 ad4
> bootonce set on ad4p5
> [~]b...@alya% gpart show
> =>   34  490234685  ad4  GPT  (234G)
>  341281  freebsd-boot  (64K)
> 162   419430402  freebsd-ufs  [bootme]  (20G)
>4194320283886083  freebsd-swap  (4.0G)
>50331810  2097152004  freebsd-ufs  (100G)
>   260047010   419430405  freebsd-ufs  [bootonce,bootme]  (20G)
>   301990050  188244669   - free -  (90G)
> -
>
> Install i386 kernel/world to ad4p5, successful reboot, get i386
> system. Next reboot (get amd64 system back):
> -
> [~]b...@alya% gpart show
> =>   34  490234685  ad4  GPT  (234G)
>  341281  freebsd-boot  (64K)
> 162   419430402  freebsd-ufs  [bootme]  (20G)
>4194320283886083  freebsd-swap  (4.0G)
>50331810  2097152004  freebsd-ufs  (100G)
>   260047010   419430405  freebsd-ufs  (20G)
>   301990050  188244669   - free -  (90G)
> -
>
> All seems to work fine.
>
>> Any comments or suggestions?
>
> Only one for now. With current default syslog configuration
> logging to local0.warning and local0.info goes nowhere.
> It will be good if those messages have traces at the
> default system.
>
>
> Thank you! That's really great.
>
> --
> WBR, Boris Samorodov (bsam)
> Research Engineer, http://www.ipt.ru Telephone & Internet SP
> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
> ___
> 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: www/chromium crashing whole system

[Oliver Pinter]

can you try disable the chrome sandbox feature?

chmod -s chrome-sandbox
mv chrome-sandbox chrome-sandbox.disabled_feature

and after this, the problem is still represented?

under linux with grsec path, with enabled sandbox, do not started, I
know, that is a fully different problem

On 11/19/10, Alexander Best  wrote:
> On Tue Nov 16 10, Robert N. M. Watson wrote:
>>
>> On 15 Nov 2010, at 22:19, Alexander Best wrote:
>>
>> > thanks for all your help. i've recently switched to chromium 6.0.472.63
>> > and so far my computer has been very stable.
>> >
>> > if i experience more lock ups i'll let you know and try to figure out a
>> > way to
>> > gain access to some more debugging data.
>>
>> I'd prefer we try to figure out why your system was crashing now -- the
>> kernel bug has not gone away just because Chromium is no longer triggering
>> it. Working around the bug means someone else gets to run into it later --
>> perhaps when it's 9.0-RELEASE rather than 9-CURRENT...
>
> "GOOD" news btw: the new chromium port just crashed my system. ;) so the
> issue is still there.
>
> and be issue i mean the code that triggers the crash.
>
>>
>> Robert
> --
> a13x
> ___
> 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: TTY task group scheduling

[Oliver Pinter]

http://lkml.org/lkml/2010/11/16/392

On 11/18/10, O. Hartmann  wrote:
> On 11/18/10 02:30, grarpamp wrote:
>> Just documenting regarding interactive performance things.
>> This one's from Linux.
>>
>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
>
> Well,
> it would be nice to have those improvements in FreeBSD, but I doubt this
> will make it in due time to FreeBSD's kernel.
> ___
> freebsd-sta...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-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: TTY task group scheduling

[Oliver Pinter]

My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP system),
I tested 8-STABLE, but that is not too responsive, the solution is:
100Hz NOPREEMPT + kern.sched.preempt_thresh=224
After this setting, the system is likely responsive as 7-STABLE.

On 11/19/10, Garrett Cooper  wrote:
> On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter 
> wrote:
>> http://lkml.org/lkml/2010/11/16/392
>>
>> On 11/18/10, O. Hartmann  wrote:
>>> On 11/18/10 02:30, grarpamp wrote:
>>>> Just documenting regarding interactive performance things.
>>>> This one's from Linux.
>>>>
>>>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
>>>
>>> Well,
>>> it would be nice to have those improvements in FreeBSD, but I doubt this
>>> will make it in due time to FreeBSD's kernel.
>
> And my one line fix:
>
> renice 10 `pidof firefox-bin`
>
> Instantly my system is snappier (and in fact my system got really
> laggy after applying the preempt sysctl that everyone recommended
> before)... Performance issue with firefox maybe :P? I don't see the
> point of adding an additional layer to complicate the system (and
> essentially slow it down) if all you're trying to do is better
> describe the nice'ing problem, unless this logic is what you want to
> do strictly for desktop users in PCBSD, etc who may not have the
> technical wherewithal to accomplish this task.
>
> Besides, the Linux kernel has different compile time profiles for
> different workloads, so maybe it just works better for them because
> they already have a means for describing that functionality, whereas
> FreeBSD is more generic.
>
> It would be nice to describe this in a document though so people could
> also decide how to tune the system for themselves and not deal with a
> patch like what's noted above by the penguin crowd because it will
> invariably fail under some workloads or conditions (I have yet to see
> a one-size-fits-all solution in this area).
>
> 
> SCHED_ULE improvements though should be looked into if possible,
> because there are some potential items that could be done to cluster
> processes together better, maybe.
> 
>
> Thanks,
> -Garrett
>
___
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: BSDInstall: merging to HEAD

[Oliver Pinter]

Hi all!

Is there available any bootmgr(boot0)-like boot manager for GPT?

On 1/21/11, Nathan Whitehorn  wrote:
> On 01/20/11 17:21, Doug Barton wrote:
>> On 01/20/2011 14:47, Nathan Whitehorn wrote:
>>> On 01/20/11 16:44, Doug Barton wrote:
 On 01/20/2011 14:15, Chuck Swiger wrote:
> On Jan 20, 2011, at 1:37 PM, David Demelier wrote:
> [ ... ]
>> Why does the installer use GPT partition by default? Do you know
>> that GPT is not supported on every (even modern) computer ?
>
> Sure. Legacy PC/BIOS platforms can work with a hybrid GPT which
> includes the legacy or "protective" MBR used by pre-EFI systems;
> FreeBSD 7 and later, recent Linux, MacOS X 10.4 and later should be
> able to boot from disks with that hybrid format.
>
> If you need to dual-boot into Windows, however, and your hardware
> doesn't provide EFI then you're likely stuck using MBR + PC/BIOS only.

 We should not do anything by default that damages the ability to
 dual-boot windows (and by windows I really mean "xp or later" since
 we'll have xp around through 2014). If there are significant
 advantages to gpt as a default when possible then it will be necessary
 to ask the user some intelligent questions such as "Will this system
 be multi-booted?" and if yes, "Will
 ${lowest_common_denominator:-windows} be installed?"
>>>
>>> It does do exactly what you suggest. It only uses GPT by default if you
>>> have a totally unformatted disk or indicate you intend to run only
>>> FreeBSD on the machine. Otherwise, you get MBR+bsdlabel just like now.
>>
>> That isn't exactly what I suggested. :)  Imagine the following
>> scenario (which is what I used to do, until our fdisk started using
>> wacky geometries):
>> 1. Get new computer and/or new hard drive
>> 2. Boot freebsd from installation/live media (aka, disc1)
>> 3. Unceremoniously (and in some cases gleefully) delete all existing
>> partition/slices
>> 4. Slice the disk, and write out the changes with "regular" MBR
>> 5. Boot windows, install into the first unused slice/partition
>>
>> Now if by "indicate you intend to run only FreeBSD on the machine"
>> above you mean that you already have questions built into the process
>> that covers what I proposed above, then fine. My point is simply that
>> running the installer on a blank (or newly blank'ed) disk is not by
>> itself a sign that everything that will be installed understands gpt.
> It does. It only does GPT by default if you say "I want to erase my hard
> disk" (or it is already blank), then select "Automatic partitioning". If
> you have an existing partition scheme, it is kept even if you select
> "automatic" (assuming it is bootable on your platform).
>
> If you want something more complicated (i.e. any kind of dual-booting
> scenario), then you will want to specify partition sizes with the editor
> anyway. Once you exit automatic mode to invoke the editor, it allows you
> to set up bsdlabel-only, MBR+bsdlabel, GPT, installations spanning
> multiple disks, and whatever else you might want to do. If that isn't
> enough flexibility, there is also a "I don't need no stinking partition
> editor" option, where you can set up whatever you like with a shell.
> -Nathan
> ___
> 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"

[head] does not build arm

[Oliver Pinter]

Hi all!

I try to build 9-CURRENT for arm, but become this error:

tcp_output.o(.text+0x2b00): In function `tcp_addoptions':
: undefined reference to `__ucmpdi2'
*** Error code 1

Stop in /usr/home/op/xtalin/build/arm.arm/usr/9-CURRENT.git/sys/DB-88F5XXX.
*** Error code 1

the command is:
# make buildkernel TARGET_ARCH=arm KERNCONF=DB-88F5XXX

host:
FreeBSD pandora-devel9 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sun Feb 13
22:41:19 CET 2011
root@pandora-devel9:/usr/obj/usr/9-CURRENT.git/sys/GENERIC  amd64

and the top of the source:
commit 7eaeb4db8ae148ecfcf232bf7652d9cf508788d3
Author: uqs 
Date:   Sun Feb 13 22:17:49 2011 +

Add back soon-to-be-release FreeBSD 7.4 which got clobbered in the previous
merges.


git-svn-id: svn://svn.freebsd.org/base/head@218672
ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
___
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"

stackgap

[Oliver Pinter]

Hi All!

The linked[1][2] stackgap patches why not included in FreeBSD tree? I
used this patches for a long while (~2 year ago), without problem. And
I have an updated patch for 7-STABLE:
http://peonia.teteny.elte.hu/freebsd/patches/stable/stable/20091229025818-randomize_mmap.patch

[1] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff
[2] http://unix.derkeiler.com/Mailing-Lists/FreeBSD/arch/2005-05/0109.html

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: [Need Help]isboot (iSCSI boot driver) version 0.2.1

[Oliver Pinter]

iscsi initiator paniced over 4 dev, and the code has limitations of
devices, it is hardcoded to 4

9f2ae5be (scottl 2007-07-24 15:35:02 +  39) #define ISCSIDEV"iscsi"
9f2ae5be (scottl 2007-07-24 15:35:02 +  40)
9f2ae5be (scottl 2007-07-24 15:35:02 +  41) #define
ISCSI_MAX_TARGETS  4 //64
9f2ae5be (scottl 2007-07-24 15:35:02 +  42)
9f2ae5be (scottl 2007-07-24 15:35:02 +  43) #define ISCSI_MAX_LUNS
 4

when setting this to 64, than paniced the kernel


On 7/4/10, Alexander Motin  wrote:
> Daisuke Aoyama wrote:
 Notes/Known Issues/Limitations:
 FreeBSD can't use transfer length > 64KB.
>>>
>>> Since 8.0 FreeBSD can use any transfer lengths. 64K is a safety limit
>>> for CAM SIMs that do not report maximum transfer size. If your driver
>>> supports bigger transactions (and even if not), you should fill maxio
>>> field in XPT_PATH_INQ response.
>>
>> I set maxio=1024*1024 in version 0.2.2. As a result, the request (each
>> ccb)
>> have 256 blocks (128KB). I don't know why it is 128KB.
>
> 128KB is a default MAXPHYS value. You may rise it in your kernel if you
> want. I am successfully using 1MB MAXPHYS now.
>
> --
> Alexander Motin
> ___
> 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"

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

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

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

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

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

[Oliver Pinter]

pick

On 9/20/14, William Orr  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 
>
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -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 (

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

[Oliver Pinter]

On 10/8/14, Yonghyeon PYUN  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"

Re: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail

[Oliver Pinter]

On 11/15/14, Dominik Zajac  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: 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
 wrote:
> Am Wed, 31 Dec 2014 21:41:34 +0100
> Dimitry Andric  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:
>> 
>> 
>>
>> 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 
>  _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  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: 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  wrote:
> On 01 Jan 2015, at 18:35, Oliver Pinter  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 

 .endif # ! Posix
+
+.include 

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
 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  wrote:
>> On 01 Jan 2015, at 18:35, Oliver Pinter  
>> 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 '|

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  wrote:
> On 01 Jan 2015, at 18:35, Oliver Pinter  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: sendmail make distribution error and fix

[Oliver Pinter]

On 1/7/15, Oliver Pinter  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: 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  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: URGENT: RNG broken for last 4 months

[Oliver Pinter]

On Tue, Feb 17, 2015 at 11:19 PM, Fabian Keil
 wrote:
> John-Mark Gurney  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=, 
> 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=, 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= optimized out>) at /usr/src/sys/amd64/amd64/trap.c:856
> #7  0x8088a131 in trap_pfault (frame=0xfe009397b7e0, 
> usermode=) 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 , 
> 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 in spa_open (name=0xff

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

[Oliver Pinter]

On Wed, Feb 25, 2015 at 9:34 PM, John Baldwin  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: atkbd.c not compiling?

[Oliver Pinter]

On Sat, Feb 28, 2015 at 10:25 PM, Ryan Stone  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  wrote:
> On Feb 28, 2015, at 14:15, Garrett Cooper  wrote:
>
>> On Feb 28, 2015, at 13:56, Ryan Stone  wrote:
>>
>>> On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper  
>>> 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: Broadwell Support FreeBSD 10.1

[Oliver Pinter]

On Mon, Mar 23, 2015 at 12:32 AM, Marek Novotny
 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: 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  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  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: Kernel build failed in sys/x86/acpica @r281433

[Oliver Pinter]

On 4/11/15, David Wolfskill  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: 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  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: CTF: wpa_supplicant/hostapd 2.4 import

[Oliver Pinter]

On 4/23/15, Oliver Pinter  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  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]

On 4/26/15, Oliver Pinter  wrote:
> On 4/23/15, Oliver Pinter  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  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: Race VT+X11 on -current

[Oliver Pinter]

Hi Hans!

On 5/10/15, Hans Petter Selasky  wrote:
> On 05/10/15 18:53, Wolfgang Zenker wrote:
>> Hi,
>>
>> * Hans Petter Selasky  [150510 14:47]:
>>> On 05/09/15 23:05, Wolfgang Zenker wrote:
 * Allan Jude  [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: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

[Oliver Pinter]

On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff  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:47 PM, Oliver Pinter
 wrote:
> On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff  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: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

[Oliver Pinter]

On Mon, Jun 1, 2015 at 9:55 PM, Oliver Pinter
 wrote:
> On Mon, Jun 1, 2015 at 9:47 PM, Oliver Pinter
>  wrote:
>> On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff  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:7

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: broken release generation when

[Oliver Pinter]

On 6/13/15, Glen Barber  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"

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"

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  wrote:
> Oliver Pinter  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"

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 
#include 

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  wrote:
>
>> On Jul 7, 2015, at 15:00, Oliver Pinter  
>> 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 
>> #include 
>>
>> 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"

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

[Oliver Pinter]

On 7/8/15, O'Connor, Daniel  wrote:
>
>> On 8 Jul 2015, at 08:11, Garrett Wollman 
>> 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"

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

[Oliver Pinter]

On 7/8/15, Konstantin Belousov  wrote:
> On Wed, Jul 08, 2015 at 11:53:39AM +0200, Oliver Pinter wrote:
>> On 7/8/15, O'Connor, Daniel  wrote:
>> >
>> >> On 8 Jul 2015, at 08:11, Garrett Wollman
>> >> 
>> >> 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/9/15, NGie Cooper  wrote:
> On Thu, Jul 9, 2015 at 1:41 AM, Konstantin Belousov 
> 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: duration of buildworld

[Oliver Pinter]

Hi!

On 7/27/15, Matthias Apitz  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"

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

[Oliver Pinter]

On 8/20/15, Dimitry Andric  wrote:
> On 20 Aug 2015, at 00:56, Oliver Pinter 
> 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  wrote:
>
>> On Aug 20, 2015, at 9:38 AM, Oliver Pinter 
>> wrote:
>>
>> On 8/20/15, Dimitry Andric  wrote:
>>> On 20 Aug 2015, at 00:56, Oliver Pinter 
>>> 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"

Re: panic: Stray timeout

[Oliver Pinter]

On 8/30/15, Andriy Gapon  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=, ap= 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=)
> 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=) 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=) at
> /usr/src/sys/kern/kern_intr.c:1356
> #10 0x805fba9b in fork_exit (callout=0x805fedc0
> ,
> 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 , 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=)
> 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 ,
> 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 , 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 , 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
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-cu

Re: panic: Stray timeout

[Oliver Pinter]

On 8/31/15, Jean-Sébastien Pédron  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"

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:   48 85 fftest   %rdi,%rdi
8039c32c:

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"

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

[Oliver Pinter]

CC+= swills

On 9/17/15, Oliver Pinter  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
> 
> 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: 

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: 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
> for authoring and committing. Here's the original:
>
> % svn log -vc392405 svn://svn.freebsd.org/ports
> ---

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"

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: 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 
wrote:

> Oliver Pinter > 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 
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"

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: 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, 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: 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"

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

[Oliver Pinter]

On 2/5/16, Oliver Pinter  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 = &null_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"

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

[Oliver Pinter]

On 2/6/16, Konstantin Belousov  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 = &null_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,
&fullpath, &freepath);
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: 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: 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: 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"

[RFC] Enable nxstack by default

[Oliver Pinter]

Hi all!

I think, it's the time to enable the nxstack feature. Any comments, pros, cons?
From 2641987c35b025fa92adba402535a71aa1a4f7ce Mon Sep 17 00:00:00 2001
From: Oliver Pinter 
Date: Mon, 17 Oct 2011 21:14:58 +0200
Subject: [PATCH] enable nxstack by default

Signed-off-by: Oliver Pinter 

diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 45f6d64..507b4de 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,7 @@ static int elf_legacy_coredump = 0;
 SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, 
 &elf_legacy_coredump, 0, "");
 
-static int __elfN(nxstack) = 0;
+static int __elfN(nxstack) = 1;
 SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
 nxstack, CTLFLAG_RW, &__elfN(nxstack), 0,
 __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable stack");
___
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] Enable nxstack by default

[Oliver Pinter]

Looks good to me.

On 10/18/11, Kostik Belousov  wrote:
> On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
>> Hi all!
>>
>> I think, it's the time to enable the nxstack feature. Any comments,
>> pros, cons?
>
> I dragged the change long enough for it to miss the 9.0.
> After the 9.0 is released, I will flip the switch with the following
> change.
>
> diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
> index 8455f48..926fe64 100644
> --- a/sys/kern/imgact_elf.c
> +++ b/sys/kern/imgact_elf.c
> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
>  SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
>  &elf_legacy_coredump, 0, "");
>
> -static int __elfN(nxstack) = 0;
> +int __elfN(nxstack) =
> +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
> + 1;
> +#else
> + 0;
> +#endif
>  SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
>  nxstack, CTLFLAG_RW, &__elfN(nxstack), 0,
>  __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable
> stack");
> diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
> index 7500462..0e27351 100644
> --- a/sys/powerpc/aim/mmu_oea64.c
> +++ b/sys/powerpc/aim/mmu_oea64.c
> @@ -1445,6 +1445,8 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes,
> u_int8_t *flags, int wait)
>   return (void *)va;
>  }
>
> +extern int elf32_nxstack;
> +
>  void
>  moea64_init(mmu_t mmu)
>  {
> @@ -1464,6 +1466,8 @@ moea64_init(mmu_t mmu)
>   uma_zone_set_allocf(moea64_mpvo_zone,moea64_uma_page_alloc);
>   }
>
> + elf32_nxstack = 1;
> +
>   moea64_initialized = TRUE;
>  }
>
> diff --git a/sys/powerpc/booke/machdep.c b/sys/powerpc/booke/machdep.c
> index c2b5e6f..82a37e1 100644
> --- a/sys/powerpc/booke/machdep.c
> +++ b/sys/powerpc/booke/machdep.c
> @@ -192,6 +192,8 @@ void print_kernel_section_addr(void);
>  void print_kenv(void);
>  u_int booke_init(uint32_t, uint32_t);
>
> +extern int elf32_nxstack;
> +
>  static void
>  cpu_e500_startup(void *dummy)
>  {
> @@ -227,6 +229,9 @@ cpu_e500_startup(void *dummy)
>   /* Set up buffers, so they can be used to read disk labels. */
>   bufinit();
>   vm_pager_bufferinit();
> +
> + /* Cpu supports execution permissions on the pages. */
> + elf32_nxstack = 1;
>  }
>
>  static char *
>
>
___
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] Enable nxstack by default

[Oliver Pinter]

On 10/18/11, Arnaud Lacombe  wrote:
> Hi,
>
> On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper  wrote:
>> On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov 
>>> wrote:
>>>>
>>>> On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
>>>>>
>>>>> Hi all!
>>>>>
>>>>> I think, it's the time to enable the nxstack feature. Any comments,
>>>>> pros, cons?
>>>>
>>>> I dragged the change long enough for it to miss the 9.0.
>>>> After the 9.0 is released, I will flip the switch with the following
>>>> change.
>>>>
>>>> diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
>>>> index 8455f48..926fe64 100644
>>>> --- a/sys/kern/imgact_elf.c
>>>> +++ b/sys/kern/imgact_elf.c
>>>> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
>>>>  SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
>>>> &elf_legacy_coredump, 0, "");
>>>>
>>>> -static int __elfN(nxstack) = 0;
>>>> +int __elfN(nxstack) =
>>>> +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit
>>>> */
>>>>
>>> Why leaving 32bits x86 CPU supporting the NX feature behind ?
>>
>> Most likely because it was assumed that i386 doesn't fully support it.
>> According to ye great Wikipedia, NX support didn't roll into i386 until
>> Prescott, which was pretty late in the non-64-bit capable family of CPUs,
>> as
>> its successor -- Conroe -- was 64-bit. Intel detuned some of the early
>> Dual
>> Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD.
>>
>> There are probably more details in binutils, gcc, etc, that I'm missing
>> and
>> Kostik can expound on.
>>
> NX support is advertised in the cpuid flags, just add the logic to
> handle this interface. Kostik's patch is just incomplete, but he's got
> a commit bit so he can commit it as-is, as he will.
>
> If nonexec_stack becomes the default, it should be on every CPU
> supporting the feature, not just the low-hanging one.
>
>  - Arnaud
>

the NX detection code already implemented in i386, but this feature
required PAE:

@initializecpu(void):

»   »   }
#ifdef PAE
»   »   if ((amd_feature & AMDID_NX) != 0) {
»   »   »   uint64_t msr;

»   »   »   msr = rdmsr(MSR_EFER) | EFER_NXE;
»   »   »   wrmsr(MSR_EFER, msr);
»   »   »   pg_nx = PG_NX;
»   »   }
#endif
»   »   break
___
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] Enable nxstack by default

[Oliver Pinter]

In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X
(~nxstack), mprotect restriction, veriexec, mmap randomization[2]...)

[0] http://pax.grsecurity.net/docs/index.html
[1] http://www.netbsd.org/~elad/recent/man/security.8.html
[2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff

On 10/19/11, Arnaud Lacombe  wrote:
> Hi,
>
> 2011/10/18 Kostik Belousov :
>> On Tue, Oct 18, 2011 at 01:06:27PM -0400, Arnaud Lacombe wrote:
>>> Hi,
>>>
>>> On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter 
>>> wrote:
>>> > On 10/18/11, Arnaud Lacombe  wrote:
>>> >> Hi,
>>> >>
>>> >> On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper 
>>> >> wrote:
>>> >>> On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
>>> >>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov
>>> >>>> 
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
>>> >>>>>>
>>> >>>>>> Hi all!
>>> >>>>>>
>>> >>>>>> I think, it's the time to enable the nxstack feature. Any
>>> >>>>>> comments,
>>> >>>>>> pros, cons?
>>> >>>>>
>>> >>>>> I dragged the change long enough for it to miss the 9.0.
>>> >>>>> After the 9.0 is released, I will flip the switch with the
>>> >>>>> following
>>> >>>>> change.
>>> >>>>>
>>> >>>>> diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
>>> >>>>> index 8455f48..926fe64 100644
>>> >>>>> --- a/sys/kern/imgact_elf.c
>>> >>>>> +++ b/sys/kern/imgact_elf.c
>>> >>>>> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
>>> >>>>>  SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
>>> >>>>>     &elf_legacy_coredump, 0, "");
>>> >>>>>
>>> >>>>> -static int __elfN(nxstack) = 0;
>>> >>>>> +int __elfN(nxstack) =
>>> >>>>> +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32
>>> >>>>> bit
>>> >>>>> */
>>> >>>>>
>>> >>>> Why leaving 32bits x86 CPU supporting the NX feature behind ?
>>> >>>
>>> >>> Most likely because it was assumed that i386 doesn't fully support
>>> >>> it.
>>> >>> According to ye great Wikipedia, NX support didn't roll into i386
>>> >>> until
>>> >>> Prescott, which was pretty late in the non-64-bit capable family of
>>> >>> CPUs,
>>> >>> as
>>> >>> its successor -- Conroe -- was 64-bit. Intel detuned some of the
>>> >>> early
>>> >>> Dual
>>> >>> Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about
>>> >>> AMD.
>>> >>>
>>> >>> There are probably more details in binutils, gcc, etc, that I'm
>>> >>> missing
>>> >>> and
>>> >>> Kostik can expound on.
>>> >>>
>>> >> NX support is advertised in the cpuid flags, just add the logic to
>>> >> handle this interface. Kostik's patch is just incomplete, but he's got
>>> >> a commit bit so he can commit it as-is, as he will.
>>> >>
>>> >> If nonexec_stack becomes the default, it should be on every CPU
>>> >> supporting the feature, not just the low-hanging one.
>>> >>
>>> >>  - Arnaud
>>> >>
>>> >
>>> > the NX detection code already implemented in i386, but this feature
>>> > required PAE:
>>> >
>>> yes, this is the conclusion I reached too. But this does not change
>>> the fact that the VM should know about that, and this is missing from
>>> Kostik's patch. I guess the first hunk should read:
>>>
>>> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
>>>  SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
>>>     &elf_legacy_coredump, 0, &qu

Re: possible mountroot regression

[Oliver Pinter]

On 10/19/11, Olivier Smedts  wrote:
> Hello,
>
> 2011/10/19 Marcel Moolenaar :
>>
>> On Oct 18, 2011, at 9:04 AM, Andriy Gapon wrote:
>>
>>> Would you be able to commit a variant of this patch sans the 'x' part?
>>>
>>
>> Yes, soonish. If people like the 'x' change I can do that in a followup
>> commit as well. I just need to know if people like it or not...
>
> Yes, it's useful. But why not "q" for "quit" ? Just a bikeshed color idea...
>
> Cheers

eXit :)

>
> --
> Olivier Smedts _
> ASCII ribbon campaign ( )
> e-mail: oliv...@gid0.org- against HTML email & vCards  X
> www: http://www.gid0.org- against proprietary attachments / \
>
>   "Il y a seulement 10 sortes de gens dans le monde :
>   ceux qui comprennent le binaire,
>   et ceux qui ne le comprennent pas."
> ___
> 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"

[PATCH][acpi_thermal] add dimension

[Oliver Pinter]

Hi all!

$subject
From c46f65c2d53ef3bd8bcc877bb9da518a524d7c1b Mon Sep 17 00:00:00 2001
From: Oliver Pinter 
Date: Sun, 6 Nov 2011 20:49:16 +0100
Subject: [PATCH] specify polling_rate dimension

Signed-off-by: Oliver Pinter 

diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
index 18996bd..43267b4 100644
--- a/sys/dev/acpica/acpi_thermal.c
+++ b/sys/dev/acpica/acpi_thermal.c
@@ -245,7 +245,7 @@ acpi_tz_attach(device_t dev)
 	SYSCTL_ADD_INT(&acpi_tz_sysctl_ctx,
 		   SYSCTL_CHILDREN(acpi_tz_sysctl_tree),
 		   OID_AUTO, "polling_rate", CTLFLAG_RW,
-		   &acpi_tz_polling_rate, 0, "monitor polling rate");
+		   &acpi_tz_polling_rate, 0, "monitor polling rate in sec");
 	SYSCTL_ADD_INT(&acpi_tz_sysctl_ctx,
 		   SYSCTL_CHILDREN(acpi_tz_sysctl_tree), OID_AUTO,
 		   "user_override", CTLFLAG_RW, &acpi_tz_override, 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: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]

[Oliver Pinter]

On 11/9/11, Arnaud Lacombe  wrote:
> Hi,
>
> On Tue, Nov 8, 2011 at 9:35 PM, Julian Elischer  wrote:
>> On 11/8/11 5:52 PM, Arnaud Lacombe wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer
>>>  wrote:

 On 11/8/11 10:49 AM, Arnaud Lacombe wrote:
>
> Hi,
> To avoid future complaints about the fact that I would be only "talk"
> without "action", I did implement what I suggested above. As it is
> quite a large patch-set, I will not post it directly here, however, it
> is available on github:
>
> https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug
>
> It convert a bunch of debug interface to use the caller instruction
> pointer, as well as a proof-of-concept teaching printf(9) to convert
> IP to symbol_name+offset.
>
> It translates in a direct saving of about +250kB on i386's GENERIC,
> just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0,
> translates to a save of +80kB.
>
> Please note that this is still WIP code.

 A couple of comments.
 Firstly, the idea of a printf method to print the IP as symbol+offset is
 an
 interesting idea
 that should be followed up in its own right.

>>> FWIW, I have no credit in this idea. It has been in Linux for ages and
>>> ages.
>>
>> yeah as I said  at work I use linux and BSD...
>> the linux stuff that just prints out IP really annoys me.
>>
>> the list stuff and netgraph debug (which should be off in any production
>> system)
> this is, I guess, where we do not agree. You find it acceptable to run
> totally different code in production and during debug. I do not. This
> is completely insane, even more nowadays where heavy parallelism
> increases the likelihood of races, and subtle change in the code, even
> optimization, can cause total behavioral change (ie. Heisenbug).
>
> For the record, we have been tracking for more than 2 months (first
> occurrences happened a year ago) an mbuf corruption in the network
> stack, present in all released code since at least FreeBSD 7[0]. Each
> time we think it is fixed, we are proven wrong by customers within a
> few days when the system crashes again. Even the last attempt which
> was believed to be bullet-proof failed and crashes daily.
>
> All that to say that production code should embed enough facilities to
> allow the system to be fully debugged with a runtime cost as low as
> possible, and a code-size cost as low as possible[1]. I should be able
> to connect on a production machine, turn a knob, an see what is going
> wrong, without the customer noticing.
>
> In the worst case, when you have to enable debug-only code, it must
> not be done by making the non-debug case more expensive, but wrap
> around. The whole original point of the patches was that LOCK_FILE and
> LOCK_LINE are a bad answer to a wrong problem.
>
> `__FILE__, __LINE__' and the bloat introduced is not the problem,
> `const char *file, int line' in way too much prototypes is.
>
> Now, you make me realize that `const char *file, int line' should just
> be removed, not replaced by `unsigned long' or anything else. It's
> likely to be done in another iteration.
>
>> just require you to be able to see the console. and have sources nearby.
>> if you need the IP use gdb.
>>
> "console debugging" is yet another abomination which should be hunted
> down. Just try to do any useful work at high-pps on a serial
> console...
>
>> it's just what you are used to. You are obviously from the dark side
>> ^H^H^H^H^H^H linux.
>>
> My obedience is totally irrelevant to the problem.
>
> However, if you want to know, my heart tends to be with BSDs.
> Unfortunately, it's a sad love-story where your Beloved keeps
> deceiving you day after day. You want to change small bits at a time,
> make several iteration of progress to make things brighter, but your
> Beloved refuses any change because of too much inertia. Sad.
>
>> so you are used to doing it that way.. but don't expect us to change just
>> because that's what Linux does.
>>
> again, mentioning Linux is totally irrelevant. Use of Instruction
> Pointer are implementation details for a not so intrusive solution to
> the problem I pointed out, and which you are totally missing.
>
> Now, please answer this: do you find any of the bloat to the non-debug
> case (ie. passing a NULL pointer and a 0 integer, when `LOCK_DEBUG ==
> 0') worth the extra debugability comfort to be acceptable ?
>
> If you do, then your focus is on making things comfortable for
> developers, at the expense 100's of users, rather than making things
> comfortable for 100's of users, at the expense of developers.
>
>> When we have a problem at work on teh Linux driver, my first step is
>> always
>> to try duplicate it on FreeBSD because:
>>
> well, you're lucky FreeBSD supports your device! Lately, we got lately
> a shiny multi-queue network cards with bypass mechanism... that is not
> supported in Free

Re: Is fork() hook ever possible?

[Oliver Pinter]

On 11/15/11, Andrey Chernov  wrote:
> On Mon, Nov 14, 2011 at 06:08:55PM -0500, David Schultz wrote:
>> Not quite.  OpenBSD's implementation is more careful.  I just
>> noticed a funny thing about FreeBSD's KERN_ARND sysctl: If the
>> random device isn't (or can't be) loaded, KERN_ARND silently
>> decides to initialize itself with the output of random().  This
>> means that whatever minuscule amount of entropy it might have
>> picked up from the clock is reduced to a maximum of 31 bits.
>> That's a fantastic way to provide a false sense of security...
>
> I agree.
>
> Lets separate two things: "no /dev/random for jails" and "no random kernel
> module is loaded".
> IMHO kernel module should _not_ be optional anymore, it solves problem you
> describe and all similar problems at once.
>
> Adding KERN_ARND to arc4random() at this moment solves "no /dev/random for
> jails" problem alone and _not_ pretends to solve "no random kernel module
> is loaded" problem. When random kernel module will become non-optional,
> KERN_ARND automagically makes good security in that place too.
>
> P.S. Do I answer your doubts about &rdat key initialization in my prev.
> posting?

I think it's a much correct solution, rather than the original patch,
while it initializes the whole structure, not only the key array...
(&rdat.key vs &rdat; and uninitialized pid and tv):

fd = _open(RANDOMDEV, O_RDONLY, 0);
done = 0;
if (fd >= 0) {
-   if (_read(fd, &rdat, KEYSIZE) == KEYSIZE)
+   if (_read(fd, &rdat, sizeof(rdat)) == sizeof(rdat))
done = 1;
(void)_close(fd);
-   }
+   }



>
> --
> http://ache.vniz.net/
> ___
> 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: [RFC] Enable nxstack by default

[Oliver Pinter]

On 11/15/11, Jeremie Le Hen  wrote:
> Hi,
>
> On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote:
>> In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X
>> (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...)
>>
>> [0] http://pax.grsecurity.net/docs/index.html
>> [1] http://www.netbsd.org/~elad/recent/man/security.8.html
>> [2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff
>
> Suleiman actually wrought two patches, one randomizing the stack (the
> one you pointed out) and another one randomizing non-fixed mmap(2)
> calls:
>
> http://people.freebsd.org/~ssouhlal/testing/mmap_random-20050528.diff
>
>
> FYI, they do not apply cleanly on recent source trees (the patches were
> made in 2005), but they can be applied with little fiddling.  I'm
> running multiple 8.x production machines with them without any problem.

Yeah, I use thins patch in 7-STABLE and 9-STABLE too.
Patch for 9-STABLE has attached.



>
> I've always wanted them to be committed as opt-in knobs, but I can't
> remember why they hadn't at the time.
>
> Cheers,
> --
> Jeremie Le Hen
>
> Men are born free and equal.  Later on, they're on their own.
>   Jean Yanne
>
commit 779a962519e7ead63dda24348b98f6cde8156752
Author: Oliver Pinter 
Date:   Tue Oct 4 00:24:01 2011 +0200

forwardport mmap-randomization patch from 7-STABLE-op

Signed-off-by: Oliver Pinter 

diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
index fe01142..dc66db6 100644
--- a/sys/kern/kern_exec.c
+++ b/sys/kern/kern_exec.c
@@ -106,6 +106,7 @@ MALLOC_DEFINE(M_PARGS, "proc-args", "Process arguments");
 static int sysctl_kern_ps_strings(SYSCTL_HANDLER_ARGS);
 static int sysctl_kern_usrstack(SYSCTL_HANDLER_ARGS);
 static int sysctl_kern_stackprot(SYSCTL_HANDLER_ARGS);
+static int sysctl_kern_stackgap_random(SYSCTL_HANDLER_ARGS);
 static int do_execve(struct thread *td, struct image_args *args,
 struct mac *mac_p);
 
@@ -120,6 +121,9 @@ SYSCTL_PROC(_kern, KERN_USRSTACK, usrstack, CTLTYPE_ULONG|CTLFLAG_RD|
 SYSCTL_PROC(_kern, OID_AUTO, stackprot, CTLTYPE_INT|CTLFLAG_RD,
 NULL, 0, sysctl_kern_stackprot, "I", "");
 
+SYSCTL_PROC(_kern, OID_AUTO, stackgap_random, CTLTYPE_INT|CTLFLAG_RW,
+NULL, 0, sysctl_kern_stackgap_random, "I", "stackgap maximum offset");
+
 u_long ps_arg_cache_limit = PAGE_SIZE / 16;
 SYSCTL_ULONG(_kern, OID_AUTO, ps_arg_cache_limit, CTLFLAG_RW, 
 &ps_arg_cache_limit, 0, "");
@@ -177,6 +181,30 @@ sysctl_kern_stackprot(SYSCTL_HANDLER_ARGS)
 	sizeof(p->p_sysent->sv_stackprot)));
 }
 
+static int	stackgap_random = 64 * 1024;
+
+static int
+sysctl_kern_stackgap_random(SYSCTL_HANDLER_ARGS)
+{
+	int	err;
+	int	val;
+
+	val=stackgap_random;
+	err=sysctl_handle_int(oidp, &val, sizeof(int), req);
+	if (err || !req->newptr) {
+		return (err);
+	}
+
+	if ((val64*1024*1024) {
+		return (EINVAL);
+	}
+
+	stackgap_random=val;
+
+	return (0);
+}
+
 /*
  * Each of the items is a pointer to a `const struct execsw', hence the
  * double pointer here.
@@ -1248,6 +1276,7 @@ exec_copyout_strings(imgp)
 	size_t execpath_len;
 	int szsigcode, szps;
 	char canary[sizeof(long) * 8];
+	int sgap;
 
 	szps = sizeof(pagesizes[0]) * MAXPAGESIZES;
 	/*
@@ -1265,7 +1294,11 @@ exec_copyout_strings(imgp)
 		if (p->p_sysent->sv_szsigcode != NULL)
 			szsigcode = *(p->p_sysent->sv_szsigcode);
 	}
-	destp =	(caddr_t)arginfo - szsigcode - SPARE_USRSPACE -
+	sgap=0;
+	if (stackgap_random!=0) {
+		sgap=ALIGN(arc4random()&(stackgap_random-1));
+	}
+	destp =	(caddr_t)arginfo - szsigcode - SPARE_USRSPACE - sgap -
 	roundup(execpath_len, sizeof(char *)) -
 	roundup(sizeof(canary), sizeof(char *)) -
 	roundup(szps, sizeof(char *)) -
diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
index e85b681..991a37d 100644
--- a/sys/vm/vm_mmap.c
+++ b/sys/vm/vm_mmap.c
@@ -68,6 +68,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -99,6 +100,10 @@ static int vm_mmap_cdev(struct thread *, vm_size_t, vm_prot_t, vm_prot_t *,
 static int vm_mmap_shm(struct thread *, vm_size_t, vm_prot_t, vm_prot_t *,
 int *, struct shmfd *, vm_ooffset_t, vm_object_t *);
 
+static int mmap_random=1;
+SYSCTL_INT(_vm, OID_AUTO, mmap_random, CTLFLAG_RW, &mmap_random, 0,
+		"random mmap offset");
+
 /*
  * MPSAFE
  */
@@ -256,7 +261,8 @@ sys_mmap(td, uap)
 		/*
 		 * XXX for non-fixed mappings where no hint is provided or
 		 * the hint would fall in the potential heap space,
-		 * place it after the end of the largest possible heap.
+		 * place it after the end of the largest possible heap,
+		 * plus a random offset, if mmap_random is set.
 		 *
 		 * There should really be a pmap call to determine a 

[RFC] fix git detection code in newvers.sh when svn installed

[Oliver Pinter]

Hi All!

When svn installed and the source stored in git, then now the version 
detection failed. The attached patch fixed this situation.


-- 
Oliver Pinter
(Tresorium)
From a84c998c251a83ba3fa3c734b7fbc6fe1af17c6a Mon Sep 17 00:00:00 2001
From: Oliver Pinter 
Date: Tue, 3 Jan 2012 12:17:43 +0100
Subject: [PATCH] fix git detection code in newvers.sh

Signed-off-by: Oliver Pinter 

diff --git a/sys/conf/newvers.sh b/sys/conf/newvers.sh
index c6184a8..b015735 100644
--- a/sys/conf/newvers.sh
+++ b/sys/conf/newvers.sh
@@ -92,6 +92,9 @@ for dir in /bin /usr/bin /usr/local/bin; do
 		svnversion=${dir}/svnversion
 		break
 	fi
+done
+
+for dir in /bin /usr/bin /usr/local/bin; do
 	if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then
 		git_cmd="${dir}/git --git-dir=${SYSDIR}/../.git"
 		break
___
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] fix git detection code in newvers.sh when svn installed

[Oliver Pinter]

On Friday 06 January 2012 19:35:31 Sergey Kandaurov wrote:
> On 6 January 2012 21:50, Oliver Pinter  wrote:
> > Hi All!
> >
> > When svn installed and the source stored in git, then now the version
> > detection failed. The attached patch fixed this situation.
>
> FWIW, a different version proposed by Maciej Milewski on -current
> some time ago. I don't have/use git, so I cannot test these changes.
> It is good in the sense that it doesn't duplicate a search path.
> The patch is below for reference:
>
> --- sys/conf/newvers.sh   2011-11-19 00:56:50.795815738 +0100
> +++ sys/conf/newvers-patched.sh   2011-11-19 00:58:21.187818982 +0100
> @@ -88,14 +88,14 @@
>  i=`${MAKE:-make} -V KERN_IDENT`
>
>  for dir in /bin /usr/bin /usr/local/bin; do
> - if [ -x "${dir}/svnversion" ] ; then
> - svnversion=${dir}/svnversion
> - break
> - fi
>   if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then
>   git_cmd="${dir}/git --git-dir=${SYSDIR}/../.git"
>   break
>   fi
> + if [ -x "${dir}/svnversion" ] ; then
> + svnversion=${dir}/svnversion
> + break
> + fi
>  done
>
>  if [ -n "$svnversion" ] ; then

The problem with this, when git founded first and the source not stored in 
git, then the svn version not correctly set, due the loop first found git, 
and than breaked out.

The same situation as my patch fixed, but from svn viewpoint.

-- 
Oliver Pinter
(Tresorium)
___
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"

[PATCH] unbreak XDM build when clang set as base compiler

[Oliver Pinter]

Hi all!

This patch fixed the problem, when buildig xdm on a machine where
clang is the base the compiler (WITH_CLANG_IS_CC).


unbreak_xdm_build_when_clang_set_as_CC.diff
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"

[PATCH] unbreak imake build when clang set as base compiler

[Oliver Pinter]

Hi all!

This patch fixed the problem, when buildig imake on a machine where
clang is the base the compiler (WITH_CLANG_IS_CC).


unbreak_imake_build_when_clang_set_as_CC.diff
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"

[PATCH] unbreak gccmakedep build when clang set as base compiler

[Oliver Pinter]

Hi all!

This patch fixed the problem, when buildig gccmakedep (yeah, gcc...)
on a machine where
clang is the base the compiler (WITH_CLANG_IS_CC).


unbreak_gccmakedep_build_when_clang_set_as_CC.diff
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: [PATCH] unbreak imake build when clang set as base compiler

[Oliver Pinter]

On 9/26/12, Garrett Cooper  wrote:
> On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter 
> wrote:
>> Hi all!
>>
>> This patch fixed the problem, when buildig imake on a machine where
>> clang is the base the compiler (WITH_CLANG_IS_CC).
>
> (Picking a random message to reply to) Why not create PRs and CC the
> relevant parties?

because I hope, there become this issue a mote attention ;)

of course, I create in near future a PR, but before that, I send an
updated patch, and yes, I know, that this is not a clean solution, but
better than nothing.

>
___
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: [PATCH] unbreak imake build when clang set as base compiler

[Oliver Pinter]

On 9/26/12, Garrett Cooper  wrote:
> On Wed, Sep 26, 2012 at 2:18 PM, Oliver Pinter 
> wrote:
>> On 9/26/12, Garrett Cooper  wrote:
>>> On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter 
>>> wrote:
>>>> Hi all!
>>>>
>>>> This patch fixed the problem, when buildig imake on a machine where
>>>> clang is the base the compiler (WITH_CLANG_IS_CC).
>>>
>>> (Picking a random message to reply to) Why not create PRs and CC the
>>> relevant parties?
>>
>> because I hope, there become this issue a mote attention ;)
>
> Or gets lost in someone's mailbox :(...
>
>> of course, I create in near future a PR, but before that, I send an
>> updated patch, and yes, I know, that this is not a clean solution, but
>> better than nothing.
>
> Having a PR is better than a random email that will most likely get
> lost. I would definitely respond to:
>
> "Hey $dev! I filed $PR -- can you please take a look at it? It solves
> '$reason'. Thanks!"

ports/172103 ports/172104 ports/172102 ports/172101 ports/172100 ;)

>
> You might get better results this way too and less duplicated effort
> by multiple individuals.. just sayin'...
>
> Thanks!
> -Garrett
>
___
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: [PATCH] unbreak imake build when clang set as base compiler

[Oliver Pinter]

On 9/27/12, Oliver Pinter  wrote:
> On 9/26/12, Garrett Cooper  wrote:
>> On Wed, Sep 26, 2012 at 2:18 PM, Oliver Pinter 
>> wrote:
>>> On 9/26/12, Garrett Cooper  wrote:
>>>> On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter 
>>>> wrote:
>>>>> Hi all!
>>>>>
>>>>> This patch fixed the problem, when buildig imake on a machine where
>>>>> clang is the base the compiler (WITH_CLANG_IS_CC).
>>>>
>>>> (Picking a random message to reply to) Why not create PRs and CC the
>>>> relevant parties?
>>>
>>> because I hope, there become this issue a mote attention ;)
>>
>> Or gets lost in someone's mailbox :(...
>>
>>> of course, I create in near future a PR, but before that, I send an
>>> updated patch, and yes, I know, that this is not a clean solution, but
>>> better than nothing.
>>
>> Having a PR is better than a random email that will most likely get
>> lost. I would definitely respond to:
>>
>> "Hey $dev! I filed $PR -- can you please take a look at it? It solves
>> '$reason'. Thanks!"
>
> ports/172103 ports/172104 ports/172102 ports/172101 ports/172100 ;)

and the patches are here too:
http://oliverp.teteny.bme.hu/freebsd/patches/ports-clang/

>
>>
>> You might get better results this way too and less duplicated effort
>> by multiple individuals.. just sayin'...
>>
>> Thanks!
>> -Garrett
>>
>
___
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"

git.freebsd.org is down?

[Oliver Pinter]

Hi All!

I got this message, when I why try to pull from git.freebsd.org:

---8<---
fatal: unable to connect git.freebsd.org:
git.freebsd.org[0: 69.147.83.33]: errno=Connection refused
git.freebsd.org[1: 2001:4f8:fff6::21]: errno=No route to host
---8<---

The IPv6 related are ok, while this machine does not have an IPv6
address but the first not.

The git.kernek.org adderss is pingable.
___
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"