Thursday, 2022-06-23

*** tpb <[email protected]> has joined #openrisc00:00
*** wxwisias1f <[email protected]> has quit IRC (Quit: Lost terminal)00:19
shornezx2c4: I put some debugging inside of the openrisc IPI driver, it definitely looks like its losing the IPIs08:40
shornehttps://gist.github.com/stffrdhrn/94d92b831c5f38bfc2d60dc13f978f0008:44
shorneI can see at the kernel side, but code looks ok to me08:44
shornechecking qemu side08:44
shorneI can see the same in qemu too, irq line is raised by IRQ is not firing11:27
*** wxwisiasdf <[email protected]> has joined #openrisc16:53
wxwisiasdfHello!16:53
wxwisiasdfHow can I tell gcc to use mod/div instructions from OpenRISC instead of using libgcc-generated ones?16:53
*** wxwisiasdf <[email protected]> has quit IRC (Quit: Lost terminal)18:51
shornegone... but, check out : or1k-elf-gcc --target-help19:35
*** wxwisiasdf <[email protected]> has joined #openrisc20:26
wxwisiasdfso qemu can't use vector or1k stuff right20:26
shorneyou make have missed it, check out : or1k-elf-gcc --target-help20:30
shornewxwisiasdf: I don't know of any platforms supporting vector stuff yet, sorry20:30
wxwisiasdfow, okay20:31
wxwisiasdfdoes llvm support or1k?20:32
wxwisiasdfthe only llvm i see is from 2014 which is, not good since i use c++23 for the kernel and bootloader20:33
shornewxwisiasdf: yes, there is an or1k port, its not upstream though... see here20:36
wxwisiasdfshouldn't be hard to merge with current llvm.... right?20:36
shornehttps://github.com/openrisc/llvm-or1k20:37
shornewxwisiasdf: it might not be too hard, I haven't looked at it much.  last I talked to whitequark they said merging to llvm upstream required to provide a lot of ongoing support20:38
shorneI think it should not be too hard to update the port20:38
wxwisiasdfOkay..20:39
shornezx2c4: I placed an interrupt patch on my or1k-virt-2 branch in qemu, I dont see RCU stalls in the wireguard tests anylonger20:54
shornebut its not running perfectly yet20:54
wxwisiasdfoh non, the naked attribute not support on gcc21:18
shornewxwisiasdf: what is that?21:22
wxwisiasdfshorne: i use naked functions for writing bootloaders in c21:32
wxwisiasdfsorry, not c, c++21:32
wxwisiasdfnaked functions means that the function doesn't use the stack, thus no epilogue and prologue, allowing for me to do funky stuff21:33
wxwisiasdfi already patched the s390 target to support naked functions (yes i wrote a bootsector in c++), so i guess or1k shouldn't be that hard either21:33
shornewxwisiasdf: ok, I would have thought it's supported out of the box with gcc, if you want to send patches for gcc please cc me21:38
wxwisiasdf??22:14
wxwisiasdfshorne: how do i send patches?22:14
shornezx2c4: oh, test do pass with SMP=4 now22:14
shornewxwisiasdf: git send-email, https://gcc.gnu.org/contribute.html22:14
tpbTitle: Contributing to GCC - GNU Project (at gcc.gnu.org)22:14
shornezx2c4: [  734.852000] reboot: Restarting system, very slow though on SMP22:15
zx2c4shorne: awesome! What's not running perfectly?22:15
zx2c4Ahhh speed22:15
zx2c4734sec wow22:15
shornelet me try a few more times, if its stable at least thats a start, we can figure out speed later22:15
shorneyeah I was not waiting long enough22:16
shornesomething is wrong as its much faster on UP22:16
wxwisiasdfah well i don't know since i ran clang-format22:17
wxwisiasdfi think they wont mind... right?22:17
shornezx2c4: maybe my 4way tlb patches could be dropped, the extra tlb flush work could hurt performance22:17
shornewxwisiasdf: they would mind, don't reformat code for patches, gcc code is already in the gnu standard format22:18
shornezx2c4: but good step forward I think22:18
wxwisiasdfdamn22:19
zx2c4shorne: that'd be a bummer22:20
zx2c4I suspect there's something else other than tlb flush though22:20
zx2c4Like some sort of contention 22:20
zx2c4Some mutex qemu is taking22:21
zx2c4Just a hunch though 22:21
shornezx2c4: yeah, it could be, I added some mutex's to timers its possible its causing slowness22:23
shorneill see if profiling qemu UP vs SMP shows anything22:23
shornegot to go to work now...22:24
zx2c4Your latest in your branch? Ill be home in 40 min and will play22:24
*** wxwisiasdf <[email protected]> has quit IRC (Ping timeout: 240 seconds)22:26
*** wxwisiasdf <[email protected]> has joined #openrisc22:28
shornezx2c4: yeah, just qemu needs updates I think22:37
shornezx2c4: just in case there is one patch for cache flush here: https://github.com/stffrdhrn/linux/commits/or1k-wireguard22:38
shorneI put it on top of your work, I am not sure it helps much and if it does I want to clean it up22:39
shorneI did another run and it passes22:39
shorne[  499.916000] reboot: Restarting system22:39
shorneqemu: https://github.com/stffrdhrn/linux/commits/or1k-virt22:40
shornelinux: https://github.com/stffrdhrn/linux/commits/or1k-wireguard22:40
shorne(linux stuff probably not needed, I think you have what you need on your jd/openrisc branch)22:41
zx2c4Alright22:47
zx2c4shorne: btw i moved the jd/openrisc branch into the wireguard repo because that's were itll be submitted from eventually https://git.zx2c4.com/wireguard-linux/log/?h=jd/openrisc23:30
tpbTitle: wireguard-linux - WireGuard for the Linux kernel (at git.zx2c4.com)23:30
zx2c4hey it's not hanging23:32
zx2c4ratelimiter selftests takes 13 seconds though... i guess it keeps having to retry because it's too slow or the timer is inconsistent or something?23:32
zx2c4ahh and the test that creates a big string in bash takes forever23:34
zx2c4hmm... memory write slowness? hm23:34
zx2c4   5.88%  qemu-system-or1k                                     [.] tlb_flush_page_by_mmuidx_async_023:34
zx2c4  13.62%  qemu-system-or1k                                     [.] helper_lookup_tb_ptr23:34
zx2c4yea this one test takes the majority of the time23:38
wxwisiasdfwell there we go, this is my first patch to gcc but ey, i hope it good23:57

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!