FreeBSD Quarterly Status Report - Third Quarter 2016

[Benjamin Kaduk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

FreeBSD Project Quarterly Status Report - 3rd Quarter 2016

   As focused as we are on the present and what is happening now, it is
   sometimes useful to take a fresh look at where we have come from, and
   where we are going. This quarter, we had our newest doc committer
   working to trace through the tangled history of many utilities, and we
   also get a glimpse looking forward at what may come in FreeBSD 12.

   Though 11.0-RELEASE was not finalized until after the period covered in
   this report, we can still have some anticipatory excitement for the
   features that will be coming in 12.0. The possibilities are
   tantalizing: a base system with no GPL components, arm64 as a Tier-1
   architecture, capsicum protection for common utilities, and the
   CloudABI for custom software are just a few.

   The work of the present is no less exciting, with 11.0 making its way
   out just after the end of Q3, the new core coming into its own, and
   much more that you'll have to read and find out.

   --Benjamin Kaduk
 __

   Please submit status reports for the fourth quarter of 2016 by January 7.
 __

FreeBSD Team Reports

 * FreeBSD Release Engineering Team
 * Ports Collection
 * The FreeBSD Core Team
 * The FreeBSD Foundation

Projects

 * Capsicum Update
 * ClonOS: New FreeBSD-Based Free/Open Hosting Platform
 * CloudABI: Running Untrusted Programs Directly on top of FreeBSD
 * Improvements to Non-Transparent Bridge Subsystem
 * The Graphics Stack on FreeBSD
 * Using lld, the LLVM Linker, to Link FreeBSD
 * VirtualBox Shared Folders Filesystem
 * ZFS Code Sync with Latest OpenZFS/Illumos

Kernel

 * evdev Support
 * FreeBSD Driver for the Annapurna Labs ENA
 * FreeBSD on Hyper-V and Azure
 * Timekeeping Code Improvements

Google Summer of Code

 * Google Summer of Code 2016
 * Non-BSM to BSM Conversion Tools
 * ptnet Driver and bhyve Device Model

Architectures

 * FreeBSD on Annapurna Labs Alpine
 * FreeBSD on Marvell Armada38x
 * FreeBSD/arm64
 * UEFI Runtime Services

Ports

 * KDE on FreeBSD
 * LXQt on FreeBSD
 * Xfce on FreeBSD

Documentation

 * Documenting the History of Utilities in /bin and /sbin
 __

FreeBSD Team Reports

FreeBSD Release Engineering Team

   Links
   FreeBSD 11.0-RELEASE schedule
URL: https://www.FreeBSD.org/releases/11.0R/schedule.html

   Contact: FreeBSD Release Engineering Team 

   The FreeBSD Release Engineering Team is responsible for setting and
   publishing release schedules for official project releases of FreeBSD,
   announcing code freezes, and maintaining the respective branches, among
   other things.

   The FreeBSD Release Engineering Team continued the 11.0-RELEASE cycle
   which was planned to be released in September, but as a result of
   several last-minute issues, the final release announcement was delayed.

   This project was sponsored by The FreeBSD Foundation.
 __

Ports Collection

   Links
   FreeBSD Ports Website
URL: https://www.FreeBSD.org/ports/
   How to Contribute
URL: 
https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html
   Ports Monitoring Website
URL: http://portsmon.FreeBSD.org/index.html
   Ports Management Team Website
URL: https://www.FreeBSD.org/portmgr/index.html
   Ports Management Team on Twitter
URL: https://twitter.com/FreeBSD_portmgr/
   Ports Management Team on Facebook
URL: https://www.facebook.com/portmgr
   Ports Management Team on Google+
URL: https://plus.google.com/communities/108335846196454338383

   Contact: René Ladan 
   Contact: FreeBSD Ports Management Team 

   The Ports Tree currently contains over 26,300 ports, with the PR count
   around 2,150. Of these PRs, 516 are unassigned. The last quarter saw
   5,295 commits by 117 active committers. Compared to the preceding
   quarter, there is both a slight increase in the number of PRs and the
   number of unassigned PRs, and a slight decrease in the number of
   committers.

   In the last quarter, four commits bits were taken in for safe keeping:
   erwin, miwi, and sem left by their own request and jase was inactive
   for more than 18 months. We welcomed two new committers: Tobias Berner
   (tcberner) and Joseph Mingrone (jrm).

   On the management side, erwin and miwi left portmgr. bapt also left
   portmgr but is still the liaison for core.

   On the infrastructure side, three new USES (grantlee, kde, linux) and
   one new Keyword (javavm) were introduced. The default version of the
   Linux ports is 

Re: was: CURRENT [r308087] still crashing: Backtrace provided

[O. Hartmann]

Am Sun, 13 Nov 2016 12:41:07 +0300
"Andrey V. Elsukov"  schrieb:

> On 13.11.2016 12:23, O. Hartmann wrote:
> > Great, thank you. I would first like to confirm that r307234 is indeed
> > causing the crash - since it appears to be easy to trigger, that should
> > be faster. If not, the core will help track down the real problem.
> 
>  Although I was under the impression the in-kernel-config option
> 
>  makeoptionsDEBUG=-g
> 
>  would make debugging symbols available, I'm proved wrong.
> >>
> >> Do you have option FLOWTABLE in your kernel config?  
> > 
> > Would you suggest to disable this feature in the kernel? Or does the 
> > feature, by
> > accident, influence the debugging ??  
> 
> Hi,
> 
> I never used FLOWTABLE, but as I know, when L2 caching was reintroduced
> the kernel with enabled FLOWTABLE has started crashing almost
> immediately. glebius@ added workaround in r300854 to prevent the panic.
> Then we discussed with him that the change in in_pcb.c should be
> reasonable. And he decided to revert the workaround. Now it seems
> without r300854 FLOWTABLE isn't usable.
> 

... it seems that FLOWTABLE is the culprit.

Running CURRENT 308616 for hours now ...

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpn65F4cV7h_.pgp
Description: OpenPGP digital signature

Re: Lenovo X1 Carbon or T460s

[Andreas Nilsson]

I have a Lenovo X1 yoga, which should be pretty similar to 4th gen X1
Carbon.

I'm running 12-CURRENT with with drm-next-47 bits and corresponding
xorg-next.

I have graphics running fine good enough. There are some yet to be resolved
crashes of gtk-apps, and libreoffice makes X segfault.

Both wired and wireless is working fine. I have not yet made the 4g modem
work.

Best regards
Andreas

On Sun, Nov 13, 2016 at 9:18 PM, Stefan Hagen 
wrote:

> * Stefan Hagen wrote:
> > * Suspend does now work
> Typo: Suspend does NOT work!
>
> Bye,
> Stefan
> ___
> 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: firewire panic

[Andriy Gapon]

On 11/11/2016 14:25, Andriy Gapon wrote:
> panic: mutex sbp not owned at /usr/src/sys/dev/firewire/sbp.c:967
> cpuid = 2
> curthread: 0xf8000ada5000
> stack: 0xfe0504ded000 - 0xfe0504df1000
> stack pointer: 0xfe0504df0a00
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x80420bbb = 
> db_trace_self_wrapper+0x2b/frame
> 0xfe0504df0930
> kdb_backtrace() at 0x80670359 = kdb_backtrace+0x39/frame 
> 0xfe0504df09e0
> vpanic() at 0x8063986c = vpanic+0x14c/frame 0xfe0504df0a20
> panic() at 0x806395b3 = panic+0x43/frame 0xfe0504df0a80
> __mtx_assert() at 0x8061c40d = __mtx_assert+0xed/frame 
> 0xfe0504df0ac0
> sbp_cam_scan_lun() at 0x80474667 = sbp_cam_scan_lun+0x37/frame
> 0xfe0504df0af0
> xpt_done_process() at 0x802aacfa = xpt_done_process+0x2da/frame
> 0xfe0504df0b30
> xpt_done_td() at 0x802ac2e5 = xpt_done_td+0xd5/frame 
> 0xfe0504df0b80

So, it's pretty obvious that the sbp mutex can not be held when
sbp_cam_scan_lun() is called.
After removing the assertion, just to move further, I do not get any panics and
can access the disk.
But I see many witness warnings.  Some examples:

bus_dma_tag_create with the following non-sleepable locks held:
exclusive sleep mutex sbp (sbp) r = 0 (0xf8000ff04f48) locked @
/usr/src/sys/modules/firewire/sbp/../../../dev/firewire/sbp.c:802
stack backtrace:
#0 0x80ab20a0 at witness_debugger+0x70
#1 0x80ab3387 at witness_warn+0x3d7
#2 0x810174dd at bus_dma_tag_create+0x3d
#3 0x83703402 at fwdma_malloc+0x82
#4 0x836ed759 at sbp_post_explore+0x849
#5 0x836f9e76 at fw_bus_probe_thread+0x906
#6 0x80a164c4 at fork_exit+0x84
#7 0x80ea970e at fork_trampoline+0xe

bus_dmamem_alloc with the following non-sleepable locks held:
exclusive sleep mutex sbp (sbp) r = 0 (0xf8000ff04f48) locked @
/usr/src/sys/modules/firewire/sbp/../../../dev/firewire/sbp.c:802
stack backtrace:
#0 0x80ab20a0 at witness_debugger+0x70
#1 0x80ab3387 at witness_warn+0x3d7
#2 0x810175c3 at bus_dmamem_alloc+0x33
#3 0x83703424 at fwdma_malloc+0xa4
#4 0x836ed759 at sbp_post_explore+0x849
#5 0x836f9e76 at fw_bus_probe_thread+0x906
#6 0x80a164c4 at fork_exit+0x84
#7 0x80ea970e at fork_trampoline+0xe

bus_dmamap_create with the following non-sleepable locks held:
exclusive sleep mutex sbp (sbp) r = 0 (0xf8000ff04f48) locked @
/usr/src/sys/modules/firewire/sbp/../../../dev/firewire/sbp.c:802
stack backtrace:
#0 0x80ab20a0 at witness_debugger+0x70
#1 0x80ab3387 at witness_warn+0x3d7
#2 0x8101755f at bus_dmamap_create+0x2f
#3 0x836ed7d2 at sbp_post_explore+0x8c2
#4 0x836f9e76 at fw_bus_probe_thread+0x906
#5 0x80a164c4 at fork_exit+0x84
#6 0x80ea970e at fork_trampoline+0xe

lock order reversal:
1st 0xf8000ff04f48 sbp (sbp) @ /usr/src/sys/kern/kern_mutex.c:220
2nd 0xfe0001b94870 firewire (firewire) @
/usr/src/sys/modules/firewire/firewire/../../../dev/firewire/firewire.c:302
stack backtrace:
#0 0x80ab20a0 at witness_debugger+0x70
#1 0x80ab1f94 at witness_checkorder+0xe54
#2 0x80a33854 at __mtx_lock_flags+0xa4
#3 0x836f6423 at fw_asyreq+0x2d3
#4 0x80a68f2c at softclock_call_cc+0x19c
#5 0x80a69327 at softclock+0x47
#6 0x80a18d76 at intr_event_execute_handlers+0x96
#7 0x80a193f6 at ithread_loop+0xa6
#8 0x80a164c4 at fork_exit+0x84
#9 0x80ea970e at fork_trampoline+0xe

lock order reversal:
1st 0xf8000ff04f48 sbp (sbp) @ /usr/src/sys/kern/kern_mutex.c:220
2nd 0xf8000a0b4460 CAM device lock (CAM device lock) @
/usr/src/sys/cam/scsi/scsi_xpt.c:2349
stack backtrace:
#0 0x80ab20a0 at witness_debugger+0x70
#1 0x80ab1f94 at witness_checkorder+0xe54
#2 0x80a33854 at __mtx_lock_flags+0xa4
#3 0x8031af12 at scsi_scan_lun+0x122
#4 0x836eef40 at sbp_cam_scan_target+0x100
#5 0x80a68f2c at softclock_call_cc+0x19c
#6 0x80a69327 at softclock+0x47
#7 0x80a18d76 at intr_event_execute_handlers+0x96
#8 0x80a193f6 at ithread_loop+0xa6
#9 0x80a164c4 at fork_exit+0x84
#10 0x80ea970e at fork_trampoline+0xe


-- 
Andriy Gapon
___
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: Lenovo X1 Carbon or T460s

[K. Macy]

On Saturday, November 12, 2016, Mark Heily  wrote:

> On Fri, Nov 11, 2016 at 11:41 PM, Kevin Oberman  > wrote:
>
> >
> > In regard to video, have you installed and are you using vaapi?
> >
>
> vaapi appears to be preinstalled, however when I run "vainfo" it is unable
> to find a driver.
>
> The underlying problem is that Intel Skylake graphics are not fully
> supported under FreeBSD yet; see https://wiki.freebsd.org/Graphics


Actually don't.

Refer to the -X11 and -current archives. I've already discussed this
multiple times. UXA and full offload work fine. The problem is trueos is
using the modesetting driver and Glamor acceleration doesn't fully work yet
without artifacts. This is more an issue of ease of development for the
configuration tool on trueos than fundamental limitation.

The code currently in tree doesn't support anything newer than Haswell.
Support for Broadwell, Skylake, and Kaby Lake is out of tree. However, that
is what trueos is using.

-M


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

Re: Lenovo X1 Carbon or T460s

[Stefan Hagen]

* Stefan Hagen wrote:
> * Suspend does now work
Typo: Suspend does NOT work!

Bye,
Stefan
___
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: Lenovo X1 Carbon or T460s

[Stefan Hagen]

* Jeremie Le Hen wrote:
> Thanks for the feedback on the X1 Carbon. Does anyone have experience with
> the T460s?

I own an x260 on 11.0-RELEASE at the moment, which is pretty much the
same hardware.

* WIFI works pretty well with the iwm driver.
* GPU works in a very basic and unaccelerated way with the intel driver.
  I'm also not able to control the backlight (but I didn't try hard)
  So you may want to follow the "Skylake/HD graphics support" mail thread.
