Re: panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447
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(&ncneg_hot.nl_lock); > if (!(ncp->nc_flag & NCF_HOTNEGATIVE)) { > list_locked = true; > mtx_lock(&neglist->nl_lock); > } > } else { > list_locked = true; > mtx_lock(&neglist->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(&ncp->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(&numcachehv, 1); } } - if (!(ncp->nc_flag & NCF_NEGATIVE)) { - TAILQ_REMOVE(&ncp->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(&numcache, 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"
Re: was: CURRENT [r308087] still crashing: Backtrace provided
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: was: CURRENT [r308087] still crashing: Backtrace provided
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
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
Skylake/HD graphics support
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: Skylake/HD graphics support
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"
Re: Lenovo X1 Carbon or T460s
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: panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447
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(&ncneg_hot.nl_lock); >> if (!(ncp->nc_flag & NCF_HOTNEGATIVE)) { >> list_locked = true; >> mtx_lock(&neglist->nl_lock); >> } >> } else { >> list_locked = true; >> mtx_lock(&neglist->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(&ncp->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(&numcachehv, 1); > } > } > - if (!(ncp->nc_flag & NCF_NEGATIVE)) { > - TAILQ_REMOVE(&ncp->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(&numcache, 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 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: Lenovo X1 Carbon or T460s
* 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
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: firewire panic
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
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: was: CURRENT [r308087] still crashing: Backtrace provided
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
FreeBSD Quarterly Status Report - Third Quarter 2016
-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 now CentOS 6, with the Fedora 10 ports scheduled for removal at the