Re: [PATCH] Recent libm additions

[K. Macy]

>
> Well, actually, the functions in polevll.c should have been copied
> into ld80/e_powl.c, and polevall.c should never have been committed.
> Unfortunately, the code was not reviewed for correctness.

That is not correct. Please stop repeating it. Bruce Evans and John
Baldwin were both looped in. Neither made this observation.
___
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: rust broken?

[K. Macy]

On Thu, Jun 7, 2018 at 11:26 PM, Greg  wrote:
> On 06/07, Matthew Macy wrote:
>>
>> On Thu, Jun 7, 2018 at 10:33 Michael Butler 
>> wrote:
>>
>>> Ah - I'll re-enable that to see if it makes a difference ..
>>>
>>
>>
>> It's not a question of enabling. It doesn't explicitly use the 11 symbols.
>> Rust developers assume that every OS has a frozen ABI like Linux. The rust
>> from rustup will only work on 11. This is why you need to use the port /
>> pkg.
>
>
> It does use the 11 (pre-ino64) symbols.
> Rust from rustup has worked fine on CURRENT for a few months already.
>

There's also kevent and who knows what else. But that's cool. There
was no sign of movement there when last I used Rust in October.

-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"

Re: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)

[K. Macy]

>
> I wrote up a couple more paragraphs about why I think it happens and
> what we'd need to do to import more of that sense over into src.  But
> it was way longer than it needs to be.  We get a lot more man-hours in
> ports/ acting as conduits for the "outside patches -> svn" pipeline
> because the incentives are rigged.  A bad outside contribution brought
> into ports more often yields "hey, you should have noticed" to the
> committer and more opprobrium back to the submitter.  A bad outside
> contribution brought into src falls all over the commiter.
>
> Not entirely unreasonable, since a lot of even small-ish breakages in
> src are much bigger deals than even large-ish breakages in ports.  But
> it still makes it expensive to contemplate being a conduit...

Whereas the incentives in ports are structured such as to encourage
being a conduit and arguably it's a big part of being a responsible
porter, in src there is an active disincentive. A committer invites
substantial criticism by breaking src by importing a change but
invites no criticism for ignoring review requests or patches. There
are a few people who go through the pain of wading through patches and
committing them but as a general rule one has to have some level of
rapport with a proxy to get changes in without a bit. Whereas with
TrueOS the Git PR system lets one submit a change, the CI system
builds it to verify, and then it's thumbs up or thumbs down and it
goes in, undergoes further review / refinement, or is rejected
outright. There's something to be said for automation.

Submitting enhancements is even harder. There's always someone who
will be upset by a change in existing behavior, no matter how logical
a change may seem to the rest of us. This obvious change is almost 10
years old and seems completely common sense:

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

I've been keeping it in my bookmarks hoping that Eitan will commit it,
but may at some point overcome my reservations and just go ahead and
commit.

My problem with the bug system is classification. If a bug report
refers to something I touched recently, it's easy to assign it to me.
However, when I've tried wading through the bug system to find things
that I might be able to fix, I have not found it easy at all. This is
where culling older bug reports comes in. With a poor signal to noise
ratio from too many PRs, what really happens is _fewer_ things get
fixed, not more.

Cheers.
-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"

Re: ifa_ifwithnet failed ???

[K. Macy]

please update to r334253

On Sat, May 26, 2018 at 11:36 PM, O. Hartmann  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Sun, 27 May 2018 03:17:07 +
> "Pieper, Jeffrey E"  schrieb:
>
>> I'm seeing this spam dmesg continuously on a build from this afternoon 
>> (r334252):
>>
>> May 27 03:06:03 u0855 kernel: ifa_ifwithnet failed
>> May 27 03:06:03 u0855 syslogd: last message repeated 11 times
>> May 27 03:06:03 u0855 kernel: .
>> May 27 03:06:05 u0855 kernel: ifa_ifwithnet failed
>> May 27 03:06:39 u0855 syslogd: last message repeated 60 times
>> May 27 03:08:39 u0855 syslogd: last message repeated 59 times
>>
>>
>> Is anyone else seeing this?
>>
>> Jeff Pieper
>> ___
>> 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"
>
> Me, too, on a router/firewall system running:
>
> FreeBSD 12.0-CURRENT #7 r334236: Sat May 26 08:03:39 CEST 2018
>
> The console is spammed with ifa_ifwithnet failed after first boot but while 
> running, the
> message disappears or at least the console isn't spammed any more.
>
> oh
>
> -BEGIN PGP SIGNATURE-
>
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWwpR/gAKCRDS528fyFhY
> lDydAf9r1QPwk6Fd51gNafTBV9Izzzcf6L0HJEyZWOdxZ2+3HmVWAv1jA9heq33q
> NjnJRiCYcUo/aOQ0Ms1At0No2trXAfsEy47HzHvCSjVWnJvWJDR22LLpokAZyvfM
> XBHZbPSBdLmvW75XSHqVfSzCKKcpy2qeLB19sTIKW3K/RIQkLxAL
> =CUlq
> -END PGP SIGNATURE-
> ___
> 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: ifa_ifwithnet failed ???

[K. Macy]

My guess is that this is caused by my changes. However, this is the
first time I've heard this reported so it would be useful to know how
I might reproduce it.

Thanks.
-M

On Sat, May 26, 2018 at 8:33 PM, Pieper, Jeffrey E
<jeffrey.e.pie...@intel.com> wrote:
>
> 
> From: kmacy...@gmail.com [kmacy...@gmail.com] on behalf of K. Macy 
> [km...@freebsd.org]
> Sent: Saturday, May 26, 2018 8:20 PM
> To: Pieper, Jeffrey E
> Cc: freebsd-current ‎[freebsd-current@freebsd.org]‎
> Subject: Re: ifa_ifwithnet failed ???
>
> On Sat, May 26, 2018 at 8:17 PM, Pieper, Jeffrey E
> <jeffrey.e.pie...@intel.com> wrote:
>> I'm seeing this spam dmesg continuously on a build from this afternoon 
>> (r334252):
>>
>> May 27 03:06:03 u0855 kernel: ifa_ifwithnet failed
>> May 27 03:06:03 u0855 syslogd: last message repeated 11 times
>> May 27 03:06:03 u0855 kernel: .
>> May 27 03:06:05 u0855 kernel: ifa_ifwithnet failed
>> May 27 03:06:39 u0855 syslogd: last message repeated 60 times
>> May 27 03:08:39 u0855 syslogd: last message repeated 59 times
>
>
>> What did this happen subsquent to?
>
> I just started seeing it yesterday on current, but prior to that we've been 
> pulling from https://github.com/intel-wired-ethernet/freebsd, but that isn't 
> rebased as frequently as it should be so that probably doesn't help very 
> much. We just started using current for https://reviews.freebsd.org/D15577.
>
> Jeff
>
>> ___
>> 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: ifa_ifwithnet failed ???

[K. Macy]

On Sat, May 26, 2018 at 8:17 PM, Pieper, Jeffrey E
 wrote:
> I'm seeing this spam dmesg continuously on a build from this afternoon 
> (r334252):
>
> May 27 03:06:03 u0855 kernel: ifa_ifwithnet failed
> May 27 03:06:03 u0855 syslogd: last message repeated 11 times
> May 27 03:06:03 u0855 kernel: .
> May 27 03:06:05 u0855 kernel: ifa_ifwithnet failed
> May 27 03:06:39 u0855 syslogd: last message repeated 60 times
> May 27 03:08:39 u0855 syslogd: last message repeated 59 times


What did this happen subsquent to?


> Is anyone else seeing this?
>
> Jeff Pieper
> ___
> 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: SVN - r334189 breaks build

[K. Macy]

Fix going in in about 10

On Thu, May 24, 2018 at 3:45 PM, Michael Butler
 wrote:
> On a GENERIC box ..
>
> --- bridgestp.o ---
> /usr/src/sys/net/bridgestp.c:2046:2: error: no member named 'cstqe_next'
> in 'struct ifnet::(anonymous at /usr/src/sys/net/if_var.h:241:2)'; did
> you mean 'stqe_next'?
> CK_STAILQ_FOREACH(ifp, _ifnet, if_link) {
> ^
> /usr/src/sys/contrib/ck/include/ck_queue.h:253:13: note: expanded from
> macro 'CK_STAILQ_FOREACH'
>(var) = CK_STAILQ_NEXT((var), field))
>^
> /usr/src/sys/contrib/ck/include/ck_queue.h:291:32: note: expanded from
> macro 'CK_STAILQ_NEXT'
> (ck_pr_load_ptr(&(elm)->field.cstqe_next))
>   ^
> /usr/src/sys/net/if_var.h:241:2: note: 'stqe_next' declared here
> STAILQ_ENTRY(ifnet) if_link;/* all struct ifnets are chained
> (CK_) */
>
> And on a custom kernel ..
>
> --- hwpmc_mod.o ---
> /usr/src/sys/dev/hwpmc/hwpmc_mod.c:1727:2: error: no member named
> 'clh_first' in 'struct (anonymous at
> /usr/src/sys/dev/hwpmc/hwpmc_mod.c:178:8)'; did you mean 'lh_first'?
> CK_LIST_FOREACH(po, _ss_owners, po_ssnext)
> ^
> /usr/src/sys/contrib/ck/include/ck_queue.h:363:15: note: expanded from
> macro 'CK_LIST_FOREACH'
> for ((var) = CK_LIST_FIRST((head));
>\
>  ^
> /usr/src/sys/contrib/ck/include/ck_queue.h:358:54: note: expanded from
> macro 'CK_LIST_FIRST'
> #define CK_LIST_FIRST(head) ck_pr_load_ptr(&(head)->clh_first)
> ^
> /usr/src/sys/dev/hwpmc/hwpmc_mod.c:178:8: note: 'lh_first' declared here
> static LIST_HEAD(, pmc_owner)   pmc_ss_owners;
>^
> ___
> 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: [RFC] Deprecation and removal of the drm2 driver

[K. Macy]

Why are you running i386 on that?

On Tue, May 22, 2018 at 4:26 PM, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
> On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote:
>> >
>> >
>> > it makes me giggle that people still think non-amd64 is "legacy".
>> >
>> > i386 is alive and well - new chips are being fabbed based on the 586
>> > design with pci-e slots; not to mention things like the Talos and
>> > AmigaOne for PowerPC.
>>
>>
>> DRM2 doesn't support anything later than mid-Haswell. The chips in
>> question all pre-date 2007. Users of low-volume hardware on chips from
>> that period are welcome to continue to sustain themselves on the drm2
>> port just as the other 95+% of the user base will use what is now
>> referred to as drm-next. Even by powerpc maintainers' admission DRM2
>> also only barely works there. I've promised Justin that I'll make
>> drm-next work on Talos once POWER9 support is solid enough.
>
> % dmesg | CPU
> CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.34-MHz K8-class 
> CPU)
> % kldstat
> troutmask:sgk[205] kldstat
> Id Refs AddressSize Name
>  91 0x8141e000 db148radeonkms.ko
> 101 0x814fa000 3f7d0drm2.ko
> 112 0x8153a000 acf8 agp.ko
> 121 0x81545000 12f9 radeonkmsfw_CAICOS_pfp.ko
> 131 0x81547000 16f7 radeonkmsfw_CAICOS_me.ko
> 141 0x81549000 d73  radeonkmsfw_BTC_rlc.ko
> 151 0x8154a000 5f97 radeonkmsfw_CAICOS_mc.ko
>
> Mid-Haswell?
>
> --
> Steve
___
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: [RFC] Deprecation and removal of the drm2 driver

[K. Macy]

> I am concerned about just shoving it out to ports, as that makes
> it rot even faster.
>
> I am still very concerned that our in base i9xx code is like 4
> years old and everyone is told to go to kmod-next from ports
> as well.
>
> No, I do not have a solution, but I have not tried hard to find
> one.  I am sure if we try hard to find one it can be done.

drm-next is a port and it's what most everyone will be using going
forward. You're asking us to make a special case for a small vocal
group of i386 users. If i386 is sufficiently important, its user base
can support it.

Cheers.
-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"

Re: [RFC] Deprecation and removal of the drm2 driver

[K. Macy]

>
>
> it makes me giggle that people still think non-amd64 is "legacy".
>
> i386 is alive and well - new chips are being fabbed based on the 586
> design with pci-e slots; not to mention things like the Talos and
> AmigaOne for PowerPC.


DRM2 doesn't support anything later than mid-Haswell. The chips in
question all pre-date 2007. Users of low-volume hardware on chips from
that period are welcome to continue to sustain themselves on the drm2
port just as the other 95+% of the user base will use what is now
referred to as drm-next. Even by powerpc maintainers' admission DRM2
also only barely works there. I've promised Justin that I'll make
drm-next work on Talos once POWER9 support is solid enough.

Cheers.

-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"

Re: [RFC] Deprecation and removal of the drm2 driver

[K. Macy]

>
> I just ask.
> Or why not include drm-next to base svn repo and add some
> option to make.conf to swith drm2/dem-next ?

Even if it's not being built on amd64 we're still responsible for
keeping it building on !amd64 so long as it's in base. This makes
changing APIs and universe runs more burdensome. The graphics
developers have given you notice that it will now be your collective
responsibility to keep it up to date.

Cheers.
-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"

Re: [RFC] Deprecation and removal of the drm2 driver

[K. Macy]

On Mon, May 21, 2018 at 10:07 AM, Steve Kargl
 wrote:
> On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
>> On Sun, 20 May 2018 21:10:28 +0200
>> Oliver Pinter  wrote:
>>
>> > > One of the reasons for the deprecation and removal of the drm2 bits
>> > > is that they prevent us from automatically loading the
>> > > drm-next/stable-kmod kernel modules, since the two collide.
>> > > Regards
>> >
>> >
>> > Then it wold be better to resolve this problem, rather then removing a
>> > working solution. What's about module versioning what in other cases
>> > works?
>> >
>>
>> May be just move old drm2 to ports?
>
> Why?  "If it isn't broken, why fix it?"
>
> The conflict affects x86_64-*-freebsd aka amd64.  The
> conflict does not affect any other architecture.  The
> Makefile infrastructure can use MACHINE_ARCH to exclude
> drm2 from build of amd64.
>

Having it as a port puts the burden squarely on those using it and not
on the majority who are running hardware from this decade.

-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"

Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[K. Macy]

Chalk another review fail up to shuffling patches between git and phab.
Sorry for the inconvenience.
-M

On Wed, Apr 11, 2018 at 10:26 AM, K. Macy <km...@freebsd.org> wrote:
> Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line.
> -M
>
> On Wed, Apr 11, 2018 at 10:24 AM, K. Macy <km...@freebsd.org> wrote:
>> Sorry about that. It looks like my review must have been missing a line.
>>
>> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
>>
>> _iflib_assert(sctx);
>>
>> -   CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
>> -
>> +   CTX_LOCK_INIT(ctx);
>> +   STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
>> ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
>> if (ifp == NULL) {
>> device_printf(dev, "can not allocate ifnet structure\n");
>> @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
>> *uniq, int cpu, char *name)
>>  }
>>
>>  void
>>
>> On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill <da...@catwhisker.org> 
>> wrote:
>>> This was running:
>>>
>>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156  
>>> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 
>>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
>>> amd64
>>>
>>> during boot, after updating from:
>>>
>>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155  
>>> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 
>>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
>>> amd64
>>>
>>> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>>>
>>> It appears that r332389 is implicated.
>>>
>>> ...
>>> Unread portion of the kernel message buffer:
>>>
>>> __curthread () at ./machine/pcpu.h:230
>>> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
>>> (kgdb) #0  __curthread () at ./machine/pcpu.h:230
>>> #1  doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
>>> #2  0x80433f4c in db_fncall_generic (addr=,
>>> rv=, nargs=, args=)
>>> at /usr/src/sys/ddb/db_command.c:609
>>> #3  db_fncall (dummy1=, dummy2=,
>>> dummy3=, dummy4=)
>>> at /usr/src/sys/ddb/db_command.c:657
>>> #4  0x80433a99 in db_command (last_cmdp=,
>>> cmd_table=, dopager=)
>>> at /usr/src/sys/ddb/db_command.c:481
>>> #5  0x80433814 in db_command_loop ()
>>> at /usr/src/sys/ddb/db_command.c:534
>>> #6  0x80436a3f in db_trap (type=, code=>> out>)
>>> at /usr/src/sys/ddb/db_main.c:250
>>> #7  0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
>>> at /usr/src/sys/kern/subr_kdb.c:697
>>> #8  0x80f7eaa8 in trap (frame=0xfe4377a0)
>>> at /usr/src/sys/amd64/amd64/trap.c:548
>>> #9  
>>> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
>>> at /usr/src/sys/kern/subr_kdb.c:479
>>> #11 0x80b2feda in vpanic (fmt=, 
>>> ap=0xfe437910)
>>> at /usr/src/sys/kern/kern_shutdown.c:826
>>> #12 0x80b2fca0 in kassert_panic (
>>> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
>>> at /usr/src/sys/kern/kern_shutdown.c:723
>>> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
>>> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=>> out>)
>>> at /usr/src/sys/kern/kern_mutex.c:246
>>> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
>>> at /usr/src/sys/net/iflib.c:3716
>>> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
>>> at /usr/src/sys/kern/subr_gtaskqueue.c:331
>>> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
>>> at /usr/src/sys/kern/subr_gtaskqueue.c:506
>>> #17 0x80af0064 in fork_exit (
>>> callout=0x80b73540 ,
>>> arg=0xfe0844223008, frame=0xfe437ac0)
>>> at /usr/src/sys/kern/kern_fork.c:1039
>>> #18 
>>> (kgdb)
>>>
>>> If the dump would be useful, I can put it up for access.
>>>
>>> Peace,
>>> david
>>> --
>>> David H. Wolfskill  da...@catwhisker.org
>>> Well, what did you EXPECT from Trump?  He has a history of breaking 
>>> promises.
>>>
>>> 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: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[K. Macy]

Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line.
-M

On Wed, Apr 11, 2018 at 10:24 AM, K. Macy <km...@freebsd.org> wrote:
> Sorry about that. It looks like my review must have been missing a line.
>
> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
>
> _iflib_assert(sctx);
>
> -   CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
> -
> +   CTX_LOCK_INIT(ctx);
> +   STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
> ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
> if (ifp == NULL) {
> device_printf(dev, "can not allocate ifnet structure\n");
> @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
> *uniq, int cpu, char *name)
>  }
>
>  void
>
> On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill <da...@catwhisker.org> wrote:
>> This was running:
>>
>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156  
>> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 
>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
>> amd64
>>
>> during boot, after updating from:
>>
>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155  
>> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 
>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
>> amd64
>>
>> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>>
>> It appears that r332389 is implicated.
>>
>> ...
>> Unread portion of the kernel message buffer:
>>
>> __curthread () at ./machine/pcpu.h:230
>> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
>> (kgdb) #0  __curthread () at ./machine/pcpu.h:230
>> #1  doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
>> #2  0x80433f4c in db_fncall_generic (addr=,
>> rv=, nargs=, args=)
>> at /usr/src/sys/ddb/db_command.c:609
>> #3  db_fncall (dummy1=, dummy2=,
>> dummy3=, dummy4=)
>> at /usr/src/sys/ddb/db_command.c:657
>> #4  0x80433a99 in db_command (last_cmdp=,
>> cmd_table=, dopager=)
>> at /usr/src/sys/ddb/db_command.c:481
>> #5  0x80433814 in db_command_loop ()
>> at /usr/src/sys/ddb/db_command.c:534
>> #6  0x80436a3f in db_trap (type=, code=> out>)
>> at /usr/src/sys/ddb/db_main.c:250
>> #7  0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
>> at /usr/src/sys/kern/subr_kdb.c:697
>> #8  0x80f7eaa8 in trap (frame=0xfe4377a0)
>> at /usr/src/sys/amd64/amd64/trap.c:548
>> #9  
>> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
>> at /usr/src/sys/kern/subr_kdb.c:479
>> #11 0x80b2feda in vpanic (fmt=, ap=0xfe437910)
>> at /usr/src/sys/kern/kern_shutdown.c:826
>> #12 0x80b2fca0 in kassert_panic (
>> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
>> at /usr/src/sys/kern/kern_shutdown.c:723
>> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
>> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=)
>> at /usr/src/sys/kern/kern_mutex.c:246
>> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
>> at /usr/src/sys/net/iflib.c:3716
>> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
>> at /usr/src/sys/kern/subr_gtaskqueue.c:331
>> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
>> at /usr/src/sys/kern/subr_gtaskqueue.c:506
>> #17 0x80af0064 in fork_exit (
>> callout=0x80b73540 ,
>> arg=0xfe0844223008, frame=0xfe437ac0)
>> at /usr/src/sys/kern/kern_fork.c:1039
>> #18 
>> (kgdb)
>>
>> If the dump would be useful, I can put it up for access.
>>
>> Peace,
>> david
>> --
>> David H. Wolfskill  da...@catwhisker.org
>> Well, what did you EXPECT from Trump?  He has a history of breaking promises.
>>
>> 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: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[K. Macy]