* Audio works
* NVME SSD works
* Suspend does now work

I had the T430 before, which is working very great with FreeBSD. If you
need everything to be supported, go for a bit older version.

pciconf:
hostb0@pci0:0:0:0:  class=0x06 card=0x504a17aa chip=0x19048086 rev=0x08 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Host Bridge/DRAM Registers'
--
vgapci0@pci0:0:2:0: class=0x03 card=0x504a17aa chip=0x19168086 rev=0x07 
hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 520'
--
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x504a17aa chip=0x9d2f8086 rev=0x21 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-LP USB 3.0 xHCI Controller'
--
none0@pci0:0:20:2:  class=0x118000 card=0x504a17aa chip=0x9d318086 rev=0x21 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-LP Thermal subsystem'
--
none1@pci0:0:22:0:  class=0x078000 card=0x504a17aa chip=0x9d3a8086 rev=0x21 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-LP CSME HECI'
--
pcib1@pci0:0:28:0:  class=0x060400 card=0x504a17aa chip=0x9d108086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
class  = bridge
--
pcib2@pci0:0:28:2:  class=0x060400 card=0x504a17aa chip=0x9d128086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
class  = bridge
--
pcib3@pci0:0:28:4:  class=0x060400 card=0x504a17aa chip=0x9d148086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-LP PCI Express Root Port'
--
isab0@pci0:0:31:0:  class=0x060100 card=0x504a17aa chip=0x9d488086 rev=0x21 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-LP LPC Controller'
--
none2@pci0:0:31:2:  class=0x058000 card=0x504a17aa chip=0x9d218086 rev=0x21 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-LP PMC'
--
hdac0@pci0:0:31:3:  class=0x040300 card=0x504a17aa chip=0x9d708086 rev=0x21 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-LP HD Audio'
--
none3@pci0:0:31:4:  class=0x0c0500 card=0x504a17aa chip=0x9d238086 rev=0x21 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-LP SMBus'
--
em0@pci0:0:31:6:class=0x02 card=0x223317aa chip=0x15708086 rev=0x21 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection I219-V'
--
none4@pci0:2:0:0:   class=0xff card=0x504a17aa chip=0x522a10ec rev=0x01 
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTS522A PCI Express Card Reader'
--
iwm0@pci0:4:0:0:class=0x028000 card=0x01308086 chip=0x24f38086 rev=0x3a 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Wireless 8260'
--
nvme0@pci0:5:0:0:   class=0x010802 card=0x00011179 chip=0x010f1179 rev=0x01 
hdr=0x00
vendor = 'Toshiba America Info Systems'
class  = mass storage

