ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
djrscally has quit [Ping timeout: 256 seconds]
Pali has quit [Ping timeout: 256 seconds]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
apritzel_ has quit [Ping timeout: 256 seconds]
Tokamak has joined #armlinux
mrlemke has joined #armlinux
XV8 has joined #armlinux
balrog has quit [Ping timeout: 256 seconds]
balrog has joined #armlinux
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
XV8 has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #armlinux
Tokamak has quit [Client Quit]
amitk has joined #armlinux
Tokamak has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
iivanov has joined #armlinux
tchebb_ has quit [Ping timeout: 268 seconds]
tchebb has joined #armlinux
matthias_bgg has joined #armlinux
apritzel_ has joined #armlinux
djrscally has joined #armlinux
apritzel_ has quit [Ping timeout: 240 seconds]
<ukleinek>
Posterdati: maybe #debian is the better place to ask?
<ukleinek>
Posterdati: that's on OFTC I guess
headless has joined #armlinux
sszy has joined #armlinux
guillaume_g has joined #armlinux
nsaenz has joined #armlinux
<Posterdati>
ukleinek: they told me to come here...
<ukleinek>
Posterdati: oh
<ukleinek>
Posterdati: then you have to explain in detail what you want to do. I don't understand "configuring apt repository for overlays". overlays as in device tree overlays? Do you want to apply them dynamically in Linux? Or the bootloader?
<Posterdati>
no
<Posterdati>
in debian for arm in tinker board
<Posterdati>
binary overlays are installed and updated from a repository
<Posterdati>
which server is specified in /etc/apt/source.list.d/somefile.list
<Posterdati>
now
<Posterdati>
since I upgraded debian 10 to 11 on this device, the old repository won't work, I need a new repository which I do not know!
<Posterdati>
I searched on the net, no clue at all!
<ukleinek>
what is the old repo?
<Posterdati>
it was a linaro server obs.linaro.org/
* ukleinek
probably should know, but doesn't and claims "maybe #debian is the better place to ask?"
alexels has joined #armlinux
Amit_T has joined #armlinux
headless has quit [Quit: Konversation terminated!]
Amit_T has quit [Ping timeout: 240 seconds]
apritzel has joined #armlinux
Amit_T has joined #armlinux
Pali has joined #armlinux
headless has joined #armlinux
Amit_T has quit [Ping timeout: 240 seconds]
Amit_T has joined #armlinux
mcoquelin has quit [Remote host closed the connection]
<ajb-lina->
are there any known issues with an invalid tpdir_el0 being set for TLS on aarch64? I have a very infrequent qemu linux-user bug which segs when reading TLS on a trivial test case
<ajb-lina->
(i.e. qemu itself segs when running on aarch64 hw)
prabhakarlad has joined #armlinux
mcoquelin has joined #armlinux
headless has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
Amit_T has quit [Ping timeout: 240 seconds]
bb_eof has joined #armlinux
* ajb-lina-
goes search the kernel tree for struct processor
System_Error has quit [Ping timeout: 276 seconds]
XV9 has joined #armlinux
XV8 has quit [Ping timeout: 240 seconds]
bb_eof has quit [Quit: Leaving...]
atorgue has joined #armlinux
torez has joined #armlinux
Amit_T has joined #armlinux
<mrutland>
ajb-lina-: not that I am aware of -- is qemu writing to that by accident and corrupting it?
<mrutland>
ajb-lina-: which kernel version?
<ajb-lina->
mrutland: Linux aarch64.ci.qemu.org 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:32:12 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
<ajb-lina->
mrutland: I'm getting an occasional SEGV when qemu tries to read an internal TLS variable
<ajb-lina->
mrutland: I can reproduce in gdb - but I see the segv and gdb can access the memory
<ajb-lina->
it's in the heap although the heap is ---p
<mrutland>
looking at v5.4.88, I can't spot anything obvious w.r.t. tpidr_el0 kernel-side. We don't touch it in the entry code unless we hit a fatal kernel stack overflow, and the context-switch looks sane to me
<ajb-lina->
mrutland: yeah I don't think the value is corrupted - but the memory isn't accesible
<mrutland>
sorry, I thought the value in X0 was all zeros, rather than being the pointer 0x306f7a8
<ajb-lina->
I think gdb must be accessing the memory through some other means maybe?
<mrutland>
so tbh I'd suspect the TPIDR itself is sane, and something is corrupting memory or the mappings thereof
<mrutland>
Is this with a stable build of qemu, or a development version?
<ajb-lina->
mrutland: I'm working with HEAD - it's something we've been seeing periodically in our CI for some time
<ajb-lina->
mrutland: but it seems to occur in CI more often than running manually
<mrutland>
How painful is it to reproduce when running manually? Is it a 1/10, 1/100, or 1/UNKNOWN ?
<ajb-lina->
1/300-400 (or 1/100-200 without gdb involved)
<mrutland>
Hmmm
<mrutland>
The big problem here is v5.4.88 is ancient, even relative to stable v5.4.y, so if this is a kernel bug it might already have been fixed, and if not we don't have a good baseline for investigation.
<mrutland>
How long does it take for the issue to appear, when it does appear? Is that seconds/minutes/hours?
<mrutland>
I wonder if we can script something to run atop a more recent kernel and see if it blows up
<ajb-lina->
mrutland: also aslr seems to play a role because if you run in gdb without enabling aslr the fixed address never fails
torez has quit [Ping timeout: 240 seconds]
<ajb-lina->
mrutland: ok I'll see if I can update this cloud machine for next week
guillaume_g has quit [Quit: Konversation terminated!]
torez has joined #armlinux
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #armlinux
alexels has quit [Quit: WeeChat 3.4]
Tokamak has joined #armlinux
nsaenz has quit [Remote host closed the connection]
headless has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
apritzel_ has joined #armlinux
apritzel_ has quit [Ping timeout: 256 seconds]
<arnd>
mrutland, ndesaulniers: I have now managed to get a kernel built with the out-of-line atomics to see what impact that has on compile speed. My results with arm and arm64 defconfigs show almost exactly a 10% speedup with this, on top of the other patches from mingo
<broonie>
nice
<ndesaulniers>
these results make me think it's more worthwhile trying to automate detangling headers than improving the compilers performance.
atorgue has quit [Quit: Client closed]
<ukleinek>
broonie: do you have a plan for my series that changes spi_driver::remove?
<broonie>
khilman: It's queued to be applied at some rc, I forget which.
<ukleinek>
broonie: are you waiting for acks? are you disturbed by gregkh?
<broonie>
ukleinek: It's queued to be applied at some rc, I forget which.
<ukleinek>
broonie: ah great.
* ukleinek
checks if he missed a mail about that
<broonie>
I didn't say anything, I'm partly leaving it to sit in case anyone has anything to say about it.
* ukleinek
nods
<arnd>
ndesaulniers: the problem with the atomics is that these are actually needed almost everywhere, as spinlock, cmpxchg, and set_bit are all based on the same low-level primitives. 10% total compile time is a huge improvement for a single header file, but I like none of the solutions that would get us there:
<arnd>
out-of-line atomics as in my prototype probably have a noticeable runtime overhead, though some of that may get recovered by LTO
<ajb-lina->
mrutland: FWIW I managed to update the box to 5.16.5 and still see the same erros
<arnd>
splitting up the atomics into the most comon ones and all the rest would probably help, but be rather counterintuitive