Re: Instant panic while trying run ports-mgmt/poudriere

2015-09-01 Thread John-Mark Gurney
Konstantin Belousov wrote this message on Tue, Sep 01, 2015 at 21:44 +0300:
> On Tue, Sep 01, 2015 at 11:24:06AM -0700, John-Mark Gurney wrote:
> > Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 23:21 +0300:
> > > On 27/08/2015 21:09, John-Mark Gurney wrote:
> > > > Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
> > > >> On 27/08/2015 02:36, John-Mark Gurney wrote:
> > > >>> We should/cannot get here w/ an empty list.  If we do, then there is
> > > >>> something seriously wrong...  The current kn (which we must have as we
> > > >>> are here) MUST be on the list, but as you just showed, there are no
> > > >>> knotes on the list.
> > > >>>
> > > >>> Can you get me a print of the knote?  That way I can see what flags
> > > >>> are on it?
> > > >>
> > > >> Apologies if the following might sound a little bit patronizing, but it
> > > >> seems that you have got all the facts correctly, but somehow the
> > > >> connection between them did not become clear.
> > > >>
> > > >> So:
> > > >> 1. The list originally is NOT empty.  I guess that it has one entry, 
> > > >> but
> > > >> that's an unimportant detail.
> > > >> 2. This is why the loop is entered. It's a fact that it is entered.
> > > >> 3. The list becomes empty precisely because the entry is removed during
> > > >> the iteration in the loop (as kib has explained).  It's a fact that the
> > > >> list became empty at least in the panic that I reported.
> > > > 
> > > > On you're latest dump, you said:
> > > > Here is another +1 with r286922.
> > > > 
> > > > I can add a couple of bits of debugging data:   
> > > > 
> > > > 
> > > > 
> > > > (kgdb) fr 8 
> > > > 
> > > > #8  0x80639d60 in knote (list=0xf8019a733ea0,   
> > > > 
> > > > hint=2147483648, lockflags=) at
> > > > 
> > > > /usr/src/sys/kern/kern_event.c:1964 
> > > > 
> > > > 1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {   
> > > > 
> > > > 
> > > > First off, that can't be r286922, per:
> > > > https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
> > > > 
> > > > line 1964 is blank...  The line of code above should be at line 1884,
> > > > so not sure what is wrong here...
> > > 
> > > No, it can not be indeed, because I am running head.
> > > r286922 was the latest version of the repository, not the head branch,
> > > at the moment when I pulled the repository via git.
> > > 
> > > > Assuming that the pc really is at the line, f_event has not yet been
> > > > called,
> > > 
> > > Even on the second loop iteration?
> > > 
> > > >which is why I said that the list cannot be empty yet, as
> > > > f_event hasn't been called yet to remove the knote...  It could be that
> > > > optimization moved stuff around, but if that is the case, then the
> > > > above wasn't useful..
> > > 
> > > I provided the disassembly of the code as well, it's very obvious how
> > > the code was translated.
> > > 
> > > >> 4. The element is not only unlinked from the list, but its memory is
> > > >> also freed.
> > > > 
> > > > Where is the memory freed?  A knote MUST NOT be freed in an f_event
> > > > handler.  The only location that a list element is allowed to be
> > > > freed is in knote_drop, which must happen after f_detach is called,
> > > > but that can't/won't happen from knote (I believe the timer handles
> > > > this specially, but we are talking about normal knlist type filters)..
> > > 
> > > Well, right.  knote()->filt_proc()->knlist_remove_inevent() just removes
> > > the knote from the list.  But then there is KNOTE_ACTIVATE() that passes
> > > the knote to a different owner (so to say). And given that the knote has
> > > EV_ONESHOT set on it (in filt_proc) and that poudriere can put quite a
> > > stress load on a system, I am not surprised that another thread gets a
> > > chance to call knote_drop() on the knote before the original thread
> > > proceeds to the next iteration.
> > 
> > Ok, I think I have identified the race that you guys were trying to
> > tell me about, and though the _SAFE macro would be a similar fix, I'm
> > going to rewrite the loop so that this is more explicit on what
> > is happening here...
> > 
> > So, the race is this...  In knote, when the note is removed by
> > f_event, things are find until the KQ lock is dropped...  Once this
> > lock is dropped, effective ownership of the knote is transfered
> > from the knlist to the kq lock as the _DETACHED flag is now set,
> > which means that reading any fields from that note is undefined..
> > 
> > Once the kq lock is released in knote, then it is possible for a
> > functional like kqueue_scan to endup knote_drop'ing the 

Re: Instant panic while trying run ports-mgmt/poudriere

2015-09-01 Thread Ed Maste
On 1 September 2015 at 15:01, John-Mark Gurney  wrote:
>
> But I would ask you to respect my maintainership of the code... Just
> because you get paid to work on FreeBSD full time does not mean you
> get to run roughshod over other people's work and force them to work
> on your time frame...  Other people have jobs, and families and
> responsiblities too...

A quick comment on this point, on behalf of the FreeBSD Foundation
(and not core): working for the Foundation as either permanent staff
or on a project grant conveys no special status with respect to making
changes in FreeBSD. Staff and project developers are expected to abide
by the same rules and social conventions when interacting with the
FreeBSD community.

That said, the discussion and diagnosis of this issue has been ongoing
for about ten days, and avg provided a detailed sequence of events
five days ago. In this case the patch fixed a panic that several
people were experiencing, was tested by several people who experienced
the panic, and received review. In my opinion r287366 was handled in a
fair and reasonable fashion.
___
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: Instant panic while trying run ports-mgmt/poudriere

2015-09-01 Thread John-Mark Gurney
Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 23:21 +0300:
> On 27/08/2015 21:09, John-Mark Gurney wrote:
> > Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
> >> On 27/08/2015 02:36, John-Mark Gurney wrote:
> >>> We should/cannot get here w/ an empty list.  If we do, then there is
> >>> something seriously wrong...  The current kn (which we must have as we
> >>> are here) MUST be on the list, but as you just showed, there are no
> >>> knotes on the list.
> >>>
> >>> Can you get me a print of the knote?  That way I can see what flags
> >>> are on it?
> >>
> >> Apologies if the following might sound a little bit patronizing, but it
> >> seems that you have got all the facts correctly, but somehow the
> >> connection between them did not become clear.
> >>
> >> So:
> >> 1. The list originally is NOT empty.  I guess that it has one entry, but
> >> that's an unimportant detail.
> >> 2. This is why the loop is entered. It's a fact that it is entered.
> >> 3. The list becomes empty precisely because the entry is removed during
> >> the iteration in the loop (as kib has explained).  It's a fact that the
> >> list became empty at least in the panic that I reported.
> > 
> > On you're latest dump, you said:
> > Here is another +1 with r286922.
> > 
> > I can add a couple of bits of debugging data:   
> > 
> > 
> > 
> > (kgdb) fr 8 
> > 
> > #8  0x80639d60 in knote (list=0xf8019a733ea0,   
> > 
> > hint=2147483648, lockflags=) at
> > 
> > /usr/src/sys/kern/kern_event.c:1964 
> > 
> > 1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {   
> > 
> > 
> > First off, that can't be r286922, per:
> > https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
> > 
> > line 1964 is blank...  The line of code above should be at line 1884,
> > so not sure what is wrong here...
> 
> No, it can not be indeed, because I am running head.
> r286922 was the latest version of the repository, not the head branch,
> at the moment when I pulled the repository via git.
> 
> > Assuming that the pc really is at the line, f_event has not yet been
> > called,
> 
> Even on the second loop iteration?
> 
> >which is why I said that the list cannot be empty yet, as
> > f_event hasn't been called yet to remove the knote...  It could be that
> > optimization moved stuff around, but if that is the case, then the
> > above wasn't useful..
> 
> I provided the disassembly of the code as well, it's very obvious how
> the code was translated.
> 
> >> 4. The element is not only unlinked from the list, but its memory is
> >> also freed.
> > 
> > Where is the memory freed?  A knote MUST NOT be freed in an f_event
> > handler.  The only location that a list element is allowed to be
> > freed is in knote_drop, which must happen after f_detach is called,
> > but that can't/won't happen from knote (I believe the timer handles
> > this specially, but we are talking about normal knlist type filters)..
> 
> Well, right.  knote()->filt_proc()->knlist_remove_inevent() just removes
> the knote from the list.  But then there is KNOTE_ACTIVATE() that passes
> the knote to a different owner (so to say). And given that the knote has
> EV_ONESHOT set on it (in filt_proc) and that poudriere can put quite a
> stress load on a system, I am not surprised that another thread gets a
> chance to call knote_drop() on the knote before the original thread
> proceeds to the next iteration.

Ok, I think I have identified the race that you guys were trying to
tell me about, and though the _SAFE macro would be a similar fix, I'm
going to rewrite the loop so that this is more explicit on what
is happening here...

So, the race is this...  In knote, when the note is removed by
f_event, things are find until the KQ lock is dropped...  Once this
lock is dropped, effective ownership of the knote is transfered
from the knlist to the kq lock as the _DETACHED flag is now set,
which means that reading any fields from that note is undefined..

Once the kq lock is released in knote, then it is possible for a
functional like kqueue_scan to endup knote_drop'ing the note...

Upon further examination, we may have another race as in knote_drop,
when we call f_detach, we don't have the list locked, nor kq, which
means that knlist_remove_inevent could be modifing the list at the same
time that kqueue_register could be modifing it to remove a _DELETED
note...

I'd like to close both races at the same time since they go
hand in hand...

> > The rest of your explination is invalid due to the invalid assumption
> > of this point...
> 
> Eagerly waiting for your explanation...
> 
> > If you can provide 

Re: Instant panic while trying run ports-mgmt/poudriere

2015-09-01 Thread Konstantin Belousov
On Tue, Sep 01, 2015 at 11:24:06AM -0700, John-Mark Gurney wrote:
> Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 23:21 +0300:
> > On 27/08/2015 21:09, John-Mark Gurney wrote:
> > > Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
> > >> On 27/08/2015 02:36, John-Mark Gurney wrote:
> > >>> We should/cannot get here w/ an empty list.  If we do, then there is
> > >>> something seriously wrong...  The current kn (which we must have as we
> > >>> are here) MUST be on the list, but as you just showed, there are no
> > >>> knotes on the list.
> > >>>
> > >>> Can you get me a print of the knote?  That way I can see what flags
> > >>> are on it?
> > >>
> > >> Apologies if the following might sound a little bit patronizing, but it
> > >> seems that you have got all the facts correctly, but somehow the
> > >> connection between them did not become clear.
> > >>
> > >> So:
> > >> 1. The list originally is NOT empty.  I guess that it has one entry, but
> > >> that's an unimportant detail.
> > >> 2. This is why the loop is entered. It's a fact that it is entered.
> > >> 3. The list becomes empty precisely because the entry is removed during
> > >> the iteration in the loop (as kib has explained).  It's a fact that the
> > >> list became empty at least in the panic that I reported.
> > > 
> > > On you're latest dump, you said:
> > > Here is another +1 with r286922.  
> > >   
> > > I can add a couple of bits of debugging data: 
> > >   
> > >   
> > >   
> > > (kgdb) fr 8   
> > >   
> > > #8  0x80639d60 in knote (list=0xf8019a733ea0, 
> > >   
> > > hint=2147483648, lockflags=) at  
> > >   
> > > /usr/src/sys/kern/kern_event.c:1964   
> > >   
> > > 1964} else if ((lockflags & KNF_NOKQLOCK) != 0) { 
> > >   
> > > 
> > > First off, that can't be r286922, per:
> > > https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
> > > 
> > > line 1964 is blank...  The line of code above should be at line 1884,
> > > so not sure what is wrong here...
> > 
> > No, it can not be indeed, because I am running head.
> > r286922 was the latest version of the repository, not the head branch,
> > at the moment when I pulled the repository via git.
> > 
> > > Assuming that the pc really is at the line, f_event has not yet been
> > > called,
> > 
> > Even on the second loop iteration?
> > 
> > >which is why I said that the list cannot be empty yet, as
> > > f_event hasn't been called yet to remove the knote...  It could be that
> > > optimization moved stuff around, but if that is the case, then the
> > > above wasn't useful..
> > 
> > I provided the disassembly of the code as well, it's very obvious how
> > the code was translated.
> > 
> > >> 4. The element is not only unlinked from the list, but its memory is
> > >> also freed.
> > > 
> > > Where is the memory freed?  A knote MUST NOT be freed in an f_event
> > > handler.  The only location that a list element is allowed to be
> > > freed is in knote_drop, which must happen after f_detach is called,
> > > but that can't/won't happen from knote (I believe the timer handles
> > > this specially, but we are talking about normal knlist type filters)..
> > 
> > Well, right.  knote()->filt_proc()->knlist_remove_inevent() just removes
> > the knote from the list.  But then there is KNOTE_ACTIVATE() that passes
> > the knote to a different owner (so to say). And given that the knote has
> > EV_ONESHOT set on it (in filt_proc) and that poudriere can put quite a
> > stress load on a system, I am not surprised that another thread gets a
> > chance to call knote_drop() on the knote before the original thread
> > proceeds to the next iteration.
> 
> Ok, I think I have identified the race that you guys were trying to
> tell me about, and though the _SAFE macro would be a similar fix, I'm
> going to rewrite the loop so that this is more explicit on what
> is happening here...
> 
> So, the race is this...  In knote, when the note is removed by
> f_event, things are find until the KQ lock is dropped...  Once this
> lock is dropped, effective ownership of the knote is transfered
> from the knlist to the kq lock as the _DETACHED flag is now set,
> which means that reading any fields from that note is undefined..
> 
> Once the kq lock is released in knote, then it is possible for a
> functional like kqueue_scan to endup knote_drop'ing the note...
Did you read the commit message and my previous N messages about the
subject ? Can you point me at a difference between the commit message
and the above text ?

I object against the your pointless and fact-less backout request
and have no intention of complying with it.

> 

Re: Upgrading to r297291 LAGG(4) stops working.

2015-09-01 Thread John Baldwin
On Monday, August 31, 2015 09:58:45 AM Adrian Chadd wrote:
> Hi,
> 
> +glebius, as he recently messed around with the wifi stack and his
> changes may have broken how mac addresses are assigned to the
> hardware.

Glebius did break this, though not because of what you say.  It's broken
because the 'ifconfig_ath0' line that sets the mac address no longer
does anything because 'ath0' is no longer an interface (and so that
line is now ignored, plus it wouldn't work if it were passed to ifconfig
now anyway).

At the very least the Handbook section on this needs to be updated to give
working instructions for both HEAD and stable branches.

-- 
John Baldwin
___
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 on boot during scan with pmspcv

2015-09-01 Thread John Baldwin
On Tuesday, August 25, 2015 02:27:42 PM Conrad Meyer wrote:
> For some reason, it only crops up on UEFI boot. "Legacy" boot "just works."
> 
> It looks like we're locking a mutex in a struct at NULL.
> 
> (trap)
> __mtx_assert+0xdb
> agtiapi_cam_action+0x45
> xpt_action_default+0xbe3(?)
> scsi_scan_bus+0x1cd
> xpt_scanner_thread+0x15c
> ...
> 
> 
> Fault is at 0x18.
> 
> http://i.imgur.com/615PC6b.jpg
> 
> (kgdb) l *(agtiapi_cam_action+0x45)
> 0x806d4ef5 is in agtiapi_cam_action
> (/usr/src/sys/dev/pms/freebsd/driver/ini/src/agtiapi.c:1818).
> 
> Possibly here?
> 
> 1814   mtx_assert( &(pmcsc->pCardInfo->pmIOLock), MA_OWNED );

Probably pCardInfo is NULL.

Looking at the pms driver source is making my stomach churn, but I don't
see anything obvious.  The field is set during attach, so it shouldn't be
NULL when the intrhook runs.  Do you have any other storage devices on
this box?  If so, I would try to kldload the pms driver after you have
booted far enough to setup dumps (either that or setup remote kgdb).

-- 
John Baldwin
___
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"


nmap: route_dst_generic: Failed to obtain system routes: getsysroutes_dnet: sysroutes_dnet_find_interfaces() failed

2015-09-01 Thread O. Hartmann
Running a simple "namp -sS" on the network or a dedicated IP, I get this error:

route_dst_generic: Failed to obtain system routes: getsysroutes_dnet:
sysroutes_dnet_find_interfaces() failed

System is FreeBSD 11.0-CURRENT #1 r287321: Mon Aug 31 09:35:35 CEST 2015 amd64
and most recent port's security/nmap.

Any hints? I see this problem on several CURRENT systems.

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"


Re: Instant panic while trying run ports-mgmt/poudriere

2015-09-01 Thread Andriy Gapon

John-Mark,

with all the due respect I have to invoke the forest-vs-trees argument here:

- it is established that in the knote() loop the current knote member of the
klist can be removed
- it's a fact that getting a pointer to a next element from a removed element is
an illegal operation
- FOREACH_SAFE is specifically designed to handle exactly this kind of the 
iteration



-- 
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: Panic on boot during scan with pmspcv

2015-09-01 Thread Garrett Cooper

> On Sep 1, 2015, at 13:30, Conrad Meyer  wrote:
> 
>> On Mon, Aug 31, 2015 at 6:20 PM, John Baldwin  wrote:
>> Probably pCardInfo is NULL.
>> 
>> Looking at the pms driver source is making my stomach churn, but I don't
>> see anything obvious.  The field is set during attach, so it shouldn't be
>> NULL when the intrhook runs.  Do you have any other storage devices on
>> this box?  If so, I would try to kldload the pms driver after you have
>> booted far enough to setup dumps (either that or setup remote kgdb).
> 
> In fact, I don't have any storage devices attached to the PMC
> controller on this box. So it's a pretty low priority for me other
> than not panicing. I've configured the BIOS to legacy boot and the
> issue no longer crops up.
> 
> I just wanted to register the stack and unpleasantness on -CURRENT@ in
> case someone else runs into it too and/or PMC is reading and can
> diagnose/fix it.

If you see something, bug it :)!
___
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: [drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer

2015-09-01 Thread Kevin Oberman
On Sun, Aug 30, 2015 at 3:06 PM, Adrian Chadd  wrote:

> Hi,
>
> has anyone asked dumbbell directly about it?
>
>
>
> -a
>
>
> On 30 August 2015 at 14:25, Slawa Olhovchenkov  wrote:
> > On Sun, Aug 30, 2015 at 11:59:26PM +0300, Ruslan Makhmatkhanov wrote:
> >
> >> Slawa Olhovchenkov wrote on 08/30/2015 22:17:
> >> > On Sun, Aug 30, 2015 at 09:58:31PM +0300, Ruslan Makhmatkhanov wrote:
> >>
> >> >> No doubt that this is not the root cause, but frankly I haven't that
> >> >> "GPU hung" messages in my system. I have others like this one
> triggered
> >> >> on shutdown:
> >> >> error: [drm:pid1041:intel_lvds_enable] *ERROR* timed out waiting for
> >> >> panel to power off
> >> >>
> >> >> And this one spamming almost with the same frequency as "pinned
> buffer":
> >> >> error: [drm:pid1016:gen6_sanitize_pm] *ERROR* Power management
> >> >> discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 000d, was 180d
> >> >>
> >> >> But I had not investigated that yet and not sure they are related.
> >> >> It's on r287029 head.
> >> >
> >> > All of this related to import new DRI/DRM code and such code in Linux
> >> > have same problems.
> >> > r282141 in stable related to r279599 and r275209 in current.
> >> > Can you try to revert r279599?
> >>
> >> You are right. After reverting r279599 two of this messages ("timed out
> >> waiting for panel to power off" and "unbind pinned buffer") disappeared,
> >> while "Power management discrepancy" is still there. Should I try to
> >> revert r275209 too?
> >
> > I think r275209 is not relevant here.
>
>
This thread has been quiet of late and seems to be an annoyance that a real
problem.

I would like to suggest that it might belong on x11@ rather than current@.
I see the same issue on stable and first saw it  in late March after the
MFC of  r280369 which incorporated r277487, r277959, r278146-278148,
r278152 and r278159.These are all older than the commits suggested. r277487
was the primary commit to head.

I reported this to x11@ back on April 1, but when I went a day with no
errors, I sent a note that it was transient and had disappeared on April 9.
Clearly I was too quick on the draw as the messages reappeared in a day or
two, but I never got around to following up.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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 on boot during scan with pmspcv

2015-09-01 Thread Conrad Meyer
On Mon, Aug 31, 2015 at 6:20 PM, John Baldwin  wrote:
> Probably pCardInfo is NULL.
>
> Looking at the pms driver source is making my stomach churn, but I don't
> see anything obvious.  The field is set during attach, so it shouldn't be
> NULL when the intrhook runs.  Do you have any other storage devices on
> this box?  If so, I would try to kldload the pms driver after you have
> booted far enough to setup dumps (either that or setup remote kgdb).
>

In fact, I don't have any storage devices attached to the PMC
controller on this box. So it's a pretty low priority for me other
than not panicing. I've configured the BIOS to legacy boot and the
issue no longer crops up.

I just wanted to register the stack and unpleasantness on -CURRENT@ in
case someone else runs into it too and/or PMC is reading and can
diagnose/fix it.

Best,
Conrad
___
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: Upgrading to r297291 LAGG(4) stops working.

2015-09-01 Thread Gleb Smirnoff
On Mon, Aug 31, 2015 at 09:58:45AM -0700, Adrian Chadd wrote:
A> Hi,
A> 
A> +glebius, as he recently messed around with the wifi stack and his
A> changes may have broken how mac addresses are assigned to the
A> hardware.

I've tested that with new code setting MAC address on wlan0 passed it
down to device driver (iwn in my case).

As Adrian already noted to Ranjan, his setup worked only by accident :)
If it were not ath(4), but some more dumb WiFi device, the setup wouldn't
work.

-- 
Totus tuus, Glebius.
___
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: r287197: wlan interfaces aren't brought up at boot or u

2015-09-01 Thread Gleb Smirnoff
  Idwer,

  can you please subscribe to this bug?

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

And getting involved with debugging is much appreciated.

-- 
Totus tuus, Glebius.
___
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"