20% guaranteed ROI, condo development construction finance -- lenders wanted from as little as 500, 000THB
Purchase a condo with easy payment plan With construction expected to be completed within 20 months, you could own your own condo with an ocean view in the most sought after address in Pattaya -- Pratumnak Hill. Once completed you could choose to rent it for regular income or sell it to capitalise on your investment. We have a range of one, two and three bedroom condos still available ranging from 3.9 to 9.9m Thai Baht / 120,000 to 310,000USD / 70,000 to 180,000GBP. The payment plan is 25% deposit, 65% over construction that can be tailored to suit your needs, and final payment of 10% Click here for more details regarding this opportunity Collect 5% every six months. Watch your money grow in the sun. This investment is backed by the Tudor Group and their latest project in Pattaya, Thailand called The Cube, which is currently under construction. The small investor opportunity is aimed at the people that would like to invest their money, but don’t normally have the chance, as their budget is lower than the majority of the offers on the table. The people with budgets of 500,000 and 1,000,000 Baht. Its too small to actually purchase a Condo or House, but they would still like to participate if they had the chance. Small Investment Guaranteed Returns 20% Guaranteed Return for 2 years. Invest from 500,000 upto 2,000,000 Thai Baht and receive a guaranteed return of 10% per annum fixed for 2 years. Example Investment & Payout Rates Invest 500,000 THB 6 months - Receive 25,000 THB 12 months - Receive 25,000 THB 18 months - Receive 25,000 THB 24 months - Receive 25,000 THB Plus your 500,000THB returned in full. Click here for more details regarding this opportunity Look forward to hearing from you Regards Simon Ditchburn The Tudor Group Click here to unsubscribehttp://email.leadonics.com/wf/unsubscribe?upn=Q1G7K8cYCrLWsp3rtsmPRunbkgV55iYL1ZdjJK8vUDJvYQs5YjXf75pJtzzCpgpXu6q34c3g4uIlVMvgeO41OqdskShnqpDGAzk2T1VQfZ5W8cG7xjnjOYwW0yo5ZYc7xdfIMt02VOxNPqm-2FOPNUOUpy3L6ezdzLeULAmcOPz4upNe5fbaqeZX-2FrJ0iyGD1lNKyy-2FR-2F9OBGqvxOASWWYCWnrCXAci1xYEyLXL5M8oFz2-2FlifkdNpQtFKl06xOSmgWS8P4KS8iBEIrjyAlWYJvqkWpaOfrnRfULeF2L3zwKE0vs53WvTmxyihBibPnYSdJ8UPH3-2B1nkpKLPD3RvRL2uCtbZuWU-2FByqQ1cd0IOSvLpA9vU77q2zzp8q58Vpz5LeCwUJS5LGlFZkiL9QI3MVen8kYSRzomGzyw6-2B22gvc0-3D ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192303] New: C++11 std::list<>::remove_if() visits elements multiple times
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192303 Bug ID: 192303 Summary: C++11 std::list<>::remove_if() visits elements multiple times Product: Base System Version: 10.0-STABLE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: kamik...@bsdforen.de Created attachment 145205 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145205&action=edit Bug demo When calling std::list<>::remove_if() with a lambda for the condition (I did not test without lambdas), it visits the list entry *following* a delete twice. Attached is a demo of the bug. The number of visits should be 10: # ./main Initial list: 0 1 2 3 4 5 6 7 8 9 Remove odd numbers ... | val | remove |-| | 0 | | 1 | X | 2 | | 2 | | 3 | X | 4 | | 4 | | 5 | X | 6 | | 6 | | 7 | X | 8 | | 8 | | 9 | X Updated list: 0 2 4 6 8 Visits: 14 Build the test program with: # make CXX="c++ -std=c++11" main -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192303] C++11 std::list<>::remove_if() visits elements multiple times
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192303 --- Comment #1 from kamik...@bsdforen.de --- I forgot to post my uname: FreeBSD AprilRyan.norad 10.0-STABLE FreeBSD 10.0-STABLE #0 r268659: Tue Jul 15 11:25:22 CEST 2014 root@AprilRyan.norad:/usr/obj/S403/amd64/usr/src/sys/S403 amd64 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192303] C++11 std::list<>::remove_if() visits elements multiple times
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192303 --- Comment #2 from kamik...@bsdforen.de --- Just built it using gcc49: gcc version 4.9.2 20140723 (prerelease) (FreeBSD Ports Collection) It produces the expected output: # ./main Initial list: 0 1 2 3 4 5 6 7 8 9 Remove odd numbers ... | val | remove |-| | 0 | | 1 | X | 2 | | 3 | X | 4 | | 5 | X | 6 | | 7 | X | 8 | | 9 | X Updated list: 0 2 4 6 8 Visits: 10 I also got independent confirmation of the issue: https://www.bsdforen.de/threads/c-11-bug-unter-freebsd-10.31225/ -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 187443] Impossible clean shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187443 envol...@gmail.com changed: What|Removed |Added Severity|Affects Only Me |Affects Some People --- Comment #1 from envol...@gmail.com --- freebsd-acpi mailing list discussion: http://lists.freebsd.org/pipermail/freebsd-acpi/2014-June/008671.html (patch for acpi) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] New: high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 Bug ID: 192315 Summary: high load average while idle, slow keyboard reaction Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: swi...@freebsd.org Was seeing load average of around 5, even with next to nothing running and the system was nearly completely idle. Keyboard was also slow to react and shutting down paused for longer than 60 seconds for bufdaemon. Touching the keyboard would make it continue. Setting kern.eventtimer.timer=HPET seemed to resolve the issue. See https://lists.freebsd.org/pipermail/freebsd-current/2014-July/051498.html for others who have experienced the same thing. Opening bug per Adrian's request. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 Alexander Motin changed: What|Removed |Added CC||m...@freebsd.org --- Comment #1 from Alexander Motin --- Line "Event timer "LAPIC" quality 400" in verbose dmesg tells that LAPIC timer in your CPU (used by default) is not compatible with CPU C-states (deep idle states). Can you make sure that C-states are not used on your system by checking 'sysctl dev.cpu | grep cx_usage' and 'sysctl -a | grep cx_lowest'? Timer code was not changing for quite some time already, while C-states were enabled by default less time ago, IIRC. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #2 from Alexander Motin --- Theoretically C-states should be blocked automatically in such situation, but who knows... Also check whether your BIOS support C1E state, and if it does, try to disable it. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192316] New: Invariant TSC gets misdetected on Intel Core 2 Duo processors, resulting in sluggish system behavior
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316 Bug ID: 192316 Summary: Invariant TSC gets misdetected on Intel Core 2 Duo processors, resulting in sluggish system behavior Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: jan.kokemuel...@gmail.com Hi, On this Intel Core 2 Duo T6570 processor, the TSC timer gets a very high priority, even though it is not invariant. If there is power saving enabled and the processor goes to lower C-states, this results in a sluggish system. Thread on freebsd-current: https://lists.freebsd.org/pipermail/freebsd-current/2014-July/051498.html There are some Intel models hard coded as TSC invariant in the TSC detection logic, even if they are not. Suggested fix: just check if the TSC_INVARIANT processor bit is set or not. I've attached a patch. Cheers, Jan -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192316] Invariant TSC gets misdetected on Intel Core 2 Duo processors, resulting in sluggish system behavior
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316 --- Comment #1 from jan.kokemuel...@gmail.com --- Created attachment 145227 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145227&action=edit suggested patch -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: thread_local broken on clang
On Thu, Jul 31, 2014 at 2:54 AM, Troy Heron wrote:
> Hello,
>
> I'm attempting to port an application to FreeBSD (version 10 to be
> specific). The application has been developed using C++11 and uses
> thread_local.
>
> As below, the use of thread_local is giving me linking errors for the C++
> ABI.
>
> troy@freebsd10:~ # cat tl.cpp
> #include
>
> thread_local std::string test;
>
> int main()
> {
> }
> troy@freebsd10:~ # clang++ -std=c++11 tl.cpp -o tl
> /tmp/tl-7sN7Nb.o: In function `__cxx_global_var_init':
> tl.cpp:(.text+0xbb): undefined reference to `__cxa_thread_atexit'
> clang++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> troy@freebsd10:~ #
>
> Has anyone else experienced this? Should I report it as a bug?
Please report a bug. You can also ask this question on freebsd-stable
mailing list.
cheers,
Hiren
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191318] freebsd-update(8) from 9.2p8 to 10.0: after first reboot, old ifconfig can't handle 10.x interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191318 Kurt Jaeger changed: What|Removed |Added Status|In Discussion |Issue Resolved Resolution|--- |FIXED --- Comment #3 from Kurt Jaeger --- Further tests showed that this is not a general problem. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #3 from Steve Wills --- (In reply to Alexander Motin from comment #1) > Line "Event timer "LAPIC" quality 400" in verbose dmesg tells that LAPIC > timer in your CPU (used by default) is not compatible with CPU C-states > (deep idle states). Can you make sure that C-states are not used on your > system by checking 'sysctl dev.cpu | grep cx_usage' and 'sysctl -a | grep > cx_lowest'? > > Timer code was not changing for quite some time already, while C-states were > enabled by default less time ago, IIRC. meatwad% sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 15.53% 82.84% 1.61% last 149us dev.cpu.0.cx_usage_counters: 1509220 8046504 156453 dev.cpu.1.cx_usage: 15.21% 77.78% 6.99% last 1803us dev.cpu.1.cx_usage_counters: 462080 2361986 212335 dev.cpu.2.cx_usage: 15.54% 78.02% 6.43% last 1601us dev.cpu.2.cx_usage_counters: 542112 2721324 224459 dev.cpu.3.cx_usage: 14.02% 79.92% 6.05% last 1014us dev.cpu.3.cx_usage_counters: 496716 2831459 214487 dev.cpu.4.cx_usage: 16.10% 77.77% 6.11% last 5971us dev.cpu.4.cx_usage_counters: 467800 2258637 177471 dev.cpu.5.cx_usage: 15.24% 77.76% 6.99% last 612us dev.cpu.5.cx_usage_counters: 462824 2361157 212369 dev.cpu.6.cx_usage: 19.44% 74.33% 6.21% last 872us dev.cpu.6.cx_usage_counters: 640034 2446184 204690 dev.cpu.7.cx_usage: 15.40% 79.04% 5.55% last 51us dev.cpu.7.cx_usage_counters: 464464 2382488 167297 meatwad% sysctl -a | grep cx_lowest hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_lowest: C8 dev.cpu.1.cx_lowest: C8 dev.cpu.2.cx_lowest: C8 dev.cpu.3.cx_lowest: C8 dev.cpu.4.cx_lowest: C8 dev.cpu.5.cx_lowest: C8 dev.cpu.6.cx_lowest: C8 dev.cpu.7.cx_lowest: C8 meatwad% Note this is after setting kern.eventtimer.timer=HPET as mentioned previously. If it matters, I can undo that and run these again. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #4 from Steve Wills --- (In reply to Alexander Motin from comment #2) > Theoretically C-states should be blocked automatically in such situation, > but who knows... Also check whether your BIOS support C1E state, and if it > does, try to disable it. How would I check that? Just look for something related to C1E in BIOS configuration? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191302] [kernel] add short sleep in sys/kern/init_main.c before panic() ?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191302 --- Comment #3 from Kurt Jaeger --- The crash and clear screen was so fast that I did not even see that it was a panic. Most other panics had the message about "press a button or we'll reboot in 15 seconds". That one had not, and so I failed to suspect a panic and needed to film it. Film at http://opsec.eu/backup/20140621042.mp4 Is PANIC_REBOOT_WAIT_TIME not set to 15 seconds in general ? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #6 from Alexander Motin --- (In reply to Steve Wills from comment #4) > (In reply to Alexander Motin from comment #2) > > Theoretically C-states should be blocked automatically in such situation, > > but who knows... Also check whether your BIOS support C1E state, and if it > > does, try to disable it. > > How would I check that? Just look for something related to C1E in BIOS > configuration? Usually there is some option mentioning C1E state somewhere under the CPU options. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #5 from Alexander Motin --- (In reply to Steve Wills from comment #3) > (In reply to Alexander Motin from comment #1) > > Line "Event timer "LAPIC" quality 400" in verbose dmesg tells that LAPIC > > timer in your CPU (used by default) is not compatible with CPU C-states > > (deep idle states). Can you make sure that C-states are not used on your > > system by checking 'sysctl dev.cpu | grep cx_usage' and 'sysctl -a | grep > > cx_lowest'? > > > > Timer code was not changing for quite some time already, while C-states were > > enabled by default less time ago, IIRC. > > meatwad% sysctl dev.cpu | grep cx_usage > dev.cpu.0.cx_usage: 15.53% 82.84% 1.61% last 149us > dev.cpu.0.cx_usage_counters: 1509220 8046504 156453 > dev.cpu.1.cx_usage: 15.21% 77.78% 6.99% last 1803us > dev.cpu.1.cx_usage_counters: 462080 2361986 212335 > dev.cpu.2.cx_usage: 15.54% 78.02% 6.43% last 1601us > dev.cpu.2.cx_usage_counters: 542112 2721324 224459 > dev.cpu.3.cx_usage: 14.02% 79.92% 6.05% last 1014us > dev.cpu.3.cx_usage_counters: 496716 2831459 214487 > dev.cpu.4.cx_usage: 16.10% 77.77% 6.11% last 5971us > dev.cpu.4.cx_usage_counters: 467800 2258637 177471 > dev.cpu.5.cx_usage: 15.24% 77.76% 6.99% last 612us > dev.cpu.5.cx_usage_counters: 462824 2361157 212369 > dev.cpu.6.cx_usage: 19.44% 74.33% 6.21% last 872us > dev.cpu.6.cx_usage_counters: 640034 2446184 204690 > dev.cpu.7.cx_usage: 15.40% 79.04% 5.55% last 51us > dev.cpu.7.cx_usage_counters: 464464 2382488 167297 > meatwad% sysctl -a | grep cx_lowest > hw.acpi.cpu.cx_lowest: C8 > dev.cpu.0.cx_lowest: C8 > dev.cpu.1.cx_lowest: C8 > dev.cpu.2.cx_lowest: C8 > dev.cpu.3.cx_lowest: C8 > dev.cpu.4.cx_lowest: C8 > dev.cpu.5.cx_lowest: C8 > dev.cpu.6.cx_lowest: C8 > dev.cpu.7.cx_lowest: C8 > meatwad% > > Note this is after setting kern.eventtimer.timer=HPET as mentioned > previously. If it matters, I can undo that and run these again. That does not tell much after you enabled HPET, except that your system does have C-states. Reboot without switching to HPET and check again. If C-states block working, you should not see states deeper then C1 used even if enabled. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #7 from Alexander Motin --- (In reply to Alexander Motin from comment #6) > (In reply to Steve Wills from comment #4) > > (In reply to Alexander Motin from comment #2) > > > Theoretically C-states should be blocked automatically in such situation, > > > but who knows... Also check whether your BIOS support C1E state, and if it > > > does, try to disable it. > > > > How would I check that? Just look for something related to C1E in BIOS > > configuration? > > Usually there is some option mentioning C1E state somewhere under the CPU > options. But that is after you make sure that normal C-states are not used by FreeBSD itself. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #8 from Steve Wills --- (In reply to Alexander Motin from comment #5) > That does not tell much after you enabled HPET, except that your system does > have C-states. Reboot without switching to HPET and check again. If C-states > block working, you should not see states deeper then C1 used even if enabled. Ok, rebooted without setting HPET: meatwad% sysctl kern.timecounter.hardware kern.eventtimer.timer kern.timecounter.hardware: TSC-low kern.eventtimer.timer: LAPIC meatwad% sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 22.28% 77.71% 0.00% last 1359us dev.cpu.0.cx_usage_counters: 17048 59466 0 dev.cpu.1.cx_usage: 21.54% 78.45% 0.00% last 939us dev.cpu.1.cx_usage_counters: 17294 62983 0 dev.cpu.2.cx_usage: 31.10% 68.89% 0.00% last 1146us dev.cpu.2.cx_usage_counters: 33021 73155 0 dev.cpu.3.cx_usage: 21.15% 78.84% 0.00% last 738us dev.cpu.3.cx_usage_counters: 18109 67474 0 dev.cpu.4.cx_usage: 21.94% 78.05% 0.00% last 447us dev.cpu.4.cx_usage_counters: 18022 64084 0 dev.cpu.5.cx_usage: 22.70% 77.29% 0.00% last 682us dev.cpu.5.cx_usage_counters: 18103 61637 0 dev.cpu.6.cx_usage: 26.53% 73.46% 0.00% last 430us dev.cpu.6.cx_usage_counters: 33056 91541 0 dev.cpu.7.cx_usage: 22.60% 77.39% 0.00% last 6us dev.cpu.7.cx_usage_counters: 16724 57250 0 meatwad% sysctl -a | grep cx_lowest hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_lowest: C8 dev.cpu.1.cx_lowest: C8 dev.cpu.2.cx_lowest: C8 dev.cpu.3.cx_lowest: C8 dev.cpu.4.cx_lowest: C8 dev.cpu.5.cx_lowest: C8 dev.cpu.6.cx_lowest: C8 dev.cpu.7.cx_lowest: C8 meatwad% -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #9 from Alexander Motin --- (In reply to Steve Wills from comment #8) > (In reply to Alexander Motin from comment #5) > > That does not tell much after you enabled HPET, except that your system does > > have C-states. Reboot without switching to HPET and check again. If C-states > > block working, you should not see states deeper then C1 used even if > > enabled. > > Ok, rebooted without setting HPET: > > meatwad% sysctl kern.timecounter.hardware kern.eventtimer.timer > kern.timecounter.hardware: TSC-low > kern.eventtimer.timer: LAPIC > meatwad% sysctl dev.cpu | grep cx_usage > dev.cpu.0.cx_usage: 22.28% 77.71% 0.00% last 1359us > dev.cpu.0.cx_usage_counters: 17048 59466 0 > dev.cpu.1.cx_usage: 21.54% 78.45% 0.00% last 939us > dev.cpu.1.cx_usage_counters: 17294 62983 0 > dev.cpu.2.cx_usage: 31.10% 68.89% 0.00% last 1146us > dev.cpu.2.cx_usage_counters: 33021 73155 0 > dev.cpu.3.cx_usage: 21.15% 78.84% 0.00% last 738us > dev.cpu.3.cx_usage_counters: 18109 67474 0 > dev.cpu.4.cx_usage: 21.94% 78.05% 0.00% last 447us > dev.cpu.4.cx_usage_counters: 18022 64084 0 > dev.cpu.5.cx_usage: 22.70% 77.29% 0.00% last 682us > dev.cpu.5.cx_usage_counters: 18103 61637 0 > dev.cpu.6.cx_usage: 26.53% 73.46% 0.00% last 430us > dev.cpu.6.cx_usage_counters: 33056 91541 0 > dev.cpu.7.cx_usage: 22.60% 77.39% 0.00% last 6us > dev.cpu.7.cx_usage_counters: 16724 57250 0 > meatwad% sysctl -a | grep cx_lowest > hw.acpi.cpu.cx_lowest: C8 > dev.cpu.0.cx_lowest: C8 > dev.cpu.1.cx_lowest: C8 > dev.cpu.2.cx_lowest: C8 > dev.cpu.3.cx_lowest: C8 > dev.cpu.4.cx_lowest: C8 > dev.cpu.5.cx_lowest: C8 > dev.cpu.6.cx_lowest: C8 > dev.cpu.7.cx_lowest: C8 > meatwad% Hmm. It looks like the deepest C-state was actually disabled automatically. Then it is surprising to have any problem with LAPIC. But, just to be sure that BIOS does not fool us, could you disable all C-states completely with something like this in rc.conf: performance_cx_lowest="C1" economy_cx_lowest="C1" , and if it won't help, also disable C1E in BIOS. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192320] New: Use of thread_local produces linking errors on system version of clang++
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320
Bug ID: 192320
Summary: Use of thread_local produces linking errors on system
version of clang++
Product: Base System
Version: 10.0-STABLE
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: misc
Assignee: freebsd-bugs@FreeBSD.org
Reporter: troy.he...@hixxy.org
During porting of a C++ application to FreeBSD I have discovered problem with
using thread_local with the system version of Clang 3.3.
As below, it's use produces linking errors to the C++ ABI.
troy@freebsd10:~ # cat tl.cpp
#include
thread_local std::string test;
int main()
{
}
troy@freebsd10:~ # clang++ -std=c++11 tl.cpp -o tl
/tmp/tl-7sN7Nb.o: In function `__cxx_global_var_init':
tl.cpp:(.text+0xbb): undefined reference to `__cxa_thread_atexit'
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)
troy@freebsd10:~ #
troy@freebsd10:~ # clang++ -v
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: x86_64-unknown-freebsd10.0
Thread model: posix
troy@freebsd10:~ #
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192321] New: Issuing ctladm getsync for non existing lun caused crash and reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192321 Bug ID: 192321 Summary: Issuing ctladm getsync for non existing lun caused crash and reboot Product: Base System Version: 10.0-STABLE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: nde...@gmail.com Here's a transcript of a shell session and after the last command for a non existing LUN the box rebooted. [0:18][root@nas:ndenev]#ctladm devlist LUN Backend Size (Blocks) BS Serial NumberDevice ID 0 block 976707584 512 MYSERIAL 0 MYDEVID 0 1 block 976773168 512 MYSERIAL 1 MYDEVID 1 2 block 536870912 512 MYSERIAL 2 MYDEVID 2 [0:18][root@nas:ndenev]#ctladm getsync 0:0 0:0: sync interval: 0 [0:18][root@nas:ndenev]#ctladm getsync 0:1 0:1: sync interval: 0 [0:18][root@nas:ndenev]#ctladm getsync 0:2 0:2: sync interval: 0 [0:18][root@nas:ndenev]#ctladm getsync 0:3 OS : FreeBSD nas.home.lan 10.0-STABLE FreeBSD 10.0-STABLE #9 r269182: Wed Jul 30 23:18:23 UTC 2014 r...@nas.home.lan:/usr/obj/usr/src/sys/NAS amd64 Console transcript of the crash : instruction pointer = 0x20:0x802b2a06 stack pointer = 0x28:0xfe0096031700 frame pointer = 0x28:0xfe0096031990 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 = 1200 (ctladm) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0x80510570 at kdb_backtrace+0x60 #1 0x804d51d5 at panic+0x155?? #2 0x806eadff at trap_fatal+0x38?? #3 0x806eb118 at trap_pfault+0x308 #4 0x806ea7c0 at trap+0x4a0 #5 0x806d0f82 at calltrap+0x8 #6 0x803d2cb4 at devfs_ioctl_f+0x114 #7 0x80527405 at kern_ioctl+0x255 #8 0x8052715c at sys_ioctl+0x13c #9 0x806eb731 at amd64_syscall+0x351 #10 0x806d126b at Xfast_syscall+0xfb Uptime: 5m11s Automatic reboot in 15 seconds - press a key on the console to abort -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192184] [uefi] fresh install of 2014-07-14 11.0-CURRENT amd64 snapshot doesn't boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192184 Hiren Panchasara changed: What|Removed |Added Status|Issue Resolved |Open CC||hi...@freebsd.org Resolution|FIXED |--- --- Comment #11 from Hiren Panchasara --- (In reply to Dave Cottlehuber from comment #4) > yup, adding the following: > > set kern.vty=vt > boot_verbose="YES" > > gets us all the way to mountroot> This did not work for me. On minnowboard max, I am trying FreeBSD-11.0-CURRENT-amd64-20140714-r268622-mini-memstick.img via microSD card and console o/p looks like this: >>> FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0x79bab000 EFI version: 2.40 EFI Firmware: EDK II (rev 1.00) FreeBSD/amd64 EFI loader, Revision 1.1 (r...@grind.freebsd.org, Mon Jul 14 18:35:42 UTC 2014) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0xfb6e98 data=0x1296b0+0x4e96e0 syms=[0x8+0x140e38+0x8+0x15ba73] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 3 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -sv ?[37;44mBooting...?[0m Start @ 0x802db000 ... / (and sits there forever) I also tried following combination without success (and same failure as above): 'set kern.vty=vt' 'set hw.vga.textmode=1' and 'set kern.vty=vt' 'set hw.vga.textmode=1' and 'set kern.vty=syscons' I haven't attached hdmi to this yet so no clue whats going on there. This is how I got the image on sdcard: # dd if=/home/hirenp/Downloads/FreeBSD-11.0-CURRENT-amd64-20140714-r268622-mini-memstick.img of=/dev/mmcsd0 bs=1m conv=sync 232+1 records in 233+0 records out 244318208 bytes transferred in 24.974703 secs (9782627 bytes/sec) # gpart show mmcsd0 => 3 475616 mmcsd0 GPT (1.8G) [CORRUPT] 31600 1 efi (800K) 1603 32 2 freebsd-boot (16K) 1635 471936 3 freebsd-ufs (230M) 4735712048 4 freebsd-swap (1.0M) I've been told that [CURRUPT] in the o/p above is "okay" and not the real problem. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192315] high load average while idle, slow keyboard reaction
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192315 --- Comment #10 from Steve Wills --- (In reply to Alexander Motin from comment #9) > > Hmm. It looks like the deepest C-state was actually disabled automatically. > Then it is surprising to have any problem with LAPIC. But, just to be sure > that BIOS does not fool us, could you disable all C-states completely with > something like this in rc.conf: > performance_cx_lowest="C1" > economy_cx_lowest="C1" > , and if it won't help, also disable C1E in BIOS. Setting performance_cx_lowest="C1" and economy_cx_lowest="C1" in rc.conf did seem to help. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192324] New: [uefi] 2014-07-14 11.0-CURRENT snapshot doesn't boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192324 Bug ID: 192324 Summary: [uefi] 2014-07-14 11.0-CURRENT snapshot doesn't boot Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Keywords: uefi Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: hi...@freebsd.org CC: dmaho...@isc.org On minnowboard max, I am trying FreeBSD-11.0-CURRENT-amd64-20140714-r268622-mini-memstick.img via microSD card and console o/p looks like this: >>> FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0x79bab000 EFI version: 2.40 EFI Firmware: EDK II (rev 1.00) FreeBSD/amd64 EFI loader, Revision 1.1 (r...@grind.freebsd.org, Mon Jul 14 18:35:42 UTC 2014) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0xfb6e98 data=0x1296b0+0x4e96e0 syms=[0x8+0x140e38+0x8+0x15ba73] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 3 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -sv ?[37;44mBooting...?[0m Start @ 0x802db000 ... / (and sits there forever) I also tried following combination without success (and same failure as above): 'set kern.vty=vt' 'set hw.vga.textmode=1' and 'set kern.vty=vt' 'set hw.vga.textmode=1' and 'set kern.vty=syscons' I haven't attached hdmi to this yet so no clue whats going on there. This is how I got the image on sdcard: # dd if=/home/hirenp/Downloads/FreeBSD-11.0-CURRENT-amd64-20140714-r268622-mini-memstick.img of=/dev/mmcsd0 bs=1m conv=sync 232+1 records in 233+0 records out 244318208 bytes transferred in 24.974703 secs (9782627 bytes/sec) # gpart show mmcsd0 => 3 475616 mmcsd0 GPT (1.8G) [CORRUPT] 31600 1 efi (800K) 1603 32 2 freebsd-boot (16K) 1635 471936 3 freebsd-ufs (230M) 4735712048 4 freebsd-swap (1.0M) I've been told that [CURRUPT] in the o/p above is "okay" and not the real problem. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192184] [uefi] fresh install of 2014-07-14 11.0-CURRENT amd64 snapshot doesn't boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192184 Hiren Panchasara changed: What|Removed |Added Status|Open|Issue Resolved Resolution|--- |FIXED --- Comment #12 from Hiren Panchasara --- (In reply to Hiren Panchasara from comment #11) > (In reply to Dave Cottlehuber from comment #4) > > yup, adding the following: > > > > set kern.vty=vt > > boot_verbose="YES" > > > > gets us all the way to mountroot> > > This did not work for me. On minnowboard max, I am trying > FreeBSD-11.0-CURRENT-amd64-20140714-r268622-mini-memstick.img via microSD > card and console o/p looks like this: > > >>> FreeBSD EFI boot block >Loader path: /boot/loader.efi > Consoles: EFI console > Image base: 0x79bab000 > EFI version: 2.40 > EFI Firmware: EDK II (rev 1.00) > > FreeBSD/amd64 EFI loader, Revision 1.1 > (r...@grind.freebsd.org, Mon Jul 14 18:35:42 UTC 2014) > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0xfb6e98 data=0x1296b0+0x4e96e0 > syms=[0x8+0x140e38+0x8+0x15ba73] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 3 seconds... > > Type '?' for a list of commands, 'help' for more detailed help. > OK boot -sv > ?[37;44mBooting...?[0m > Start @ 0x802db000 ... > / > > (and sits there forever) > > I also tried following combination without success (and same failure as > above): > 'set kern.vty=vt' > 'set hw.vga.textmode=1' and 'set kern.vty=vt' > 'set hw.vga.textmode=1' and 'set kern.vty=syscons' > > I haven't attached hdmi to this yet so no clue whats going on there. > > This is how I got the image on sdcard: > # dd > if=/home/hirenp/Downloads/FreeBSD-11.0-CURRENT-amd64-20140714-r268622-mini- > memstick.img of=/dev/mmcsd0 bs=1m conv=sync > 232+1 records in > 233+0 records out > 244318208 bytes transferred in 24.974703 secs (9782627 bytes/sec) > > # gpart show mmcsd0 > => 3 475616 mmcsd0 GPT (1.8G) [CORRUPT] >31600 1 efi (800K) > 1603 32 2 freebsd-boot (16K) > 1635 471936 3 freebsd-ufs (230M) > 4735712048 4 freebsd-swap (1.0M) > > I've been told that [CURRUPT] in the o/p above is "okay" and not the real > problem. This looks like a separate issue. Closing this bug and opened a new one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192324 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192325] New: [PATCH] snmp_pf: add support for retrieving ALTQ counters
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192325 Bug ID: 192325 Summary: [PATCH] snmp_pf: add support for retrieving ALTQ counters Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: timm...@monkeyplayground.net Created attachment 145235 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145235&action=edit This patch updates snmp_pf (both the module and the MIB) to allow retrieval of the ALTQ counters. The FreeBSD base system contains a snmp daemon called bsnmpd. It implements most of its functionality via loadable modules. The snmp_pf module is responsible for constructing the MIB for the pf packet filter. Currently, it retrieves a description of the ALTQ queues in use by pf, however it doesn't support retrieving any statistics for those queues. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192262] the -S flag of newfs do not take effective,sector size always set to 512
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192262 Jov changed: What|Removed |Added Status|Needs Triage|Issue Resolved Resolution|--- |Works As Intended -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
