On Tue, Aug 08, 2006 at 12:15:07PM -0400, John Baldwin wrote:
> On Tuesday 08 August 2006 05:50, Yar Tikhiy wrote:
> > On Fri, Aug 04, 2006 at 04:44:07PM -0400, John Baldwin wrote:
> > >
> > > To be honest, as someone who works with bug reports, I'd actually like
> > > backtraces up front w/o req
On Tuesday 08 August 2006 05:50, Yar Tikhiy wrote:
> On Fri, Aug 04, 2006 at 04:44:07PM -0400, John Baldwin wrote:
> >
> > To be honest, as someone who works with bug reports, I'd actually like
> > backtraces up front w/o requiring the user to compile a custom kernel,
etc.
> > Having a simple
On Fri, Aug 04, 2006 at 04:44:07PM -0400, John Baldwin wrote:
>
> To be honest, as someone who works with bug reports, I'd actually like
> backtraces up front w/o requiring the user to compile a custom kernel, etc.
> Having a simple backend in place and kdb_backtrace()'s where relevant would
>
On Fri, 4 Aug 2006, John Baldwin wrote:
On Friday 04 August 2006 16:01, Marcel Moolenaar wrote:
The point is that kdb_backtrace() is there if you want a backtrace and
you call it based on whatever option that makes sense at the call-site
or even unconditionally if that's the right thing.
Whet
On Aug 4, 2006, at 1:44 PM, John Baldwin wrote:
Places that call kdb_enter() aren't all #ifdef KDB IIRC. It's
just a feature that kdb_foo() functions become NOPs when the
kernel isn't
configured for debugging, so I think the #ifdef KDB's would be
redundant.
None of the kdb_*() functions
On Friday 04 August 2006 16:01, Marcel Moolenaar wrote:
> On Fri, Aug 04, 2006 at 01:14:22PM -0400, John Baldwin wrote:
> > >
> > > So, putting the kdb_backtrace() under KDB is not a matter of said
> > > function not being present without KDB, it's that we don't want
> > > to emit backtraces when
On Fri, Aug 04, 2006 at 09:27:56AM -0700, Sam Leffler wrote:
> Yar Tikhiy wrote:
> > On Thu, Aug 03, 2006 at 10:11:11AM -0700, Sam Leffler wrote:
> >> Yar Tikhiy wrote:
> >>> yar 2006-08-03 09:59:09 UTC
> >>>
> >>> FreeBSD src repository
> >>>
> >>> Modified files:
> >>> sys/net
On Aug 5, 2006, at 11:41 AM, Yar Tikhiy wrote:
On Fri, Aug 04, 2006 at 01:01:54PM -0700, Marcel Moolenaar wrote:
On Fri, Aug 04, 2006 at 01:14:22PM -0400, John Baldwin wrote:
So, putting the kdb_backtrace() under KDB is not a matter of said
function not being present without KDB, it's that w
On Fri, Aug 04, 2006 at 01:01:54PM -0700, Marcel Moolenaar wrote:
> On Fri, Aug 04, 2006 at 01:14:22PM -0400, John Baldwin wrote:
> > >
> > > So, putting the kdb_backtrace() under KDB is not a matter of said
> > > function not being present without KDB, it's that we don't want
> > > to emit backtr
On Fri, 2006-Aug-04 09:23:52 -0700, Marcel Moolenaar wrote:
>So, putting the kdb_backtrace() under KDB is not a matter of said
>function not being present without KDB, it's that we don't want
>to emit backtraces when debugging is not enabled. Backtraces are
>a debugging tool and it makes sense to e
On Fri, Aug 04, 2006 at 01:14:22PM -0400, John Baldwin wrote:
> >
> > So, putting the kdb_backtrace() under KDB is not a matter of said
> > function not being present without KDB, it's that we don't want
> > to emit backtraces when debugging is not enabled. Backtraces are
> > a debugging tool and
On Friday 04 August 2006 12:23, Marcel Moolenaar wrote:
> On Aug 4, 2006, at 12:03 AM, Yar Tikhiy wrote:
>
> > Just noticed that many calls to kdb_backtrace() are under "#ifdef
> > KDB" while subr_kdb.c is marked as standard in /sys/conf/files and
> > the function itself is always available (yet c
Yar Tikhiy wrote:
> On Thu, Aug 03, 2006 at 10:11:11AM -0700, Sam Leffler wrote:
>> Yar Tikhiy wrote:
>>> yar 2006-08-03 09:59:09 UTC
>>>
>>> FreeBSD src repository
>>>
>>> Modified files:
>>> sys/net if_vlan.c
>>> Log:
>>> Should vlan_input() ever be called with i
On Aug 4, 2006, at 12:03 AM, Yar Tikhiy wrote:
Just noticed that many calls to kdb_backtrace() are under "#ifdef
KDB" while subr_kdb.c is marked as standard in /sys/conf/files and
the function itself is always available (yet can do nothing.)
Should calls to kdb_backtrace() be put under "#ifdef
On Friday 04 August 2006 03:03, Yar Tikhiy wrote:
> On Thu, Aug 03, 2006 at 02:58:00PM -0400, John Baldwin wrote:
> > On Thursday 03 August 2006 14:08, Yar Tikhiy wrote:
> > > On Thu, Aug 03, 2006 at 10:11:11AM -0700, Sam Leffler wrote:
> > > > Yar Tikhiy wrote:
> > > > > yar 2006-08-03 09:
On Thu, Aug 03, 2006 at 02:58:00PM -0400, John Baldwin wrote:
> On Thursday 03 August 2006 14:08, Yar Tikhiy wrote:
> > On Thu, Aug 03, 2006 at 10:11:11AM -0700, Sam Leffler wrote:
> > > Yar Tikhiy wrote:
> > > > yar 2006-08-03 09:59:09 UTC
> > > >
> > > > FreeBSD src repository
> > > >
On Thursday 03 August 2006 14:08, Yar Tikhiy wrote:
> On Thu, Aug 03, 2006 at 10:11:11AM -0700, Sam Leffler wrote:
> > Yar Tikhiy wrote:
> > > yar 2006-08-03 09:59:09 UTC
> > >
> > > FreeBSD src repository
> > >
> > > Modified files:
> > > sys/net if_vlan.c
> > > L
On Thu, Aug 03, 2006 at 10:11:11AM -0700, Sam Leffler wrote:
> Yar Tikhiy wrote:
> > yar 2006-08-03 09:59:09 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > sys/net if_vlan.c
> > Log:
> > Should vlan_input() ever be called with ifp pointing to a no
Yar Tikhiy wrote:
> yar 2006-08-03 09:59:09 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/net if_vlan.c
> Log:
> Should vlan_input() ever be called with ifp pointing to a non-Ethernet
> interface, do not just assign -1 to tag because it breaks the lo
>
> Removing the "dead" assignment to evl->evl_encap_proto above and
> reducing the bcopy window by 2 bytes here is a nano-optimization.
> Which is worse, it smuggles hidden dot1q details in this otherwise
> encapsulation-neutral block of code. E.g., I could use the former
> code for both dot1q
On Tue, Aug 01, 2006 at 05:40:56PM -0700, Sam Leffler wrote:
>
> We obviously had no idea you were interested in this. I was asked to
> review the original change and noticed the bogus panic code and
> suggested it be fixed at the same time. I already pointed out to Qing
> Li that the new code is
Yar Tikhiy wrote:
> On Tue, Aug 01, 2006 at 05:28:10PM +, Qing Li wrote:
>> qingli 2006-08-01 17:28:10 UTC
>>
>> FreeBSD src repository
>>
>> Modified files:
>> sys/net if_vlan.c
>> Log:
>> In vlan_input(), if the network interface does not perform h/w based
>>
On Tue, Aug 01, 2006 at 05:28:10PM +, Qing Li wrote:
> qingli 2006-08-01 17:28:10 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/net if_vlan.c
> Log:
> In vlan_input(), if the network interface does not perform h/w based
> vlan tag processing, the co
On Thu, 29 Jun 2006, Yar Tikhiy wrote:
I stress tested gif(4) in the same manner for kicks and got a very similar
panic in in_control(). I suppose that my change eliminated a concurrency
problem in vlan(4) and we began to feel the lack of refcounting at ifnet
level. Indeed, a thread can kee
On Thu, Jun 29, 2006 at 04:36:30PM +0200, Andre Oppermann wrote:
> Yar Tikhiy wrote:
> >On Thu, Jun 29, 2006 at 01:24:56PM +0400, Maxim Konovalov wrote:
> >>On Thu, 29 Jun 2006, 07:52-, Yar Tikhiy wrote:
> >>
> >>>yar 2006-06-29 07:52:30 UTC
> >>>
> >>> FreeBSD src repository
> >>>
> >
Yar Tikhiy wrote:
On Thu, Jun 29, 2006 at 01:24:56PM +0400, Maxim Konovalov wrote:
On Thu, 29 Jun 2006, 07:52-, Yar Tikhiy wrote:
yar 2006-06-29 07:52:30 UTC
FreeBSD src repository
Modified files:
sys/net if_vlan.c
Log:
Detach the interface first, do vlan
On Thu, Jun 29, 2006 at 01:24:56PM +0400, Maxim Konovalov wrote:
> On Thu, 29 Jun 2006, 07:52-, Yar Tikhiy wrote:
>
> > yar 2006-06-29 07:52:30 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > sys/net if_vlan.c
> > Log:
> > Detach the interface fi
On Thu, 29 Jun 2006, 07:52-, Yar Tikhiy wrote:
> yar 2006-06-29 07:52:30 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/net if_vlan.c
> Log:
> Detach the interface first, do vlan_unconfig() then.
> Previously, another thread could get a pointer to t
On Thu, Feb 09, 2006 at 10:11:58PM +, Ed Maste wrote:
E> emaste 2006-02-09 22:11:58 UTC
E>
E> FreeBSD src repository
E>
E> Modified files:
E> sys/net if_vlan.c
E> Log:
E> Add a MODULE_VERSION so that other modules (perhaps third-party) can
E> depend on this on
29 matches
Mail list logo
