<gurki>
not mine, but ive played with it in the past and it worked
<gurki>
be aware that having verilator running only is a very small part of the overall task "boot linux within an rtl simulation"
<Guest36>
Thanks will check it out
* bjdooks
is going to have to give up on messing around with warning checks and go do some realwork
xliang has joined #riscv
<xliang>
Do EV manufacturers use RISC-V?
Wickram has quit [Quit: WeeChat 3.8]
seds has quit [Server closed connection]
seds has joined #riscv
xliang has quit [Remote host closed the connection]
<conchuod>
arnd: is there something different about s390 & platform devices? Was looking at <202306192215.TvQco9m6-lkp@intel.com>
<conchuod>
Or is that some sort of implicit header includes issue? The driver does include platform_device.h so not too sure what is going awry & there are clearly issues unrelated to that driver w/ the same functions.
<arnd>
conchuod: it looks like the problem is the invalid 'select USB_PHY' statement in Kconfig: once Kconfig is unable to resolve the dependencies, all kinds of things can go wrong, and you end up with drivers getting built that have unmet dependencies
<conchuod>
arnd: Ah, okay. Thanks.
<arnd>
CONFIG_USB_LGM_PHY solves that by using 'depends on USB_SUPPORT', which I think should be sufficient here
<arnd>
conchuod: the background here is that on s390, you don't have CONFIG_HAS_IOMEM set by default, unless PCI is enabled, so lib/devres.c does not get built either
<arnd>
wihtout PCI and IOMEM, there is also no USB, so the dependency leads to this driver not getting built
<bjdooks>
is there anything that wouldn't have one of those these days?
<conchuod>
arnd: Yeah, I figured there was something like that at play. Thanks.
<arnd>
bjdooks: pcie was added as an option in z12, about a decade ago, but I would assume that there are still some around that either predate z12 or that did not need the option
<arnd>
bjdooks: all the distro kernels should enable PCIe support I assume
JanC has quit [Ping timeout: 240 seconds]
<conchuod>
arnd: What was weird to me about it is that it was an allmodconfig, rather than a randconfig.
<arnd>
conchuod: indeed, that is strange. I see HAVE_PCI=y and PCI=n in the .config they used. There are some known problems with building random PCI drivers on s390, so maybe the lkp folks intentionally disable PCI in their s390 allmodconfig builds to have less noise
<conchuod>
There's clearly a bunch of other issues with that allmodconfig anyway, so wouldn't be surprised.
JanC has joined #riscv
Guest36 has quit [Quit: Client closed]
JanC has quit [Ping timeout: 240 seconds]
JanC has joined #riscv
JanC has quit [Ping timeout: 240 seconds]
Wickram has joined #riscv
aurel32 has quit [Server closed connection]
aurel32 has joined #riscv
JanC has joined #riscv
ntwk has joined #riscv
heat has joined #riscv
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
aerkiaga has joined #riscv
awita has joined #riscv
ntwk has quit [Quit: ntwk]
MaxGanzII_ has quit [Ping timeout: 240 seconds]
Armand has joined #riscv
Wickram has quit [Quit: WeeChat 3.8]
aerkiaga has quit [Remote host closed the connection]
wgrant has quit [Ping timeout: 240 seconds]
mturquette has quit [Server closed connection]
mturquette has joined #riscv
wgrant has joined #riscv
Xark has joined #riscv
elastic_dog has quit [Ping timeout: 240 seconds]
<conchuod>
palmer: What does it have issues linking? vmlinux.o?
<palmer>
and the trunk run is at 40 minutes, so I have a feeling ever 16 is just really slow
<conchuod>
Hmm, I've just used ClangBuiltLinux clang version 16.0.0 (/stuff/brsdk/llvm/clang 08d094a0e457360ad8b94b017d2dc277e697ca76) to build your for-next, took 16 minutes - which not unreasonable for no ccache and -j 28
<palmer>
I'm talking just the link step
<palmer>
that's allyesconfig?
<conchuod>
Yup
<palmer>
wacky
<conchuod>
I've got some later versions of clang/llvm, I'll try those too
<palmer>
so maybe something's hosed on this machine? I'm building LLVM from source, just however those build scrips Nathan sent do it
<conchuod>
Ye, I built it from source too using nathan's scripts
<palmer>
wacky
<palmer>
we have super weird machines here at work, but I doubt they're 4x slower running the linker
<conchuod>
I'll go try whatever llvm-17 trunk that I have & 16.latest, and then reply to your mail
<palmer>
cool, thanks
elastic_dog has joined #riscv
billchenchina has joined #riscv
billchenchina- has joined #riscv
vagrantc has joined #riscv
billchenchina has quit [Ping timeout: 260 seconds]
<palmer>
maybe we just VDSO the non-coherent ops in userspace? that way we have an out if we need more complex stuff later
<palmer>
though maybe anything doing userspace IO to non-coherent devices is just sufficiently vendor-specific that we don't care any more?
JanC has quit [Ping timeout: 240 seconds]
prabhakar has joined #riscv
prabhakarlad has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
Tenkawa has joined #riscv
JanC has joined #riscv
awita has quit [Ping timeout: 240 seconds]
zapb_ has quit [Ping timeout: 258 seconds]
jobol has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #riscv
zapb_ has joined #riscv
zapb_ has quit [Ping timeout: 260 seconds]
enoq has quit [Quit: enoq]
enoq has joined #riscv
ldevulder has quit [Quit: Leaving]
zapb_ has joined #riscv
ntwk has joined #riscv
somlo__ is now known as somlo
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #riscv
BootLayer has quit [Quit: Leaving]
JanC_ has joined #riscv
JanC is now known as Guest9671
JanC_ is now known as JanC
Guest9671 has quit [Ping timeout: 240 seconds]
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
vgtw_ has joined #riscv
vgtw has quit [Ping timeout: 252 seconds]
awita has joined #riscv
<courmisch>
conchuod: well if something doesn't work it doesn't work, yes, though that would obviously be up to user-space to figure out that it can't work
<courmisch>
not that I personally have any use of UIO
terminalpusher has quit [Remote host closed the connection]
<conchuod>
courmisch: to be clear, I am not against putting zicbom in hwprobe if there's legitimate interest - just in that situation you probably need to fail probing in the first place & not even create the uio device if the extension isn't present.
<courmisch>
conchuod: is it even possible for the kernel to know that Zibcom will be necessary? I am not familiar with UIO
<conchuod>
You can check if a device is non-coherent from DT & there's a function to check what extensions are available.
<conchuod>
I'd much rather not have that crap in UIO though :)
<conchuod>
And I am sure Hellwig would too
awita has quit [Remote host closed the connection]
Tenkawa has quit [Quit: Was I really ever here?]
Tenkawa has joined #riscv
prabhakarlad has quit [Quit: Client closed]
rsalveti has quit [Quit: Connection closed for inactivity]
danilogondolfo has quit [Remote host closed the connection]
<nathanchance>
palmer: Sorry I’ve been silent on the LLD DCE issue, have my head down with other regressions ATM. I might have some time tomorrow to help triage, otherwise it won’t be until next week that I can get to it. I would be curious to know if a performance regression is visible with defconfig + CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y compared to defconfig.
<palmer>
nathanchance: no worries on my end, we can probably just wait a cycle
<conchuod>
nathanchance: From a quick test, about 1 second on my box for -j 30. Good bit of noise though.
<conchuod>
Also, I was thinking - not really a regression for anything other than allyesconfig since the HAVE_ option isn't enough to turn it on.
<conchuod>
It's only things like LKP or other CI that'll get hit - and the hit is penal if you do many all*configs a day.
<nathanchance>
conchuod: You mean like our CI? :P I will see if I can get something wired up with hyperfine, should be able to objectively demonstrate an issue that way. If it does not show up with defconfig, it is possible there is some combination of configurations that is needed to trigger this and it might be easier to tell exactly what is going wrong once we know what those are, I can try a configuration bisect
Armand has quit [Quit: Leaving]
<conchuod>
It's only a regression for things that build the testing types of configs is what I meant, not for defconfig. I didn't realise it was a default N config with an ARCH_HAS. I thought there was just the ARCH_HAS nathanchance
<muurkha>
awesome
rsalveti has joined #riscv
enoq has quit [Quit: enoq]
<conchuod>
I build yes and no config too nathanchance so I don't want it merged if it'll add 2h to the build ;)
<conchuod>
(not that allnoconfig really matters here, the too was in reference to allmodconfig)