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> Posterdati: full URL please?
<Posterdati> I deleted the old one, and changed to the new: http://obs.linaro.org/linaro-overlay-bullseye/bullseye/
<ukleinek> Posterdati: I'd look into http://obs.linaro.org/linaro-overlay-bullseye/bullseye/Packages for the right contacts
<Posterdati> shall I use https://paste.debian.net/1229547/
<Posterdati> ?
<Posterdati> sorry
<ukleinek> that won't work
<Posterdati> I know...
<Posterdati> what is the correct form then?
* 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
<ajb-lina-> http://ix.io/3OE5
<ajb-lina-> mrutland: ^
<ajb-lina-> if I'm working with a core dump gdb would complain it can't access the memory
matthias_bgg has quit [Remote host closed the connection]
<mrutland> hmm, so the generated addr is 0? Is that the base of the TLS?
<mrutland> (i.e. was that TPIDR_EL0 + 0 ) ?
apritzel_ has joined #armlinux
<mrutland> Hmm... upstream stable v5.4.y is v5.4.176
<ajb-lina-> mrutland: AFAICT - I can't read the current state of tpdir_el0 from gdb
apritzel_ has quit [Ping timeout: 256 seconds]
<ajb-lina-> but it checks out with we print at the start
<ajb-lina-> http://ix.io/3OEa
<ajb-lina-> mrutland: ^
<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
<ajb-lina-> mrutland: should heap look like
<mrutland> Ah; I'd misread the prior report
<ajb-lina-> 01d10000-03d98000 ---p 00000000 00:00 0 [heap]
<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
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<ukleinek> broonie: FTR: currently there are no new spi drivers in next that would need adaption
<arnd> there may be a way to make each individual atomic op simpler, as at the moment there are something like 10 levels of indirection
<ardb> arnd: do GCC/Clang support precompiled headers?
<arnd> ardb: they both do in principle, but when I tried, I could not see any benefit
<arnd> I suspect something in kbuild completely defeats it, possibly the way we encode the module name in certain macros
Amit_T has quit [Remote host closed the connection]
<ndesaulniers> or force the build timestamp into every header
apritzel_ has joined #armlinux
torez has quit [Remote host closed the connection]
jlinton has joined #armlinux
mcoquelin has quit [Quit: Leaving]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
djrscally has quit [Quit: Konversation terminated!]
headless has quit [Quit: Konversation terminated!]
djrscally has joined #armlinux
iivanov has quit [Remote host closed the connection]
apritzel_ has quit [Quit: Leaving]
Tokamak has joined #armlinux
System_Error has joined #armlinux