Sorry about that. It looks like my review must have been missing a line.

@@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)

_iflib_assert(sctx);

-   CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
-
+   CTX_LOCK_INIT(ctx);
+   STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
if (ifp == NULL) {
device_printf(dev, "can not allocate ifnet structure\n");
@@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
*uniq, int cpu, char *name)
 }

 void

On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill  wrote:
> This was running:
>
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156  
> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
>
> during boot, after updating from:
>
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155  
> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
>
> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>
> It appears that r332389 is implicated.
>
> ...
> Unread portion of the kernel message buffer:
>
> __curthread () at ./machine/pcpu.h:230
> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:230
> #1  doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
> #2  0x80433f4c in db_fncall_generic (addr=,
> rv=, nargs=, args=)
> at /usr/src/sys/ddb/db_command.c:609
> #3  db_fncall (dummy1=, dummy2=,
> dummy3=, dummy4=)
> at /usr/src/sys/ddb/db_command.c:657
> #4  0x80433a99 in db_command (last_cmdp=,
> cmd_table=, dopager=)
> at /usr/src/sys/ddb/db_command.c:481
> #5  0x80433814 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:534
> #6  0x80436a3f in db_trap (type=, code=)
> at /usr/src/sys/ddb/db_main.c:250
> #7  0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
> at /usr/src/sys/kern/subr_kdb.c:697
> #8  0x80f7eaa8 in trap (frame=0xfe4377a0)
> at /usr/src/sys/amd64/amd64/trap.c:548
> #9  
> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
> at /usr/src/sys/kern/subr_kdb.c:479
> #11 0x80b2feda in vpanic (fmt=, ap=0xfe437910)
> at /usr/src/sys/kern/kern_shutdown.c:826
> #12 0x80b2fca0 in kassert_panic (
> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
> at /usr/src/sys/kern/kern_shutdown.c:723
> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=)
> at /usr/src/sys/kern/kern_mutex.c:246
> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
> at /usr/src/sys/net/iflib.c:3716
> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
> at /usr/src/sys/kern/subr_gtaskqueue.c:331
> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
> at /usr/src/sys/kern/subr_gtaskqueue.c:506
> #17 0x80af0064 in fork_exit (
> callout=0x80b73540 ,
> arg=0xfe0844223008, frame=0xfe437ac0)
> at /usr/src/sys/kern/kern_fork.c:1039
> #18 
> (kgdb)
>
> If the dump would be useful, I can put it up for access.
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Well, what did you EXPECT from Trump?  He has a history of breaking promises.
>
> 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: Is there possible run a MacOS X binary

[K. Macy]

>
>
>
A MachO activator is indeed not useful without an OSX install.

But let's be honest, Mach IPC is a loadable kernel module requiring no real
kernel changes. It's not upstreamable because of a general poor
understanding of IPC by noisy commentators and a religious aversion to a
technology perceived as having failed in the marketplace of ideas.



On Wed, Dec 7, 2016 at 10:45 Warner Losh  wrote:

> On Mon, Dec 5, 2016 at 12:31 PM, Kevin P. Neal 
> wrote:
>
> > On Mon, Dec 05, 2016 at 02:49:07PM -0300, Nilton Jose Rizzo wrote:
>
> >>
>
> >>
>
> >>  Sorry for cross posting (-current and -ports)
>
> >>
>
> >>
>
> >> Is there any emulator like linuxator to run Mac OS X binaries, or
>
> >> is ther any licensing problem?
>
> >
>
> > It may be possible to make an emulator for Darwin (the OS that Mac OS
> sits
>
> > on top of), but an emulator for Mac OS would probably require a legal
> copy
>
> > of Mac OS.
>
> >
>
> > So, no, there is no Mac OS emulator for FreeBSD. And I'd be surprised if
>
> > it ever happened.
>
>
>
> NetBSD has (or had) a macho image activator, which is the first step
>
> in this process. But Kevin is right that most of the functionality of
>
> MacOS isn't in the kernel, and you'd need a copy of MacOS to run it in
>
> emulation. Plus there's a lot of Mach code that MacOS depends on that
>
> has no simple counterparts in FreeBSD, and that would be a lot of work
>
> to make happen. It's one of the things that's a barrier to entry for a
>
> simple, straight forward launchd port, for example.
>
>
>
>
>
>
>
___
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

[K. Macy]

On Monday, November 14, 2016, Lars Engels <lars.eng...@0x20.net> wrote:

> On Sun, Nov 13, 2016 at 01:56:45PM -0800, K. Macy wrote:
> > On Saturday, November 12, 2016, Mark Heily <m...@heily.com
> <javascript:;>> wrote:
> >
> > > On Fri, Nov 11, 2016 at 11:41 PM, Kevin Oberman <rkober...@gmail.com
> <javascript:;>
> > > <javascript:;>> 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.
>
> When can we expect your graphics work in HEAD? :)
>

The core kernel changes will probably happen by the end of the year now
that a number of committers have Skylake and Kaby Lake laptops. Once those
are done the drivers themselves can be made in to ports. Adrian, Alexander
Motin, and Conrad have all expressed an interest in moving this along.

-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"

Re: Lenovo X1 Carbon or T460s

[K. Macy]

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: External toolchain support broken for devel/llvm38 but not devel/llvm37

[K. Macy]

On Monday, August 29, 2016, Volodymyr Kostyrko  wrote:

> Matthew Macy wrote:
>
>> It looks like there is something broken with the devel/llvm38 port or
>> external toolchain support has regressed:
>>
>>
>> This works:
>> make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37
>> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s
>>
>> This fails:
>>   make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38
>> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s
>>
>> with:
>>
>> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclan
>> g_rt.ubsan_standalone-x86_64.a: No such file: No such file or directory
>> clang-3.8: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>>
>
> I second this - I also faced it. I think this is not a problem with a
> ports but rather with a build as correspondent files can be found in
> /usr/obj under /usr/obj/usr/src/tmp/usr/lib/clang/3.8.0/lib/freebsd/.
> Looks like this files are compiled during build but taken from compilers's
> directory. Linking 'em to the target directory makes build succeed.


The point of using the external toolchain for me is to bypass building
clang in src. ~31 of the ~47 minutes in buildworld are spent compiling
pieces of llvm/clang. I'd much rather fix the ports than make buildworld
require additional work. For the moment I've disconnected the two pieces
that fail: svn and libc/tests. They don't really belong in base any more
than git and piglit do.


>
> --
> Sphinx of black quartz judge my vow.
> ___
> 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: Hardware rendered Wayland client up and running

[K. Macy]

On Saturday, August 13, 2016, Adrian Chadd  wrote:

> w!
>
> ok, what has to be committed to -head?




O.o

For the range of hardware supported by 3.8 just evdev and his drm kevent
patch. For anything newer (e.g. Cherryview) everything in my patch queue
that we've been talking about for at least a month.



-a
>
>
> On 13 August 2016 at 19:12, Lundberg, Johannes
> > wrote:
> > Hi FreeBSD hackers!
> >
> > Today we reached a big milestone. For the first time, we could render
> > Wayland clients, backed by hardware, not shm (shared memory), on Intel
> Atom
> > Cherryview.
> >
> > Please see attached image of my setup.
> >
> > UP board (Intel Cherryview)
> > OS running on on-board eMMC (need sdhci and mmc patches to function)
> > Ports: https://github.com/freebsd/freebsd-ports-graphics/tree/wayland
> > Base: https://github.com/FreeBSDDesktop/freebsd-base-
> graphics/tree/drm-next
> > (from today, evdev enabled kernel)
> >
> > Mouse and keyboard available using libinput.
> > Device detection by libudev-devd.
> >
> > Only one thing, we needed to disable PRIME in drm to get the Wayland
> > clients to properly allocate image buffers. Working on getting that
> fixed!
> >
> > This opens up for the next big task, getting XWayland working that enable
> > use of unmodified X clients as well as testing Wayland enabled libraries
> > like Enlightenment, QT5, GTK3, etc. That however is not high priority for
> > me so I will probably not work on that.
> >
> > [image: Inline image 1]
> >
> > --
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
> > もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
> > 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
> > ---
> > CONFIDENTIALITY NOTE: The information in this email is confidential
> > and intended solely for the addressee.
> > Disclosure, copying, distribution or any other action of use of this
> > email by person other than intended recipient, is prohibited.
> > If you are not the intended recipient and have received this email in
> > error, please destroy the original message.
> > ___
> > 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
> "
___
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"

lengthy sdhci timeouts on KBL-Y tester

[K. Macy]

I have a KBL-Y "Software Development Platform" for purposes of getting
the i915 KMS working on that system on FreeBSD. I've just installed 11
BETA4. sdhci timeouts add several minutes to boot time. The dmesg
output follows:
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-BETA4 #0 r303759: Fri Aug  5 02:26:47 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
LLVM 3.8.0)
VT(efifb): resolution 2560x1440
CPU: Intel(R) Core(TM) m5-7Y54 CPU @ 1.20GHz (1608.05-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x806e9  Family=0x6  Model=0x8e  Stepping=9
  
Features=0xbfebfbff
  
Features2=0x7ffafbbf
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended
Features=0x29c67af
  XSAVE Features=0xf
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8160288768 (7782 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: unblocking device.
ioapic0  irqs 0-119 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x81018940, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)

Re: iwm load panic

[K. Macy]

On Thursday, August 4, 2016, Christian Schwarz  wrote:

> Any idea which revision/commit introduced this regression?
>
> (I want to test iwm + freebsd-base-graphics on my laptop tonight and
>  hence avoid crashers like this one in advance.)
>
> @mmacy: is the revision in the current drm-next-4.6 branch of
> https://github.com/FreeBSDDesktop/freebsd-base-graphics.git
>
>
Yes. That is what I run on my Skylake based gen4 carbon x1. 8260 support
was just added, so I don't know if it's possible to use new hardware
without exposing one's self to this bug.

In fairness, 80-85% of the time it loads just fine, and this bug looks much
easier to fix than the various issues I am looking at right now. Once
loaded the driver has worked quite satisfactorily.

-M



> Thanks,
>
> --
> Christian Schwarz
>
>
> ___
> 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: iwm load panic

[K. Macy]

Uhm, yes. I can read that too. I'm suggesting that someone working on
the iwm driver can fix it.

On the boot immediately prior to this my system panicked with an
assert in idr - which is much more my bailiwick.


-M

On Thu, Aug 4, 2016 at 1:04 AM, Hans Petter Selasky <h...@selasky.org> wrote:
> On 08/04/16 09:56, K. Macy wrote:
>>
>> #12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at
>
>
> Hi,
>
> Looks like a NULL pointer, queue=NULL
>
> --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"

iwm load panic

[K. Macy]

I get this panic periodically at iwm load time:

(kgdb) p ic->ic_tq
value has been optimized out
(kgdb) down
#12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at
/usr/home/mmacy/drm-next-4.6/sys/kern/subr_taskqueue.c:554
554 TQ_LOCK(queue);
(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:221
#1  doadump (textdump=0) at
/usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:298
#2  0x82703ac9 in vt_kms_postswitch (arg=)
at 
/usr/home/mmacy/drm-next-4.6/sys/modules/drm2/drm2/../../../dev/drm2/linux_fb.c:82
#3  0x8093fb55 in vt_window_switch (vw=0x817e87d0
)
at /usr/home/mmacy/drm-next-4.6/sys/dev/vt/vt_core.c:540
#4  0x8093c9b0 in vtterm_cngrab (tm=) at
/usr/home/mmacy/drm-next-4.6/sys/dev/vt/vt_core.c:1465
#5  0x80a78f12 in cngrab () at
/usr/home/mmacy/drm-next-4.6/sys/kern/kern_cons.c:368
#6  0x80ae88c6 in vpanic (fmt=0x810f771b "%s",
ap=0xfe0461098e70)
at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:745
#7  0x80ae87b3 in panic (fmt=) at
/usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:690
#8  0x80fc0361 in trap_fatal (frame=0xfe0461099170, eva=100)
at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:841
#9  0x80fc0553 in trap_pfault (frame=0xfe0461099170, usermode=0)
at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:691
#10 0x80fbfafc in trap (frame=0xfe0461099170) at
/usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:442
#11 
#12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at
/usr/home/mmacy/drm-next-4.6/sys/kern/subr_taskqueue.c:554
#13 0x827823bb in ieee80211_draintask (ic=,
task=0xfe004fc17150)
at /usr/home/mmacy/drm-next-4.6/sys/net80211/ieee80211_var.h:796
#14 iwm_detach_local (sc=, do_net80211=)
at /usr/home/mmacy/drm-next-4.6/sys/modules/iwm/../../dev/iwm/if_iwm.c:6121
#15 0x80b21e8c in run_interrupt_driven_config_hooks ()
at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_autoconf.c:118
#16 0x80b21ccb in config_intrhook_establish (hook=)
at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_autoconf.c:182
#17 0x82781d03 in iwm_attach (dev=)
at /usr/home/mmacy/drm-next-4.6/sys/modules/iwm/../../dev/iwm/if_iwm.c:5825
#18 0x80b26340 in DEVICE_ATTACH (dev=0xf8000744f700) at
./device_if.h:180
#19 device_attach (dev=0xf8000744f700) at
/usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:2900
#20 0x8071730d in pci_driver_added (dev=,
driver=)
at /usr/home/mmacy/drm-next-4.6/sys/dev/pci/pci.c:4330
#21 0x80b23e9d in BUS_DRIVER_ADDED (_dev=0xf8000744f800,
_driver=0x82790c08 )
at ./bus_if.h:204
#22 devclass_driver_added (dc=, driver=)
at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:1099
#23 0x80b23e02 in devclass_add_driver (dc=,
driver=, pass=,
dcp=) at
/usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:1172
#24 0x80ac2300 in module_register_init (arg=)
at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_module.c:123
#25 0x80ab3f14 in linker_file_sysinit (lf=)
at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:234
#26 linker_load_file (filename=, result=)
at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:434
#27 linker_load_module (kldname=,
modname=0xf8000f0a8000 "if_iwm", parent=,
verinfo=, lfpp=) at
/usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:2024
#28 0x80ab5d48 in kern_kldload (td=,
file=, fileid=0xfe0461099874)
at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:1041
#29 0x80ab5eab in sys_kldload (td=0xf800966f1500,
uap=)
at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:1067
#30 0x80fc0cc8 in syscallenter (td=, sa=)
at 
/usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/../../kern/subr_syscall.c:135
#31 amd64_syscall (td=, traced=0) at
/usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:942
#32 
#33 0x00080086d38a in ?? ()
___
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: [PATCH] randomized delay in locking primitives, take 2

[K. Macy]

On Sun, Jul 31, 2016 at 7:03 AM, Adrian Chadd  wrote:
> Hi,
>
> Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are
> any performance degredations on lower count CPUs?


The adaptive spinning path will never run on a uniprocessor. Except
for potential i-cache displacement you're not going to actually see
any effect unless there is substantial contention. You'll need all
threads consistently contending for the same lock. A potential
workload to exercise this would be to run ncpu threads sending small
UDP packets on a driver with a legacy mutex protected IFQ interface.


> Also, yeah, the MOD operator in each loop could get spendy on older
> CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to
> achieve much the same autotuning with pow2 operations instead of
> divide/mod?
>
>
> -a
> ___
> 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: ACPI errors when booting laptop

[K. Macy]

Have you checked for BIOS updates? The BIOS on recent Skylake laptops
have been a running disaster. At least the Dell XPS laptops had ACPI
errors be fixed by an update.

-M

On Sat, Jul 30, 2016 at 10:43 PM, Ben Woods  wrote:
> Hi everyone,
>
> I get the following ACPI errors in my dmesg when booting my NEC Lavie HZ750
> laptop with FreeBSD 12-current. I have noticed things not functioning
> correct (except suspend/resume not working), but then again I don't really
> know much about ACPI or what I should expect to see. Any ideas what the
> problem is?
>
> Full dmesg is also attached.
>
> acpi0:  on motherboard
> acpi_ec_ecdt_probe: can't get handle
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC._REG] (Node
> 0xf80005494980), AE_NOT_EXIST (20160527/psparse-559)
> acpi0: Power Button (fixed)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: 

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

[K. Macy]

On Wednesday, July 6, 2016, Don Lewis  wrote:

> On  6 Jul, Matthew Macy wrote:
> > As a first step towards managing linux user space in a chrooted
> > /compat/linux, initially for i915 testing with intel gpu tools, later
> > on to get widevine and steam to work I'm trying to get apt to work.
> > I've fixed a number of issues to date in pseudofs/linprocfs but now
> > I'm running in to a bug caused by differences in SIGCHLD handling
> > between Linux and FreeBSD. The situation is that apt will spawn dpkg
> > and wait on a pipe read. On Linux when dpkg exits the  SIGCHLD to apt
> > causes a short read on the pipe which lets apt then continue. On
> > FreeBSD a SIGCHLD is silently ignored. I've even experimented with
> > doing a kill -20  to no effect.
> >
> > It would be easy enough to check sysvec against linux in pipe_read and
> > break out of the loop when it's awakened from msleep (assuming there
> > aren't deeper issues with signal propagation for anything other than
> > SIGINT/SIGKILL) and then do a short read. However, I'm assuming that
> > anyone who has worked in this area probably has a cleaner solution.
>
> It shoulds like SA_RESTART is set in sa_flags for SIGCHLD but shouldn't
> be in this case.



Good point.

Thinking more about it, this seems like a bug in FreeBSD. Not a valid
behavioral difference.

-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: panic with tcp timers

[K. Macy]

On Tue, Jun 28, 2016 at 10:51 AM, Matthew Macy  wrote:
> You guys should really look at Samy Bahra's epoch based reclamation. I solved 
> a similar problem in drm/linuxkpi using it.

The point being that this is a bug in the TCP life cycle handling
_not_ in callouts. Churning the callout interface is not the best /
only solution.
-M


>
>   On Tue, 28 Jun 2016 02:58:56 -0700 Julien Charbon  
> wrote 
>  >
>  >  Hi Randall,
>  >
>  > On 6/25/16 4:41 PM, Randall Stewart via freebsd-net wrote:
>  > > Ok
>  > >
>  > > Lets try this again with my source changed to my @freebsd.net :-)
>  > >
>  > > Now I am also attaching a patch for you Gleb, this will take some poking 
> to
>  > > get in to your NF-head since it incorporates some changes we made 
> earlier.
>  > >
>  > > I think this will fix the problem.. i.e. dealing with two locks in the 
> callout system (which it was
>  > > never meant to have done)..
>  > >
>  > > Note we probably can move the code to use the callout lock init now.. 
> but lets see if this works
>  > > on your setup on c096 and if so we can think about doing that.
>  >
>  >  Thanks for proposing a patch.  I believe your patch will work with
>  > callout lock init, but not without:  You still have a use-after-free
>  > issue on the tcpcb without callout lock init.
>  >
>  >  The case being subtle as usual, let me try to describe that could happen:
>  >
>  >  With your patch we have:
>  >
>  > void
>  > tcp_timer_keep(void *xtp)
>  > {
>  > struct tcpcb *tp = xtp;
>  > struct tcptemp *t_template;
>  > struct inpcb *inp;
>  > CURVNET_SET(tp->t_vnet);
>  > #ifdef TCPDEBUG
>  > int ostate;
>  >
>  > ostate = tp->t_state;
>  > #endif
>  > inp = tp->t_inpcb;
>  > KASSERT(inp != NULL, ("%s: tp %p tp->t_inpcb == NULL", __func__,
>  > tp));
>  > INP_WLOCK(inp);
>  > if (callout_pending(>t_timers->tt_keep) ### Use after free
>  > of tp here
>  > !callout_active(>t_timers->tt_keep)) {
>  > INP_WUNLOCK(inp);
>  > CURVNET_RESTORE();
>  > return;
>  > }
>  > ...
>  >
>  >  The use-after-free scenario:
>  >
>  > [CPU 1] the callout fires, tcp_timer_keep entered
>  > [CPU 1] blocks on INP_WLOCK(inp);
>  > [CPU 2] schedules tcp_timer_keep with callout_reset()
>  > [CPU 2] tcp_discardcb called
>  > [CPU 2] tcp_timer_keep callout successfully canceled
>  > [CPU 2] tcpcb freed
>  > [CPU 1] unblocks, the tcpcb is used
>  >
>  >  Then the tcpcb will used just after being freed...  Might also crash or
>  > not depending in the case.
>  >
>  >  Extra notes:
>  >
>  >  o The invariant I see here is:  The "callout successfully canceled"
>  > step should never happen when "the callout is currently being executed".
>  >
>  >  o Solutions I see to enforce this invariant:
>  >
>  >  - First solution:  Use callout lock init with inp lock, your patch
>  > seems to permit that now.
>  >
>  >  - Second solution:  Change callout_async_drain() behavior:  It can
>  > return 0 (fail) when the callout is currently being executed (no matter
>  > what).
>  >
>  >  - Third solution:  Don't trust callout_async_drain(callout) return
>  > value of 1 (success) if the previous call of callout_reset(callout)
>  > returned 0 (fail).  That was the exact purpose of r284261 change, but
>  > this solution is also step backward in modernization of TCP
>  > timers/callout...
>  >
>  > 
> https://svnweb.freebsd.org/base/stable/10/sys/netinet/tcp_timer.c?r1=284261=284260=284261
>  >
>  >  Hopefully my description is clear enough...
>  >
>  > --
>  > Julien
>  >
>  >
>
> ___
> 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"

Latest freebsd installer memstick image fails to mountroot by default on Thinkpad e565

[K. Macy]

Just to clarify I'm talking about BSD install images, not my i915 tester.

On Friday, June 3, 2016, Matthew Macy  wrote:

>
> In order to boot USB reliably on recent laptop hardware (both my thinkpad
> and XPS13 need this) you need to add the following to the installer images
> loader.conf:
>
> kern.cam.boot_delay="1"
> kern.cam.scsi_delay="3000"
>
> ___
> 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: repeatable panic on pageout with 945GM

[K. Macy]

It looks like it might be trying to remove mappings for a page that doesn't
have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem
release mmap. Compile the kernel and driver with -O0 and look at the page.
It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two.

-M

On Thursday, June 2, 2016, Michael Butler 
wrote:

> On 05/23/16 21:10, Michael Butler wrote:
> > On 05/22/16 09:58, Michael Butler wrote:
> >> With KDE and compositing enabled, I randomly get the following:
> >>
> >> (kgdb) info stack
> >> #0  doadump (textdump=) at pcpu.h:221
> >> #1  0x8064e98e in kern_reboot (howto=260) at
> >> /usr/src/sys/kern/kern_shutdown.c:366
> >> #2  0x8064eea1 in vpanic (fmt=, ap= >> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
> >> #3  0x8064ed13 in panic (fmt=0x0) at
> >> /usr/src/sys/kern/kern_shutdown.c:690
> >> #4  0x809d18ed in vm_fault_hold (map=,
> >> vaddr=, fault_type=,
> >> fault_flags=, m_hold=) at
> >> /usr/src/sys/vm/vm_fault.c:327
> >> #5  0x809cf548 in vm_fault (map=0xf8000200, vaddr= >> optimized out>, fault_type=1 '\001', fault_flags=)
> >> at /usr/src/sys/vm/vm_fault.c:273
> >> #6  0x80a1849f in trap_pfault (frame=,
> >> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741
> >> #7  0x80a17b30 in trap (frame=0xfe00dbec5830) at
> >> /usr/src/sys/amd64/amd64/trap.c:442
> >> #8  0x809fd5a1 in calltrap () at
> >> /usr/src/sys/amd64/amd64/exception.S:236
> >> #9  0x80a0a3bb in pmap_remove_all (m=) at
> >> /usr/src/sys/amd64/amd64/pmap.c:3950
> >> #10 0x809c0c57 in cdev_pager_free_page (object= >> out>, m=0xfe0001e410d0) at /usr/src/sys/vm/device_pager.c:214
> >> #11 0x816aff33 in i915_gem_release_mmap (obj=
> [ .. snip .. ]
>
> Even with the most recent mesa update - something is upsetting this
> device :-(
>
> (kgdb) bt
> #0  doadump (textdump=) at pcpu.h:221
> #1  0x805cfe9a in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:366
> #2  0x805d03e1 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
> #3  0x805d0253 in panic (fmt=0x0) at
> /usr/src/sys/kern/kern_shutdown.c:690
> #4  0x8096c56e in vm_fault_hold (map=,
> vaddr=, fault_type=,
> fault_flags=, m_hold=) at
> /usr/src/sys/vm/vm_fault.c:327
> #5  0x80969f78 in vm_fault (map=0xf8000200, vaddr= optimized out>, fault_type=1 '\001', fault_flags=)
> at /usr/src/sys/vm/vm_fault.c:273
> #6  0x809b556f in trap_pfault (frame=,
> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741
> #7  0x809b4c00 in trap (frame=0xfe00dc0ef310) at
> /usr/src/sys/amd64/amd64/trap.c:442
> #8  0x80999d81 in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:236
> #9  0x809a6d4e in pmap_remove_all (m=) at
> /usr/src/sys/amd64/amd64/pmap.c:3950
> #10 0x8095ab7b in cdev_pager_free_page (object= out>, m=0xfe0001e2c270) at /usr/src/sys/vm/device_pager.c:214
> #11 0x816aff33 in i915_gem_release_mmap (obj= out>) at
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691
> #12 0x816b15ba in i915_gem_object_get_fence (obj= optimized out>) at
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:105
> #13 0x816b7f2e in i915_gem_execbuffer_reserve_object
> (obj=0xf8009858f200, ring=)
> at
>
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:368
> #14 0x816b7d8f in i915_gem_execbuffer_reserve () at
>
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:491
> #15 0x816b6bb5 in i915_gem_do_execbuffer () at
>
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1036
> #16 0x816b7ad1 in i915_gem_execbuffer2 (dev=0xf800059e9000,
> data=0xfe00dc0efa20, file=0xf80005db4a00)
> at
>
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1273
> #17 0x812c7eae in drm_ioctl (kdev=,
> cmd=, data=0xfe00dc0efa20 "", flags= optimized out>,
> p=) at
> /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:467
> #18 0x804c721f in devfs_ioctl_f (fp=0xf800afba1550,
> com=2151703657, data=0xfe00dc0efa20, cred=0xf800af2dc800,
> td=0xf80005e2ca00)
> at /usr/src/sys/fs/devfs/devfs_vnops.c:815
> #19 0x806377fe in kern_ioctl (td=,
> fd=, com=,
> data=0xfe00dc0efa20 "") at file.h:327
> #20 0x80637481 in sys_ioctl (td=0xf80005e2ca00,
> uap=0xfe00dc0efb80) at /usr/src/sys/kern/sys_generic.c:743
> #21 0x809b5e79 in amd64_syscall (td=,
> traced=0) at subr_syscall.c:135
> #22 0x8099a06b in Xfast_syscall () at
> /usr/src/sys/amd64/amd64/exception.S:396
> #23 0x0008024f57ca in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
>
> 

Re: dmesg: can't reuse a leaf (ixl_rx_miss_bufs)!

[K. Macy]

It will be fixed in the next iflib update.

On Thursday, May 26, 2016, Juan Ramón Molina Menor  wrote:

> Hi!
>
> In three different machines running HEAD I have this message in the very
> first lines of the dmesg output:
>
> can't reuse a leaf (ixl_rx_miss_bufs)!
>
> I don’t remember seeing it before and I have not configured any ixl
> device. It seems harmless, but I wonder if it’s a sign of a bug somewhere.
>
> Cheers,
> Juan
> ___
> 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: pkg chroot issues?

[K. Macy]

On Sunday, May 22, 2016, Tim Kientzle  wrote:

> Crochet has some experimental hooks to install packages onto the system
> being built, but this seems to be hitting problems due to limitations in
> 'pkg -c'.  In particular, it seems that pkg performs the chroot before it
> does any network lookups.  This is a problem if the chroot is not a
> complete system environment (which it cannot be when you're building an
> image for another system).
>
> There's some further discussion on github:
>
>   https://github.com/freebsd/crochet/issues/141
>
> Any suggestions?
>
> Cheers,
>
> Tim
>
>
Just like you need to mount devfs you should have a resolv.conf in your
chroot first. Just copy it over before running pkg. This works for me in my
image creation script.


-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: em(4) broken in HEAD?

[K. Macy]

Much to my chagrin, this too is my fault. Please apply the attached
patch if it hasn't yet been committed to -CURRENT.

On Fri, May 20, 2016 at 11:28 PM, Joel Dahl <j...@vnode.se> wrote:
> On Fri, May 20, 2016 at 07:32:30PM -0700, K. Macy wrote:
>> I'm seeing watchdog resets on em(4) in my VMWare as of the last day or two.
>>
>> >
>> >
>> > I don't use ipfw, aliases or anything other than stock networking. I
>> > was unable to copy a large image off the VM without getting an
>> > unending stream of watchdog resets which could only be fixed by a
>> > reboot. Fortunately a subsequent IFC fixed it  as of ~15 hours ago.
>> >
>>
>> I take that back. It's still happening.
>
> OK - good to know. I'm going to be travelling for a few days so I won't have
> time to do a binary search to find the commit that broke it.
>
> --
> Joel
diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c
index 2ef5a3c..00cb46f 100644
--- a/sys/kern/subr_taskqueue.c
+++ b/sys/kern/subr_taskqueue.c
@@ -68,7 +68,6 @@ struct taskqueue {
 	TAILQ_HEAD(, taskqueue_busy) tq_active;
 	struct mtx		tq_mutex;
 	struct thread		**tq_threads;
-	struct thread		*tq_curthread;
 	int			tq_tcount;
 	int			tq_spin;
 	int			tq_flags;
@@ -222,7 +221,7 @@ taskqueue_enqueue_locked(struct taskqueue *queue, struct task *task)
 	 * Count multiple enqueues.
 	 */
 	if (task->ta_pending) {
-		if (task->ta_pending < UCHAR_MAX)
+		if (task->ta_pending < USHRT_MAX)
 			task->ta_pending++;
 		TQ_UNLOCK(queue);
 		return (0);
@@ -465,8 +464,7 @@ taskqueue_run_locked(struct taskqueue *queue)
 
 		TQ_LOCK(queue);
 		tb.tb_running = NULL;
-		if ((task->ta_flags & TASK_SKIP_WAKEUP) == 0)
-			wakeup(task);
+		wakeup(task);
 
 		TAILQ_REMOVE(>tq_active, , tb_link);
 		tb_first = TAILQ_FIRST(>tq_active);
@@ -481,9 +479,7 @@ taskqueue_run(struct taskqueue *queue)
 {
 
 	TQ_LOCK(queue);
-	queue->tq_curthread = curthread;
 	taskqueue_run_locked(queue);
-	queue->tq_curthread = NULL;
 	TQ_UNLOCK(queue);
 }
 
@@ -716,7 +712,6 @@ taskqueue_thread_loop(void *arg)
 	tq = *tqp;
 	taskqueue_run_callback(tq, TASKQUEUE_CALLBACK_TYPE_INIT);
 	TQ_LOCK(tq);
-	tq->tq_curthread = curthread;
 	while ((tq->tq_flags & TQ_FLAGS_ACTIVE) != 0) {
 		/* XXX ? */
 		taskqueue_run_locked(tq);
@@ -730,7 +725,6 @@ taskqueue_thread_loop(void *arg)
 		TQ_SLEEP(tq, tq, >tq_mutex, 0, "-", 0);
 	}
 	taskqueue_run_locked(tq);
-	tq->tq_curthread = NULL;
 	/*
 	 * This thread is on its way out, so just drop the lock temporarily
 	 * in order to call the shutdown callback.  This allows the callback
@@ -754,8 +748,7 @@ taskqueue_thread_enqueue(void *context)
 
 	tqp = context;
 	tq = *tqp;
-	if (tq->tq_curthread != curthread)
-		wakeup_one(tq);
+	wakeup_one(tq);
 }
 
 TASKQUEUE_DEFINE(swi, taskqueue_swi_enqueue, NULL,
diff --git a/sys/sys/_task.h b/sys/sys/_task.h
index 4cfa171..ce89781 100644
--- a/sys/sys/_task.h
+++ b/sys/sys/_task.h
@@ -45,8 +45,7 @@ typedef void task_fn_t(void *context, int pending);
 
 struct task {
 	STAILQ_ENTRY(task) ta_link;	/* (q) link for queue */
-	uint8_t	ta_pending;		/* (q) count times queued */
-	uint8_t	ta_flags;		/* (q) flags */
+	uint16_t ta_pending;		/* (q) count times queued */
 	u_short	ta_priority;		/* (c) Priority */
 	task_fn_t *ta_func;		/* (c) task handler */
 	void	*ta_context;		/* (c) argument for handler */
diff --git a/sys/sys/taskqueue.h b/sys/sys/taskqueue.h
index bc01088..4c4044f 100644
--- a/sys/sys/taskqueue.h
+++ b/sys/sys/taskqueue.h
@@ -98,7 +98,6 @@ void	taskqueue_set_callback(struct taskqueue *queue,
 
 #define TASK_INITIALIZER(priority, func, context)	\
 	{ .ta_pending = 0,\
-	  .ta_flags = 0,\
 	  .ta_priority = (priority),			\
 	  .ta_func = (func),\
 	  .ta_context = (context) }
@@ -114,7 +113,6 @@ void	taskqueue_thread_enqueue(void *context);
  */
 #define TASK_INIT(task, priority, func, context) do {	\
 	(task)->ta_pending = 0;\
-	(task)->ta_flags = 0;\
 	(task)->ta_priority = (priority);		\
 	(task)->ta_func = (func);			\
 	(task)->ta_context = (context);			\
@@ -224,7 +222,6 @@ int	taskqgroup_adjust(struct taskqgroup *qgroup, int cnt, int stride);
 
 #define GTASK_INIT(task, priority, func, context) do {	\
 	(task)->ta_pending = 0;\
-	(task)->ta_flags = TASK_SKIP_WAKEUP;		\
 	(task)->ta_priority = (priority);		\
 	(task)->ta_func = (func);			\
 	(task)->ta_context = (context);			\
___
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: em(4) broken in HEAD?

[K. Macy]

I'm seeing watchdog resets on em(4) in my VMWare as of the last day or two.

>
>
> I don't use ipfw, aliases or anything other than stock networking. I
> was unable to copy a large image off the VM without getting an
> unending stream of watchdog resets which could only be fixed by a
> reboot. Fortunately a subsequent IFC fixed it  as of ~15 hours ago.
>

I take that back. It's still happening. That's too bad I had been
hoping to announce the Skylake i915 CFT tonight.
-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"

Re: em(4) broken in HEAD?

[K. Macy]

On Fri, May 20, 2016 at 11:33 AM, Johan Hendriks  wrote:
> H
>
> Op vrijdag 20 mei 2016 heeft Joel Dahl  het volgende
> geschreven:
>
>> On Fri, May 20, 2016 at 01:59:46PM +0200, O. Hartmann wrote:
>> > On Fri, 20 May 2016 13:55:50 +0200
>> > Joel Dahl > wrote:
>> >
>> > > Hi,
>> > >
>> > > I've just rebuilt CURRENT on a VMware virtual machine and it's now
>> > > running r300276. After reboot, I ssh'ed to the machine but my ssh
>> > > session hanged after ~10 seconds or so. The console started spitting
>> > > out "em0: Watchdog timeout - resetting" messages at the same time.
>> > > Basically no networking works.
>> > >
>> > > It's the same thing after every reboot. Networking works for a few
>> > > seconds, just long enough for you to run a couple of commands over
>> > > ssh. Then it breaks.
>> > >
>> > > My previous build on this machine was from about one week ago. It
>> > > works like it should.
>> > >
>> >
>> > Do you use by any means IPFW ?
>>
>> Nope.
>>


I don't use ipfw, aliases or anything other than stock networking. I
was unable to copy a large image off the VM without getting an
unending stream of watchdog resets which could only be fixed by a
reboot. Fortunately a subsequent IFC fixed it  as of ~15 hours ago.

-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"

boot broken on VMWare somewhere between r300069 and r300176

[K. Macy]

I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
did an IFC to r300176 and boot will hang right ater printing out
"setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
shell as hanging in piperead. Diffing between those two revisions I
don't see any obvious offenders so I'm hoping that individuals who
have committed in the last 24 hours will have some idea of their
changes having such an impact.

Thanks in advance.

-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"

Re: i915kms broken at some commit between r296485 and r297692?

[K. Macy]

I think hps@ has a fix for this that uses a sequency of DELAY()s. The
problem is that in freebsd, attach runs before the scheduler is
running. Consequently, code using sleep primitives tends to hang
because ticks never advance. The scheduler / threading starts much
earlier on linux.

-M

On Tue, May 10, 2016 at 4:30 PM, Sergey Manucharian  wrote:
> I was running FreeBSD 11.0-CURRENT r292595 on ThinkPad T430 (i7-3520M,
> Intel video 4000). A couple of days ago I tried to update to a fresher
> version.
>
> I've built the head revision and then a couple of more:
> something has been broken somewhere between r296485 and r297692,
> I suspect namely i915kms - it won't boot: at the boot screen I see that
> all modules are loaded, then after "Booting..." message at the bottom
> screen turns black in 1-2 seconds of booting process, it seems to be the
> point when it regularly switches to native resolution (with KMS).
>
> Can anybody shed light on this? What can I check to get more details?
>
> Regularly I update to the revisions used to build snapshots at:
>
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/
>
> assuming that those revisions have less issues. So tried a few, none
> worked for me after a certain revision from the range I mentioned above.
> Now I'm on r296485.
>
> Thanks for advices!
>
> Sergey
>
> ___
> 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: Intel i7-6700T aka Skylake Support

[K. Macy]

On Sat, Apr 30, 2016 at 4:45 PM, Pete Wright  wrote:
> I recently acquired a Lenovo M900 Tiny desktop system which comes with an
> intel i7-6700T Skylate CPU and Intel HD 530 graphics processor.  I am
> successfully running 11-CURRENT via EFI but have three devices which I am
> unable to fully utilize on current as of r298768:
>
> 1) On board Wireless reported as 'Intel Wireless 8260'
>
> 2) Audio reported as 'Sunrise Point-H HD Audio'
>
> 3) Accelerated graphics.

1 & 2 I can't help you with, although 2 may become easier as a side
effect of my current work.

I've imported DRM and i915 from 4.6-rc5 and am extending the linuxkpi
to support both with minimal changes with respect to upstream. This
update will provide support up through the unreleased Kaby Lake
processors.

https://github.com/iotamudelta/freebsd-base-graphics/tree/drm-next-4.6

Left to my own devices I anticipate having something out for test in
no sooner than 2 weeks or so, as this is just a side project. I'd
welcome assistance plugging the holes in linuxkpi and subsequent
debugging.

I can frequently be found on Efnet on #freebsd-xorg.


Cheers.

-M


> I am using a USB dongle to workaround the wireless issue, and am running X
> using the VGA driver I believe.  The i915 driver does seem to work, but I do
> not believe the GPU is enabled by Xorg.  I am unable to get any audio out of
> the intel HD Audio card.
>
> If there is anything I can do as a user on my end to help get this hardware
> fully supported I'd be keen to help.  It's a nice desktop system which I'm
> hoping to use for the foreseeable future as my main workstation.
>
> The dmesg is available here:
> http://dmesgd.nycbug.org/index.cgi?do=view=2961
>
> and here is the output of pciconf:
> [pwright@boomer ~]$ pciconf -lv
> hostb0@pci0:0:0:0:class=0x06 card=0x30d017aa chip=0x191f8086
> rev=0x07 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Skylake Host Bridge/DRAM Registers'
> class  = bridge
> subclass   = HOST-PCI
> vgapci0@pci0:0:2:0:class=0x03 card=0x30d017aa chip=0x19128086
> rev=0x06 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'HD Graphics 530'
> class  = display
> subclass   = VGA
> xhci0@pci0:0:20:0:class=0x0c0330 card=0x30d017aa chip=0xa12f8086
> rev=0x31 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Sunrise Point-H USB 3.0 xHCI Controller'
> class  = serial bus
> subclass   = USB
> none0@pci0:0:22:0:class=0x078000 card=0x30d017aa chip=0xa13a8086
> rev=0x31 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Sunrise Point-H CSME HECI'
> class  = simple comms
> ahci0@pci0:0:23:0:class=0x010601 card=0x30d017aa chip=0xa1028086
> rev=0x31 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Sunrise Point-H SATA controller [AHCI mode]'
> class  = mass storage
> subclass   = SATA
> pcib1@pci0:0:28:0:class=0x060400 card=0x30d017aa chip=0xa1168086
> rev=0xf1 hdr=0x01
> vendor = 'Intel Corporation'
> device = 'Sunrise Point-H PCI Express Root Port'
> class  = bridge
> subclass   = PCI-PCI
> isab0@pci0:0:31:0:class=0x060100 card=0x30d017aa chip=0xa1468086
> rev=0x31 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Sunrise Point-H LPC Controller'
> class  = bridge
> subclass   = PCI-ISA
> none1@pci0:0:31:2:class=0x058000 card=0x30d017aa chip=0xa1218086
> rev=0x31 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Sunrise Point-H PMC'
> class  = memory
> hdac0@pci0:0:31:3:class=0x040300 card=0x30d017aa chip=0xa1708086
> rev=0x31 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Sunrise Point-H HD Audio'
> class  = multimedia
> subclass   = HDA
> none2@pci0:0:31:4:class=0x0c0500 card=0x30d017aa chip=0xa1238086
> rev=0x31 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Sunrise Point-H SMBus'
> class  = serial bus
> subclass   = SMBus
> em0@pci0:0:31:6:class=0x02 card=0x30d017aa chip=0x15b78086 rev=0x31
> hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Ethernet Connection (2) I219-LM'
> class  = network
> subclass   = ethernet
> none3@pci0:1:0:0:class=0x028000 card=0x00108086 chip=0x24f38086 rev=0x3a
> hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Wireless 8260'
> class  = network
>
>
> Cheers,
> -pete
>
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
> ___
> 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, 

Re: [CFT] packaging the base system with pkg(8)

[K. Macy]

On Mon, Apr 18, 2016 at 12:14 PM, Glen Barber  wrote:
> On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
>> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov  wrote:
>> >
>> > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
>> > packages?! WHY?! What are reasons and goals to split base in such
>> > enormous number of packages?
>>
>> Just a guess, having done the same thing myself:  it means that updates can 
>> be
>> more targeted.
>>
>
> This is exactly the reason, which has been answered numerous times.

I don't know what the "ideal" number of packages is. 755 does seem
large. However, I see it being like KSE. In hindsight KSE was overly
complicated and M:N threading wasn't the way to go. However, Julian's
work brought native threading to FreeBSD. Something it sorely needed.

Similarly, the packaging of base FreeBSD is something  that has been
desperately needed for a long time but the work to get there was
simply overwhelming. Initially there will very likely be painful
problems, but I'm comfortable that all those involved will course
correct and converge on something that most people will be content
with.

I'm sure there are those with well articulated criteria for a
different decomposition of base, with specifics on how and why. Those
select individuals can contribute meaningfully to this discussion.
Everyone else should just applaud their hard work and get back to
work. There are plenty of bugs that could have been fixed in the time
it would have taken to digest this whole thread.

-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"

Re: [CFT] packaging the base system with pkg(8)

[K. Macy]

On Tuesday, April 19, 2016, Adrian Chadd  wrote:

> It's cool. I have positive and negative reactions, and I'm totally
> happy to let people try it out at a larger scale and learn from
> mistakes.
>
> Because, honestly - fuck it, we've been behind for too long. We need
> more mature tools and knowledge with this.
>
> The irony of course is the people rolling out docker are doing it
> after finding that OS packages aren't the best granularity, but
> "whatever the package systems in the software stack we're using, and
> then tar the whole mess up and distribute it" method. Kinda like
> FreeBSD
>
>
>
Those are different, semi-orthogonal problems. Please restate your last
paragraph. I can't interpret your intent.
-M


>
> -adrian
> ___
> 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: [CFT] packaging the base system with pkg(8)

[K. Macy]

On Tuesday, April 19, 2016, Poul-Henning Kamp  wrote:

> As far as I know, nobody is taking the source code or the Makefiles
> away, so if somebody doesn't like the system being distributed with
> pkg, they can very well roll their own.
>
> It's nice to see the level of enthusiasm the FreeBSD project can
> muster, I just wish it wasn't always enthusiasm for stopping progress.



+1



>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> 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: CURRENT slow and shaky network stability

[K. Macy]

Sorry meant inpcb and autocorrect "fixed" it.

On Saturday, March 26, 2016, O. Hartmann <ohart...@zedat.fu-berlin.de>
wrote:

> Am Fri, 25 Mar 2016 13:31:31 -0700
> "K. Macy" <km...@freebsd.org <javascript:;>> schrieb:
>
> > Does this pre or postage input changes?
>
> ???
>
> First of all, and the most visible fact is, that the ssh connection with
> high terminal
> i/o (compiling world, poudriere bulk ...) receives very often broken pipe.
> The "native"
> console of the systems (non UEFI, but drm2/i915kms loaded, iGPU of
> IvyBridge XEON) in
> question is like "glue" - responding time shifted. This is on all CURRENT
> systems.
>
> >
> > On Friday, March 25, 2016, O. Hartmann <ohart...@zedat.fu-berlin.de
> <javascript:;>> wrote:
> >
> > > Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD
> > > 11.0-CURRENT #9
> > > r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky
> and
> > > like "glue": it
> > > is slow with X11, sometimes ssh connections even nearby hosts on the
> same
> > > net not under
> > > load have some time to respond to keys in xterm or on console (vt()) ~
> 1 -
> > > 3 seconds and
> > > I receive very often "broken pipe" to ssh connections to a host
> nearby. I
> > > realized this
> > > strange behaviour on a couple of systems a maintain running most recent
> > > CURRENT.
> > >
> > > I also realize a high usage of swap on a 8GB RAM, 2 core box having two
> > > ZFS volumes (one
> > > 3TB HD and one 4 TB HAD with ZFS). Using Firefox on X11 (nVidia
> > > 364.12/355.11 driver, I
> > > checked on both) and running desktop only (windowmaker) brings the
> system
> > > toward using 12
> > > or sometimes several hundreds of megabytes of swap - and I do not see
> what
> > > is using so
> > > much space.
> > >
> > > Does anyone also realize  this phenomenon?
> > >
> > > Regards,
> > >
> > > oh
> > > ___
> > > freebsd-current@freebsd.org <javascript:;> <javascript:;> mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org <javascript:;>
> > > <javascript:;>"
> > >
> > ___
> > freebsd-current@freebsd.org <javascript:;> mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org <javascript:;>"
>
>
___
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: CURRENT slow and shaky network stability

[K. Macy]

Does this pre or postage input changes?

On Friday, March 25, 2016, O. Hartmann  wrote:

> Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD
> 11.0-CURRENT #9
> r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky and
> like "glue": it
> is slow with X11, sometimes ssh connections even nearby hosts on the same
> net not under
> load have some time to respond to keys in xterm or on console (vt()) ~ 1 -
> 3 seconds and
> I receive very often "broken pipe" to ssh connections to a host nearby. I
> realized this
> strange behaviour on a couple of systems a maintain running most recent
> CURRENT.
>
> I also realize a high usage of swap on a 8GB RAM, 2 core box having two
> ZFS volumes (one
> 3TB HD and one 4 TB HAD with ZFS). Using Firefox on X11 (nVidia
> 364.12/355.11 driver, I
> checked on both) and running desktop only (windowmaker) brings the system
> toward using 12
> or sometimes several hundreds of megabytes of swap - and I do not see what
> is using so
> much space.
>
> Does anyone also realize  this phenomenon?
>
> Regards,
>
> oh
> ___
> 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: Instant panic while trying run ports-mgmt/poudriere

[K. Macy]

Is this still happening?
On Jul 15, 2015 1:41 PM, Pawel Pekala pa...@freebsd.org wrote:

 Hi John-Mark,

 On 2015-07-15 11:05 -0700, John-Mark Gurney j...@funkthat.com wrote:
 Please repost the entire panic message, and the back trace w/o X
 running...  Also, if you could share the core and kernel w/ me (you can
 email me directly if you'd like), that'd help.

 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 1; apic id = 01
 instruction pointer = 0x20:0x809338c0
 stack pointer   = 0x28:0xfe046c818a00
 frame pointer   = 0x28:0xfe046c818a50
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 1491 (sh)

 Reading symbols from /boot/kernel/zfs.ko.symbols...done.
 Loaded symbols for /boot/kernel/zfs.ko.symbols
 Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
 Loaded symbols for /boot/kernel/opensolaris.ko.symbols
 Reading symbols from /boot/kernel/amdtemp.ko.symbols...done.
 Loaded symbols for /boot/kernel/amdtemp.ko.symbols
 Reading symbols from /boot/modules/cuse4bsd.ko...done.
 Loaded symbols for /boot/modules/cuse4bsd.ko
 Reading symbols from /boot/kernel/fuse.ko.symbols...done.
 Loaded symbols for /boot/kernel/fuse.ko.symbols
 Reading symbols from /boot/kernel/tmpfs.ko.symbols...done.
 Loaded symbols for /boot/kernel/tmpfs.ko.symbols
 Reading symbols from /boot/kernel/radeonkms.ko.symbols...done.
 Loaded symbols for /boot/kernel/radeonkms.ko.symbols
 Reading symbols from /boot/kernel/iicbb.ko.symbols...done.
 Loaded symbols for /boot/kernel/iicbb.ko.symbols
 Reading symbols from /boot/kernel/iicbus.ko.symbols...done.
 Loaded symbols for /boot/kernel/iicbus.ko.symbols
 Reading symbols from /boot/kernel/iic.ko.symbols...done.
 Loaded symbols for /boot/kernel/iic.ko.symbols
 Reading symbols from /boot/kernel/drm2.ko.symbols...done.
 Loaded symbols for /boot/kernel/drm2.ko.symbols
 Reading symbols from /boot/kernel/radeonkmsfw_BARTS_pfp.ko.symbols...done.
 Loaded symbols for /boot/kernel/radeonkmsfw_BARTS_pfp.ko.symbols
 Reading symbols from /boot/kernel/radeonkmsfw_BARTS_me.ko.symbols...done.
 Loaded symbols for /boot/kernel/radeonkmsfw_BARTS_me.ko.symbols
 Reading symbols from /boot/kernel/radeonkmsfw_BTC_rlc.ko.symbols...done.
 Loaded symbols for /boot/kernel/radeonkmsfw_BTC_rlc.ko.symbols
 Reading symbols from /boot/kernel/radeonkmsfw_BARTS_mc.ko.symbols...done.
 Loaded symbols for /boot/kernel/radeonkmsfw_BARTS_mc.ko.symbols
 Reading symbols from /boot/kernel/fdescfs.ko.symbols...done.
 Loaded symbols for /boot/kernel/fdescfs.ko.symbols
 Reading symbols from /boot/kernel/ums.ko.symbols...done.
 Loaded symbols for /boot/kernel/ums.ko.symbols
 Reading symbols from /boot/kernel/uhid.ko.symbols...done.
 Loaded symbols for /boot/kernel/uhid.ko.symbols
 Reading symbols from /boot/kernel/linux.ko.symbols...done.
 Loaded symbols for /boot/kernel/linux.ko.symbols
 Reading symbols from /boot/kernel/linux_common.ko.symbols...done.
 Loaded symbols for /boot/kernel/linux_common.ko.symbols
 Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
 Loaded symbols for /boot/kernel/nullfs.ko.symbols
 Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
 Loaded symbols for /boot/kernel/linprocfs.ko.symbols
 Reading symbols from /boot/kernel/sem.ko.symbols...done.
 Loaded symbols for /boot/kernel/sem.ko.symbols
 #0  doadump (textdump=0) at pcpu.h:221
 221 pcpu.h: No such file or directory.
 in pcpu.h
 (kgdb) #0  doadump (textdump=0) at pcpu.h:221
 #1  0x8035b45e in db_dump (dummy=value optimized out,
 dummy2=false,
 dummy3=0, dummy4=0x0) at /hdd/src/sys/ddb/db_command.c:533
 #2  0x8035afd1 in db_command (cmd_table=0x0)
 at /hdd/src/sys/ddb/db_command.c:440
 #3  0x8035ac64 in db_command_loop ()
 at /hdd/src/sys/ddb/db_command.c:493
 #4  0x8035d7fb in db_trap (type=value optimized out, code=0)
 at /hdd/src/sys/ddb/db_main.c:251
 #5  0x809b4094 in kdb_trap (type=9, code=0, tf=value optimized
 out)
 at /hdd/src/sys/kern/subr_kdb.c:654
 #6  0x80d9e065 in trap_fatal (frame=0xfe046c818950,
 eva=value optimized out) at /hdd/src/sys/amd64/amd64/trap.c:848
 #7  0x80d9dd33 in trap (frame=value optimized out)
 at /hdd/src/sys/amd64/amd64/trap.c:201
 #8  0x80d7ecb2 in calltrap ()
 at /hdd/src/sys/amd64/amd64/exception.S:235
 #9  0x809338c0 in knote (list=0xf80013ae4408, hint=2147483648,
 lockflags=value optimized out) at /hdd/src/sys/kern/kern_event.c:1920
 #10 0x80938ef1 in exit1 (td=0xf800135c5980,
 rv=value optimized out) at /hdd/src/sys/kern/kern_exit.c:559
 #11 0x809383be in sys_sys_exit (td=0x0, uap=value optimized out)
 at /hdd/src/sys/kern/kern_exit.c:177
 #12 0x80d9e8d2 in amd64_syscall (td=0xf800135c5980, 

Re: GPF on Current kernel

[K. Macy]

That's really disturbing, but could be an artifact of limitations in debug
info fidelity. If curthread is corrupt I would expect things to blow up
almost instantly.

Try enabling memguard for the zone or mtype for the object that has the
corrupt mutex field.

-K
 On Jul 6, 2015 5:48 AM, Larry Rosenman l...@lerctr.org wrote:

 actually, the following are interesting further down:
 #13 0x808af473 in sys_write (td=0xdeadc0dedeadc116,
 uap=value optimized out) at /usr/src/sys/kern/sys_generic.c:398
 #14 0x80b57a6d in amd64_syscall (td=0xf80736fda4c0, traced=0)
 at subr_syscall.c:133

 the td value.

 What would you suggest?  This has become intermittent :(


 On 2015-07-06 00:42, K. Macy wrote:

 The value of the mutex in the stack trace indicates that it's a use after
 free. There are various memory debugging options (memguard, redzone) that
 may help track it down.

 -K
 On Jul 5, 2015 2:37 PM, Larry Rosenman l...@lerctr.org wrote:

  I've gotten a couple of these:

 borg.lerctr.org dumped core - see /var/crash/vmcore.3

 Sun Jul  5 16:32:12 CDT 2015

 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r285159:
 Sun
 Jul  5 09:35:33 CDT 2015 r...@borg.lerctr.org:
 /usr/obj/usr/src/sys/LER
 amd64

 panic: general protection fault

 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you
 are
 welcome to change it and/or distribute copies of it under certain
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for
 details.
 This GDB was configured as amd64-marcel-freebsd...

 Unread portion of the kernel message buffer:


 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 0; apic id = 00
 instruction pointer = 0x20:0x8083a15f
 stack pointer   = 0x28:0xfe100ca1d8a0
 frame pointer   = 0x28:0xfe100ca1d8e0
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 73971 (make)
 trap number = 9
 panic: general protection fault
 cpuid = 0
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
 0xfe100ca1d490
 vpanic() at vpanic+0x189/frame 0xfe100ca1d510
 panic() at panic+0x43/frame 0xfe100ca1d570
 trap_fatal() at trap_fatal+0x355/frame 0xfe100ca1d5d0
 trap() at trap+0x813/frame 0xfe100ca1d7e0
 calltrap() at calltrap+0x8/frame 0xfe100ca1d7e0
 --- trap 0x9, rip = 0x8083a15f, rsp = 0xfe100ca1d8a0, rbp =
 0xfe100ca1d8e0 ---
 __mtx_lock_flags() at __mtx_lock_flags+0x4f/frame 0xfe100ca1d8e0
 doselwakeup() at doselwakeup+0xb5/frame 0xfe100ca1d920
 pipeselwakeup() at pipeselwakeup+0x46/frame 0xfe100ca1d940
 pipe_write() at pipe_write+0x13d2/frame 0xfe100ca1d9f0
 dofilewrite() at dofilewrite+0x8a/frame 0xfe100ca1da40
 kern_writev() at kern_writev+0x68/frame 0xfe100ca1da90
 sys_write() at sys_write+0x63/frame 0xfe100ca1dae0
 amd64_syscall() at amd64_syscall+0x25d/frame 0xfe100ca1dbf0
 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe100ca1dbf0
 --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x45ae8a, rsp =
 0x7fffd328, rbp = 0x7fffd350 ---
 Uptime: 6h39m51s
 Dumping 3186 out of 64460
 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

 Reading symbols from /boot/kernel/zfs.ko.symbols...done.
 Loaded symbols for /boot/kernel/zfs.ko.symbols
 Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
 Loaded symbols for /boot/kernel/opensolaris.ko.symbols
 Reading symbols from /boot/kernel/linux.ko.symbols...done.
 Loaded symbols for /boot/kernel/linux.ko.symbols
 Reading symbols from /boot/kernel/linux_common.ko.symbols...done.
 Loaded symbols for /boot/kernel/linux_common.ko.symbols
 Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
 Loaded symbols for /boot/kernel/if_lagg.ko.symbols
 Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done.
 Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols
 Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done.
 Loaded symbols for /boot/kernel/snd_spicds.ko.symbols
 Reading symbols from /boot/kernel/coretemp.ko.symbols...done.
 Loaded symbols for /boot/kernel/coretemp.ko.symbols
 Reading symbols from /boot/kernel/ichsmb.ko.symbols...done.
 Loaded symbols for /boot/kernel/ichsmb.ko.symbols
 Reading symbols from /boot/kernel/smbus.ko.symbols...done.
 Loaded symbols for /boot/kernel/smbus.ko.symbols
 Reading symbols from /boot/kernel/ichwd.ko.symbols...done.
 Loaded symbols for /boot/kernel/ichwd.ko.symbols
 Reading symbols from /boot/kernel/cpuctl.ko.symbols...done.
 Loaded symbols for /boot/kernel/cpuctl.ko.symbols
 Reading symbols from /boot/kernel/cryptodev.ko.symbols...done.
 Loaded symbols for /boot/kernel

Re: GPF on Current kernel

[K. Macy]

The value of the mutex in the stack trace indicates that it's a use after
free. There are various memory debugging options (memguard, redzone) that
may help track it down.

-K
On Jul 5, 2015 2:37 PM, Larry Rosenman l...@lerctr.org wrote:

 I've gotten a couple of these:

 borg.lerctr.org dumped core - see /var/crash/vmcore.3

 Sun Jul  5 16:32:12 CDT 2015

 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r285159: Sun
 Jul  5 09:35:33 CDT 2015 r...@borg.lerctr.org:/usr/obj/usr/src/sys/LER
 amd64

 panic: general protection fault

 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you
 are
 welcome to change it and/or distribute copies of it under certain
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...

 Unread portion of the kernel message buffer:


 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 0; apic id = 00
 instruction pointer = 0x20:0x8083a15f
 stack pointer   = 0x28:0xfe100ca1d8a0
 frame pointer   = 0x28:0xfe100ca1d8e0
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 73971 (make)
 trap number = 9
 panic: general protection fault
 cpuid = 0
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
 0xfe100ca1d490
 vpanic() at vpanic+0x189/frame 0xfe100ca1d510
 panic() at panic+0x43/frame 0xfe100ca1d570
 trap_fatal() at trap_fatal+0x355/frame 0xfe100ca1d5d0
 trap() at trap+0x813/frame 0xfe100ca1d7e0
 calltrap() at calltrap+0x8/frame 0xfe100ca1d7e0
 --- trap 0x9, rip = 0x8083a15f, rsp = 0xfe100ca1d8a0, rbp =
 0xfe100ca1d8e0 ---
 __mtx_lock_flags() at __mtx_lock_flags+0x4f/frame 0xfe100ca1d8e0
 doselwakeup() at doselwakeup+0xb5/frame 0xfe100ca1d920
 pipeselwakeup() at pipeselwakeup+0x46/frame 0xfe100ca1d940
 pipe_write() at pipe_write+0x13d2/frame 0xfe100ca1d9f0
 dofilewrite() at dofilewrite+0x8a/frame 0xfe100ca1da40
 kern_writev() at kern_writev+0x68/frame 0xfe100ca1da90
 sys_write() at sys_write+0x63/frame 0xfe100ca1dae0
 amd64_syscall() at amd64_syscall+0x25d/frame 0xfe100ca1dbf0
 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe100ca1dbf0
 --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x45ae8a, rsp =
 0x7fffd328, rbp = 0x7fffd350 ---
 Uptime: 6h39m51s
 Dumping 3186 out of 64460
 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

 Reading symbols from /boot/kernel/zfs.ko.symbols...done.
 Loaded symbols for /boot/kernel/zfs.ko.symbols
 Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
 Loaded symbols for /boot/kernel/opensolaris.ko.symbols
 Reading symbols from /boot/kernel/linux.ko.symbols...done.
 Loaded symbols for /boot/kernel/linux.ko.symbols
 Reading symbols from /boot/kernel/linux_common.ko.symbols...done.
 Loaded symbols for /boot/kernel/linux_common.ko.symbols
 Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
 Loaded symbols for /boot/kernel/if_lagg.ko.symbols
 Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done.
 Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols
 Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done.
 Loaded symbols for /boot/kernel/snd_spicds.ko.symbols
 Reading symbols from /boot/kernel/coretemp.ko.symbols...done.
 Loaded symbols for /boot/kernel/coretemp.ko.symbols
 Reading symbols from /boot/kernel/ichsmb.ko.symbols...done.
 Loaded symbols for /boot/kernel/ichsmb.ko.symbols
 Reading symbols from /boot/kernel/smbus.ko.symbols...done.
 Loaded symbols for /boot/kernel/smbus.ko.symbols
 Reading symbols from /boot/kernel/ichwd.ko.symbols...done.
 Loaded symbols for /boot/kernel/ichwd.ko.symbols
 Reading symbols from /boot/kernel/cpuctl.ko.symbols...done.
 Loaded symbols for /boot/kernel/cpuctl.ko.symbols
 Reading symbols from /boot/kernel/cryptodev.ko.symbols...done.
 Loaded symbols for /boot/kernel/cryptodev.ko.symbols
 Reading symbols from /boot/kernel/dtraceall.ko.symbols...done.
 Loaded symbols for /boot/kernel/dtraceall.ko.symbols
 Reading symbols from /boot/kernel/profile.ko.symbols...done.
 Loaded symbols for /boot/kernel/profile.ko.symbols
 Reading symbols from /boot/kernel/dtrace.ko.symbols...done.
 Loaded symbols for /boot/kernel/dtrace.ko.symbols
 Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done.
 Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols
 Reading symbols from /boot/kernel/systrace.ko.symbols...done.
 Loaded symbols for /boot/kernel/systrace.ko.symbols
 Reading symbols from /boot/kernel/sdt.ko.symbols...done.
 Loaded symbols for /boot/kernel/sdt.ko.symbols
 Reading symbols from 

Re: Doing zero-copy stuff in drivers, or is vm_fault_quick_hold_pages() enough ?

[K. Macy]

On Mon, Mar 2, 2015 at 12:42 PM, Adrian Chadd adr...@freebsd.org wrote:
 Hi,

 gonzo@ committed a fix (r278615) to the videocore driver for the
 raspberry pi. The fix involved doing an explicit wire of pages that
 were about to be passed down to the hardware to send to the
 videobuffer hardware.

 It turns out that doing vm_fault_quick_hold_pages() wasn't enough -
 the pages weren't being wired, and they may disappear before the
 hardware gets to them.


Then your code is buggy or you've hit a bug in the VM. Holding a page
is a short-term wiring.

Right above vm_page_hold():
/*
 * Keep page from being freed by the page daemon
 * much of the same effect as wiring, except much lower
 * overhead and should be used only for *very* temporary
 * holding (wiring).
 */


 I looked at vmapbuf() and how it uses vm_fault_quick_hold_pages(), but
 I can't find anything that wires the pages down before it hands the
 addresses to the hardware.

 So, am I missing something about how/where that's done?
Yes.

 Thanks,


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

Re: Doing zero-copy stuff in drivers, or is vm_fault_quick_hold_pages() enough ?

[K. Macy]

 Right above vm_page_hold():
 /*
  * Keep page from being freed by the page daemon
  * much of the same effect as wiring, except much lower
  * overhead and should be used only for *very* temporary
  * holding (wiring).
  */

 What's the definition of very temporary holding ? What's the
 behavioural difference?


Long enough to complete a DMA operation versus the lifetime of  an
executing program.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: nagios vs w/uptime

[K. Macy]

 I wonder if that implies that any non-normal exit from a program that
 has been xo'd will result in the loss of output that would not have been
 lost before the xo changes?  That could lead to all kinds of subtle
 failures of existing scripts and apps.

Well, so long as the app doesn't crash in a way that would bypass it
shouldn't registering that with atexit() flush any pending output?

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

Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[K. Macy]

Hi Hans,

It mostly looks fine, but it's a large change and there are some
places in the patch where it isn't clear that the right thing is being
done by looking at the patch alone. Please give us some time to
review.


Thanks.

-K

On Wed, Nov 19, 2014 at 11:02 AM, Hans Petter Selasky h...@selasky.org wrote:
 Hi,

 The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code and the
 patch below completely removes it. I suggest we will now be using the
 m_pkthdr.rsstype also known as M_HASHTYPE to decide if the flowid value
 is valid or not. When the rsstype is set to M_HASHTYPE_NONE the
 m_pkthdr.flowid field is not valid. Else this field contains valid data
 for both TX and RX direction.

 Background:
 ===

 The network drivers today use the rsstype field only when receiving
 traffic. After my patch it is also used when sending traffic, and probably
 we should rename it.

 The reason for using the rsstype field for transmit, is to avoid introducing
 another field in the MBUF's packet header in order to steer outgoing traffic
 into special multiple purpose hardware FIFOs. This new feature should
 coexist with the existing flowid mechanism, and this is achieved by
 introducing a new hash type which I've named M_HASHTYPE_HWRING in my
 patch. This type can be selected by upper layers when generating traffic for
 lower layers, to indicate that the traffic is of a special kind and should
 have special treatment by the hardware, like rate-limiting. Hardware which
 doesn't support M_HASHTYPE_HWRING will send out the packets like usual.


 Patch is available from here:
 =
 http://home.selasky.org:8192/m_flowid_removal.diff


 Comments are appreciated!


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

Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[K. Macy]

On Wed, Nov 19, 2014 at 1:34 PM, Hans Petter Selasky h...@selasky.org wrote:
 On 11/19/14 21:46, K. Macy wrote:

 Hi Hans,

 It mostly looks fine, but it's a large change and there are some
 places in the patch where it isn't clear that the right thing is being
 done by looking at the patch alone. Please give us some time to
 review.


 No problem. Do you think you need more than a week?

(Didn't CC the others last time)

I probably won't. But I speak only for myself. However, I don't think
it's fair to ask you to wait more than two. I've been on the other end
of that too many times myself.

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

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

[K. Macy]

On Wed, Aug 20, 2014 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:

 On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky h...@selasky.org
 wrote:

  Hi Luigi,
 
 
  On 08/20/14 11:32, Luigi Rizzo wrote:
 
  On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky h...@selasky.org
  wrote:
 
   Hi,
 
  A month has passed since the last e-mail on this topic, and in the
  meanwhile some new patches have been created and tested:
 
  Basically the approach has been changed a little bit:
 
  - The creation of hardware transmit rings has been made independent of
  the
  TCP stack. This allows firewall applications to forward traffic into
  hardware transmit rings aswell, and not only native TCP applications.
  This
  should be one more reason to get the feature into the kernel.
  ​...
 
  ​the patch seems to include only part of the generic code (ie no ioctls
  for manipulating the rates, no backend code). Do i miss something ?
 
 
  The IOCTLs for managing the rates are:
 
  SIOCARATECTL, SIOCSRATECTL, SIOCGRATECTL and SIOCDRATECTL
 
  And they go to the if_ioctl callback.​


 ​i really think these new 'advanced' features should go
 through some ethtool-like API, not more ioctls.
 We have a strong need to design and implement such
 an API also to have a uniform mechanism to manipulate
 rss, queues and other NIC features.




There is no ethtool equivalent yet, but exposing them through a sysctl is
definitely the place to start before putting it straight in to ifconfig.
The ifnet API is already a bit of a mess.



 ​...​
 
 
 
  I have a few comments/concerns:
 
  + looks like flowid and txringid are overlapped in scope,
 both will be used (in the backend) to select a specific
 tx queue. I don't have a solution but would like to know
 how do you plan to address this -- does one have priority
 over the other, etc.
 
 
  Not 100% . In some cases the flowID is used differently than the
 txringid,
  though it might be possible to join the two. Would need to investigate
  current users of the flow ID.


 ​in some 10G drivers i have seen, at the driver
 level the flowid is used on the tx path to assign
 packets to a given ​tx queue, generally to improve
 cpu affinity. Of course some applications
 may want a true flow classifier so they do not
 have to re-do the classification multiple times.
 But then, we have a ton of different classifiers
 with the same need -- e.g. ipfw dynamic rules,
 dummynet pipe/queue id, divert ports...
 Pipes are stored in mtags, which are very expensive
 so i do see a point in embedding them in the mbufs,
 it's just that going this path there is no end
 to the list.



The purpose of the flowid was to enforce packet ordering on transmit while
being large enough to store a RSS hash, potentially allowing input
consumers to use it to semi-uniquely label (srcip, srcport, dstip, dstport)
tuples. It seems to that the txringid would be almost entirely redundant.
Why not just let users set the flowid?


 If we can merge the flowID and the txringid into one field, would it be
  acceptable to add an IOCTL to read/write this value for all sockets?


That sounds reasonable - although I have not thought through all the
implications.


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

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

[K. Macy]

 - uint32_t - m_flowid_t is plain gratuitous.  Now we need to include
mbuf.h in more places just to get this definition.  What's the
advantage of this?  style(9) isn't too fond of typedefs either.  Also,
drivers *do* need to know the width of the flowid.  At least lagg(4)
looks at the high bits of the flowid (see flowid_shift in lagg).  How
high it can go depends on the width of the flowid.


 The flowid should be typedef'ed. Else how can you know its type passing
 flowid along function arguments and so on?



I agree with Navdeep. It's usage should be obvious  from context. This just
pollutes the namespace.




 - Interfaces can come and go, routes can change, and so the relationship
between an inpcb and txringid is not stable at all.  What happens when
the outbound route for an inpcb changes?


 This is managed separately by a daemon or such.


No it's not. Currently, unless you're using flowtables, the route and
llentry are looked up for every single outbound packet. Most users are
lightly enough loaded that they don't see the potential 8x reduction in pps
from the added overhead.




 The problem about using the inpcb approach which you are suggesting, is
 that you limit the rate control feature to traffic which is bound by
 sockets. Can your way of doing rate control be useful to non-socket based
 firewall applications, for example?

 You also assume a 1:1 mapping between inpcb and the flowID, right. What
 about M:N mappings, where multiple streams should share the same flowID,
 because it makes more sense?


That doesn't make any sense to me. FlowIDs are not a limited resource like
8-bit ASIDs where clever resource management was required. An M:N mapping
would permit arbitrary interleaving of multiple streams which simply
doesn't seem useful unless there is some critical case where it is a huge
performance win. In general it is adding complexity for a gratuitous
generalization.





 - The in_ratectlreq structure that you propose is inadequate in its
current form.  For example, cxgbe's hardware can do rate limiting on a
per-ring as well as per-connection basis, and it allows for pps,
bandwidth, or min-max limits.  I think this is the critical piece that
we NIC maintainers must agree on before any code hits the core kernel:
how to express a rate-limit policy in a standard way and allow for
hardware assistance opportunistically.  ipfw(4)'s dummynet is probably
interested in this part too, so it's great that Luigi is paying
attention to this thread.


 My in_ratectlreq is a work in progress.


Which means that it probably makes sense to not impinge upon the core
system until it is more refined.



 - The RATECTL ioctls deal with in_ratectlreq so we need to standardize
the ratectlreq structure before these ioctls can be considered generic
ifnet ioctls.  This is the reason cxgbetool (and not ifconfig) has a
private ioctl to frob cxgbe's per-queue rate-limiters.  I did not want
to add ifnet ioctls that in reality were cxgbe only.  Ditto for i2c
ioctls.  Now we have multiple drivers with i2c and melifaro@ is doing
the right thing by promoting these private ioctls to a standard ifnet
ioctl.  Have you considered a private mlxtool as a stop gap measure?


 It might end that we need to create our own tool for this, having vendor
 specific IOCTLs, if we cannot agree how to do this in a general way.



 To summarize my take on all of this: we need a standard ratectlreq
 structure,


 Agree.


  a standard way to associate an inpcb with one,


 Maybe.


Associating it with an inpcb doesn't exclude adding a mechanism for
supporting it in firewalls.

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

Re: fast bcopy...

[K. Macy]

It's highly chipset and processor dependent what works best. Intel now
has non-temporal loads and stores which work much better in some cases
but provide little benefit in others.

-Kip

On Wed, May 2, 2012 at 11:52 PM, Steven Atreju snatr...@googlemail.com wrote:
 Luigi Rizzo wrote:
 2. apparently, bcopy is not the fastest way to copy memory.

 http://now.cs.berkeley.edu/Td/bcopy.html

 Best Regards.

 Steven.
 ___
 freebsd-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

 Because there were leaks, there were 100% panics for IPv6, ... at least on
 the version I had seen in autumn last year.

 There is certainly no one more interested then me on these in, esp. for v6
 where the removal of route caching a long time ago made nd6_nud_hint() a NOP
 with dst and rt being passed down as NULL only, and where we are doing up to
 three route lookups in the output path if no cached rt is passed down along
 from the ULP.

 If there is an updated patch, I'd love to see it.

Ok, I'm following up as this seems to be getting some interest. This
the relevant part of the last mail that I received from you. The final
part having been dedicated to the narrow potential ABI changes that
were to make it in to the release.

From: Bjoern A. Zeeb b...@freebsd.org
Date: Mon, Sep 19, 2011 at 3:19 PM
To: K. Macy km...@freebsd.org
Cc: Robert Watson rwat...@freebsd.org, rysto32 ryst...@gmail.com,
Qing Li qin...@freebsd.org

Sorry it's taking me so long while I was travelling but also now being
back home again.
I would yet have to find a code path through IPv6 that will a) not
panic on INVARIANTS
and b) actually update the inp_lle cache.

Once I stop finding the next hiccup going one step deeper into the
stack (and I made
it to if_ethersubr.c) I'll get to legacy IP and the beef and I'll hope
that all you
all will have reviewed and tested that thoroughly.

Checking whether a similar problem would exist in v4 I however found a possible
lle reference leak in the legacy IP path as well.

There's also a missed place where we do not update the generation counter (even
though kind of pointless place but still to do for completeness).

I am also pondering why we are not always invalidating the ro_lle cache (when we
update the ro_rt entry in the callgraph after tcp_output).  I wonder if we can
provoke strange results say changing the default route from something connected
on interface 1 to interface 2.

...

/bz

--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.

===

The only comment in here which was sufficiently specific to actually
take action on was: pondering why we are not always invalidating the
ro_lle cache (when we update the ro_rt entry in the callgraph after
tcp_output). Which was subsequently addressed by ensuring that the
LLE_VALID flag was actually meaningful by clearing it when the llentry
is removed from the interface's hash table in an unrelated commit
because of weird behaviour observed with the flow.

a) Where is the possible leak in the legacy path?

b) Where were the panics in v6?

In light of the fact that I don't or at least didn't have any means of
testing v6 (I can probably get a testbed set up at iX now) and the
netinet6 specific portions of the patch consist of 4 lines of code
which should really be entrusted to you given that your performance
parity work for v6 has actively being funded, it was clearly a mistake
to tie the fate of the patch as a whole to those narrow bits.

Once I get a response to a) and b) I'll follow up with a patch against
head. I'm sure whatever I had has bitrotted somewhat in the meantime.

Thanks for your help,
Kip
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing qing...@bluecoat.com wrote:

 From previous tests, the difference between flowtable and
routing table was small with a single process (about 5% or 50ns
in the total packet processing time, if i remember well),
but there was a large gain with multiple concurrent processes.


 Yes, that sounds about right when we did the tests a long while ago.


 Removing flowtable increases the cost in ip_output()
 (obviously) but also in ether_output() (because the
 route does not have a lle entry so you need to call
 arpresolve on each packet).


 Yup.


 So in revising the route lookup i believe it would be good
 if we could also get at once most of the info that
 ether_output() is computing again and again.


 Well, the routing table no longer maintains any lle info, so there
 isn't much to copy out the rtentry at the completion of route
 lookup.

 If I understood you correctly, you do believe there is a lot of value
 in Flowtable caching concept, but you are not suggesting we reverting
 back to having the routing table maintain L2 entries, are you ?



One could try a similar conversion of the L2 table to an rmlock
without copy while lock is held.

-Kip


-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

On Tue, Apr 24, 2012 at 5:03 PM, K. Macy km...@freebsd.org wrote:
 On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing qing...@bluecoat.com wrote:

 From previous tests, the difference between flowtable and
routing table was small with a single process (about 5% or 50ns
in the total packet processing time, if i remember well),
but there was a large gain with multiple concurrent processes.


 Yes, that sounds about right when we did the tests a long while ago.


 Removing flowtable increases the cost in ip_output()
 (obviously) but also in ether_output() (because the
 route does not have a lle entry so you need to call
 arpresolve on each packet).


 Yup.


 So in revising the route lookup i believe it would be good
 if we could also get at once most of the info that
 ether_output() is computing again and again.


 Well, the routing table no longer maintains any lle info, so there
 isn't much to copy out the rtentry at the completion of route
 lookup.

 If I understood you correctly, you do believe there is a lot of value
 in Flowtable caching concept, but you are not suggesting we reverting
 back to having the routing table maintain L2 entries, are you ?



 One could try a similar conversion of the L2 table to an rmlock
 without copy while lock is held.

Odd .. *with* copy while lock is held.

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
 On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote:
 
 From previous tests, the difference between flowtable and
 routing table was small with a single process (about 5% or 50ns
 in the total packet processing time, if i remember well),
 but there was a large gain with multiple concurrent processes.
 

 Yes, that sounds about right when we did the tests a long while ago.

 
  Removing flowtable increases the cost in ip_output()
  (obviously) but also in ether_output() (because the
  route does not have a lle entry so you need to call
  arpresolve on each packet).
 

 Yup.

 
  So in revising the route lookup i believe it would be good
  if we could also get at once most of the info that
  ether_output() is computing again and again.
 

 Well, the routing table no longer maintains any lle info, so there
 isn't much to copy out the rtentry at the completion of route
 lookup.

 If I understood you correctly, you do believe there is a lot of value
 in Flowtable caching concept, but you are not suggesting we reverting
 back to having the routing table maintain L2 entries, are you ?

 I see a lot of value in caching in general.

 Especially for a bound socket it seems pointless to lookup the
 route, iface and mac address(es) on every single packet instead of
 caching them. And, routes and MAC addresses are volatile anyways
 so making sure that we do the lookup 1us closer to the actual use
 gives no additional guarantee.

 The frequency with which these info (routes and MAC addresses)
 change clearly influences the mechanism to validate the cache.
 I suppose we have the following options:

 - direct notification: a failure in a direct chain of calls
  can be used to invalidate the info cached in the socket.
  Similarly, some incoming traffic (e.g. TCP RST, FIN,
  ICMP messages) that reach a socket can invalidate the cached values
 - assume a minimum lifetime for the info (i think this is what
  happens in the flowtable) and flush it unconditionally
  every such interval (say 10ms).
 - if some info changes infrequently (e.g. MAC addresses) one could
  put a version number in the cached value and use it to validate
  the cache.

I have a patch that has been sitting around for a long time due to
review cycle latency that caches a pointer to the rtentry (and
llentry) in the the inpcb. Before each use the rtentry is checked
against a generation number in the routing tree that is incremented on
every routing table update.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: pmap and mtx scalability problem

[K. Macy]

Known problem. There is an open disagreement about how to improve the
granularity of locking in pmap.

-Kip