Bye,
Stefan
___
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: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447

[Don Lewis]

The machine managed to survive 21 hours of building FreeBSD 12 ports.
All of the panic happened while building FreeBSD 10 ports, which build
faster.  That may be enough to affect timing and affect the likelyhood
of a race condition triggering the panic.

On 13 Nov, Mateusz Guzik wrote:
> On Sat, Nov 12, 2016 at 05:11:57PM -0800, Don Lewis wrote:
>> This !neg_locked code in cache_negative_remove() looks suspicious to me:
>> 
>> if (!neg_locked) {
>> if (ncp->nc_flag & NCF_HOTNEGATIVE) {
>> hot_locked = true;
>> mtx_lock(_hot.nl_lock);
>> if (!(ncp->nc_flag & NCF_HOTNEGATIVE)) {
>> list_locked = true;
>> mtx_lock(>nl_lock);
>> }
>> } else {
>> list_locked = true;
>> mtx_lock(>nl_lock);
>> }
>> 
>> It looks like you handle NCF_HOTNEGATIVE going away while waiting for
>> the ncneg_hot.nl_lock, but don't handle the possible appearance of
>> NCF_HOTNEGATIVE while waiting for neglist->nl_lock.
>> 
> 
> Promotions from regular to hot are only possible on a hit, which is
> prevented by the caller holding both the vnode and bucket lock. The only
> way to see the entry at this stage is from the shrinker, which can
> demote it and then take all the locks to try to remove it. But it checks
> after locking if the node is still there.
> 
>> What protects nc_flag, the lock for the list that it resides on?
>> 
> 
> It is supposed to be the hot list lock and I think this uncovers a bug
> here.
> 
> Consider a NCF_HOTNEGATIVE entry which is being evicted. It sets the
> NCV_DVDROP flag without the lock held, but the entry is still not
> removed from negative lists. So in principle we can either lose the
> newly set flag or the information that hotnegative is unset.
> 
> That said, I think the fix would be to remove from negative entries
> prior to setting the NCV_DVDROP flag.
> 
> Normally the flag is protected by the hotlist lock.
> 
> Untested, but should do the trick:
> 
> --- vfs_cache.c.old   2016-11-13 09:37:50.09600 +0100
> +++ vfs_cache.c.new   2016-11-13 09:39:45.00400 +0100
> @@ -868,6 +868,13 @@
>   nc_get_name(ncp), ncp->nc_neghits);
>   }
>   LIST_REMOVE(ncp, nc_hash);
> + if (!(ncp->nc_flag & NCF_NEGATIVE)) {
> + TAILQ_REMOVE(>nc_vp->v_cache_dst, ncp, nc_dst);
> + if (ncp == ncp->nc_vp->v_cache_dd)
> + ncp->nc_vp->v_cache_dd = NULL;
> + } else {
> + cache_negative_remove(ncp, neg_locked);
> + }
>   if (ncp->nc_flag & NCF_ISDOTDOT) {
>   if (ncp == ncp->nc_dvp->v_cache_dd)
>   ncp->nc_dvp->v_cache_dd = NULL;
> @@ -878,13 +885,6 @@
>   atomic_subtract_rel_long(, 1);
>   }
>   }
> - if (!(ncp->nc_flag & NCF_NEGATIVE)) {
> - TAILQ_REMOVE(>nc_vp->v_cache_dst, ncp, nc_dst);
> - if (ncp == ncp->nc_vp->v_cache_dd)
> - ncp->nc_vp->v_cache_dd = NULL;
> - } else {
> - cache_negative_remove(ncp, neg_locked);
> - }
>   atomic_subtract_rel_long(, 1);
>  }

I will give this a try.

___
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: Lenovo X1 Carbon or T460s

[Jeremie Le Hen]

Thanks for the feedback on the X1 Carbon. Does anyone have experience with
the T460s?

On Nov 11, 2016 12:25, "Jeremie Le Hen"  wrote:

> Hi guys,
>
> I'm about to purchase a new laptop, one of the two mentioned in the
> subject.
>
> I'm looking for reports of hardware support for both of them under
> FreeBSD. What are the goods and bads?
>
> Thanks!
> -- Jeremie
>
___
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: Skylake/HD graphics support

[Hans Petter Selasky]

On 11/13/16 18:43, Daniel Campos do Nascimento wrote:

Hello,

First time posting on a mailing list...

I currently have 11.0-STABLE installed on my laptop which has a Core
i7-6500U. I can't get Xorg-server to work neither with xf86-driver-intel,
nor with i915kms driver; I'm falling back on the scfb driver. I would like
to know how the situation is with 12.0-CURRENT regarding graphics?



Hi,

You will need to build a kernel from drm-next-4.7 branch for now:

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

Then it will work, just make sure xf86-driver-intel is installed. No 
need to kldload anything.


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

Skylake/HD graphics support

[Daniel Campos do Nascimento]

Hello,

First time posting on a mailing list...

