xsltproc outputting nothing

2017-06-09 Thread blubee blubeeme 
I tried sending this email to the gnome mailing list but no responses. Can
possibly get some help with this here:

===
Hi

I am trying to convert a .xsl file to a hpp file but the output is only a
blank file.

Here's the commands that I am running:

xsltproc --verbose --stringparam format hpp ./lib/tag.xsl > TAGS.hpp
creating dictionary for stylesheet
reusing dictionary from ./lib/tag.xsl for stylesheet
xsltParseStylesheetProcess : found stylesheet
xsltPrecomputeStylesheet: removing ignorable blank node
xsltParseTemplateContent: removing text
xsltCompilePattern : parsing 'tags'
xsltCompilePattern : parsed tags, default priority 0.00
added pattern : 'tags' priority 0.00
parsed 1 templates
Resolving attribute sets references
freeing dictionary from stylesheet


here's the tags.xsl file:




http://www.w3.org/1999/XSL/Transform";>
  

  



  
//  Automatically generated from lib/tag.xml using lib/tag.xsl.

#ifndef utsushi_tag_hpp_
#define utsushi_tag_hpp_

#include 

#include 

#include "key.hpp"
#include "string.hpp"

namespace utsushi {

struct tag
{
  //! Collect options and groups by the aspects they affect
  /*! A %tag::symbol is a string-like key that can be used to indicate
   *  which aspects are affected by an option or group.  An option may
   *  specify zero or more %tag symbols.
   *
   *  Similar to a descriptor, every %tag::symbol provides name() and
   *  text() accessors describing its purpose.  A user interface may
   *  use this information to provide a more human-oriented and mostly
   *  self-documenting view of tags.
   *
   *  \note  The UI is responsible for the translation of name() and
   * text() as well as any formatting of the text().
   *
   *  \sa  descriptor::name(), descriptor::text()
   */
  class symbol
: boost::totally_ordered< symbol >
  {
  public:
symbol (const key& key,
const string& name, const string& text);

//! \copybrief descriptor::name
const string& name () const;
//! \copybrief descriptor::text
const string& text () const;

bool operator== (const symbol& ts) const;
bool operator< (const symbol& ts) const;

operator key () const;

  private:
key key_;
string name_;
string text_;
  };

  static const symbol none;
  static const symbol ;
};

class tags
{
private:
  typedef std::set< tag::symbol > container_type;
  static container_type set_;
  static void initialize ();

public:
  typedef container_type::size_type size_type;
  typedef container_type::const_iterator const_iterator;

  static size_type count ();
  static const_iterator begin ();
  static const_iterator end ();
};

}   // namespace utsushi

#endif  /* utsushi_tag_hpp_ */

  

  
//  Automatically generated from tag.xml using tag.xsl.

#ifdef HAVE_CONFIG_H
#include 
#endif

#include "utsushi/i18n.hpp"
#include "utsushi/tag.hpp"

namespace utsushi {

tag::symbol::symbol (const key& key,
 const string& name, const string& text)
  : key_(key), name_(name), text_(text)
{}

const string&
tag::symbol::name () const
{
  return name_;
}

const string&
tag::symbol::text () const
{
  return text_;
}

bool
tag::symbol::operator== (const symbol& ts) const
{
  return key_ == ts.key_;
}

bool
tag::symbol::operator< (const tag::symbol& ts) const
{
  return key_ < ts.key_;
}

tag::symbol::operator key () const
{
  return key_;
}


const tag::symbol tag:: (
  "_",
  SEC_N_(""),
  CCB_N_("")
);

tags::container_type tags::set_;

void
tags::initialize ()
{
  container_type::iterator hint = set_.begin ();

  hint = set_.insert (hint, tag::);
}

tags::size_type
tags::count ()
{
  if (set_.empty ())
{
  initialize ();
}
  return set_.size ();
}

tags::const_iterator
tags::begin ()
{
  if (set_.empty ())
{
  initialize ();
}
  return set_.begin ();
}

tags::const_iterator
tags::end ()
{
  if (set_.empty ())
{
  initialize ();
}
  return set_.end ();
}

}   // namespace utsushi

  



  



Best,
Owen
___
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 @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

2017-06-09 Thread David Wolfskill 
Build machine updated from r319689 to r319733 OK; smoke test was
uneventful.

Laptop updated similarly, but smoke test was a little more "interesting".

