Re: Strange issue after early AP startup

2017-01-19 Thread Hans Petter Selasky 

On 01/18/17 09:00, Hans Petter Selasky wrote:

On 01/18/17 02:18, John Baldwin wrote:

You might still want to adjust 'nextevent' to schedule the next interrupt
to be sooner than 'timerperiod' though.  You could just set
'nextevent' to
'now' in that case instead of 'next'.


Right, I'll give that a spin. Would have to be "now + 1" instead of
"now", due to check before et_start() ?



Hi John,

Here is another variant of my patch which solves the EARLY AP startup 
problem with timers. What do you think?


> diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c
> index 7f7769d..8bacff6 100644
> --- a/sys/kern/kern_clocksource.c
> +++ b/sys/kern/kern_clocksource.c
> @@ -207,7 +207,7 @@ handleevents(sbintime_t now, int fake)
> }
> } else
> state->nextprof = state->nextstat;
> -   if (now >= state->nextcallopt) {
> +   if (now >= state->nextcallopt || now >= state->nextcall) {
> state->nextcall = state->nextcallopt = SBT_MAX;
> callout_process(now);
> }

I can add prints/asserts to show that what happens is that 
"state->nextcallopt > now" while "state->nextcall <= now". This 
situtation is allowed to persist due to the way getnextcpuevent() is 
currently implemented.


Can the people CC'ed give the attached patch a spin and report back?

--HPS
diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c
index 7f7769d..8bacff6 100644
--- a/sys/kern/kern_clocksource.c
+++ b/sys/kern/kern_clocksource.c
@@ -207,7 +207,7 @@ handleevents(sbintime_t now, int fake)
 		}
 	} else
 		state->nextprof = state->nextstat;
-	if (now >= state->nextcallopt) {
+	if (now >= state->nextcallopt || now >= state->nextcall) {
 		state->nextcall = state->nextcallopt = SBT_MAX;
 		callout_process(now);
 	}
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r311568 makes freerdp very slow

2017-01-19 Thread Jakob Alvermark 
On Wed, January 18, 2017 19:29, John Baldwin wrote:
> On Tuesday, January 17, 2017 01:46:31 PM Jakob Alvermark wrote:
>
>> On Fri, January 13, 2017 22:46, Jakob Alvermark wrote:
>>
>>> On Fri, January 13, 2017 19:44, John Baldwin wrote:
>>>
>>>
 On Friday, January 13, 2017 09:58:01 AM Jakob Alvermark wrote:



> On Thu, January 12, 2017 19:26, John Baldwin wrote:
>
>
>
>> On Thursday, January 12, 2017 12:42:11 PM Shawn Webb wrote:
>>
>>
>>
>>
>>> On Thu, Jan 12, 2017 at 06:05:08PM +0100, Jakob Alvermark
>>> wrote:
>>>
>>>
>>>
>>>
 Hi,





 r311568 Set MORETOCOME for AIO write requests on a socket.

 After this commit freerdp is very slow.





 Before the password prompt would appear immediately when
 connecting to a server. Now it takes 5-10 seconds. After
 entering the password, another 5-10 seconds until I am
 connected. Once connected, there is a considerable lag.


 What could be the problem?




>>>
>>> I don't know what the problem is, but I am seeing the same
>>> symptom.
>>>
>>>
>>
>> Can you get a ktrace of the freerdp process during this?  The
>> commit should only be setting MORETOCOME if multiple aio_write
>> requests are queued to the same socket (so that TCP can batch
>> them into a single packet). However, it should not affect an
>> application just calling aio_write() on a socket once.
>>
>> --
>> John Baldwin
>>
>>
>>
>
> Hi John,
>
>
>
>
> I got the ktrace, what do I do with it?
>
>
>

 kdump will generate a text representation, perhaps using 'kdump -s'
 to not include dumps of raw I/O data.  If you can put the output of
 kdump at a URL I can fetch from then I can look at it.

>>>
>>> OK, here it is:
>>> http://filebin.ca/38mkuLau9Yqu/ktrace.out.xfreerdp.txt
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Jakob
>>>
>>
>> Hi,
>>
>>
>> Did you get any chance to look at this?
>>
>
> I have not yet, but can you please try the fix in r312387?
>
>
> --
> John Baldwin
>
>

Yes, I am now at r312404 and it works as before again.
Thanks!

Jakob

___
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: ISO image: where is the CLANG compiler?

2017-01-19 Thread O. Hartmann 
On Thu, 19 Jan 2017 06:58:16 +0100
Matthias Apitz  wrote:

> El día Wednesday, January 18, 2017 a las 08:00:04PM -0500, Allan Jude
> escribió:
> 
> > On 2017-01-18 14:37, O. Hartmann wrote:  
> > > Am Wed, 18 Jan 2017 16:38:32 +0100
> > > Matthias Apitz  schrieb:
> > >   
> > >> Why you do not just boot from USB some mem stick image, mount some disk
> > >> space to /mnt, svn checkout CURRENT to /mnt and build a booteable system
> > >> (world and kernel) and install to DESTDIR=/mnt ?
> > >>
> > >> I do not understand all this hassle?
> > >>
> > >>  matthias
> > >>  
> > > 
> > > Wow!
> > > 
> > > As I initially stated, that is EXACTLY what I was inclined to do except
> > > the fact that I had already an intact /usr/obj and usr/src with a
> > > complete compiled system.
> > > 
> > > I booted from mem stick and I was lost due to no cc!
> > > 
> > > Even for "make installworld" it seems I have to rely on the compiler. And
> > > the images (ISO, memstick et cetera) provided these days do not contain
> > > any clang.  
> 
> Yes, you will need it and it will complain about missing it, if for
> example you moved 'obj and 'src' to other dirs after 'make build...'
> 
> But, in your case the mem image really is lacking the cc/clang; I
> fetched the image an did:
> 
> 
> # mdconfig -a -t vnode -u 1 -f
> ~guru/Downloads/FreeBSD-11.0-RELEASE-amd64-memstick.img # mount -o
> ro /dev/md1p3 /mnt # find /mnt -name clang
> /mnt/usr/share/doc/llvm/clang
> /mnt/usr/lib/clang
> /mnt/usr/lib/debug/usr/lib/clang
> # find /mnt -name cc
> /mnt/usr/include/netinet/cc
> 
> With this img  alone, you can't compile a system :-(
> 
> Setup a system from DVD and build your own image containing a complete
> system on an USB key; with this boot your damaged system, recompile and
> reinstall world and kernel. If you (O. Hartmann) need a step by step
> guide, I could send it to you.
> 
>   matthias
> 

Hello,

thanks for your help offering! very kind.

I've already solved the problem - not with the suggested process, but via
copying missing libs and files from and identical intact source. After that, I
ran make buildword/buildkernel and was able to successfully install the new
system.

As I stated before: I already had a complete compiled world and kernel existing
in their proper, intact folders (usr/src and usr/obj). There was no need to
compile a whole world.
Intending to "make installworld" failed, this is the real problem, because the
ISO/memstick images provided lack obviously in the required infrastructure and
so these images are worthless for sophisticated rescue operations - or even
such a simple ask as described initially in my posting.

I created images on CURRENT of my own - they all lack in the ability of having
the necessary tools aboard. So I consider every image useless for rescue
operations except, maybe, the DVD image - but this one is not provided anymore.
For what reason? Time? Accepted. Space/disk usage? Well, welcome back in the
stoneage of computer technology ... 

I remember faintly that there was a small discussion on the @CURRENT list, but
I didn't realize that the result would be the extraction of the compiler.

Just for the record: most servers delivered to us do not have CD/DVD drives
anymore - they are outdated and considered an extra these days. Purchasing 1 GB
USB thumbdrives is getting even harder, smallest size my employer provides now
is 2 GB. And most optical drives are DVD. From my point of view - and this is a
personal view - the "standard" is > 1GB so there is no need to break down by
force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 GB. I'd
consider having < 2GB the line of standards (2 GB USB mem drive).
And for those, with need of very small images, smaller images could be provided
as the extra.

Thank you very much,

kind regards,
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"

Build failure: smbios.ko (r312404)

2017-01-19 Thread Jochen Neumeister 

Hi list,

i use 12 current, and will update to r312404.

Buildworld stop with this error:

===> bios (install)
===> bios/smbios (install)
install -T release -o root -g wheel -m 555   smbios.ko /boot/kernel/
install: smbios.ko: No such file or directory
*** Error code 71

Stop.
bmake[5]: stopped in /usr/src/sys/modules/bios/smbios
*** Error code 1

Stop.
bmake[4]: stopped in /usr/src/sys/modules/bios
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src/sys/modules
*** Error code 1

Stop.
bmake[2]: stopped in /usr/obj/usr/src/sys/MIWIBOX
*** Error code 1

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

Stop.
make: stopped in /usr/src

Google doesn't help me.

Any tipps for me?


Regards

Jochen

___
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: ISO image: where is the CLANG compiler?

2017-01-19 Thread Matthias Apitz 
El día Thursday, January 19, 2017 a las 10:16:46AM +0100, O. Hartmann escribió:

> I created images on CURRENT of my own - they all lack in the ability of having
> the necessary tools aboard. So I consider every image useless for rescue
> operations except, maybe, the DVD image - but this one is not provided 
> anymore.
> For what reason? Time? Accepted. Space/disk usage? Well, welcome back in the
> stoneage of computer technology ... 

No. The process I'm using to create an image for an USB stick leads to a
complete system from which you can even, after booting it, 'make install...'
to another system mounted on /mnt to the booted USB stick. You can even
enrich the USB stick with 'pkg install ...' up to a complete running KDE
desktop system, all running from the USB stick, to test, for example, a
new hardware if it fits your needs. The stick must be of some 16
marketing-GB, or bigger.

This has nothing todo with stoneage, but is just a matter of preparing
something for your needs. Again, let me know if you need this guide.

matthias



-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Wo ist der antiimperialistische Schutzwall, wenn man ihn braucht? 
US-Panzertransport durch ex-DDR"
"Where is the anti-imperialistic  wall, if it's needed? Transport of US-tanks 
through the ex-GDR"
https://deutsch.rt.com/kurzclips/45282-us-panzertransporte-durch-ex-ddr/
___
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"

USB_ERR_TIMEOUT, USB_ERR_IOERROR in Freebsd-current

2017-01-19 Thread M&S - Krasznai András 
Hi

I have FreeBSD-current on a Lenovo T510 laptop.

Since a few weeks I observe the following error messages during boot:

usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
uhub2: 8 ports with 8 removable, self powered
usb_alloc_device: set address 3 failed (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 3 failed, 
USB_ERR_IOERROR
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
sdhci_pci0-slot0:  Controller timeout
sdhci_pci0-slot0: == REGISTER DUMP ==
sdhci_pci0-slot0: Sys addr: 0x | Version:  0x0400
sdhci_pci0-slot0: Blk size: 0x | Blk cnt:  0x
sdhci_pci0-slot0: Argument: 0x | Trn mode: 0x
sdhci_pci0-slot0: Present:  0x01ff | Host ctl: 0x0001
sdhci_pci0-slot0: Power:0x000f | Blk gap:  0x
sdhci_pci0-slot0: Wake-up:  0x | Clock:0x4007
sdhci_pci0-slot0: Timeout:  0x000e | Int stat: 0x0001
sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
sdhci_pci0-slot0: AC12 err: 0x | Slot int: 0x0001
sdhci_pci0-slot0: Caps: 0x01e032b2 | Max curr: 0x0040
sdhci_pci0-slot0: ===
usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 3 failed, 
USB_ERR_IOERROR


The error slows down the boot process, otherwise I did not observe other 
problems.

The same laptop did not show similar error messages with FreeBSD-11, nor with 
any earlier version.

I attached the dmesg output, kernel configuration and pciconf -lv output.

Did anybody experience similar things?

best regards

Üdvözlettel:

Krasznai András
rendszermérnök
M&S Informatikai Zrt.
1136 Budapest, Pannónia u. 11.
Tel: +36 (1) 703-2923
Fax: +36 (1) 703-2949
Mobil: +36 (30) 703-2923
E-mail: krasznai.and...@mands.hu



GEN12
Description: GEN12


pciconf.out
Description: pciconf.out


dmesg.out
Description: dmesg.out
___
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: USB_ERR_TIMEOUT, USB_ERR_IOERROR in Freebsd-current

2017-01-19 Thread Hans Petter Selasky 

On 01/19/17 11:13, M&S - Krasznai András wrote:

Did anybody experience similar things?


Yes, it might be related to EARLY AP startup.

There is a PR with two patches attached which you can try:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215898

--HPS
___
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: Strange issue after early AP startup

2017-01-19 Thread Jia-Shiun Li 
On Thu, Jan 19, 2017 at 4:23 PM, Hans Petter Selasky 
wrote:

>
> I can add prints/asserts to show that what happens is that
> "state->nextcallopt > now" while "state->nextcall <= now". This situtation
> is allowed to persist due to the way getnextcpuevent() is currently
> implemented.
>
> Can the people CC'ed give the attached patch a spin and report back?
>
>
As far as c2d system time is concerned, it works correctly for me w/
r312210.

-Jia-Shiun.
___
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"

CURRENT: UEFI boot does not work on ASrock Z77 M4

2017-01-19 Thread O. Hartmann 
I'm utilizing two systems running FreeBSD Current (most recent) on top of
Asrock Z77 M4pro main PCBs (one is the uATX version, the other regular ATX). The
firmware is the last one a customer can pick up from Asrock's website and it is
dated from 2013. Apart from the fact that the hardware is not useful for any
reliable system, I'm out of resources to exchange these systems with more modern
hardware.

The problem I face is with UEFI. Both boxes do have their OS on SSD (Samsung
850Pro and Samsung 830). I've created a EFI partition of 800k in size with
gpart and it is the first one on the SSD. Both SSDs are UFS and GPT. The
partiton starts at block 40.
Such a configuration works with the very same SSD fine with more modern
hardware (checked with a Fujitsu Celsius M740/UEFI). But the crap Asrock
rejects to boot UEFI. I tried to prepare a hdd the same way - no success. 

The funny part is that any USB thumbdrive with UEFI boot only is booting UEFI
as expected and several Windows 8 or Windows 10 DVDs seem to have no problem.

Maybe the location of the EFI partition (starting block) keeps the secret to
success, but I failed to put the partition at a proper starting point. On the
other hand, all SSDs I have prepared so far for UEFI booting, start their efi
partition with block 40 and they boot.

The big question is: what is the efford to fix this issue - if their will be a
fixing ever? The firmware of those boxes is really as minimal as possible
regarding to options for UEFI booting - but it is fancy coloured ;-)

Many thanks in advance,

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"

USB_ERR_TIMEOUT, USB_ERR_IOERROR in Freebsd-current

2017-01-19 Thread M&S - Krasznai András 
Hello



I tried both patches (separately) which were suggested in



https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215898





on FreeBSD-current r312404 today, and now I can confirm that both solved the 
original problem, the patched kernel boots and no USB_ERR_TIMEOUT nor 
USB_ERR_IOERROR messages were shown.



best regards / Üdvözlettel:

Krasznai András
rendszermérnök
M&S Informatikai Zrt.
1136 Budapest, Pannónia u. 11.
Tel: +36 (1) 703-2923
Fax: +36 (1) 703-2949
Mobil: +36 (30) 703-2923
E-mail: krasznai.and...@mands.hu

___
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_HEAD_i386 - Build #4694 - Failure

2017-01-19 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #4694 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4694/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4694/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4694/console

Change summaries:

312419 by ngie:
Add manpage for mlx4ib(4)

This manpage isn't differentiated from mlx4en except where necessary,
replacing eth/ETH with ib/IB.

Eventually the manpages will be split and the common bits be placed
in a manpage named "mlx4.4".

MFC after:  3 weeks
Reviewed by:hselasky
Sponsored by:   Dell EMC Isilon
Differential Revision:  https://reviews.freebsd.org/D9241

312418 by ngie:
Conditionalize hyperv support in gettimeofday(2) based on MK_HYPERV

The effect at runtime is negligible as the hyperv timer isn't available
except when hyperv is loaded.

This is a prerequisite for conditionalizing the header build/install out
of the build

MFC after:  3 weeks
Reviewed by:sephe
Sponsored by:   Dell EMC Isilon
Differential Revision:  https://reviews.freebsd.org/D9242

312417 by asomers:
Fix build of devd with GCC 4.2

Reported by:olivier
Pointy-hat-to:  asomers
MFC after:  27 days
X-MFC-with: 312395
Sponsored by:   Spectra Logic Corp

312416 by cem:
ffs_vnops: Simplify extattr access

As suggested in r167010, use the structure type and macros to access and
modify UFS2 extended attributes.  Add assertions that pointers are
aligned in places where we now access the data through a structure
pointer, instead of character-by-character.

PR: 216127
Reported by:dewayne at heuristicsystems.com.au
Reviewed by:kib@
Sponsored by:   Dell EMC Isilon
Differential Revision:  https://reviews.freebsd.org/D9225

312414 by kib:
Rename tmpfs_mount member allnode_lock to include namespace prefix.

Sponsored by:   The FreeBSD Foundation
MFC after:  1 week



The end of the build log:

[...truncated 30778 lines...]
--- _sigtimedwait.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe   -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa 
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include 
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD 
 -MF.depend._sigtimedwait.o -MT_sigtimedwait.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -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 -Wno-unused-local-typedef 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter  -Qunused-arguments  
-I/usr/src/lib/libutil -I/usr/src/lib/msun/i387 -I/usr/src/lib/msun/x86 
-I/usr/src/lib/msun/src   -c _sigtimedwait.S -o _sigtimedwait.o
--- _sigwait.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe   -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa 
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include 
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD 
 -MF.depend._sigwait.o -MT_sigwait.o -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -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 -Wno-unused-local-typedef -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter  -Qunused-arguments  
-I/usr/src/lib/libutil -I/usr/src/lib/msun/i387 -I/usr/src/lib/msun/x86 
-I/usr/src/lib/msun/src   -c _sigwait.S -o _sigwait.o
--- _sigwaitinfo.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe   -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa 
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/l

Re: ISO image: where is the CLANG compiler?

2017-01-19 Thread Ultima 
If you plan on running a desktop environment like this make sure its super
speed usb 3.0 or the system will be considerably slow. This is a perfect
backup plan and I always have one for the ready. This is especially
important when on current. I don't think you have to worry so much about
having a smaller usb, it can always be partitions to fit the you're needs.

On Thu, Jan 19, 2017 at 5:12 AM, Matthias Apitz  wrote:

> El día Thursday, January 19, 2017 a las 10:16:46AM +0100, O. Hartmann
> escribió:
>
> > I created images on CURRENT of my own - they all lack in the ability of
> having
> > the necessary tools aboard. So I consider every image useless for rescue
> > operations except, maybe, the DVD image - but this one is not provided
> anymore.
> > For what reason? Time? Accepted. Space/disk usage? Well, welcome back in
> the
> > stoneage of computer technology ...
>
> No. The process I'm using to create an image for an USB stick leads to a
> complete system from which you can even, after booting it, 'make
> install...'
> to another system mounted on /mnt to the booted USB stick. You can even
> enrich the USB stick with 'pkg install ...' up to a complete running KDE
> desktop system, all running from the USB stick, to test, for example, a
> new hardware if it fits your needs. The stick must be of some 16
> marketing-GB, or bigger.
>
> This has nothing todo with stoneage, but is just a matter of preparing
> something for your needs. Again, let me know if you need this guide.
>
> matthias
>
>
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎
> +49-176-38902045
> "Wo ist der antiimperialistische Schutzwall, wenn man ihn braucht?
> US-Panzertransport durch ex-DDR"
> "Where is the anti-imperialistic  wall, if it's needed? Transport of
> US-tanks through the ex-GDR"
> https://deutsch.rt.com/kurzclips/45282-us-panzertransporte-durch-ex-ddr/
> ___
> 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"

Status - ClearFOG PRO

2017-01-19 Thread Outback Dingo 
Can someone comment on the status on the ClearFOG PRO?? Ive seen recent commits
going into the tree that mention it specifically in the DTS file, Is
an image buildable? What
is working now, what is not? I have two that need some FreeBSD love.
___
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: vt(4) odd scrolling behavior

2017-01-19 Thread Kyle Evans 
On Sat, Dec 17, 2016 at 1:34 AM, Poul-Henning Kamp  wrote:
> I've seen it too.  I think beastie sets a scrolling region and
> doesn't clear it.

FWIW- I got some time to mess with it again today, and disabling
beastie (via beastie_disable="YES" in /boot/loader.conf) entirely does
not change the situation on my side, unfortunately. =(

I couldn't think of anything else to try that might affect it, but
open to suggestions.

Thanks,

Kyle Evans
___
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: ISO image: where is the CLANG compiler?

2017-01-19 Thread Glen Barber 
On Thu, Jan 19, 2017 at 10:16:46AM +0100, O. Hartmann wrote:
> On Thu, 19 Jan 2017 06:58:16 +0100
> Matthias Apitz  wrote:
> 
> > El día Wednesday, January 18, 2017 a las 08:00:04PM -0500, Allan Jude
> > escribió:
> > 
> > > On 2017-01-18 14:37, O. Hartmann wrote:  
> > > > Am Wed, 18 Jan 2017 16:38:32 +0100
> > > > Matthias Apitz  schrieb:
> > > >   
> > > >> Why you do not just boot from USB some mem stick image, mount some disk
> > > >> space to /mnt, svn checkout CURRENT to /mnt and build a booteable 
> > > >> system
> > > >> (world and kernel) and install to DESTDIR=/mnt ?
> > > >>
> > > >> I do not understand all this hassle?
> > > >>
> > > >>matthias
> > > >>  
> > > > 
> > > > Wow!
> > > > 
> > > > As I initially stated, that is EXACTLY what I was inclined to do except
> > > > the fact that I had already an intact /usr/obj and usr/src with a
> > > > complete compiled system.
> > > > 
> > > > I booted from mem stick and I was lost due to no cc!
> > > > 
> > > > Even for "make installworld" it seems I have to rely on the compiler. 
> > > > And
> > > > the images (ISO, memstick et cetera) provided these days do not contain
> > > > any clang.  
> > 
> > Yes, you will need it and it will complain about missing it, if for
> > example you moved 'obj and 'src' to other dirs after 'make build...'
> > 
> > But, in your case the mem image really is lacking the cc/clang; I
> > fetched the image an did:
> > 
> > 
> > # mdconfig -a -t vnode -u 1 -f
> > ~guru/Downloads/FreeBSD-11.0-RELEASE-amd64-memstick.img # mount -o
> > ro /dev/md1p3 /mnt # find /mnt -name clang
> > /mnt/usr/share/doc/llvm/clang
> > /mnt/usr/lib/clang
> > /mnt/usr/lib/debug/usr/lib/clang
> > # find /mnt -name cc
> > /mnt/usr/include/netinet/cc
> > 
> > With this img  alone, you can't compile a system :-(
> > 
> > Setup a system from DVD and build your own image containing a complete
> > system on an USB key; with this boot your damaged system, recompile and
> > reinstall world and kernel. If you (O. Hartmann) need a step by step
> > guide, I could send it to you.
> > 
> > matthias
> > 
> 
> Hello,
> 
> thanks for your help offering! very kind.
> 
> I've already solved the problem - not with the suggested process, but via
> copying missing libs and files from and identical intact source. After that, I
> ran make buildword/buildkernel and was able to successfully install the new
> system.
> 
> As I stated before: I already had a complete compiled world and kernel 
> existing
> in their proper, intact folders (usr/src and usr/obj). There was no need to
> compile a whole world.
> Intending to "make installworld" failed, this is the real problem, because the
> ISO/memstick images provided lack obviously in the required infrastructure and
> so these images are worthless for sophisticated rescue operations - or even
> such a simple ask as described initially in my posting.
> 
> I created images on CURRENT of my own - they all lack in the ability of having
> the necessary tools aboard. So I consider every image useless for rescue
> operations except, maybe, the DVD image - but this one is not provided 
> anymore.
> For what reason? Time? Accepted. Space/disk usage? Well, welcome back in the
> stoneage of computer technology ... 
> 
> I remember faintly that there was a small discussion on the @CURRENT list, but
> I didn't realize that the result would be the extraction of the compiler.
> 
> Just for the record: most servers delivered to us do not have CD/DVD drives
> anymore - they are outdated and considered an extra these days. Purchasing 1 
> GB
> USB thumbdrives is getting even harder, smallest size my employer provides now
> is 2 GB. And most optical drives are DVD. From my point of view - and this is 
> a
> personal view - the "standard" is > 1GB so there is no need to break down by
> force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 GB. 
> I'd
> consider having < 2GB the line of standards (2 GB USB mem drive).
> And for those, with need of very small images, smaller images could be 
> provided
> as the extra.
> 

I do want to weigh in here and inform I am actively watching this
thread.  clang(1) is not in disc1.iso or bootonly.iso because the
MK_TOOLCHAIN knob is disabled in the targets that generate them.  This
has actually been the case for quite some time for these images.

dvd1.iso does contain clang, but very rarely (if ever, actually) are
there dvd1.iso images produced for development snapshots.  This is, in
part, solely because of the additional space/bandwidth required on the
mirrors (not just mirrors controlled by the Project, but third-party
mirrors as well).

I am working on splitting out how the memstick.img and disc1.iso images
are produced, but ran into a problem which I'm looking into a workaround
that is backwards-compatible.  Since for USB images, a 700MB limit does
not make sense, and right now it just so happens that the memstick.img
is created from the same contents of disc1.iso.

I know thi

Re: ISO image: where is the CLANG compiler?

2017-01-19 Thread Glen Barber 
On Thu, Jan 19, 2017 at 07:10:00PM +, Glen Barber wrote:
> On Thu, Jan 19, 2017 at 10:16:46AM +0100, O. Hartmann wrote:
> > On Thu, 19 Jan 2017 06:58:16 +0100
> > Matthias Apitz  wrote:
> > 
> > > El día Wednesday, January 18, 2017 a las 08:00:04PM -0500, Allan Jude
> > > escribió:
> > > 
> > > > On 2017-01-18 14:37, O. Hartmann wrote:  
> > > > > Am Wed, 18 Jan 2017 16:38:32 +0100
> > > > > Matthias Apitz  schrieb:
> > > > >   
> > > > >> Why you do not just boot from USB some mem stick image, mount some 
> > > > >> disk
> > > > >> space to /mnt, svn checkout CURRENT to /mnt and build a booteable 
> > > > >> system
> > > > >> (world and kernel) and install to DESTDIR=/mnt ?
> > > > >>
> > > > >> I do not understand all this hassle?
> > > > >>
> > > > >>  matthias
> > > > >>  
> > > > > 
> > > > > Wow!
> > > > > 
> > > > > As I initially stated, that is EXACTLY what I was inclined to do 
> > > > > except
> > > > > the fact that I had already an intact /usr/obj and usr/src with a
> > > > > complete compiled system.
> > > > > 
> > > > > I booted from mem stick and I was lost due to no cc!
> > > > > 
> > > > > Even for "make installworld" it seems I have to rely on the compiler. 
> > > > > And
> > > > > the images (ISO, memstick et cetera) provided these days do not 
> > > > > contain
> > > > > any clang.  
> > > 
> > > Yes, you will need it and it will complain about missing it, if for
> > > example you moved 'obj and 'src' to other dirs after 'make build...'
> > > 
> > > But, in your case the mem image really is lacking the cc/clang; I
> > > fetched the image an did:
> > > 
> > > 
> > > # mdconfig -a -t vnode -u 1 -f
> > > ~guru/Downloads/FreeBSD-11.0-RELEASE-amd64-memstick.img # mount -o
> > > ro /dev/md1p3 /mnt # find /mnt -name clang
> > > /mnt/usr/share/doc/llvm/clang
> > > /mnt/usr/lib/clang
> > > /mnt/usr/lib/debug/usr/lib/clang
> > > # find /mnt -name cc
> > > /mnt/usr/include/netinet/cc
> > > 
> > > With this img  alone, you can't compile a system :-(
> > > 
> > > Setup a system from DVD and build your own image containing a complete
> > > system on an USB key; with this boot your damaged system, recompile and
> > > reinstall world and kernel. If you (O. Hartmann) need a step by step
> > > guide, I could send it to you.
> > > 
> > >   matthias
> > > 
> > 
> > Hello,
> > 
> > thanks for your help offering! very kind.
> > 
> > I've already solved the problem - not with the suggested process, but via
> > copying missing libs and files from and identical intact source. After 
> > that, I
> > ran make buildword/buildkernel and was able to successfully install the new
> > system.
> > 
> > As I stated before: I already had a complete compiled world and kernel 
> > existing
> > in their proper, intact folders (usr/src and usr/obj). There was no need to
> > compile a whole world.
> > Intending to "make installworld" failed, this is the real problem, because 
> > the
> > ISO/memstick images provided lack obviously in the required infrastructure 
> > and
> > so these images are worthless for sophisticated rescue operations - or even
> > such a simple ask as described initially in my posting.
> > 
> > I created images on CURRENT of my own - they all lack in the ability of 
> > having
> > the necessary tools aboard. So I consider every image useless for rescue
> > operations except, maybe, the DVD image - but this one is not provided 
> > anymore.
> > For what reason? Time? Accepted. Space/disk usage? Well, welcome back in the
> > stoneage of computer technology ... 
> > 
> > I remember faintly that there was a small discussion on the @CURRENT list, 
> > but
> > I didn't realize that the result would be the extraction of the compiler.
> > 
> > Just for the record: most servers delivered to us do not have CD/DVD drives
> > anymore - they are outdated and considered an extra these days. Purchasing 
> > 1 GB
> > USB thumbdrives is getting even harder, smallest size my employer provides 
> > now
> > is 2 GB. And most optical drives are DVD. From my point of view - and this 
> > is a
> > personal view - the "standard" is > 1GB so there is no need to break down by
> > force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 GB. 
> > I'd
> > consider having < 2GB the line of standards (2 GB USB mem drive).
> > And for those, with need of very small images, smaller images could be 
> > provided
> > as the extra.
> > 
> 
> I do want to weigh in here and inform I am actively watching this
> thread.  clang(1) is not in disc1.iso or bootonly.iso because the
> MK_TOOLCHAIN knob is disabled in the targets that generate them.  This
> has actually been the case for quite some time for these images.
> 
> dvd1.iso does contain clang, but very rarely (if ever, actually) are
> there dvd1.iso images produced for development snapshots.  This is, in
> part, solely because of the additional space/bandwidth required on the
> mirrors (not just mirrors controlled by the Project, but third-party
> mirrors as well).
>

Re: ISO image: where is the CLANG compiler?

2017-01-19 Thread Andreas Nilsson 
On Thu, Jan 19, 2017 at 8:10 PM, Glen Barber  wrote:

> On Thu, Jan 19, 2017 at 10:16:46AM +0100, O. Hartmann wrote:
> > On Thu, 19 Jan 2017 06:58:16 +0100
> > Matthias Apitz  wrote:
> >
> > > El día Wednesday, January 18, 2017 a las 08:00:04PM -0500, Allan Jude
> > > escribió:
> > >
> > > > On 2017-01-18 14:37, O. Hartmann wrote:
> > > > > Am Wed, 18 Jan 2017 16:38:32 +0100
> > > > > Matthias Apitz  schrieb:
> > > > >
> > > > >> Why you do not just boot from USB some mem stick image, mount
> some disk
> > > > >> space to /mnt, svn checkout CURRENT to /mnt and build a booteable
> system
> > > > >> (world and kernel) and install to DESTDIR=/mnt ?
> > > > >>
> > > > >> I do not understand all this hassle?
> > > > >>
> > > > >>matthias
> > > > >>
> > > > >
> > > > > Wow!
> > > > >
> > > > > As I initially stated, that is EXACTLY what I was inclined to do
> except
> > > > > the fact that I had already an intact /usr/obj and usr/src with a
> > > > > complete compiled system.
> > > > >
> > > > > I booted from mem stick and I was lost due to no cc!
> > > > >
> > > > > Even for "make installworld" it seems I have to rely on the
> compiler. And
> > > > > the images (ISO, memstick et cetera) provided these days do not
> contain
> > > > > any clang.
> > >
> > > Yes, you will need it and it will complain about missing it, if for
> > > example you moved 'obj and 'src' to other dirs after 'make build...'
> > >
> > > But, in your case the mem image really is lacking the cc/clang; I
> > > fetched the image an did:
> > >
> > >
> > > # mdconfig -a -t vnode -u 1 -f
> > > ~guru/Downloads/FreeBSD-11.0-RELEASE-amd64-memstick.img # mount -o
> > > ro /dev/md1p3 /mnt # find /mnt -name clang
> > > /mnt/usr/share/doc/llvm/clang
> > > /mnt/usr/lib/clang
> > > /mnt/usr/lib/debug/usr/lib/clang
> > > # find /mnt -name cc
> > > /mnt/usr/include/netinet/cc
> > >
> > > With this img  alone, you can't compile a system :-(
> > >
> > > Setup a system from DVD and build your own image containing a complete
> > > system on an USB key; with this boot your damaged system, recompile and
> > > reinstall world and kernel. If you (O. Hartmann) need a step by step
> > > guide, I could send it to you.
> > >
> > > matthias
> > >
> >
> > Hello,
> >
> > thanks for your help offering! very kind.
> >
> > I've already solved the problem - not with the suggested process, but via
> > copying missing libs and files from and identical intact source. After
> that, I
> > ran make buildword/buildkernel and was able to successfully install the
> new
> > system.
> >
> > As I stated before: I already had a complete compiled world and kernel
> existing
> > in their proper, intact folders (usr/src and usr/obj). There was no need
> to
> > compile a whole world.
> > Intending to "make installworld" failed, this is the real problem,
> because the
> > ISO/memstick images provided lack obviously in the required
> infrastructure and
> > so these images are worthless for sophisticated rescue operations - or
> even
> > such a simple ask as described initially in my posting.
> >
> > I created images on CURRENT of my own - they all lack in the ability of
> having
> > the necessary tools aboard. So I consider every image useless for rescue
> > operations except, maybe, the DVD image - but this one is not provided
> anymore.
> > For what reason? Time? Accepted. Space/disk usage? Well, welcome back in
> the
> > stoneage of computer technology ...
> >
> > I remember faintly that there was a small discussion on the @CURRENT
> list, but
> > I didn't realize that the result would be the extraction of the compiler.
> >
> > Just for the record: most servers delivered to us do not have CD/DVD
> drives
> > anymore - they are outdated and considered an extra these days.
> Purchasing 1 GB
> > USB thumbdrives is getting even harder, smallest size my employer
> provides now
> > is 2 GB. And most optical drives are DVD. From my point of view - and
> this is a
> > personal view - the "standard" is > 1GB so there is no need to break
> down by
> > force the FreeBSD image (if size is the reason) down to < 800 MB or < 1
> GB. I'd
> > consider having < 2GB the line of standards (2 GB USB mem drive).
> > And for those, with need of very small images, smaller images could be
> provided
> > as the extra.
> >
>
> I do want to weigh in here and inform I am actively watching this
> thread.  clang(1) is not in disc1.iso or bootonly.iso because the
> MK_TOOLCHAIN knob is disabled in the targets that generate them.  This
> has actually been the case for quite some time for these images.
>
> dvd1.iso does contain clang, but very rarely (if ever, actually) are
> there dvd1.iso images produced for development snapshots.  This is, in
> part, solely because of the additional space/bandwidth required on the
> mirrors (not just mirrors controlled by the Project, but third-party
> mirrors as well).
>
> I am working on splitting out how the memstick.img and disc1.iso images
> are produced, but ran into a pr

Re: crash in iflib_fast_intr

2017-01-19 Thread Shawn Webb 
On Wed, Jan 18, 2017 at 02:45:34PM -0500, Shawn Webb wrote:
> On Wed, Jan 18, 2017 at 07:31:12AM -0700, Sean Bruno wrote:
> > 
> > 
> > On 01/18/17 03:37, peter.b...@bsd4all.org wrote:
> > > Hi,
> > > 
> > > A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. 
> > > Since GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. 
> > > Problem is reproducible.
> > > 
> > > KDB: stack backtrace:
> > > #0 0x805cec97 at kdb_backtrace+0x67
> > > #1 0x80584816 at vpanic+0x186
> > > #2 0x80584683 at panic+0x43
> > > #3 0x8090f222 at trap_fatal+0x322
> > > #4 0x8090f3ec at trap_pfault+0x1bc
> > > #5 0x8090eaa0 at trap+0x280
> > > #6 0x808f35e1 at calltrap+0x8
> > > #7 0x806a202d at iflib_fast_intr+0x3d
> > > #8 0x8054963b at intr_event_handle+0x9b
> > > #9 0x80965f38 at intr_execute_handlers+0x48
> > > #10 0x8096b1cf at lapic_handle_intr+0x3f
> > > #11 0x808f3cc7 at Xapic_isr1+0xb7
> > > #12 0x805b994a at sched_idletd+0x37a
> > > #13 0x805460f5 at fork_exit+0x85
> > > #14 0x808f3b1e at fork_trampoline+0xe
> > > 
> > > Peter
> > 
> > Thanks for the report.  We're looking at this.
> > 
> > This is with an igb(4) interface or em(4)?
> > 
> > sean
> > 
> 
> I'm getting something similar with em(4):
> 
> https://goo.gl/photos/MXiFXtatBYcWagJTA
> 
> I'm at this commit in HardenedBSD:
> 
> https://github.com/HardenedBSD/hardenedBSD/commit/2108b0d56984115eb52e72bd16539071064b348e

r312434 fixes this for me. Thanks a lot for the quick turnaround!

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

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


signature.asc
Description: PGP signature

Re: ISO image: where is the CLANG compiler?

2017-01-19 Thread Glen Barber 
On Thu, Jan 19, 2017 at 08:50:34PM +0100, Andreas Nilsson wrote:
> On Thu, Jan 19, 2017 at 8:10 PM, Glen Barber  wrote:
> > I do want to weigh in here and inform I am actively watching this
> > thread.  clang(1) is not in disc1.iso or bootonly.iso because the
> > MK_TOOLCHAIN knob is disabled in the targets that generate them.  This
> > has actually been the case for quite some time for these images.
> >
> > dvd1.iso does contain clang, but very rarely (if ever, actually) are
> > there dvd1.iso images produced for development snapshots.  This is, in
> > part, solely because of the additional space/bandwidth required on the
> > mirrors (not just mirrors controlled by the Project, but third-party
> > mirrors as well).
> >
> > I am working on splitting out how the memstick.img and disc1.iso images
> > are produced, but ran into a problem which I'm looking into a workaround
> > that is backwards-compatible.  Since for USB images, a 700MB limit does
> > not make sense, and right now it just so happens that the memstick.img
> > is created from the same contents of disc1.iso.
> >
> > I know this does not help with the immediate issue, but wanted to chime
> > in with I do see and understand the larger issue, and am working on
> > a more long-term resolution instead of a one-line workaround.
> >
> >
> Good to see discussion, but my 5c is: do not enlarge regular install media,
> it is hefty enough. I'd rather see it shrink, although without the
> limitations of old cd's rescue-env.
> 
> Install media is install media, not live image. Live usb-sticks are so easy
> to do on your own, why waste the Projects storage and bandwidth on it?
> 

For cases like what initiated this thread, actually.  But, I'm not
looking to increase the disc1.iso size, but separate the disc1.iso and
memstick.img targets, which then can be created from different userland
environments (one with /usr/bin/clang and one without, for example).

But, I do agree with you that keeping the downloadable installer medium
as small as possible (while still being usable for "rescue" cases like
this) is ideal.

Glen



signature.asc
Description: PGP signature

FreeBSD_HEAD_i386 - Build #4695 - Fixed

2017-01-19 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #4695 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4695/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4695/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4695/console

Change summaries:

312428 by kib:
Refcount tmpfs nodes and mount structures.

On dotdot lookup and fhtovp operations, it is possible for the file
represented by tmpfs node to be removed after the thread calculated
the pointer.  In this case, tmpfs_alloc_vp() accesses freed memory.

Introduce the reference count on the nodes.  The allnodes list from
tmpfs mount owns 1 reference, and threads performing unlocked
operations on the node, add one transient reference.  Similarly, since
struct tmpfs_mount maintains the list where nodes are enlisted,
refcount it by one reference from struct mount and one reference from
each node on the list.  Both nodes and tmpfs_mounts are removed when
refcount goes to zero.

Note that this means that nodes and tmpfs_mounts might survive some
time after the node is deleted or tmpfs_unmount() finished.  The
tmpfs_alloc_vp() in these cases returns error either due to node
removal (tn_nlinks == 0) or because of insmntque1(9) error.

Tested by:  pho (as part of larger patch)
Sponsored by:   The FreeBSD Foundation
MFC after:  2 weeks

312427 by erj:
e1000: Add support for Kaby Lake generation i219 (4) and i219 (5) devices

MFC after:  1 week
Sponsored by:   Intel Corporation

312426 by avg:
fix a thread preemption regression in schedulers introduced in r270423

Commit r270423 fixed a regression in sched_yield() that was introduced
in earlier changes.  Unfortunately, at the same time it introduced an
new regression.  The problem is that SWT_RELINQUISH (6), like all other
SWT_* constants and unlike SW_* flags, is not a bit flag.  So, (flags &
SWT_RELINQUISH) is true in cases where that was not really indended,
for example, with SWT_OWEPREEMPT (2) and SWT_REMOTEPREEMPT (11).

A straight forward fix would be to use (flags & SW_TYPE_MASK) ==
SWT_RELINQUISH, but my impression is that the switch types are designed
mostly for gathering statistics, not for influencing scheduling
decisions.

So, I decided that it would be better to check for SW_PREEMPT flag
instead.  That's also the same flag that was checked before r239157.
I double-checked how that flag is used and I am confident that the flag
is set only in the places where we really have the preemption:
- critical_exit + td_owepreempt
- sched_preempt in the ULE scheduler
- sched_preempt in the 4BSD scheduler

Reviewed by:kib, mav
MFC after:  4 days
Sponsored by:   Panzura
Differential Revision: https://reviews.freebsd.org/D9230

312425 by kib:
Make tmpfs directory cursor available outside tmpfs_subr.c.

Tested by:  pho
Sponsored by:   The FreeBSD Foundation
MFC after:  1 week

312424 by hselasky:
Fix problem with suspend and resume when using Skylake chipsets. Make
sure the XHCI controller is reset after halting it. The problem is
clearly a BIOS bug as the suspend and resume is failing without
loading the XHCI driver. The same happens when using Linux and the
XHCI driver is not loaded.

Submitted by:   Yanko Yankulov 
PR: 216261
MFC after:  1 week

312423 by kib:
Refresh tmpfs(5) man page.

Provide more useful explanation of features and quirks.

Reviewed by:emaste, vangyzen
Sponsored by:   The FreeBSD Foundation
MFC after:  1 week
Differential revision:  https://reviews.freebsd.org/D9211

312422 by ngie:
Only conditionally add in hyperv support if we're building amd64

This unbreaks the build because the assembly is written for x64.

MFC after:  3 weeks
X-MFC with: r312418
Pointyhat to:   ngie
Reported by:Jenkins (i386 job)
Sponsored by:   Dell EMC Isilon

___
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: vt(4) chops off the leftmost three columns

2017-01-19 Thread Anindya Mukherjee 
Hi Adrian,

I was looking at the source for the vt driver. Wondering how much work it is to 
add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?

Also, how dependent is splash/screensaver support on the VESA implementation?

Thanks,
Anindya
___
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"

panic on current during shutdown: panic: racct_adjust_resource: resource 4 usage < 0

2017-01-19 Thread Larry Rosenman 

Thu Jan 19 18:03:38 CST 2017

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r311997: 
Sat Jan 14 22:35:29 CST 2017 
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64


panic: racct_adjust_resource: resource 4 usage < 0

GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.

done.

Unread portion of the kernel message buffer:
<118>.
<118>Terminated
<118>Jan 19 17:54:50 192.168.200.11 last message repeated 13 times
<118>Jan 19 17:54:59 borg syslogd: exiting on signal 15
panic: racct_adjust_resource: resource 4 usage < 0
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe2eb7c18830

vpanic() at vpanic+0x186/frame 0xfe2eb7c188b0
kassert_panic() at kassert_panic+0x126/frame 0xfe2eb7c18920
racct_adjust_resource() at racct_adjust_resource+0xca/frame 
0xfe2eb7c18950

racct_set_locked() at racct_set_locked+0xec/frame 0xfe2eb7c18990
racct_set() at racct_set+0x54/frame 0xfe2eb7c189c0
vmspace_exit() at vmspace_exit+0x147/frame 0xfe2eb7c18a00
exit1() at exit1+0x56b/frame 0xfe2eb7c18a60
sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe2eb7c18a70
amd64_syscall() at amd64_syscall+0x2ea/frame 0xfe2eb7c18bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe2eb7c18bf0
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8025c916a, rsp = 
0x7fffebd8, rbp = 0x7fffebf0 ---

Uptime: 4d4h19m38s
Dumping 12670 out of 64463 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%


Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.

done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.

done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux.ko.debug...done.

done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.

done.
Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/if_lagg.ko.debug...done.

done.
Reading symbols from /boot/kernel/snd_envy24ht.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/snd_envy24ht.ko.debug...done.

done.
Reading symbols from /boot/kernel/snd_spicds.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/snd_spicds.ko.debug...done.

done.
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/coretemp.ko.debug...done.

done.
Reading symbols from /boot/kernel/fuse.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fuse.ko.debug...done.

done.
Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichsmb.ko.debug...done.

done.
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/smbus.ko.debug...done.

done.
Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichwd.ko.debug...done.

done.
Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/cpuctl.ko.debug...done.

done.
Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/cryptodev.ko.debug...done.

done.
Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtraceall.ko.debug...done.

done.
Reading symbols from /boot/kernel/profile.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/profile.ko.debug...done.

done.
Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtrace.ko.debug...done.

done.
Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading 
symbols from 
/usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done.

done.
Reading symbols from /boot/kernel/systrace.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/systrace.ko.debug...done.

done.
Reading symbols from /boot/kernel/sdt.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/sdt.ko.debug...done.

done.
Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from 
/usr/lib/debug//b