On Tue, Apr 24, 2012 at 9:14 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine 
 and see poor
 scalability of pmap/mtx -- more then 50% cpu spend on system time.

 pmcstat:

 @ CPU_CLK_UNHALTED_CORE [194841 samples]

 42.65%  [83102]    _mtx_lock_sleep @ /boot/kernel/kernel
  40.97%  [34051]     pmap_enter
  100.0%  [34051]      vm_fault_hold
   100.0%  [34051]       trap_pfault
  30.40%  [25262]     vm_page_activate
  100.0%  [25262]      vm_fault_hold
   100.0%  [25262]       trap_pfault
  18.41%  [15300]     vm_pageq_remove
  73.63%  [11266]      vm_page_free_toq
   70.69%  [7964]        vm_object_terminate
   29.31%  [3302]        vm_object_page_remove
  26.37%  [4034]       vm_fault_hold
   100.0%  [4034]        trap_pfault

 make -j 8:

 15.44%  [10740]    _mtx_lock_sleep @ /boot/kernel/kernel
  38.77%  [4164]      pmap_enter
  99.93%  [4161]       vm_fault_hold
   100.0%  [4161]        trap_pfault
  00.07%  [3]          kmem_back
   100.0%  [3]           kmem_malloc
  27.98%  [3005]      vm_page_activate
  100.0%  [3005]       vm_fault_hold
   100.0%  [3005]        trap_pfault
  20.64%  [2217]      vm_pageq_remove
  64.73%  [1435]       vm_page_free_toq
   63.41%  [910]         vm_object_terminate

 make -j 4

 06.86%  [4222]     pagezero @ /boot/kernel/kernel
  98.39%  [4154]      trap_pfault
  100.0%  [4154]       trap
  01.11%  [47]        vm_fault_hold

 ___
 freebsd-performa...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-performance
 To unsubscribe, send any mail to freebsd-performance-unsubscr...@freebsd.org



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: pmap and mtx scalability problem

[K. Macy]

No. I developed a patch from Jeffr that pushed the vm_page_lock array
down in to the machine dependent code, replacing most of the uses of
the single vm_page_queue_lock. However, alc doesn't like the design
and has not proposed an alternative.

-Kip

On Tue, Apr 24, 2012 at 10:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote:

 Known problem. There is an open disagreement about how to improve the
 granularity of locking in pmap.

 split locking to process-specific information and global information?
 use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)?

 sorry for stupidity, if any.



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: pmap and mtx scalability problem

[K. Macy]

It's a bit dated at this point. Nonetheless, when gitorious is able to
give something other than 503 to my search queries I'll post it.

On Tue, Apr 24, 2012 at 10:45 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote:

 No. I developed a patch from Jeffr that pushed the vm_page_lock array
 down in to the machine dependent code, replacing most of the uses of
 the single vm_page_queue_lock. However, alc doesn't like the design
 and has not proposed an alternative.

 can i test this?

 -Kip

 On Tue, Apr 24, 2012 at 10:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
  On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote:
 
  Known problem. There is an open disagreement about how to improve the
  granularity of locking in pmap.
 
  split locking to process-specific information and global information?
  use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)?
 
  sorry for stupidity, if any.



 --
    ?The real damage is done by those millions who want to 'get by.'
 The ordinary men who just want to be left in peace. Those who don?t
 want their little lives disturbed by anything bigger than themselves.
 Those with no sides and no causes. Those who won?t take measure of
 their own strength, for fear of antagonizing their own weakness. Those
 who don?t like to make waves?or enemies.

    Those for whom freedom, honour, truth, and principles are only
 literature. Those who live small, love small, die small. It?s the
 reductionist approach to life: if you keep it small, you?ll keep it
 under control. If you don?t make any noise, the bogeyman won?t find
 you.

    But it?s all an illusion, because they die too, those people who
 roll up their spirits into tiny little balls so as to be safe. Safe?!
 From what? Life is always on the edge of death; narrow streets lead to
 the same place as wide avenues, and a little candle burns itself out
 just like a flaming torch does.

    I choose my own way to burn.?

    Sophie Scholl



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: pmap and mtx scalability problem

[K. Macy]

You can try these. Your mileage *will* vary.


https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_release_8_1_0_page_lock

https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_trunk_page_lock

On Tue, Apr 24, 2012 at 10:51 PM, K. Macy km...@freebsd.org wrote:
 It's a bit dated at this point. Nonetheless, when gitorious is able to
 give something other than 503 to my search queries I'll post it.

 On Tue, Apr 24, 2012 at 10:45 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote:

 No. I developed a patch from Jeffr that pushed the vm_page_lock array
 down in to the machine dependent code, replacing most of the uses of
 the single vm_page_queue_lock. However, alc doesn't like the design
 and has not proposed an alternative.

 can i test this?

 -Kip

 On Tue, Apr 24, 2012 at 10:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru 
 wrote:
  On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote:
 
  Known problem. There is an open disagreement about how to improve the
  granularity of locking in pmap.
 
  split locking to process-specific information and global information?
  use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)?
 
  sorry for stupidity, if any.



 --
    ?The real damage is done by those millions who want to 'get by.'
 The ordinary men who just want to be left in peace. Those who don?t
 want their little lives disturbed by anything bigger than themselves.
 Those with no sides and no causes. Those who won?t take measure of
 their own strength, for fear of antagonizing their own weakness. Those
 who don?t like to make waves?or enemies.

    Those for whom freedom, honour, truth, and principles are only
 literature. Those who live small, love small, die small. It?s the
 reductionist approach to life: if you keep it small, you?ll keep it
 under control. If you don?t make any noise, the bogeyman won?t find
 you.

    But it?s all an illusion, because they die too, those people who
 roll up their spirits into tiny little balls so as to be safe. Safe?!
 From what? Life is always on the edge of death; narrow streets lead to
 the same place as wide avenues, and a little candle burns itself out
 just like a flaming torch does.

    I choose my own way to burn.?

    Sophie Scholl



 --
    “The real damage is done by those millions who want to 'get by.'
 The ordinary men who just want to be left in peace. Those who don’t
 want their little lives disturbed by anything bigger than themselves.
 Those with no sides and no causes. Those who won’t take measure of
 their own strength, for fear of antagonizing their own weakness. Those
 who don’t like to make waves—or enemies.

    Those for whom freedom, honour, truth, and principles are only
 literature. Those who live small, love small, die small. It’s the
 reductionist approach to life: if you keep it small, you’ll keep it
 under control. If you don’t make any noise, the bogeyman won’t find
 you.

    But it’s all an illusion, because they die too, those people who
 roll up their spirits into tiny little balls so as to be safe. Safe?!
 From what? Life is always on the edge of death; narrow streets lead to
 the same place as wide avenues, and a little candle burns itself out
 just like a flaming torch does.

    I choose my own way to burn.”

    Sophie Scholl



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

Most of these issues are well known. Addressing the bottlenecks is
simply time consuming due to the fact that any bugs introduced during
development potentially impact many users.

-Kip
On Sun, Apr 22, 2012 at 4:14 AM, Adrian Chadd adr...@freebsd.org wrote:
 Hi,

 This honestly sounds like it's begging for an
 instrumentation/analysis/optimisation project.

 What do we need to do?


 Adrian



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

Comments inline below:

On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
 On Thu, Apr 19, 2012 at 11:06:38PM +0200, K. Macy wrote:
 On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
  On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
   This is indeed a big problem. ?I'm working (rough edges remain) on
   changing the routing table locking to an rmlock (read-mostly) which
  
 
  This only helps if your flows aren't hitting the same rtentry.
  Otherwise you still convoy on the lock for the rtentry itself to
  increment and decrement the rtentry's reference count.
 
   i was wondering, is there a way (and/or any advantage) to use the
   fastforward code to look up the route for locally sourced packets ?
 
  actually, now that i look at the code, both ip_output() and
  the ip_fastforward code use the same in_rtalloc_ign(...)
 
  
 
  If the number of peers is bounded then you can use the flowtable. Max
  PPS is much higher bypassing routing lookup. However, it doesn't scale
  to arbitrary flow numbers.
 
  re. flowtable, could you point me to what i should do instead of
  calling in_rtalloc_ign() ?

 If you build with it in your kernel config and enable the sysctl
 ip_output will automatically use it for TCP and UDP connections. If
 you're doing forwarding you'll need to patch the forwarding path.

 cool.
 For the records, with netsend 10.0.0.2 ports 18 0 5 on an ixgbe
 talking to a remote host i get the following results (with a single
 port netsend does a connect() and then send(), otherwise it
 loops around a sendto() )


Sorry, 5000 vs 5000-5001 means 1 vs 2 streams? Does this mean for a
single socket the overhead is less without it compiled in than with it
compiled in but enabled? That is certainly different from what I see
with TCP where I see a 30% increase in aggregate throughput the last
time I tried this (on IPoIB).

For the record the M_FLOWID is used to pick the transmit queue so with
multiple streams you're best of setting it if your device has more
than one hardware device queue.

        net.flowtable.enabled   port            ns/pkt
        -
        not compiled in         5000             944    M_FLOWID not set
        0 (disable)             5000            1004
        1 (enable)              5000             980

        not compiled in         5000-5001       3400    M_FLOWID not set
        0 (disable)             5000-5001       1418
        1 (enable)              5000-5001       1230

 The small penalty when flowtable is disabled but compiled in is
 probably because the net.flowtable.enable flag is checked
 a bit deep in the code.

 The advantage with non-connect()ed sockets is huge. I don't
 quite understand why disabling the flowtable still helps there.

Do you mean having it compiled in but disabled still helps
performance? Yes, that is extremely strange.

-Kip


-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

 This is indeed a big problem.  I'm working (rough edges remain) on
 changing the routing table locking to an rmlock (read-mostly) which


This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the rtentry's reference count.

 i was wondering, is there a way (and/or any advantage) to use the
 fastforward code to look up the route for locally sourced packets ?


If the number of peers is bounded then you can use the flowtable. Max
PPS is much higher bypassing routing lookup. However, it doesn't scale
to arbitrary flow numbers.


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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
 On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
  This is indeed a big problem. ?I'm working (rough edges remain) on
  changing the routing table locking to an rmlock (read-mostly) which
 

 This only helps if your flows aren't hitting the same rtentry.
 Otherwise you still convoy on the lock for the rtentry itself to
 increment and decrement the rtentry's reference count.

  i was wondering, is there a way (and/or any advantage) to use the
  fastforward code to look up the route for locally sourced packets ?

 actually, now that i look at the code, both ip_output() and
 the ip_fastforward code use the same in_rtalloc_ign(...)

 

 If the number of peers is bounded then you can use the flowtable. Max
 PPS is much higher bypassing routing lookup. However, it doesn't scale
 to arbitrary flow numbers.

 re. flowtable, could you point me to what i should do instead of
 calling in_rtalloc_ign() ?

If you build with it in your kernel config and enable the sysctl
ip_output will automatically use it for TCP and UDP connections. If
you're doing forwarding you'll need to patch the forwarding path.
Fabien Thomas has a patch for that that I just fixed/identified a bug
in for him.

-Kip


-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

 This only helps if your flows aren't hitting the same rtentry.
 Otherwise you still convoy on the lock for the rtentry itself to
 increment and decrement the rtentry's reference count.


 The rtentry lock isn't obtained anymore.  While the rmlock read
 lock is held on the rtable the relevant information like ifp and
 such is copied out.  No later referencing possible.  In the end
 any referencing of an rtentry would be forbidden and the rtentry
 lock can be removed.  The second step can be optional though.

Can you point me to a tree where you've made these changes?

 i was wondering, is there a way (and/or any advantage) to use the
 fastforward code to look up the route for locally sourced packets ?


 If the number of peers is bounded then you can use the flowtable. Max
 PPS is much higher bypassing routing lookup. However, it doesn't scale
 to arbitrary flow numbers.


 In theory a rmlock-only lookup into a default-route only routing
 table would be faster than creating a flow table entry for every
 destination.  It a matter of churn though.  The flowtable isn't
 lockless in itself, is it?

It is. In a steady state where the working set of peers fits in the
table it should be just a simple hash of the ip and then a lookup.

-Kip
-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

 Yes, but the lookup requires a lock?  Or is every entry replicated
 to every CPU?  So a number of concurrent CPU's sending to the same
 UDP destination would content on that lock?

No. In the default case it's per CPU, thus no serialization is
required. But yes, if your transmitting thread manages to bounce to
every core during send within the flow expiration window you'll have
an extra 12 or however many bytes per peer times the number of cores.
There is usually a fair amount of CPU affinity over a given unit time.


-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: Some performance measurements on the FreeBSD network stack

[K. Macy]

On Thu, Apr 19, 2012 at 11:27 PM, Andre Oppermann an...@freebsd.org wrote:
 On 19.04.2012 23:17, K. Macy wrote:

 This only helps if your flows aren't hitting the same rtentry.
 Otherwise you still convoy on the lock for the rtentry itself to
 increment and decrement the rtentry's reference count.



 The rtentry lock isn't obtained anymore.  While the rmlock read
 lock is held on the rtable the relevant information like ifp and
 such is copied out.  No later referencing possible.  In the end
 any referencing of an rtentry would be forbidden and the rtentry
 lock can be removed.  The second step can be optional though.


 Can you point me to a tree where you've made these changes?


 It's not in a public tree.  I just did a 'svn up' and the recent
 pf and rtsocket changes created some conflicts.  Have to solve
 them before posting.  Timeframe (early) next week.



Ok. Keep us posted.

Thanks,
Kip



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: flowtable usable or not

[K. Macy]

 Less effort is required to get greater profit without having to mess
 around with things because they fit the generic case as opposed to a
 number of niche cases or provide OS features that a user may or may
 not use.

My initial venting of my frustrations at Doug appears to have turned
an open-ended discussion of FreeBSD's merits as a desktop vs. a server
OS. I don't have the inclination to read every response closely, but I
think that it is generating more heat than light.  I have three points
that I would like to make before I attempt to transition this thread
back to its initial purpose:

a) We as a members of the community are collectively responsible for
the state of FreeBSD. Simply disabling features or removing
functionality that doesn't work or doesn't work optimally and / or
filing bug reports but not being able or willing to respond to
feedback requests is in essence a form of neglect. Although we all
have day to day obligations for which the use of FreeBSD is extremely
impractical if not impossible ... any progress, any improvements, any
advancements will only happen because *we* made it happen.

b) There are many features and many changes that are introduced in to
FreeBSD which extend the potential user base which are of no obvious
benefit to many users. Just because one doesn't need a feature and
doesn't hear users crying out for it, doesn't mean that it isn't
important.

c) My grievance was in no way with Doug Barton or ports per se, but
with his response as a representative instance of a behaviour which
bothers me, and, taken over time, is detrimental to the whole.


Back to the initial subject line: flowtable usable or not

It is possible to re-structure the routing code to have a smaller
cache footprint / shorter lookup time / and eliminate all locking in
the packet transmit path (ip_output, ip_forward). However, it would
take more time and effort than I have to do so as a recreational
activity. The set of people able to fund such an effort is
non-intersecting with the set of people who would benefit the most
heavily from it. Hence, for the time being, for those who want to be
able to approach anywhere near 1Mpps, much less 10 or 15 times that,
whilst continuing to use the regular stack (i.e. not running netmap)
we are left only with flowtable for bypassing the locking and compute
overhead of per-packet route lookups.

It is beyond debate that under some, if not many, circumstances
flowtable was unusable and perhaps continues to be. Hence, any further
reports of it was broken so I turned it off, and now my life is
better should be left unsent. If you, the reader, are willing to
contribute to the testing of changes, provide backtraces from cores
etc. please follow up.


Thank you for your support.

Cheers,
Kip


-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Request for flowtable testers and actionable feedback RE: flowtable usable or not

[K. Macy]

I'm re-sending this portion of another mail as it will inevitably not
be read by most readers by virtue of having been part of a long and
digressive thread.

subject line: flowtable usable or not

It is possible to re-structure the routing code to have a smaller
cache footprint / shorter lookup time / and eliminate all locking in
the packet transmit path (ip_output, ip_forward). However, it would
take more time and effort than I have to do so as a recreational
activity. The set of people able to fund such an effort is
non-intersecting with the set of people who would benefit the most
heavily from it. Hence, for the time being, for those who want to be
able to approach anywhere near 1Mpps, much less 10 or 15 times that,
whilst continuing to use the regular stack (i.e. not running netmap)
we are left only with flowtable for bypassing the locking and compute
overhead of per-packet route lookups.

It is beyond debate that under some, if not many, circumstances
flowtable was unusable and perhaps continues to be. Hence, any further
reports of it was broken so I turned it off, and now my life is
better should be left unsent. If you, the reader, are willing to
contribute to the testing of changes, provide backtraces from cores
etc. please follow up.


Thank you for your support.

Cheers,
Kip


--
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: flowtable usable or not

[K. Macy]

On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton do...@freebsd.org wrote:
 On 03/03/2012 08:53, K. Macy wrote:
 a) We as a members of the community are collectively responsible for
 the state of FreeBSD. Simply disabling features or removing
 functionality that doesn't work or doesn't work optimally and / or
 filing bug reports but not being able or willing to respond to
 feedback requests is in essence a form of neglect. Although we all
 have day to day obligations for which the use of FreeBSD is extremely
 impractical if not impossible ... any progress, any improvements, any
 advancements will only happen because *we* made it happen.

 Since we're reiterating key points, I'll do mine one more time. While I
 sympathize with what you wrote above, if you continue to believe that

*users*

 have a responsibility to help you debug new features you're going
 to be disappointed and frustrated.

Users don't, community members do. So I guess I rest my case for you
Doug. You're an end user at the end of the day who thinks he is a
member of the community. As you've made apparent on other threads.

In your mind Other People(TM) are responsible for FreeBSD's welfare
for consuming your dogfood because you know the people who eat it.
FreeBSD would still be at the UP stage or worse the 5.x stage if
everyone thought the way you do. Individuals who fail to understand
the distinction between simple user and community member and are
confused by which role they play can only further contribute to the
acrimony.

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

Re: flowtable usable or not

[K. Macy]

On Sat, Mar 3, 2012 at 10:09 PM, Doug Barton do...@freebsd.org wrote:
 On 03/03/2012 13:03, K. Macy wrote:
 On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton do...@freebsd.org wrote:
 On 03/03/2012 08:53, K. Macy wrote:
 a) We as a members of the community are collectively responsible for
 the state of FreeBSD. Simply disabling features or removing
 functionality that doesn't work or doesn't work optimally and / or
 filing bug reports but not being able or willing to respond to
 feedback requests is in essence a form of neglect. Although we all
 have day to day obligations for which the use of FreeBSD is extremely
 impractical if not impossible ... any progress, any improvements, any
 advancements will only happen because *we* made it happen.

 Since we're reiterating key points, I'll do mine one more time. While I
 sympathize with what you wrote above, if you continue to believe that

 *users*

 have a responsibility to help you debug new features you're going
 to be disappointed and frustrated.

 Users don't, community members do.

 You're drawing a distinction that I don't.


I'm drawing a distinction that you don't make or can't make? Like I
said I expect a group of people whose existence as a distinct entity
you are unaware of to be helpful. The initial conflict stemmed from
confusion on my part that you belong to that group. However, as you've
repeatedly made clear you don't, so I was wrong to have been critical
of you. I apologize for the confusion.

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

Re: flowtable usable or not

[K. Macy]

 Apparently you've missed all the times that I've given that exact advice. :)

 But your analogy is severely flawed. Flowtable was an experimental
 feature that theoretically might have increased performance for some
 work flows, but turned out to be fatally flawed. The ports system is an
 essential part of the FreeBSD operating *system*, depended on by
 virtually 100% of FreeBSD users.

Certainly fatally flawed without any user support. Just as many new
features have been.

 Users don't have any obligation to help us debug new/experimental features.

Correct. However, I'm not sure the analogy is flawed. I am, to some
degree, guilty of the same sin. I now run Ubuntu and have never had a
single problem keeping my package system up date, in stark contrast to
my experiences of slow and nightmarishly error-ridden port updates. I
know there are users who have operated without such problems. It is
entirely possible that they're simply smarter than I am. I similarly
feel no compunction to use a FreeBSD feature (the ports system) that I
can't rely on.

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

Re: flowtable usable or not

[K. Macy]

 ... and here is the crux of the problem. The vast majority of our
 developers don't use FreeBSD as their regular workstation. So it has
 increasingly become an OS where changes are being lobbed over the wall
 by developers who don't run systems that those changes affect. That's no
 way to run a railroad.

You understand my point but then fail to or choose not to see how it
applies to you when it creates problems for you personally. In essence
my point was that It was broken so I turned it off, end of story.
does not constitute constructive feedback and does not contribute to
the development of FreeBSD. It isn't your responsibility to help me
debug my code just as it isn't my responsibility to contribute to the
maintenance of ports by dealing with a port management that for me has
been virtually unusable in coping with dependencies.  I'm not eating
the ports dog food because it is broken for me and you're not fully
eating the sys dog food because it is broken for you are perfectly
reasonable courses of action taken in isolation. However, our
respective actions cumulatively don't contribute to the welfare of
FreeBSD and my response was simply voicing frustration with such
conduct. If you do not see the parallels between the two then there
really isn't anything further to discuss about how we engage with the
community.