Turns out that laptop gets to multi-user mode OK... if I disable
starting xdm, devd, and hald.  But then, issuing "service hald onestart"
generates the panic in question -- at r319733.  At r319689, xdm &
friends worked fine.

I have placed copies of the /var/crash/*.6 files in
 -- along with
gzipped copies, as well.  (It's residential DSL in the US, so there's
not a huge amount of bandwidth.)

I get the impression that something (ini hald) was trying to use
the freebsd11 version of stat(), and Something Bad happened:

panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305
cpuid = 7
time = 1497011454
KDB: stack backtrace:
db_trace_self_wrapper() at 0x803a461b = 
db_trace_self_wrapper+0x2b/frame 0xfe0c268ff600
vpanic() at 0x80a1f94c = vpanic+0x19c/frame 0xfe0c268ff680
kassert_panic() at 0x80a1f7a6 = kassert_panic+0x126/frame 
0xfe0c268ff6f0
__mtx_lock_flags() at 0x809fedfe = __mtx_lock_flags+0x14e/frame 
0xfe0c268ff740
soo_stat() at 0x80a8f8f0 = soo_stat+0x60/frame 0xfe0c268ff770
kern_fstat() at 0x809cb378 = kern_fstat+0xa8/frame 0xfe0c268ff7c0
freebsd11_fstat() at 0x809cb28d = freebsd11_fstat+0x1d/frame 
0xfe0c268ff930
amd64_syscall() at 0x80e31fb4 = amd64_syscall+0x5a4/frame 
0xfe0c268ffab0
Xfast_syscall() at 0x80e12eab = Xfast_syscall+0xfb/frame 
0xfe0c268ffab0
--- syscall (189, FreeBSD ELF64, freebsd11_fstat), rip = 0x801b4973a, rsp = 
0x7fffe988, rbp = 0x7fffea20 ---
KDB: enter: panic


Note: the hald in question was built under FreeBSD stable/11 (as
are all my ports); I noted the existence of, and installed,
ports/misc/compat11s before (re-)creating the crash.  (And yes, the
ports that have kernel modules get the kernel modules rebuilt on
head every time I rebuild the kernel on head.)

With the caveat that I actually use the laptop in my day-to-day
activities, I'm happy to try various combinations of patching,
testing, and reporting results.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Looking forward to telling Mr. Trump: "You're fired!"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: CFT: EVDEV support in psm(4) driver

2017-06-09 Thread Jonathan Anderson 

Hi Vladimir,

On 04/16/17 15:18, Vladimir Kondratyev wrote:
Following patch [1] bring in multitouch EVDEV support for Synaptics 
and Elan PS/2
touchpads found in many laptops. (And for generic relative PS/2 mices 
as well).
This allows to replace our limited in-kernel gesture processor with 
full-blown

one from xf86-input-synaptics or xf86-input-libinput driver and makes
Synaptics and Elan PS/2 touchpad support to be mostly on par with Linux


Thanks very much... I've been using your patch for awhile with my 
Synaptics touchpad and it's lovely to have two-finger scrolling that 
works properly! I did need to massage the patch to make it apply on 
drm-next:

https://github.com/trombonehero/freebsd/commit/3d74a33a1bc709d289216cb946744afecb70f6b5

Sometimes I experience dropped touchpad events, particularly when the 
system is busy and my wi-fi is being reconfigured. Is there anything I 
can do to help debug this?



Jon

--
jonat...@freebsd.org

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

Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

2017-06-09 Thread Konstantin Belousov 
On Fri, Jun 09, 2017 at 05:57:15AM -0700, David Wolfskill wrote:
> Build machine updated from r319689 to r319733 OK; smoke test was
> uneventful.
> 
> Laptop updated similarly, but smoke test was a little more "interesting".
> 
> Turns out that laptop gets to multi-user mode OK... if I disable
> starting xdm, devd, and hald.  But then, issuing "service hald onestart"
> generates the panic in question -- at r319733.  At r319689, xdm &
> friends worked fine.
> 
> I have placed copies of the /var/crash/*.6 files in
>  -- along with
> gzipped copies, as well.  (It's residential DSL in the US, so there's
> not a huge amount of bandwidth.)
> 
> I get the impression that something (ini hald) was trying to use
> the freebsd11 version of stat(), and Something Bad happened:
> 
> panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305
> cpuid = 7
> time = 1497011454
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x803a461b = 
> db_trace_self_wrapper+0x2b/frame 0xfe0c268ff600
> vpanic() at 0x80a1f94c = vpanic+0x19c/frame 0xfe0c268ff680
> kassert_panic() at 0x80a1f7a6 = kassert_panic+0x126/frame 
> 0xfe0c268ff6f0
> __mtx_lock_flags() at 0x809fedfe = __mtx_lock_flags+0x14e/frame 
> 0xfe0c268ff740
> soo_stat() at 0x80a8f8f0 = soo_stat+0x60/frame 0xfe0c268ff770
The main suspect is r319722.
Try reverting it or downgrading before it (the later might be simple due
to the patch size).

> kern_fstat() at 0x809cb378 = kern_fstat+0xa8/frame 0xfe0c268ff7c0
> freebsd11_fstat() at 0x809cb28d = freebsd11_fstat+0x1d/frame 
> 0xfe0c268ff930
> amd64_syscall() at 0x80e31fb4 = amd64_syscall+0x5a4/frame 
> 0xfe0c268ffab0
> Xfast_syscall() at 0x80e12eab = Xfast_syscall+0xfb/frame 
> 0xfe0c268ffab0
> --- syscall (189, FreeBSD ELF64, freebsd11_fstat), rip = 0x801b4973a, rsp = 
> 0x7fffe988, rbp = 0x7fffea20 ---
> KDB: enter: panic
> 
> 
> Note: the hald in question was built under FreeBSD stable/11 (as
> are all my ports); I noted the existence of, and installed,
> ports/misc/compat11s before (re-)creating the crash.  (And yes, the
> ports that have kernel modules get the kernel modules rebuilt on
> head every time I rebuild the kernel on head.)
> 
> With the caveat that I actually use the laptop in my day-to-day
> activities, I'm happy to try various combinations of patching,
> testing, and reporting results.
> 
> Peace,
> david
> -- 
> David H. Wolfskillda...@catwhisker.org
> Looking forward to telling Mr. Trump: "You're fired!"
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.


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

Re: nvidia drivers mutex lock

2017-06-09 Thread Tomoaki AOKI 
If you want to try internal GPU...

GPU on Skylake-generation processors is not yet supported on -head.
If you want to test without nvidia GPU, you need to try drm-next branch
with x11-drivers/xf86-video-intel (for the branch?).

 https://lists.freebsd.org/pipermail/freebsd-current/2016-December/063980.html

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

 
https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM#Testing_Instructions_.2F_How_To

Don't forget to remove (or comment out) nvidia-driver related things
from loader.conf and xorg.conf if you try Intel internal GPU.
x11/nvidia-driver doesn't support hybrid (Optimus) graphics (even on
Linux version).

As I'm running with nvidia-driver, I've not tested the branch at all.
So possibly some info could be racked to make it fully functional.


On Tue, 6 Jun 2017 22:08:24 +0800
blubee blubeeme  wrote:

> This is getting out of hand. I can't even keep x going for ten minutes
> sometimes.
> I've tested all the suggestions in this thread and they just don't work.
> 
> I have put out a print of sysctl hw. here : https://paste2.org/

It was the top page. No info available.

> 
> With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
> The bios on this laptop I can either set graphics to discrete or mshybrid.
> 
> I've tried in the past to disable discrete and run mshybrid but that always
> comes up with 0 screens found. Even just doing Xorg -configure.
> 
> Anyone have some tips on disabling nvidia drivers, running this cpu with
> igpu for a while?
> 
> Best,
> Owen
> 
> On Sun, Jun 4, 2017, 18:11 blubee blubeeme  wrote:
> 
> > Thanks a lot! I'll give it a shot in a bit.
> >
> > Best,
> > Owen
> >
> > On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI  wrote:
> >
> >> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual.
> >>
> >> But beware! Sometimes upstream changes make any of FreeBSD patches not
> >> applicable (incorporating any of these, incompatible modifies, ...).
> >>
> >> For 381.22, current patchset applies and builds fine for me.
> >>
> >>
> >> On Sun, 04 Jun 2017 08:04:50 +
> >> blubee blubeeme  wrote:
> >>
> >> > I'm running with svn and I build by make.
> >> > If in use these steps, the BSD related patches will be applied, etc?
> >> >
> >> > Best,
> >> > Owen
> >> >
> >> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI 
> >> wrote:
> >> >
> >> > > Hi.
> >> > >
> >> > > Not in ports tree, but easily overridden by adding
> >> > >
> >> > >   DISTVERSION=381.22 -DNO_CHECKSUM
> >> > >
> >> > > on make command line. Makefile of x11/nvidia-driver has a mechanism
> >> > > to do so for someone requires newer version (newer GPU support, etc.).
> >> > >
> >> > > If you're using portupgrade,
> >> > >
> >> > >   portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f
> >> x11/nvidia-driver
> >> > >
> >> > > would do the same.
> >> > >
> >> > > If you installed it via pkg, there's no way to try. :-(
> >> > > (As it's pre-built.)
> >> > >
> >> > >
> >> > > On Sun, 04 Jun 2017 07:04:01 +
> >> > > blubee blubeeme  wrote:
> >> > >
> >> > > > Hi @tomoaki
> >> > > > Is that version of nvidia drivers currently in the ports tree? I
> >> just
> >> > > > checked but it seems not to be.
> >> > > >
> >> > > > @jeffrey
> >> > > > I just generated a new xorg based on the force composition setting.
> >> I
> >> > > > merged it with my previous xorg I'll reboot, see if it gives better
> >> > > > performance.
> >> > > >
> >> > > > It seems like my system is locking up more frequently now. Sometimes
> >> > > right
> >> > > > after a reboot the system, the screen locks and it's reboot and
> >> pray.
> >> > > >
> >> > > > Best,
> >> > > > Owen
> >> > > >
> >> > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet <
> >> jeffreybouq...@yahoo.com>
> >> > > wrote:
> >> > > >
> >> > > > > SOME LINES BOTTOM POSTED, SEE...
> >> > > > > 
> >> > > > > On Fri, 6/2/17, Tomoaki AOKI  wrote:
> >> > > > >
> >> > > > >  Subject: Re: nvidia drivers mutex lock
> >> > > > >  To: freebsd-current@freebsd.org
> >> > > > >  Cc: "Jeffrey Bouquet" , "blubee
> >> blubeeme" <
> >> > > > > gurenc...@gmail.com>
> >> > > > >  Date: Friday, June 2, 2017, 11:25 PM
> >> > > > >
> >> > > > >  Hi.
> >> > > > >  Version
> >> > > > >  381.22 (5 days newer than 375.66) of the driver states...
> >> > > > >  [1]
> >> > > > >
> >> > > > >   Fixed hangs and
> >> > > > >  crashes that could occur when an OpenGL context is
> >> > > > >   created while the system is out of available
> >> > > > >  memory.
> >> > > > >
> >> > > > >  Can this be related
> >> > > > >  with your hang?
> >> > > > >
> >> > > > >  IMHO,
> >> > > > >  possibly allocating new resource (using os.lock_mtx
> >> > > > >  guard)
> >> > > > >  without checking the lock first while
> >> > > > >  previous request is waiting for
> >> > > > >  another can
> >> > > > >  cause the duplicated lock situation. And high memory
> >> > > > >  pressure would easily cause the situation.
> >> > > > >
> >> > > > >   [1]

Re: nvidia drivers mutex lock

2017-06-09 Thread Tomoaki AOKI 
Hmm, now I now strongly suspect hardware or noise issue, as nvidia GPU
seems to fall / re-appear on bus for some times.

If it WAS a desktop one and GPU is attached via PCIe connector,
I'll immediately power off and re-connect the card, with some
physical dust cleaning, but this time the GPU is onboard...

 *Not shure, but possibly, too short timeout on driver initialization
  code can show problems like this (too short to initialize).


On Thu, 8 Jun 2017 02:27:51 +0800
blubee blubeeme  wrote:

> I was just looking through dmesg and noticed these:
> 
> Jun  6 21:40:52 blubee kernel: nvidia-modeset: Allocated GPU:0
> (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0
> Jun  6 21:41:05 blubee kernel: NVRM: GPU at PCI::01:00:
> GPU-54a7b304-c99d-efee-0117-0ce119063cd6
> Jun  6 21:41:05 blubee kernel: NVRM: GPU Board Serial Number:
> Jun  6 21:41:05 blubee kernel: NVRM: Xid (PCI::01:00): 79, GPU has
> fallen off the bus.
> Jun  6 21:41:05 blubee kernel:
> Jun  6 21:41:05 blubee kernel: NVRM: GPU at :01:00.0 has fallen off the
> bus.
> Jun  6 21:41:05 blubee kernel: NVRM: GPU is on Board .
> Jun  6 21:41:05 blubee kernel: NVRM: A GPU crash dump has been created. If
> possible, please run
> Jun  6 21:41:05 blubee kernel: NVRM: nvidia-bug-report.sh as root to
> collect this data before
> Jun  6 21:41:05 blubee kernel: NVRM: the NVIDIA kernel module is unloaded.
> Jun  6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to
> query display engine channel state: 0x927c:0:0:0x000f
> Jun  6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to
> query display engine channel state: 0x927c:0:0:0x000f
> Jun  6 21:41:05 blubee kernel: vgapci0: child nvidia0 requested
> pci_enable_io
> Jun  6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to
> query display engine channel state: 0x927c:0:0:0x000f
> Jun  6 21:41:06 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to
> query display engine channel state: 0x927c:0:0:0x000f
> Jun  6 21:41:22 blubee kernel: .
> 
> then that lead me to this nvidia forum thread:
> https://devtalk.nvidia.com/default/topic/985037/gtx-1070-quot-gpu-has-fallen-off-the-bus-quot-running-3d-games-in-arch-linux-/
> 
> maybe it could help somehow?
> 
> Best,
> Owen
> 
> On Tue, Jun 6, 2017 at 10:08 PM, blubee blubeeme 
> wrote:
> 
> > This is getting out of hand. I can't even keep x going for ten minutes
> > sometimes.
> > I've tested all the suggestions in this thread and they just don't work.
> >
> > I have put out a print of sysctl hw. here : https://paste2.org/
> >
> > With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
> > The bios on this laptop I can either set graphics to discrete or mshybrid.
> >
> > I've tried in the past to disable discrete and run mshybrid but that
> > always comes up with 0 screens found. Even just doing Xorg -configure.
> >
> > Anyone have some tips on disabling nvidia drivers, running this cpu with
> > igpu for a while?
> >
> > Best,
> > Owen
> >
> > On Sun, Jun 4, 2017, 18:11 blubee blubeeme  wrote:
> >
> >> Thanks a lot! I'll give it a shot in a bit.
> >>
> >> Best,
> >> Owen
> >>
> >> On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI 
> >> wrote:
> >>
> >>> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual.
> >>>
> >>> But beware! Sometimes upstream changes make any of FreeBSD patches not
> >>> applicable (incorporating any of these, incompatible modifies, ...).
> >>>
> >>> For 381.22, current patchset applies and builds fine for me.
> >>>
> >>>
> >>> On Sun, 04 Jun 2017 08:04:50 +
> >>> blubee blubeeme  wrote:
> >>>
> >>> > I'm running with svn and I build by make.
> >>> > If in use these steps, the BSD related patches will be applied, etc?
> >>> >
> >>> > Best,
> >>> > Owen
> >>> >
> >>> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI 
> >>> wrote:
> >>> >
> >>> > > Hi.
> >>> > >
> >>> > > Not in ports tree, but easily overridden by adding
> >>> > >
> >>> > >   DISTVERSION=381.22 -DNO_CHECKSUM
> >>> > >
> >>> > > on make command line. Makefile of x11/nvidia-driver has a mechanism
> >>> > > to do so for someone requires newer version (newer GPU support,
> >>> etc.).
> >>> > >
> >>> > > If you're using portupgrade,
> >>> > >
> >>> > >   portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f
> >>> x11/nvidia-driver
> >>> > >
> >>> > > would do the same.
> >>> > >
> >>> > > If you installed it via pkg, there's no way to try. :-(
> >>> > > (As it's pre-built.)
> >>> > >
> >>> > >
> >>> > > On Sun, 04 Jun 2017 07:04:01 +
> >>> > > blubee blubeeme  wrote:
> >>> > >
> >>> > > > Hi @tomoaki
> >>> > > > Is that version of nvidia drivers currently in the ports tree? I
> >>> just
> >>> > > > checked but it seems not to be.
> >>> > > >
> >>> > > > @jeffrey
> >>> > > > I just generated a new xorg based on the force composition
> >>> setting. I
> >>> > > > merged it with my previous xorg I'll reboot, see if it gives better
> >>> > > > performance.
> >>> > > >
> >>> >

Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

2017-06-09 Thread David Wolfskill 
On Fri, Jun 09, 2017 at 04:55:17PM +0300, Konstantin Belousov wrote:
> On Fri, Jun 09, 2017 at 05:57:15AM -0700, David Wolfskill wrote:
> > Build machine updated from r319689 to r319733 OK; smoke test was
> > uneventful.
> > 
> > Laptop updated similarly, but smoke test was a little more "interesting".
> > 
> > Turns out that laptop gets to multi-user mode OK... if I disable
> > starting xdm, devd, and hald.  But then, issuing "service hald onestart"
> > generates the panic in question -- at r319733.  At r319689, xdm &
> > friends worked fine.
> > 
> > I have placed copies of the /var/crash/*.6 files in
> >  -- along with
> > gzipped copies, as well.  (It's residential DSL in the US, so there's
> > not a huge amount of bandwidth.)
> > 
> > I get the impression that something (ini hald) was trying to use
> > the freebsd11 version of stat(), and Something Bad happened:
> > 
> > panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305
> > cpuid = 7
> > time = 1497011454
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at 0x803a461b = 
> > db_trace_self_wrapper+0x2b/frame 0xfe0c268ff600
> > vpanic() at 0x80a1f94c = vpanic+0x19c/frame 0xfe0c268ff680
> > kassert_panic() at 0x80a1f7a6 = kassert_panic+0x126/frame 
> > 0xfe0c268ff6f0
> > __mtx_lock_flags() at 0x809fedfe = __mtx_lock_flags+0x14e/frame 
> > 0xfe0c268ff740
> > soo_stat() at 0x80a8f8f0 = soo_stat+0x60/frame 0xfe0c268ff770
>
> The main suspect is r319722.
> Try reverting it or downgrading before it (the later might be simple due
> to the patch size).
> 

It was easy enough for me to use "svn diff -c r319722" &
"svn patch --reverse-diff" to effectively revert r319722.

I re-ran the build after that, and a subsequent reboot allowed me to
"sudo service hald onestart" (which whined a bit about dbus not being
enabled but started it anyway), after which I was able to start xdm --
so that seems to have been successful.

Perhaps I'll chat with Gleb a bit later today. :-)  (Our cubes are
adjacent.)

Thanks, Konstantin! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Looking forward to telling Mr. Trump: "You're fired!"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

destroying non-empty racct

2017-06-09 Thread Larry Rosenman 
I know we had this a while back, and it was fixed, but it's back.


Dump header from device: /dev/mfid0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 105984
  Blocksize: 512
  Dumptime: Fri Jun  9 13:25:25 2017
  Hostname: borg.lerctr.org
  Magic: FreeBSD Text Dump
  Version String: FreeBSD 12.0-CURRENT #29 r319458: Thu Jun  1 16:15:44 CDT 2017
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER
  Panic String: destroying non-empty racct: 4124672 allocated for resource 4

  Dump Parity: 1629450792
  Bounds: 3
  Dump Status: good

I do NOT have a core due to insufficient swap (I do have a text dump).

Ideas?


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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 @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

2017-06-09 Thread David Wolfskill 
On Fri, Jun 09, 2017 at 08:23:55AM -0700, David Wolfskill wrote:
> ...
> > The main suspect is r319722.
> > Try reverting it or downgrading before it (the later might be simple due
> > to the patch size).
> > 
> 
> It was easy enough for me to use "svn diff -c r319722" &
> "svn patch --reverse-diff" to effectively revert r319722.
> 
> I re-ran the build after that, and a subsequent reboot allowed me to
> "sudo service hald onestart" (which whined a bit about dbus not being
> enabled but started it anyway), after which I was able to start xdm --
> so that seems to have been successful.
> 
> Perhaps I'll chat with Gleb a bit later today. :-)  (Our cubes are
> adjacent.)
> ...

Gleb committed r319754; I finally(!) had a chance to revert the
reversion of r319722, then apply r319754 and rebuild; the follow-up
smoke test was successful.

> Thanks, Konstantin! :-)
> ...

And Gleb! :-)

[Apparently hald invokes stat(2) on a listening socket, which was ...
unexpected.]

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Looking forward to telling Mr. Trump: "You're fired!"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

2017-06-09 Thread Ngie Cooper 
On Fri, Jun 9, 2017 at 3:55 PM, David Wolfskill  wrote:

...

> Gleb committed r319754; I finally(!) had a chance to revert the
> reversion of r319722, then apply r319754 and rebuild; the follow-up
> smoke test was successful.

...

> [Apparently hald invokes stat(2) on a listening socket, which was ...
> unexpected.]

This might have been caught by lib/libc/sys/stat_test:stat_socket . If
only the compat stuff was working on ci.freebsd.org as well, or the
test(s) had been run...
-Ngie
___
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"