patch.termcap

Would someone please commit the attached termcap patch for Altos V terminals. Granted I may be the only person still using one but it'll save continual patching. Thanks for your consideration. -- Tim Rice t...@xinuos.com Index: share/termcap/termcap

Re: thread suspension when dumping core

On Tue, Jun 07, 2016 at 07:29:56AM +0300, Konstantin Belousov wrote: > On Mon, Jun 06, 2016 at 09:17:41PM -0700, Mark Johnston wrote: > > Sure, see below. For reference: > > > > td_flags = 0xa84c = INMEM | SINTR | CANSWAP | ASTPENDING | SBDRY | > > NEEDSUSPCHK > > td_pflags = 0 > > td_inhibitors

Re: wlan/ifconfig stopped working sometime between 5/25 and 6/3

Hi, this is a recent change to the regulatory handling. I've emailed Andriy who wrote the code. :) Andriy, any ideas? -adrian On 6 June 2016 at 20:15, Yoshihiro Ota wrote: > Hi, > > I started getting the following error when I tried to bring up wireless > connection

Re: thread suspension when dumping core

On Mon, Jun 06, 2016 at 09:17:41PM -0700, Mark Johnston wrote: > Sure, see below. For reference: > > td_flags = 0xa84c = INMEM | SINTR | CANSWAP | ASTPENDING | SBDRY | NEEDSUSPCHK > td_pflags = 0 > td_inhibitors = 0x2 = SLEEPING > td_locks = 0 > > stack: > mi_switch+0x21e

Re: thread suspension when dumping core

On Tue, Jun 07, 2016 at 05:46:10AM +0300, Konstantin Belousov wrote: > On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote: > > On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote: > What statement was not true: that your code sets TDF_SBDRY, or that > the lf_advlock()

Re: thread suspension when dumping core

On Mon, Jun 6, 2016 at 7:46 PM, Konstantin Belousov wrote: > On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote: >> On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote: >> > Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ?

wlan/ifconfig stopped working sometime between 5/25 and 6/3

Hi, I started getting the following error when I tried to bring up wireless connection since June 3rd. I had last updated kernel and world on May 25th before. "unable to get regulatory domain info: Device not configured" ifconfig starts working again after I reverted the user land backt May

Re: thread suspension when dumping core

On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote: > On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote: > > Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ? > > It doesn't. This code belongs to a general framework for distributed FS > locks;

Virtualbox kernel module on 11-CURRENT

Hello, I tried installing virtualbox from packages, building it from sources, trying the GENERIC kernel but everytime I can't start the kernel module 'vboxdrv', it says: "KLD vboxdrv.ko: depends on kernel - not available or version mismatch. linker_load_file: Unsupported file type" I'm using a

Port lang/gcc build fails on current

I can't build lang/gcc on current, but it works fine on 10.3. I'm running r301482 after a full rebuild and nothing in /etc/make.conf. Any ideas? > c++ -c -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG > -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W

Re: thread suspension when dumping core

On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote: > On Fri, Jun 03, 2016 at 07:23:47PM -0700, Mark Johnston wrote: > > Hi, > > > > I've recently observed a hang in a multi-threaded process that had hit > > an assertion failure and was attempting to dump core. One thread was > >

FreeBSD_HEAD_amd64_gcc - Build #1276 - Fixed

FreeBSD_HEAD_amd64_gcc - Build #1276 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1276/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1276/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1276/console

Re: panic: destroying non-empty racct: 2113536 allocated for resource 4

I've just got the same panic again. This time I didn't do anything unusual, just ran a poudriere build and the systems paniced at the end of it: Unread portion of the kernel message buffer: panic: destroying non-empty racct: 2113536 allocated for resource 4 KDB: stack backtrace: