Re: Periodical interrupt storm when playing game with USB keyboard
On 01/21/18 23:57, Johannes Lundberg wrote: Thanks for the further explanation. I curious as to where the problem might be though.. It is the game's binary-only Linux executable (Unreal Engine 2.5), Linux SDL 1.2, or on the FreeBSD side? Haven't experienced anything similar with Quake3... Switching to periodic timer feels like overkill but it does the job as a work around. You might get a clue if you ktrace the binary and look for timer or system calls which have a timeout. --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: Periodical interrupt storm when playing game with USB keyboard
On 01/21/18 23:57, Johannes Lundberg wrote: Thanks for the further explanation. I curious as to where the problem might be though.. It is the game's binary-only Linux executable (Unreal Engine 2.5), Linux SDL 1.2, or on the FreeBSD side? Haven't experienced anything similar with Quake3... Switching to periodic timer feels like overkill but it does the job as a work around. Hi, It might be simply this, that the wrong clock-type is used when setting up absolute timeouts. --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: Periodical interrupt storm when playing game with USB keyboard
On Mon, Jan 22, 2018 at 8:23 AM, Hans Petter Selasky wrote: > On 01/21/18 23:57, Johannes Lundberg wrote: > >> Thanks for the further explanation. >> I curious as to where the problem might be though.. It is the game's >> binary-only Linux executable (Unreal Engine 2.5), Linux SDL 1.2, or on the >> FreeBSD side? Haven't experienced anything similar with Quake3... >> Switching to periodic timer feels like overkill but it does the job as a >> work around. >> > > Hi, > > It might be simply this, that the wrong clock-type is used when setting up > absolute timeouts. > Actually I think the same thing happens on the Macbook (with MacOS) which has a USB internal keyboard. The Mac binary is probably the same code base as the Linux one. Running Windows binary with wine does not experience this problem, unfortunately wine can only launch this game on MacOS, not FreeBSD. I assume USB can generate higher rate of interrupts than a PS/2 which this game (*nix version) was probably designed for initially. > > --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"
lldb 6.0.0 segfaults on opening a core file
Hi, Running on -CURRENT @ Jan 20 with llvm 6.0.0, I have the following issue opening a core file with lldb: $ lldb /usr/local/bin/python2.7 -c /tmp/python2.7_90218_0.core (lldb) target create "/usr/local/bin/python2.7" --core "/tmp/python2.7_90218_0.core" Assertion failed: (template_counter >= 0), function ConsumeTemplateArgs, file /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp, line 245. This nothing happens for a couple of minutes and then it dumps core. Interestingly though, it can open its own core: %> lldb /usr/bin/lldb -c /tmp/lldb_1129_0.core (lldb) target create "/usr/bin/lldb" --core "/tmp/lldb_1129_0.core" Core file '/tmp/lldb_1129_0.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'lldb', stop reason = signal SIGABRT * frame #0: 0x000803e642ea libc.so.7`__sys_thr_kill at thr_kill.S:3 frame #1: 0x000803e642b4 libc.so.7`__raise(s=6) at raise.c:54 frame #2: 0x000803e64229 libc.so.7`abort at abort.c:67 frame #3: 0x000803ee38f1 libc.so.7`__assert(func=, file=, line=, failedexpr=) at assert.c:53 frame #4: 0x017fa8e5 lldb`::ConsumeTemplateArgs() at CPlusPlusNameParser.cpp:245 frame #5: 0x017f9f12 lldb`::ParseFullNameImpl() at CPlusPlusNameParser.cpp:551 frame #6: 0x017f97d9 lldb`::ParseFunctionImpl() at CPlusPlusNameParser.cpp:114 frame #7: 0x017f96f5 lldb`::ParseAsFunctionDefinition() at CPlusPlusNameParser.cpp:45 frame #8: 0x017ec364 lldb`::Parse() at CPlusPlusLanguage.cpp:202 frame #9: 0x017ec3e7 lldb`lldb_private::CPlusPlusLanguage::MethodName::GetBasename(void) at CPlusPlusLanguage.cpp:218 frame #10: 0x016ffcba lldb`::InitNameIndexes() at Symtab.cpp:294 frame #11: 0x017008b1 lldb`::PreloadSymbols() at Symtab.cpp:407 frame #12: 0x018dce19 lldb`::PreloadSymbols() at Module.cpp:1416 frame #13: 0x016b1e14 lldb`::GetSharedModule() at Target.cpp:2028 frame #14: 0x019c14ed lldb`::LoadModuleAtAddress() at DynamicLoader.cpp:171 frame #15: 0x0199fd35 lldb`::LoadAllCurrentModules() at DynamicLoaderPOSIXDYLD.cpp:537 frame #16: 0x0199d9aa lldb`::DidAttach() at DynamicLoaderPOSIXDYLD.cpp:171 frame #17: 0x01698231 lldb`::LoadCore() at Process.cpp:2853
Re: SG116j install crashed
On Sat, Jan 20, 2018 at 08:25:08PM +0900, KIRIYAMA Kazuhiko wrote: > At Thu, 18 Jan 2018 15:35:41 +0900, > my wrote: > > > > Hi, all > > > > I've bought Biccamera's original bland note PC (SG116j) > > impulsively because of cheapness($1780). I've installed > > 12.0-CURRENT(r327788) right away. Booted smoothly but set > > loader conf "unset hint.uart.1.at" and configure disk with > > > > mmcsd0 58 GB GPT > > mmcsd0p1 200MB efi > > mmcsd0p2 54 GB freebsd-ufs / > > mmcsd0p3 4.2 GB freebsd-swapnone > > > > But in "Tetching distribution files" of base.txz, crashed > > with: > > > > sdhci_acpi0-slot0: Controller timeout > > sdhci_acpi0-slot0: == REGISTER DUMP == > > sdhci_acpi0-slot0: Sys addr: 0x02158000 | Version: 0x1002 > > sdhci_acpi0-slot0: Blk size: 0x0200 | Blk cnt: 0x00f8 > > sdhci_acpi0-slot0: Argument: 0x017f57e8 | Trn mode: 0x0027 > > sdhci_acpi0-slot0: Present: 0x1fff0106 | Host ctl: 0x1025 > > sdhci_acpi0-slot0: Power:0x000b | Blk gap: 0x0080 > > sdhci_acpi0-slot0: Wake-up: 0x | Clock:0x0007 > > sdhci_acpi0-slot0: Timeout: 0x0007 | Int stat: 0x0001 > > sdhci_acpi0-slot0: Int enab: 0x05ff0033 | Sig enab: 0x05ff003a > > sdhci_acpi0-slot0: AC12 err: 0x8000 | Host ctl2:0x008b > > sdhci_acpi0-slot0: Caps: 0x446cc8b2 | Caps2:0x0807 > > sdhci_acpi0-slot0: Max curr: 0x | ADMA err: 0x > > sdhci_acpi0-slot0: ADMA addr:0x | Slot int: 0x > > sdhci_acpi0-slot0: === > > mmcsd0: Error indicated: 1 Timeout > > : > > (snip) > > : > > Stopped at kdb_enter+0x3b: movq$0,kdb_why > > db> > > > > Detail log has put in [1]. BTW I used [2] so all stuffs are > > within it and it should not be fetched to internet. > > > > Is there any idea to go forth? > > > > Best regards. > > > > [1] http://35.200.82.201/~kiri/freebsd/sg116j/crash_in_install.jpeg > > [2] FreeBSD-12.0-CURRENT-amd64-20180110-r327788-memstick.img > > I've got r328126 memstic and install with it, then all went > to perfect! Thanx for FreeBSD-CURRENT team! FYI, I believe that you had hit the bug fixed in r327924; sorry about that. Marius ___ 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: Periodical interrupt storm when playing game with USB keyboard
Hi Yeah the timers eventually get coalesced unless someone's asking for a ridciulously accurate timer value. So is some driver asking for hyper-accurate callout timer that isn't being coalesced? hps, is there any useful debugging to try and find callouts that are requesting stupidly accurate timers? Maybe a dtrace probe on the callout schedule entry point? -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"
Re: Periodical interrupt storm when playing game with USB keyboard
On Tue, Jan 23, 2018 at 9:48 AM, Adrian Chadd wrote: > Hi > > Yeah the timers eventually get coalesced unless someone's asking for a > ridciulously accurate timer value. > > So is some driver asking for hyper-accurate callout timer that isn't > being coalesced? hps, is there any useful debugging to try and find > callouts that are requesting stupidly accurate timers? Maybe a dtrace > probe on the callout schedule entry point? > > > > -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" > I'd say dtrace might be able to get you in the right direction very quickly. I used SDL in the past for android apps and the code is very Linux specific. I am sure there's some Linux related timers in there somewhere that FreeBSD is returning nothing from and that's what's killing the performance. I can almost guarantee that none of the SDL designers and or programmers use any *BSD systems. The easiest solution would be to go look at the timer code and implement something that FreeBSD can work with and try to get that upstream. These are just a few of the issues that will crop up when devs try to just use shims to hook into the Linux kernel. Do the design work up front and implement things in a native way or enjoy the jank. DTrace should be able to point you in the right direction relatively quickly. The DTraceBook: https://www.amazon.com/DTrace-Dynamic-Tracing-Solaris-FreeBSD/dp/0132091518 Best ___ 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"
