Re: Some performance measurements on the FreeBSD network stack
>> 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
On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo 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
>> 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
> > 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
On Thu, Apr 19, 2012 at 11:27 PM, Andre Oppermann 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: Some performance measurements on the FreeBSD network stack
Comments inline below: On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo 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 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
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 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
On Tue, Apr 24, 2012 at 4:16 PM, 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 ? > 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
On Tue, Apr 24, 2012 at 5:03 PM, K. Macy wrote: > On Tue, Apr 24, 2012 at 4:16 PM, 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 ? >> > > > 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
On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo 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
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 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
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 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
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 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 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
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 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 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 >>> 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
> 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 Date: Mon, Sep 19, 2011 at 3:19 PM To: "K. Macy" Cc: Robert Watson , rysto32 , Qing Li 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: fast bcopy...
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 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: 9.0-CURRENT-201105-amd64 install kernel panic
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=214362&r2=214363&; Thanks On Fri, Jun 10, 2011 at 9:19 PM, Kim Culhan 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: fast/syscall-free gettimeofday ?
On Tue, Jun 14, 2011 at 6:08 PM, K. Macy 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 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 ?
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 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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
On Mon, Aug 29, 2011 at 2:12 PM, Adrian Chadd 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. wrote: >> Hello out there. >> Just read this a day ago at Phoronix: >> http://www.phoronix.com/scan.php?page=news_item&px=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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
On Tue, Aug 30, 2011 at 9:47 PM, Pedro F. Giffuni 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
> 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: lock order reversal
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 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,ef
Re: 9.0-BETA2 do not support SpeedStep on E5420
On Thu, Sep 15, 2011 at 9:22 PM, Andriy Gapon wrote:
> on 15/09/2011 19:20 Arnaud Lacombe said the following:
>> est0: failed to enable SpeedStep
>> p4tcc0: on cpu0
>> est1: failed to enable SpeedStep
>> p4tcc1: on cpu1
>> est2: failed to enable SpeedStep
>> p4tcc2: on cpu2
>> est3: failed to enable SpeedStep
>> p4tcc3: on cpu3
>> est4: failed to enable SpeedStep
>> p4tcc4: on cpu4
>> est5: failed to enable SpeedStep
>> p4tcc5: on cpu5
>> est6: failed to enable SpeedStep
>> p4tcc6: on cpu6
>> est7: failed to enable SpeedStep
>> p4tcc7: 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
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 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=0xbfebfbff > Features2=0x40ce3bd > AMD Features=0x2010 > AMD Features2=0x1 > 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: on cpu0 > est1: failed to enable SpeedStep > p4tcc1: on cpu1 > est2: failed to enable SpeedStep > p4tcc2: on cpu2 > est3: failed to enable SpeedStep > p4tcc3: on cpu3 > est4: failed to enable SpeedStep > p4tcc4: on cpu4 > est5: failed to enable SpeedStep > p4tcc5: on cpu5 > est6: failed to enable SpeedStep > p4tcc6: on cpu6 > est7: failed to enable SpeedStep > p4tcc7: 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: After r22561[78] some kmods do not build any more
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 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/listi
Re: BETA3 core dump
You need to change the permissions. I'm getting a 403 from nginx. On Sat, Oct 1, 2011 at 12:20 PM, Volodymyr Kostyrko 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: Recent sys/vm/ changes and nvidia-driver
On Sat, May 8, 2010 at 2:20 PM, b. f. 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 @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode"
Could you please try with 207902? Thanks, Kip On Mon, May 10, 2010 at 11:26 AM, David Wolfskill 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"
On Mon, May 10, 2010 at 2:32 PM, K. Macy 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"
Are you not able to dump core? Thanks, Kip On Mon, May 10, 2010 at 3:08 PM, David Wolfskill 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=0xbfebfbff > Features2=0x659d > AMD Features=0x2010 > TSC: P-state invariant > real memory = 2147483648 (2048 MB) > avail memory = 2086129664 (1989 MB) > ACPI APIC Table: > 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 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > kbd1 at kbdmux0 > acpi0: 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: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pci0: at device 1.0 (no driver attached) > pcib1: irq 16 at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > aac0: 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: on aac0 > aacp1: on aac0 > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > em0: 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: 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: irq 16 at device 4.0 on pci0 > pci4: on pcib4 > pcib5: irq 16 at device 6.0 on pci0 > pci5: on pcib5 > uhci0: port 0x1400-0x141f irq 16 > at device 29.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port 0x1420-0x143f irq 19 > at device 29.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port 0x1440-0x145f irq 18 > at device 29.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > uhci3: port 0x1460-0x147f irq 16 > at device 29.3 on pci0 > uhci3: [ITHREAD] > usbus3: on uhci3 > ehci0: mem 0xd8001000-0xd80013ff > irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > vgapci0: port 0x3000-0x30ff mem > 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0:
Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode"
Please try 207949 Thanks, Kip On Tue, May 11, 2010 at 6:18 AM, David Wolfskill 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=0xbfebfbff > Features2=0x659d > AMD Features=0x2010 > TSC: P-state invariant > real memory = 2147483648 (2048 MB) > avail memory = 2086129664 (1989 MB) > ACPI APIC Table: > 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 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > kbd1 at kbdmux0 > acpi0: 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: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pci0: at device 1.0 (no driver attached) > pcib1: irq 16 at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > aac0: 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: on aac0 > aacp1: on aac0 > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > em0: 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: 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: irq 16 at device 4.0 on pci0 > pci4: on pcib4 > pcib5: irq 16 at device 6.0 on pci0 > pci5: on pcib5 > uhci0: port 0x1400-0x141f irq 16 > at device 29.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port 0x1420-0x143f irq 19 > at device 29.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port 0x1440-0x145f irq 18 > at device 29.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > uhci3: port 0x1460-0x147f irq 16 > at device 29.3 on pci0 > uhci3: [ITHREAD] > usbus3: on uhci3 > ehci0: mem 0xd8001000-0xd80013ff > irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > vgapci0: port 0x3000-0x30ff mem > 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" d
Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode"
On Tue, May 11, 2010 at 9:24 PM, David Wolfskill 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=0xbfebfbff > Features2=0x659d > AMD Features=0x2010 > TSC: P-state invariant > real memory = 2147483648 (2048 MB) > avail memory = 2086129664 (1989 MB) > ACPI APIC Table: > 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 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > kbd1 at kbdmux0 > acpi0: 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: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pci0: at device 1.0 (no driver attached) > pcib1: irq 16 at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > aac0: 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: on aac0 > aacp1: on aac0 > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > em0: 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: 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: irq 16 at device 4.0 on pci0 > pci4: on pcib4 > pcib5: irq 16 at device 6.0 on pci0 > pci5: on pcib5 > uhci0: port 0x1400-0x141f irq 16 > at device 29.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port 0x1420-0x143f irq 19 > at device 29.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port 0x1440-0x145f irq 18 > at device 29.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > uhci3: port 0x1460-0x147f irq 16 > at device 29.3 on pci0 > uhci3: [ITHREAD] > usbus3: on uhci3 > ehci0: mem 0xd8001000-0xd80013ff > irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > vgapci0: port 0x3000-0x30ff mem > 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem > 0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0
Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]
On Wed, Aug 20, 2014 at 7:41 AM, Luigi Rizzo wrote: > On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky > wrote: > > > Hi Luigi, > > > > > > On 08/20/14 11:32, Luigi Rizzo wrote: > > > >> On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky > >> 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]
> > > >> - 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: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]
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 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]
On Wed, Nov 19, 2014 at 1:34 PM, Hans Petter Selasky 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: nagios vs w/uptime
> > 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: Doing zero-copy stuff in drivers, or "is vm_fault_quick_hold_pages() enough" ?
On Mon, Mar 2, 2015 at 12:42 PM, Adrian Chadd 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" ?
>> 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: panic at vm_page_wire with FreeBSD 9.0 Beta 3
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 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: fifo_listen: fchmod public/pickup: Invalid argument with postfix on today's current
On Sat, Feb 25, 2012 at 2:15 PM, Attilio Rao wrote: > Il 25 febbraio 2012 07:15, Doug Barton 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: flowtable usable or not
. > > 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
Inviato da iPad Il giorno 01/mar/2012, alle ore 03:01, Steve Wills 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: flowtable usable or not
> 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
> 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
> > ... 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
> 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 X"s 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
> 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
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
On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton 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
On Sat, Mar 3, 2012 at 10:09 PM, Doug Barton wrote: > On 03/03/2012 13:03, K. Macy wrote: >> On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton 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: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
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: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
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 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 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
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 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 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
>> 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: [RFC] Deprecation and removal of the drm2 driver
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: [RFC] Deprecation and removal of the drm2 driver
> > 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
> > > 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
> 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
Why are you running i386 on that? On Tue, May 22, 2018 at 4:26 PM, Steve Kargl 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: SVN - r334189 breaks build
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, &V_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, &pmc_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: ifa_ifwithnet failed ???
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: ifa_ifwithnet failed ???
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 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 > 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 ???
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: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)
> > 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: rust broken?
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: [PATCH] Recent libm additions
> > 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: GPF on Current kernel
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" 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.s
Re: GPF on Current kernel
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" wrote: > actually, the following are interesting further down: > #13 0x808af473 in sys_write (td=0xdeadc0dedeadc116, > uap=) 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" 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 >>> Read
Re: Instant panic while trying run ports-mgmt/poudriere
Is this still happening? On Jul 15, 2015 1:41 PM, "Pawel Pekala" wrote: > Hi John-Mark, > > On 2015-07-15 11:05 -0700, John-Mark Gurney 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=, > 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=, code=0) > at /hdd/src/sys/ddb/db_main.c:251 > #5 0x809b4094 in kdb_trap (type=9, code=0, tf= out>) > at /hdd/src/sys/kern/subr_kdb.c:654 > #6 0x80d9e065 in trap_fatal (frame=0xfe046c818950, > eva=) at /hdd/src/sys/amd64/amd64/trap.c:848 > #7 0x80d9dd33 in trap (frame=) > 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=) at /hdd/src/sys/kern/kern_event.c:1920 > #10 0x80938ef1 in exit1 (td=0xf800135c5980, > rv=) at /hdd/src/sys/kern/kern_exit.c:559 > #11 0x809383be in sys_sys_exit (td=0x0, uap=) > at /hdd/src/sys/kern/kern_exit.c:177 > #12 0x80d9e8d2 in amd64_syscall (td=0xf800135c5980, traced=0) > at subr_syscall.c:133 > #13 0x80d7ef9b in Xfast_syscall () > at /hd
Re: CURRENT slow and shaky network stability
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: CURRENT slow and shaky network stability
Sorry meant inpcb and autocorrect "fixed" it. On Saturday, March 26, 2016, O. Hartmann wrote: > Am Fri, 25 Mar 2016 13:31:31 -0700 > "K. Macy" > 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 > 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 " > > ___ 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)
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: [CFT] packaging the base system with pkg(8)
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)
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: Intel i7-6700T aka Skylake Support
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&id=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, send any mail to "free
Re: i915kms broken at some commit between r296485 and r297692?
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"
boot broken on VMWare somewhere between r300069 and r300176
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: em(4) broken in HEAD?
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"
Re: em(4) broken in HEAD?
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?
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 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(&queue->tq_active, &tb, tb_link);
tb_first = TAILQ_FIRST(&queue->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->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: pkg chroot issues?
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: dmesg: can't reuse a leaf (ixl_rx_miss_bufs)!
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: repeatable panic on pageout with 945GM
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 > > Any hints welcome, > >
Latest freebsd installer memstick image fails to mountroot by default on Thinkpad e565
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: panic with tcp timers
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(&tp->t_timers->tt_keep) ### Use after free
> > of tp here
> > !callout_active(&tp->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&r2=284260&pathrev=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"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
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: ACPI errors when booting laptop
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: Method parse/execution fa
Re: [PATCH] randomized delay in locking primitives, take 2
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"
iwm load panic
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: iwm load panic
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 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"
Re: iwm load panic
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"
lengthy sdhci timeouts on KBL-Y tester
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) [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) [EmbeddedContro
Re: Hardware rendered Wayland client up and running
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"
Re: External toolchain support broken for devel/llvm38 but not devel/llvm37
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: Lenovo X1 Carbon or T460s
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: Lenovo X1 Carbon or T460s
On Monday, November 14, 2016, Lars Engels wrote: > On Sun, Nov 13, 2016 at 01:56:45PM -0800, K. Macy wrote: > > 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. > > 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: Is there possible run a MacOS X binary
> > > 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: Panic @r205276 (Fatal trap 12: page fault while in kernel mode)
>> >> I have the same panic. I'll try to revert 205266. > > Yes, 205266 is the culprit. Try updating. I've made the change a no-op until I can track the problem down. -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 @r205276 (Fatal trap 12: page fault while in kernel mode)
On Thu, Mar 18, 2010 at 1:38 PM, K. Macy wrote: >>> >>> I have the same panic. I'll try to revert 205266. >> >> Yes, 205266 is the culprit. > > Try updating. I've made the change a no-op until I can track the problem down. Do you all have either out-of-tree modules or modules that you did not re-build when re-compiling your kernel? 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"