I currently have 11.0-STABLE installed on my laptop which has a Core
i7-6500U. I can't get Xorg-server to work neither with xf86-driver-intel,
nor with i915kms driver; I'm falling back on the scfb driver. I would like
to know how the situation is with 12.0-CURRENT regarding graphics?

Regards,

Daniel
___
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: was: CURRENT [r308087] still crashing: Backtrace provided

[O. Hartmann]

Am Sun, 13 Nov 2016 12:41:07 +0300
"Andrey V. Elsukov"  schrieb:

> On 13.11.2016 12:23, O. Hartmann wrote:
> > Great, thank you. I would first like to confirm that r307234 is indeed
> > causing the crash - since it appears to be easy to trigger, that should
> > be faster. If not, the core will help track down the real problem.
> 
>  Although I was under the impression the in-kernel-config option
> 
>  makeoptionsDEBUG=-g
> 
>  would make debugging symbols available, I'm proved wrong.
> >>
> >> Do you have option FLOWTABLE in your kernel config?  
> > 
> > Would you suggest to disable this feature in the kernel? Or does the 
> > feature, by
> > accident, influence the debugging ??  
> 
> Hi,
> 
> I never used FLOWTABLE, but as I know, when L2 caching was reintroduced
> the kernel with enabled FLOWTABLE has started crashing almost
> immediately. glebius@ added workaround in r300854 to prevent the panic.
> Then we discussed with him that the change in in_pcb.c should be
> reasonable. And he decided to revert the workaround. Now it seems
> without r300854 FLOWTABLE isn't usable.
> 