-Kip



 Doug

 --

    This .signature sanitized for your protection



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: flowtable usable or not

[K. Macy]

 No, I already pointed out the distinction between new, experimental
 features; and essential components of the FreeBSD operating system.
 It's Ok for you to disagree with that distinction, or with its
 importance. But what you're suggesting is that if users don't help
 developers debug cool new feature X then we won't have cool new
 feature X. By implication you're saying that if we don't continue to
 develop cool new features then at some point down the road we wither and
 die. What I have tried ever-so-delicately to avoid saying is that lack
 of user help with debugging cool new feature X is generally a sign of
 lack of user demand for cool new feature X. Not all cool new ideas are
 good ones. :)

Considering there are firewall vendors and CDNs making consistent use
of it because it dramatically increases the sustainable data rates it
is a bit cavalier to say that there is a lack of demand. It doesn't
show up directly as a lack of demand when FreeBSD drastically
underperforms linux in a high bandwidth environment. The solution is
for the user to simply switch to linux how is a user to know
(parodying Star Trek technobabble) Darn it, if only FreeBSD provided
an exponential phase inverter on the warp core in the network stack.
All he or she will see is it is slow. Or another very concrete example
is iX keeps losing sales because ZFS doesn't perform adequately. ZFS
doesn't perform adequately largely because the VM system can't map and
can't recycle pages fast enough because of locking limitations. It has
nothing to do with the storage stack itself. However, most developers
themselves are not familiar with the issues much less users. So if I
were to make further locking changes I would initially inevitably
break some things. Your response would be that it isn't something
users want. You're absolutely right, because current users with higher
performance demands DON'T USE FreeBSD. Now you may wish to cut hairs
by saying well ... locking we need flowtable we don't. However, the
gist of that would be that things that you don't understand, that
don't solve anyone's immediate problems user's don't want. For many
prospective server class users the current performance profile is a
bigger deterrent than the fact that Cairo took tons of hand-wringing
to build and so I spent hours just getting a broken chat client to
install and once I did OTR support didn't work. Taken collectively the
cool new feature Xs are every bit as important to FreeBSD as ports.


 OTOH, if we don't fix the fundamental problems with ports, and other key
 areas of the operating system, we're just not going to have users,
 period. Given that most of the developers (like you) have stopped using
 FreeBSD on a day-to-day basis, who can blame them?

Not necessarily. Most big shops don't really use ports as is.
Particularly appliance vendors don't care about how package management
is handled. But yes, in principle we could end up with no desktop
users.

 Doug

 --

    This .signature sanitized for your protection



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: flowtable usable or not

[K. Macy]

 Yes, that was part of it. On the web and db systems we had what I can
 only describe as general wackiness with systems suddenly becoming
 unreachable, etc. This was with a moderately complex network setup with
 a combination of different VLANs, multiple interfaces, etc. The FreeBSD
 routers would just plain panic on a semi-regular interval. Removing
 flowtable made all this go away, and we've been quite stable since then.


I understand the switch. Uptime is important in any production
network. However, it seems like it may have been too easy to turn it
off because no one has made any effort to help me debug the issues. By
analogy your guidance for ports usability problems would be to install
Ubuntu.

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

Re: flowtable usable or not

[K. Macy]

.

 I tried it, on both FreeBSD routers, web systems, and database
 servers; all on 8.2+. It still causes massive instability. Disabling
 the sysctl, and/or removing it from the kernel solved the problems.

Routing I can believe, but I'm wondering how close attention you paid
to the workload. There are CDN networks with high uptimes and shipping
firewall products that use flowtable, so your mention of web systems
forces makes me ask for specifics.

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

Re: flowtable usable or not

[K Macy]

Inviato da iPad

Il giorno 01/mar/2012, alle ore 03:01, Steve Wills swi...@freebsd.org ha 
scritto:
 
 The failure I experienced was with web servers running 8.0 behind a F5
 load balancer in an HA setup. Whenever the failover happened, the web
 servers would continue sending to the wrong MAC address, despite the
 arp table updating. Disabling flowtable via the sysctl solved the
 problem. Maybe Doug's failure was similar, maybe not, but I thought
 I'd throw my $0.02 in.
 

Thanks. I just committed a change recently for 8 - HEAD to address that. I 
would like to know if it solves the problem.

 Steve
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.18 (FreeBSD)
 
 iQEcBAEBAgAGBQJPTtiJAAoJEPXPYrMgexuhp8EIAKGGtZzcxgQ4zVO5SKy1jAOH
 DXLRLYfdm8NJB9hYEvtUa9/nltAE35zQMp7FU4AlZ2L2ol/J7W9aODiN0gw9AFEr
 dxBYyQliDKvVwLgah9a5PaXNM3kpx9ZvZGM3lBQGQbZaEV+ERwjBXkfIqjEB4Ei5
 bBd7841jQm22s1xJOuJTdMGrpnY1DMUPdPCFOAtyQmTAhWpoELgtQBvP9kGYNKv2
 3NAPnjFuooe9fdze9VSO8TWFJSb82DVbRsz6JiR0998oHXPApCh4I5y1rNcg2qA/
 1x2EdFlivXpgjC4nKUgFjhohmdGv20FrLfex4eOq6dSMF0Baje86PJcc8EZ1DK0=
 =NUft
 -END PGP SIGNATURE-
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: fifo_listen: fchmod public/pickup: Invalid argument with postfix on today's current

[K. Macy]

On Sat, Feb 25, 2012 at 2:15 PM, Attilio Rao atti...@freebsd.org wrote:
 Il 25 febbraio 2012 07:15, Doug Barton do...@freebsd.org ha scritto:
 On 02/24/2012 21:00, Doug Barton wrote:
 I'm on today's -current (r232126) and I'm getting the error in the
 subject when trying to start postfix. I recompiled 2.9, and then tried
 2.8  both give the same error.

 Did you also rebuilt world?

I don't think a world rebuild shouldn't be necessary for that change.

 Attilio

 --
 Peace can only be achieved by understanding - A. Einstein
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



-- 
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

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

Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3

[K. Macy]

Someone was seeing the same issue with the vmtools kmod. The only
thing that might make sense is that the page lock array is defined as
being a different size in your kmod as in the kernel itself so the
lock corresponding to the page you're locking differs between the two
files.

Cheers

On Fri, Oct 21, 2011 at 5:25 PM, Penta Upa bsdb...@gmail.com wrote:
 Hi,

 I'm facing a kernel panic at vm_page_wire(). Page is locked with
 vm_page_lock() yet i get the following panic
 panic: mutex page lock not owned at /usr/src/sys/vm/vm_page:1845

 Code sequence is as below
 vm_page_lock(pp);
 vm_page_lock_assert(pp, MA_OWNED); /* No panic here */
 vm_page_wire(pp); /* Panic here for the same assertion as above, strange */
 vm_page_unlock(pp);

 Kernel on the system is unchanged after install. The only thing which
 occurred out the way was that the first time install failed for checksum
 mismatch for src.txz. Also there were some SCSI errors/warnings with the CD
 drive during install. So the next time, i only installed the base and
 kernel and later unpacked src.txz under /usr/src . Could this lead to any
 issues ?

 Attached is a test module (vmtest) and the makefile used. Uname output from
 the system is

 FreeBSD scache 9.0-BETA3 FreeBSD 9.0-BETA3 #0: Sat Sep 24 21:31:28 UTC
 2011
 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

 Is there anything i'm doing wrong here ? Kindly help.

 Regards,
 Penta

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

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

Re: BETA3 core dump

[K. Macy]

You need to change the permissions. I'm getting a 403 from nginx.

On Sat, Oct 1, 2011 at 12:20 PM, Volodymyr Kostyrko c.kw...@gmail.com wrote:
 Hi all.

 BETA3 dumps core on running heavy disk bound application. Built with clang
 and kernel is custom, but I can try to reproduce it on GENERIC if that
 matters.

 http://limbo.xim.bz/core.txt.0

 --
 Sphinx of black quartz judge my vow.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

Re: After r22561[78] some kmods do not build any more

[K. Macy]

This is a side effect of the syscall namespace disambiguation. I will
send patches to the ports maintainers.

Thanks

On Sat, Sep 17, 2011 at 10:29 AM, Rainer Hurling rhur...@gwdg.de wrote:
 Upgrading 9.0-BETA2 last night after r22561[78] was committed brings me
 trouble with at least to kmods from ports. They do not load anymore and also
 I am not able the build them:


 /usr/ports/print/acroreadwrapper#make
 ===  Vulnerability check disabled, database not found
 ===  License check disabled, port has not defined LICENSE
 ===  Extracting for acroreadwrapper-0.0.20110529
 = SHA256 Checksum OK for linux_adobe_kmod-20110529.tar.gz.
 ===  Patching for acroreadwrapper-0.0.20110529
 ===  Configuring for acroreadwrapper-0.0.20110529
 ===  Building for acroreadwrapper-0.0.20110529
 Warning: Object directory not changed from original
 /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110529
 @ - /usr/src/sys
 machine - /usr/src/sys/amd64/include
 x86 - /usr/src/sys/x86/include
 cc -O2 -fno-strict-aliasing -pipe -msse3 -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32
 -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@ -I@/contrib/altq
 -finline-limit=8000 --param inline-unit-growth=100 --param
 large-function-growth=1000 -fno-common  -fno-omit-frame-pointer  -mno-sse
 -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
 -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
  -Wmissing-include-dirs -fdiagnostics-show-option -c linux_adobe.c
 cc1: warnings being treated as errors
 linux_adobe.c: In function 'linux_adobe_linux_sched_setscheduler':
 linux_adobe.c:88: warning: implicit declaration of function
 'sched_setscheduler'
 linux_adobe.c:88: warning: nested extern declaration of 'sched_setscheduler'
 [-Wnested-externs]
 *** Error code 1
 Stop in /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110529.
 *** Error code 1
 Stop in /usr/ports/print/acroreadwrapper.



 /usr/ports/emulators/rtc#make
 ===  Vulnerability check disabled, database not found
 ===  License check disabled, port has not defined LICENSE
 ===  Extracting for rtc-2004.02.24.1_8
 ===  Patching for rtc-2004.02.24.1_8
 ===  Configuring for rtc-2004.02.24.1_8
 ===  Building for rtc-2004.02.24.1_8
 /usr/share/mk/bsd.compat.mk, line 35: warning: NOMAN is deprecated in
 favour of NO_MAN
 /sys/conf/kmod.mk, line 268: warning: duplicate script for target @
 ignored
 @ - /sys
 awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
 awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
 awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
 Warning: Object directory not changed from original
 /usr/ports/emulators/rtc/work/files
 machine - /usr/src/sys/amd64/include
 x86 - /usr/src/sys/x86/include
 cc -O2 -fno-strict-aliasing -pipe -msse3 -DCDEV_MAJOR_=202 -Werror -D_KERNEL
 -DKLD_MODULE -nostdinc  -I/usr/ports/emulators/rtc/work/files -I/sys -I. -I@
 -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param
 large-function-growth=1000 -fno-common -fno-omit-frame-pointer  -mno-sse
 -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
 -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
  -Wmissing-include-dirs -fdiagnostics-show-option -c rtc.c
 cc -O2 -fno-strict-aliasing -pipe -msse3 -DCDEV_MAJOR_=202 -Werror -D_KERNEL
 -DKLD_MODULE -nostdinc  -I/usr/ports/emulators/rtc/work/files -I/sys -I. -I@
 -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param
 large-function-growth=1000 -fno-common -fno-omit-frame-pointer  -mno-sse
 -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
 -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
  -Wmissing-include-dirs -fdiagnostics-show-option -c rtc_linux.c
 cc1: warnings being treated as errors
 rtc_linux.c: In function 'linux_ioctl_rtc':
 rtc_linux.c:74: warning: implicit declaration of function 'ioctl'
 rtc_linux.c:74: warning: nested extern declaration of 'ioctl'
 [-Wnested-externs]
 *** Error code 1
 Stop in /usr/ports/emulators/rtc/work/files.
 *** Error code 1
 Stop in /usr/ports/emulators/rtc.


 Am I doing something wrong or is this intended and some ports need
 adaptions?

 Thanks in advance,
 Rainer Hurling

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

Re: 9.0-BETA2 do not support SpeedStep on E5420

[K. Macy]

On Thu, Sep 15, 2011 at 9:22 PM, Andriy Gapon a...@freebsd.org wrote:
 on 15/09/2011 19:20 Arnaud Lacombe said the following:
 est0: failed to enable SpeedStep
 p4tcc0: CPU Frequency Thermal Control on cpu0
 est1: failed to enable SpeedStep
 p4tcc1: CPU Frequency Thermal Control on cpu1
 est2: failed to enable SpeedStep
 p4tcc2: CPU Frequency Thermal Control on cpu2
 est3: failed to enable SpeedStep
 p4tcc3: CPU Frequency Thermal Control on cpu3
 est4: failed to enable SpeedStep
 p4tcc4: CPU Frequency Thermal Control on cpu4
 est5: failed to enable SpeedStep
 p4tcc5: CPU Frequency Thermal Control on cpu5
 est6: failed to enable SpeedStep
 p4tcc6: CPU Frequency Thermal Control on cpu6
 est7: failed to enable SpeedStep
 p4tcc7: CPU Frequency Thermal Control on cpu7

 It feels strange that the latest FreeBSD do not support est(4) on a 3
 years old CPU...

 Somehow I do not read failed to enable as can not detect or can not
 support SpeedStep on this CPU.


sys/x86/cpufreq/est.c:1008

/* Attempt to enable SpeedStep if not currently enabled. */
msr = rdmsr(MSR_MISC_ENABLE);
if ((msr  MSR_SS_ENABLE) == 0) {
wrmsr(MSR_MISC_ENABLE, msr | MSR_SS_ENABLE);
if (bootverbose)
device_printf(dev, enabling SpeedStep\n);

/* Check if the enable failed. */
msr = rdmsr(MSR_MISC_ENABLE);
if ((msr  MSR_SS_ENABLE) == 0) {
device_printf(dev, failed to enable SpeedStep\n);
return (ENXIO);
}
}


Andriy -

He is correct. Possibly power management on server processors isn't
considered a priority by the maintainer.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.0-BETA2 do not support SpeedStep on E5420

[K. Macy]

I was just discussing this issues with some others - evidently est(9)
works fine on both older and newer cpus. I see you're active on lkml -
does the linux driver work correctly on this machine? i.e. do you know
that it isn't disabled in the BIOS.

Thanks

On Thu, Sep 15, 2011 at 6:20 PM, Arnaud Lacombe lacom...@gmail.com wrote:
 Hi,

 From today's -CURRENT:

 Copyright (c) 1992-2011 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-BETA2 #17 r225560+be1f8b9: Thu Sep 15 12:05:41 EDT 2011
    
 al@shai-hulud:/data/src/freebsd/obj/master/i386.i386/data/src/freebsd/src/sys/GENERIC
 i386
 CPU: Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz (2493.80-MHz 686-class 
 CPU)
  Origin = GenuineIntel  Id = 0x1067a  Family = 6  Model = 17  Stepping = 10
  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE
  AMD Features=0x2010NX,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant, performance statistics
 real memory  = 6442450944 (6144 MB)
 avail memory = 3677458432 (3507 MB)
 Event timer LAPIC quality 400
 ACPI APIC Table: 100509 APIC1714
 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
 FreeBSD/SMP: 2 package(s) x 4 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
  cpu2 (AP): APIC ID:  2
  cpu3 (AP): APIC ID:  3
  cpu4 (AP): APIC ID:  4
  cpu5 (AP): APIC ID:  5
  cpu6 (AP): APIC ID:  6
  cpu7 (AP): APIC ID:  7
 [...]
 est0: failed to enable SpeedStep
 p4tcc0: CPU Frequency Thermal Control on cpu0
 est1: failed to enable SpeedStep
 p4tcc1: CPU Frequency Thermal Control on cpu1
 est2: failed to enable SpeedStep
 p4tcc2: CPU Frequency Thermal Control on cpu2
 est3: failed to enable SpeedStep
 p4tcc3: CPU Frequency Thermal Control on cpu3
 est4: failed to enable SpeedStep
 p4tcc4: CPU Frequency Thermal Control on cpu4
 est5: failed to enable SpeedStep
 p4tcc5: CPU Frequency Thermal Control on cpu5
 est6: failed to enable SpeedStep
 p4tcc6: CPU Frequency Thermal Control on cpu6
 est7: failed to enable SpeedStep
 p4tcc7: CPU Frequency Thermal Control on cpu7

 It feels strange that the latest FreeBSD do not support est(4) on a 3
 years old CPU...

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

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

Re: lock order reversal

[K. Macy]

When WITNESS support was added to lockmgr locks a number of
longstanding LORs were exposed in the process. I can't comment on
whether or not they'll be fixed or the warnings will some day be
silenced.

On Tue, Sep 6, 2011 at 2:58 PM, Vadim Denisov m...@vadimdenisov.ru wrote:
 I install current on last week
 I have some messages in dmesg -a:
 lock order reversal:
  1st 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425
  2nd 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658
  3rd 0xc7d89168 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546
 KDB: stack backtrace:
 db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,a363435,...) at
 db_trace_self_wrapper+0x26
 kdb_backtrace(c088dd7b,c0c38d9c,c7535098,c75385d0,ef9e1404,...) at
 kdb_backtrace+0x2a
 _witness_debugger(c0c38d9c,c7d89168,c0c2816c,c75385d0,c0c56442,...) at
 _witness_debugger+0x25
 witness_checkorder(c7d89168,9,c0c56442,222,0,...) at
 witness_checkorder+0x839
 __lockmgr_args(c7d89168,80100,c7d89188,0,0,...) at __lockmgr_args+0x824
 ffs_lock(ef9e152c,c0ecca08,c7dc1c30,80100,c7d89110,...) at ffs_lock+0x8a
 VOP_LOCK1_APV(c0d3c680,ef9e152c,ef9e154c,c0d4caa0,c7d89110,...) at
 VOP_LOCK1_APV+0xb5
 _vn_lock(c7d89110,80100,c0c56442,222,c755ce80,...) at _vn_lock+0x5e
 ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x14fc
 ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13
 vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at
 vfs_donmount+0x1219
 nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84
 syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at
 syscallenter+0x263
 syscall(ef9e1d28) at syscall+0x34
 Xint0x80_syscall() at Xint0x80_syscall+0x21
 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp =
 0xbfbfea9c, ebp = 0xbfbfede8 ---
 lock order reversal:
  1st 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658
  2nd 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818
 KDB: stack backtrace:
 db_trace_self_wrapper(c0c353ac,662f7366,735f7366,7370616e,2e746f68,...) at
 db_trace_self_wrapper+0x26
 kdb_backtrace(c088dd7b,c0c38d83,c7535098,c7538978,ef9e1404,...) at
 kdb_backtrace+0x2a
 _witness_debugger(c0c38d83,c7563c9c,c0c564a4,c7538978,c0c56442,...) at
 _witness_debugger+0x25
 witness_checkorder(c7563c9c,9,c0c56442,332,c81ba298,...) at
 witness_checkorder+0x839
 __lockmgr_args(c7563c9c,80400,c81ba298,0,0,...) at __lockmgr_args+0x824
 ffs_lock(ef9e152c,e0ef5790,10,80400,c81ba220,...) at ffs_lock+0x8a
 VOP_LOCK1_APV(c0d3c680,ef9e152c,e0ef57ec,c0d4caa0,c81ba220,...) at
 VOP_LOCK1_APV+0xb5
 _vn_lock(c81ba220,80400,c0c56442,332,0,...) at _vn_lock+0x5e
 ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x298e
 ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13
 vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at
 vfs_donmount+0x1219
 nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84
 syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at
 syscallenter+0x263
 syscall(ef9e1d28) at syscall+0x34
 Xint0x80_syscall() at Xint0x80_syscall+0x21
 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp =
 0xbfbfea9c, ebp = 0xbfbfede8 ---
 lock order reversal:
  1st 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:307
  2nd 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1620
 KDB: stack backtrace:
 db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,30323631,...) at
 db_trace_self_wrapper+0x26
 kdb_backtrace(c088dd7b,c0c38d83,c7538978,c75385d0,ef9e16c8,...) at
 kdb_backtrace+0x2a
 _witness_debugger(c0c38d83,c81ba278,c0c2816c,c75385d0,c0c56442,...) at
 _witness_debugger+0x25
 witness_checkorder(c81ba278,9,c0c56442,654,0,...) at
 witness_checkorder+0x839
 __lockmgr_args(c81ba278,8,0,0,0,...) at __lockmgr_args+0x824
 ffs_snapremove(c81ba220,8,c0c3e10a,5e8,c7535098,...) at ffs_snapremove+0x11f
 ffs_truncate(c81ba220,0,0,c00,0,...) at ffs_truncate+0x577
 ufs_inactive(ef9e1a9c,c81ba298,c81ba220,c81ba298,ef9e1ab4,...) at
 ufs_inactive+0x1f8
 VOP_INACTIVE_APV(c0d3c680,ef9e1a9c,c0c40a67,94e,c0d4ca60,...) at
 VOP_INACTIVE_APV+0xa5
 vinactive(c0d3c680,ef9e1ad0,c0c40a67,8a5,0,...) at vinactive+0x8e
 vputx(ef9e1b38,c08febda,c81ba220,ef9e1b14,c0c41f00,...) at vputx+0x2f8
 vput(c81ba220,ef9e1b14,c0c41f00,133,0,...) at vput+0x10
 vn_close(c81ba220,1,c755ce00,c7dc1b80,0,...) at vn_close+0x19a
 vn_closefile(c7c300a8,c7dc1b80,c0c2706c,0,c7c300a8,...) at vn_closefile+0xe4
 _fdrop(c7c300a8,c7dc1b80,0,ef9e1bfc,0,c0ecc9d8,c7dc1c30,c0d28da0,c0ecc9d8,c0c2af54,c7dc1b80,c7b05d2c,4ce,ef9e1c0c,c085d087,c7b05d2c,8,c0c2af54,c7c300a8)
 at _fdrop+0x43
 closef(c7c300a8,c7dc1b80,4ce,ef9e1c30,c7b05d2c,...) at closef+0x2b0
 kern_close(c7dc1b80,4,ef9e1c7c,c0897ff3,c7dc1b80,...) at kern_close+0x139
 close(c7dc1b80,ef9e1cec,ef9e1d28,c0c3767a,0,...) at close+0x1a
 syscallenter(c7dc1b80,ef9e1ce4,ef9e1ce4,0,c0d819f0,...) at
 syscallenter+0x263
 

Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

[K. Macy]

On Tue, Aug 30, 2011 at 9:47 PM, Pedro F. Giffuni giffu...@tutopia.com wrote:
 FWIW;

 Christopher Bergström and Pathscale delivered the EKOPath
 Compiler Suite, but no one followed up:

 (From the WantedPorts Wiki)
 https://github.com/pathscale/path64-suite

 There has been very low interest in the FreeBSD port,
 and unfortunately this is a bad signal that we give to
 companies that want to contribute :(.


The problem I have with that is that they only support the high-end
computing variant of the card which I doubt any of us has. Without the
documentation to extend the work to ordinary cards, e.g. my GTX460, it
isn't that useful.

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

Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

[K. Macy]

 But the lack of response and non-shown interests shows a undeobtly signal
 that freeBSD seems to be
 dead for the HPC community and this could be also an indication for the lack
 of CUDA support
 by nVidia, Why performing efforts if no one cares? A great chance seems to
 have passed by ...

I wouldn't read too much in to it. What was provided only fit a fairly
narrow niche. Nvidia won't build their libraries on freebsd until we
prove the market which is fairly hard to do when you have to jump
through hoops just to get it to run and need to have a linux
environment to build the apps.

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

Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

[K. Macy]

On Mon, Aug 29, 2011 at 2:12 PM, Adrian Chadd adr...@freebsd.org wrote:
 Hi,

 http://forums.nvidia.com/index.php?showtopic=38242 Post 18

 This indicates the driver supports CUDA somehow. What's missing is a
 FreeBSD runtime.

 Can someone please do some legwork with this and see if it's possible
 to bring the Linux CUDA SDK up in the linuxulator?


Just to underscore this. There are a number of us that can contribute
to making this happen. However, it is not clear what the missing
pieces are.

Cheers

 Adrian

 On 29 August 2011 18:13, Hartmann, O. ohart...@zedat.fu-berlin.de wrote:
 Hello out there.
 Just read this a day ago at Phoronix:
 http://www.phoronix.com/scan.php?page=news_itempx=OTg0MQ

 I've also read that there is work done on the PTX assembly backend in LLVM
 for generation code for nVidia GPUs.
 I'm still grasping for the silky fathem having GPGPU on FreeBSD anyway like
 CUDA or OpenCL as the Linux and Windows
 fellows already have as well as the guys from OS X.

 Since nVidia offers 64bit ready BLOBs for their nice GPUs, I still hope that
 with LLVM, and maybe a proper OpenCL frontend like
 CLANG, FreeBSD users will have the chance to execute OpenCL code on a GPU.
 We use this stuff in science for now (and its done
 exclusiveley on Linux so far, since we use the CUDA SDK to generate OpenCL
 1.1 code executed on TESLA and GTX570 graphics
 boards which give us impressive performance for our astrodynamical modelling
 ...).

 Sorry, if someone feels bothered by my repetitive bringing up this subject
 ... I still does not have lost all hope for FreeBSD.

 oh

 ___
 freebsd-performa...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-performance
 To unsubscribe, send any mail to
 freebsd-performance-unsubscr...@freebsd.org

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

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

Re: fast/syscall-free gettimeofday ?

[K. Macy]

On Tue, Jun 14, 2011 at 6:08 PM, K. Macy km...@freebsd.org wrote:
 http://svnweb.freebsd.org/base/head/sys/sys/imgact.h

 kib added rudimentary support for this in January

To clarify, this is just the kernel side of the shared page
infrastructure, and is currently only hosting the the signal handling
code. The user library side is non-existent and no data sharing
currently happens.
-Kip

 On Tue, Jun 14, 2011 at 6:11 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
 there were discussions at some point on an imprecise but
 fast implementations of gettimeofday() that would not require
 a system call (perhaps mmapping some memory region which
 is opportunistically updated).

 Does anyone remember what happened about that ?

 Otherwise, is there any place in the kernel where i can fetch
 a struct timeval which is not off by more than, say 1 tick ?

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


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

Re: fast/syscall-free gettimeofday ?

[K. Macy]

http://svnweb.freebsd.org/base/head/sys/sys/imgact.h

kib added rudimentary support for this in January

On Tue, Jun 14, 2011 at 6:11 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
 there were discussions at some point on an imprecise but
 fast implementations of gettimeofday() that would not require
 a system call (perhaps mmapping some memory region which
 is opportunistically updated).

 Does anyone remember what happened about that ?

 Otherwise, is there any place in the kernel where i can fetch
 a struct timeval which is not off by more than, say 1 tick ?

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

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

Re: 9.0-CURRENT-201105-amd64 install kernel panic

[K. Macy]

This recent commit changed the way that the value for size being
passed to m_getjcl is initialized. Not seeing any obvious bugs, and
not having any additional context I would guess that that you're
receiving an interrupt before adapter-rx_mbuf_sz is set. I trust jfv@
to look in to this shortly.

http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=214362r2=214363;

Thanks


On Fri, Jun 10, 2011 at 9:19 PM, Kim Culhan w8hd...@gmail.com wrote:
 On Fri, June 10, 2011 11:22 am, Kim Culhan wrote:
 Booting from FreeBSD-9.0-CURRENT-201105-amd64-memstick
 the kernel panics:

 panic: m_getzone: m_getjcl: invalid cluster type

 Found a ps2 keyboard works in the debugger (not usb) and backtrace is here:

 http://www.flickr.com/photos/opensolaris/5819107302/in/photostream
 -kim
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

Please try 207949 

Thanks,
Kip



On Tue, May 11, 2010 at 6:18 AM, David Wolfskill da...@catwhisker.org wrote:
 On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
 Could you please try with 207902?
 ...

 I saved that environment (documented elsewhere ini the thread), then
 performed the normal (for me) daily update, this time, to r207911.

 Again, I see a panic during transition from single-user mode to
 multi-user mode:

 ...
  3  Select option, [Enter] for default     3
  3  or [Space] to pause timer  9           3
 �...@dy


 GDB: no debug ports present
 KDB: debugger backends: ddb
 KDB: current backend: ddb
 Copyright (c) 1992-2010 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-CURRENT #156 r207911: Tue May 11 05:55:18 PDT 2010
    r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
 WARNING: WITNESS option enabled, expect reduced performance.
 Timecounter i8254 frequency 1193182 Hz quality 0
 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
 real memory  = 2147483648 (2048 MB)
 avail memory = 2086129664 (1989 MB)
 ACPI APIC Table: PTLTD          APIC  
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 2 package(s) x 1 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  6
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 ioapic1 Version 2.0 irqs 24-47 on motherboard
 ioapic2 Version 2.0 irqs 48-71 on motherboard
 kbd1 at kbdmux0
 acpi0: PTLTD   RSDT on motherboard
 acpi0: [ITHREAD]
 acpi0: Power Button (fixed)
 Timecounter ACPI-fast frequency 3579545 Hz quality 1000
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 pci0: unknown at device 0.1 (no driver attached)
 pci0: base peripheral at device 1.0 (no driver attached)
 pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
 pci1: ACPI PCI bus on pcib1
 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
 pci2: ACPI PCI bus on pcib2
 aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 
 1.0 on pci2
 aac0: Enable Raw I/O
 aac0: New comm. interface enabled
 aac0: [ITHREAD]
 aac0: Adaptec 2200S, aac driver 2.1.9-1
 aacp0: SCSI Passthrough Bus on aac0
 aacp1: SCSI Passthrough Bus on aac0
 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
 pci3: ACPI PCI bus on pcib3
 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f 
 mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
 em0: [FILTER]
 em0: Ethernet address: 00:30:48:2d:32:6a
 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f 
 mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
 em1: [FILTER]
 em1: Ethernet address: 00:30:48:2d:32:6b
 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
 pci4: ACPI PCI bus on pcib4
 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
 pci5: ACPI PCI bus on pcib5
 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 
 at device 29.0 on pci0
 uhci0: [ITHREAD]
 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 
 at device 29.1 on pci0
 uhci1: [ITHREAD]
 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 
 at device 29.2 on pci0
 uhci2: [ITHREAD]
 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 
 at device 29.3 on pci0
 uhci3: [ITHREAD]
 usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
 irq 23 at device 29.7 on pci0
 ehci0: [ITHREAD]
 usbus4: EHCI version 1.0
 usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
 pci6: ACPI PCI bus on pcib6
 vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
 isab0: PCI-ISA bridge at device 31.0 on pci0
 isa0: ISA bus on isab0
 atapci0: Intel ICH5 UDMA100 controller port 
 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
 ata0: ATA channel 0 on atapci0
 ata0: [ITHREAD]
 ata1: ATA channel 1 on atapci0
 ata1: [ITHREAD]
 pci0: serial bus, SMBus at device 31.3 (no driver attached

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

On Tue, May 11, 2010 at 9:24 PM, David Wolfskill da...@catwhisker.org wrote:
 On Tue, May 11, 2010 at 08:30:09PM -0700, K. Macy wrote:
 Please try 207949 
 ...

 The panic (this time) didn't show up until about 10 seconds after the
 login: prompt showed up on the serial console.  Here's what it looks
 like:

 ...
  3  Select option, [Enter] for default     3
  3  or [Space] to pause timer  9           3
 �...@dy


 GDB: no debug ports present
 KDB: debugger backends: ddb
 KDB: current backend: ddb
 Copyright (c) 1992-2010 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-CURRENT #157 r207911M: Tue May 11 20:54:25 PDT 2010
    r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
 WARNING: WITNESS option enabled, expect reduced performance.
 Timecounter i8254 frequency 1193182 Hz quality 0
 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
 real memory  = 2147483648 (2048 MB)
 avail memory = 2086129664 (1989 MB)
 ACPI APIC Table: PTLTD          APIC  
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 2 package(s) x 1 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  6
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 ioapic1 Version 2.0 irqs 24-47 on motherboard
 ioapic2 Version 2.0 irqs 48-71 on motherboard
 kbd1 at kbdmux0
 acpi0: PTLTD   RSDT on motherboard
 acpi0: [ITHREAD]
 acpi0: Power Button (fixed)
 Timecounter ACPI-fast frequency 3579545 Hz quality 1000
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 pci0: unknown at device 0.1 (no driver attached)
 pci0: base peripheral at device 1.0 (no driver attached)
 pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
 pci1: ACPI PCI bus on pcib1
 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
 pci2: ACPI PCI bus on pcib2
 aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 
 1.0 on pci2
 aac0: Enable Raw I/O
 aac0: New comm. interface enabled
 aac0: [ITHREAD]
 aac0: Adaptec 2200S, aac driver 2.1.9-1
 aacp0: SCSI Passthrough Bus on aac0
 aacp1: SCSI Passthrough Bus on aac0
 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
 pci3: ACPI PCI bus on pcib3
 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f 
 mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
 em0: [FILTER]
 em0: Ethernet address: 00:30:48:2d:32:6a
 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f 
 mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
 em1: [FILTER]
 em1: Ethernet address: 00:30:48:2d:32:6b
 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
 pci4: ACPI PCI bus on pcib4
 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
 pci5: ACPI PCI bus on pcib5
 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 
 at device 29.0 on pci0
 uhci0: [ITHREAD]
 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 
 at device 29.1 on pci0
 uhci1: [ITHREAD]
 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 
 at device 29.2 on pci0
 uhci2: [ITHREAD]
 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 
 at device 29.3 on pci0
 uhci3: [ITHREAD]
 usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
 irq 23 at device 29.7 on pci0
 ehci0: [ITHREAD]
 usbus4: EHCI version 1.0
 usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
 pci6: ACPI PCI bus on pcib6
 vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
 isab0: PCI-ISA bridge at device 31.0 on pci0
 isa0: ISA bus on isab0
 atapci0: Intel ICH5 UDMA100 controller port 
 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
 ata0: ATA channel 0 on atapci0
 ata0: [ITHREAD]
 ata1: ATA channel 1 on atapci0
 ata1: [ITHREAD]
 pci0: serial bus, SMBus at device 31.3 (no driver attached)
 acpi_button0: Power Button on acpi0
 atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
 atkbdc0: Keyboard controller

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

Could you please try with 207902?

Thanks,
Kip

On Mon, May 10, 2010 at 11:26 AM, David Wolfskill da...@catwhisker.org wrote:
 On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
 ...
 You don't happen to have a backtrace?

 Oops -- sorry; got caught up in getting ready to head in to work:

 db bt
 Tracing pid 20 tid 100067 td 0xc5a19000
 _mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46
 flowtable_free_stale(c0e28f40,0,c0cd2d5b,600,0,...) at 
 flowtable_free_stale+0x2fb
 flowtable_cleaner(0,e9bc6d38,c0cbf058,343,c5f362a8,...) at 
 flowtable_cleaner+0xd0
 fork_exit(c094f920,0,e9bc6d38) at fork_exit+0xb8
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0, eip = 0, esp = 0xe9bc6d70, ebp = 0 ---
 db

 Anything else that might be useful or interesting, please let me
 know; as noted earlier, I left the machine in that state.  (I
 normally power it off after the morning's  build/test festivities,
 as it's loud  uses a fair amount of power.)

 Peace,
 david
 --
 David H. Wolfskill                              da...@catwhisker.org
 Depriving a girl or boy of an opportunity for education is evil.

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

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

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

On Mon, May 10, 2010 at 2:32 PM, K. Macy km...@freebsd.org wrote:
 Could you please try with 207902?

And if not, please get a coredump with a backtrace with symbols.

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

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

Are you not able to dump core?

Thanks,
Kip

On Mon, May 10, 2010 at 3:08 PM, David Wolfskill da...@catwhisker.org wrote:
 On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
 Could you please try with 207902?
 ...

 First, thanks for the response.

 OK; I grabbed r207902  applied it (via patch -p1), then rebuilt the
 kernel  rebooted; here's the panic now:

  3  Select option, [Enter] for default     3
  3  or [Space] to pause timer  9           3
 �...@dy


 GDB: no debug ports present
 KDB: debugger backends: ddb
 KDB: current backend: ddb
 Copyright (c) 1992-2010 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-CURRENT #155 r207844M: Mon May 10 14:55:41 PDT 2010
    r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
 WARNING: WITNESS option enabled, expect reduced performance.
 Timecounter i8254 frequency 1193182 Hz quality 0
 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3610.95-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
 real memory  = 2147483648 (2048 MB)
 avail memory = 2086129664 (1989 MB)
 ACPI APIC Table: PTLTD          APIC  
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 2 package(s) x 1 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  6
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 ioapic1 Version 2.0 irqs 24-47 on motherboard
 ioapic2 Version 2.0 irqs 48-71 on motherboard
 kbd1 at kbdmux0
 acpi0: PTLTD   RSDT on motherboard
 acpi0: [ITHREAD]
 acpi0: Power Button (fixed)
 Timecounter ACPI-fast frequency 3579545 Hz quality 1000
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 pci0: unknown at device 0.1 (no driver attached)
 pci0: base peripheral at device 1.0 (no driver attached)
 pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
 pci1: ACPI PCI bus on pcib1
 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
 pci2: ACPI PCI bus on pcib2
 aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 
 1.0 on pci2
 aac0: Enable Raw I/O
 aac0: New comm. interface enabled
 aac0: [ITHREAD]
 aac0: Adaptec 2200S, aac driver 2.1.9-1
 aacp0: SCSI Passthrough Bus on aac0
 aacp1: SCSI Passthrough Bus on aac0
 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
 pci3: ACPI PCI bus on pcib3
 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f 
 mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
 em0: [FILTER]
 em0: Ethernet address: 00:30:48:2d:32:6a
 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f 
 mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
 em1: [FILTER]
 em1: Ethernet address: 00:30:48:2d:32:6b
 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
 pci4: ACPI PCI bus on pcib4
 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
 pci5: ACPI PCI bus on pcib5
 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 
 at device 29.0 on pci0
 uhci0: [ITHREAD]
 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 
 at device 29.1 on pci0
 uhci1: [ITHREAD]
 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 
 at device 29.2 on pci0
 uhci2: [ITHREAD]
 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 
 at device 29.3 on pci0
 uhci3: [ITHREAD]
 usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
 irq 23 at device 29.7 on pci0
 ehci0: [ITHREAD]
 usbus4: EHCI version 1.0
 usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
 pci6: ACPI PCI bus on pcib6
 vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
 isab0: PCI-ISA bridge at device 31.0 on pci0
 isa0: ISA bus on isab0
 atapci0: Intel ICH5 UDMA100 controller port 
 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
 ata0: ATA channel 0 on atapci0
 ata0: [ITHREAD]
 ata1: ATA channel 1 on atapci0
 ata1: [ITHREAD]
 pci0: serial bus, SMBus at device 31.3 (no driver attached)
 acpi_button0: Power Button on acpi0
 atrtc0: AT realtime clock port 0x70

Re: Recent sys/vm/ changes and nvidia-driver

[K. Macy]

On Sat, May 8, 2010 at 2:20 PM, b. f. bf1...@googlemail.com wrote:
 On 05/08/10 13:36, Alan Cox wrote:
 Doug Barton wrote:
 On 05/05/10 11:56, Alan Cox wrote:

 I'm afraid that I would advise waiting a few days.  This round of
 changes
 are not yet complete.

 What performance differences, if any, can we expect on uniprocessors
 from the vm page lock-related changes? Kip's original post on -arch
 mentioned some performance improvements and no significant
 regressions, but on a dual 4-core machine.

I wouldn't actually worry about UP since the overhead can largely be
disabled by building without SMP. I think we need to be looking at how
a dual-core system performs, trading off any regressions there against
current processor trends of ever higher core and thread count.


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

Re: Panic @r207433: System call fork returning with the following locks held

[K. Macy]

 Sadly, it doesn't do it for me .. lockd start-up causes a panic on a
 sleeping thread. Do I need to do a buildworld as well as kernel?


We're calling vm_pageout_flush with the page queue lock held in
vm_object_page_collect_flush.  I'll have a fix in soon.

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

Re: Panic @r207433: System call fork returning with the following locks held

[K. Macy]

On Fri, Apr 30, 2010 at 12:38 PM, K. Macy km...@freebsd.org wrote:
 Sadly, it doesn't do it for me .. lockd start-up causes a panic on a
 sleeping thread. Do I need to do a buildworld as well as kernel?


 We're calling vm_pageout_flush with the page queue lock held in
 vm_object_page_collect_flush.  I'll have a fix in soon.

Please try updating to 207451

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