All right. At this very moment I compile a most recent world and kernel WITHOUT 
the
option FLOWTABLE. It takes a lot(!) of time to revert the whole system to the 
working
r307233 again (we figured out, that r307234 triggers the crashes so far).

The interesting thing to me is that the crash occured on all platforms/Intel 
architectures
I use and maintain immediately after r307233 and it lasted for at least r307884
(approx.), that was, when I reverted everything to r307157 (the point from 
which I
started non-crahsing). Now, I have several relatively modern systems (norebooks 
with
Haswell Mobile CPU, XEON Haswell Workstation and Skylake XEON Servers, AMD 
Jaguar based
PCEngines APU 2C4) with FLOWTABLE enabled and with most recent CURRENT - 
without a crash
in days under heavy load (network I/O) and poudriere builds - without issues. 
But
everything I have in my hands with IvyBridge (XEON, consumer grade CPUs) and 
lower (one
Intel Core2Duo 2-socket server) is crashing with CURRENT beyond r307233. Maybe 
I oversee
the different internal cash architectures and probably optimization problem.

Anyway, this just to repeat for the records ;-)

I'll give notice after my boxes have been compiled to most recent CURRENT with
FLOWTABLES.

Thanks and kinf regards,

Oliver 

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpnOQ91kIHfJ.pgp
Description: OpenPGP digital signature

Re: was: CURRENT [r308087] still crashing: Backtrace provided

[Andrey V. Elsukov]

On 13.11.2016 12:23, O. Hartmann wrote:
> Great, thank you. I would first like to confirm that r307234 is indeed
> causing the crash - since it appears to be easy to trigger, that should
> be faster. If not, the core will help track down the real problem.  

 Although I was under the impression the in-kernel-config option

 makeoptionsDEBUG=-g

 would make debugging symbols available, I'm proved wrong.  
>>
>> Do you have option FLOWTABLE in your kernel config?
> 
> Would you suggest to disable this feature in the kernel? Or does the feature, 
> by
> accident, influence the debugging ??

Hi,

I never used FLOWTABLE, but as I know, when L2 caching was reintroduced
the kernel with enabled FLOWTABLE has started crashing almost
immediately. glebius@ added workaround in r300854 to prevent the panic.
Then we discussed with him that the change in in_pcb.c should be
reasonable. And he decided to revert the workaround. Now it seems
without r300854 FLOWTABLE isn't usable.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: was: CURRENT [r308087] still crashing: Backtrace provided

[O. Hartmann]

Am Wed, 9 Nov 2016 17:11:37 +0300
"Andrey V. Elsukov"  schrieb:

> On 08.11.2016 21:28, Mark Johnston wrote:
> > On Sun, Nov 06, 2016 at 11:13:56AM +0100, O. Hartmann wrote:  
> >>> Great, thank you. I would first like to confirm that r307234 is indeed
> >>> causing the crash - since it appears to be easy to trigger, that should
> >>> be faster. If not, the core will help track down the real problem.  
> >>
> >> Although I was under the impression the in-kernel-config option
> >>
> >> makeoptionsDEBUG=-g
> >>
> >> would make debugging symbols available, I'm proved wrong.  
> 
> Do you have option FLOWTABLE in your kernel config?

Would you suggest to disable this feature in the kernel? Or does the feature, by
accident, influence the debugging ??

> 
> >> #9  0x807b44fb in __rw_wlock_hard (c=, 
> >> tid=, file=, 
> >> line=) at /usr/src/sys/kern/kern_rwlock.c:830  
> 
> Just my opinion. Setting RT_LLE_CACHE flag in ip_output is wrong. This
> flag should be set when ro_lle actually filled with cached data.
> 



-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpFAGATiBUut.pgp
Description: OpenPGP digital signature

Re: panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447

[Mateusz Guzik]

On Sat, Nov 12, 2016 at 05:11:57PM -0800, Don Lewis wrote:
> This !neg_locked code in cache_negative_remove() looks suspicious to me:
> 
> if (!neg_locked) {
> if (ncp->nc_flag & NCF_HOTNEGATIVE) {
> hot_locked = true;
> mtx_lock(_hot.nl_lock);
> if (!(ncp->nc_flag & NCF_HOTNEGATIVE)) {
> list_locked = true;
> mtx_lock(>nl_lock);
> }
> } else {
> list_locked = true;
> mtx_lock(>nl_lock);
> }
> 
> It looks like you handle NCF_HOTNEGATIVE going away while waiting for
> the ncneg_hot.nl_lock, but don't handle the possible appearance of
> NCF_HOTNEGATIVE while waiting for neglist->nl_lock.
> 

Promotions from regular to hot are only possible on a hit, which is
prevented by the caller holding both the vnode and bucket lock. The only
way to see the entry at this stage is from the shrinker, which can
demote it and then take all the locks to try to remove it. But it checks
after locking if the node is still there.

> What protects nc_flag, the lock for the list that it resides on?
> 

It is supposed to be the hot list lock and I think this uncovers a bug
here.

Consider a NCF_HOTNEGATIVE entry which is being evicted. It sets the
NCV_DVDROP flag without the lock held, but the entry is still not
removed from negative lists. So in principle we can either lose the
newly set flag or the information that hotnegative is unset.

That said, I think the fix would be to remove from negative entries
prior to setting the NCV_DVDROP flag.

Normally the flag is protected by the hotlist lock.

Untested, but should do the trick:

--- vfs_cache.c.old 2016-11-13 09:37:50.09600 +0100
+++ vfs_cache.c.new 2016-11-13 09:39:45.00400 +0100
@@ -868,6 +868,13 @@
nc_get_name(ncp), ncp->nc_neghits);
}
LIST_REMOVE(ncp, nc_hash);
+   if (!(ncp->nc_flag & NCF_NEGATIVE)) {
+   TAILQ_REMOVE(>nc_vp->v_cache_dst, ncp, nc_dst);
+   if (ncp == ncp->nc_vp->v_cache_dd)
+   ncp->nc_vp->v_cache_dd = NULL;
+   } else {
+   cache_negative_remove(ncp, neg_locked);
+   }
if (ncp->nc_flag & NCF_ISDOTDOT) {
if (ncp == ncp->nc_dvp->v_cache_dd)
ncp->nc_dvp->v_cache_dd = NULL;
@@ -878,13 +885,6 @@
atomic_subtract_rel_long(, 1);
}
}
-   if (!(ncp->nc_flag & NCF_NEGATIVE)) {
-   TAILQ_REMOVE(>nc_vp->v_cache_dst, ncp, nc_dst);
-   if (ncp == ncp->nc_vp->v_cache_dd)
-   ncp->nc_vp->v_cache_dd = NULL;
-   } else {
-   cache_negative_remove(ncp, neg_locked);
-   }
atomic_subtract_rel_long(, 1);
 }
 
-- 
Mateusz Guzik 
___
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"