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
Turingtoast has quit [Ping timeout: 260 seconds]
bps has quit [Ping timeout: 256 seconds]
Pali has quit [Ping timeout: 256 seconds]
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mraynal has quit [Read error: Connection reset by peer]
mraynal has joined #armlinux
TheCoffeMaker has quit [Ping timeout: 250 seconds]
TheCoffeMaker has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
TheCoffeMaker has quit [Ping timeout: 246 seconds]
TheCoffeMaker has joined #armlinux
Fridtjof_ has joined #armlinux
strudl- has joined #armlinux
aposm has quit [Remote host closed the connection]
<arnd>
ukleinek: did you come across another case where gcc turns ilog2() into a horrible mess, or does it do what one expects and just produce something slightly worse than ideal?
<arnd>
we've had cases in the past where gcc __builtin_constant_p() had inconsistent results and it ended up compiling const_ilog2() into awful runtime code
sudeepholla has joined #armlinux
Misotauros has joined #armlinux
sszy has joined #armlinux
macromorgan_ has joined #armlinux
macromorgan has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
macromorgan_ is now known as macromorgan
Misotauros has quit [Ping timeout: 248 seconds]
Turingtoast has joined #armlinux
torez has joined #armlinux
tagr has joined #armlinux
jlinton has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Misotauros has joined #armlinux
Turingtoast has joined #armlinux
HdkR_ is now known as HdkR
HdkR has joined #armlinux
HdkR has quit [Changing host]
monstr has quit [Remote host closed the connection]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sudeepholla_ has joined #armlinux
gpiccoli has quit [Quit: Quit...]
gpiccoli has joined #armlinux
jkridner has joined #armlinux
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #armlinux
<jkridner>
oddball question, is there a minimal arm kernel config I can target to run in userspace? Imagine that I wanted to test some drivers out that had only a network driver dependency and I'd like to run them in a container (not a VM). Anyone know of a config that would work (ie., no protected mode, no interrupt controller, STDIO or sockets-based console, sockets-based-networking, etc.)? just a couple of check-boxes to get started would be good.
<jkridner>
running qemu seems the obvious work-around, but I'd like to see if I can remove that overhead.
<marex>
jkridner: arent you looking for usermode linux ?
<jkridner>
yes
<jkridner>
it is largely as simple as that, but I'm not finding it.
<jkridner>
perfect! I kept searching user *space* linux, rather than user *mode* linux. Thanks marex !
<j`ey>
jkridner: UML doesn't work on arm I believe
<jkridner>
btw, hope you are doing well. I look forward to making it to another ELC soon. (assuming you are the right marex I've met before)
<jkridner>
j`ey: k. I was worried about that. I'll try to look for the issues and hope dragons aren't lurking.
<jkridner>
anyway, this is the exact feature I was looking for, so it gives me something clear to debug.
<marex>
good
<jkridner>
looks like Ubuntu for ARM has some of the utilities. That's a good sign.
<j`ey>
jkridner: arch/um/Kconfig includes arch/$(HEADER_ARCH)/um/Kconfig, and only arch/x86/um exists
<jkridner>
k
<jkridner>
:-( also, "The syscall interception technique used by UML makes it inherently slower for any userspace applications"
luispm has quit [Remote host closed the connection]
<jkridner>
ubuntu 'user-mode-linux' has no install candidates. unsure why it was removed.
bps has quit [Ping timeout: 260 seconds]
<maz>
jkridner: I don't think it ever worked on arm or arm64.
<marex>
maz: oh hey
<marex>
maz: do you have a moment, I would like to pick your brain
<maz>
I vaguely remember someone looking into it 6 or 7 years ago, but it went nowhere.
<maz>
marex: sure.
<marex>
(seems like a good opportunity to revisit that)
* maz
prepares to run away...
<marex>
maz: well, simple question really ... is clk_enable() supposed to work in hardirq context of irq_eoi() callback ?
<marex>
maz: or not
<marex>
I mean, there is that spinlock, which could be an issue ?
<marex>
(it is about the stm32 pinctrl driver splat ... I just didn't get to replying to you via email yet)
sudeepholla has quit [Ping timeout: 240 seconds]
<maz>
you can take any lock you want, just something that is 'stronger' than the locks the irq core already takes.
<maz>
given that we have raw spinlocks for most things, anything that is weaker (mutex or normal spinlocks) is forbidden.
<maz>
(with RT, spinlocks are downgraded to mere mutextes)
<marex>
maz: I wonder whether the clk_enable_lock() spin lock should be turned to raw one then ?
<maz>
marex: my gut feeling is that this is a bad idea. it would certainly hurt RT performance by creating larger critical sections.
<marex>
maz: I have to say, I am out of ideas how to get out of this
<maz>
I'm actually pretty dubious about the whole GPIO clocking while in interrupt.
<maz>
why isn't that on at all times?
<maz>
the moment you have a level interrupt, you need it anyway.
<marex>
maz: that's some ST oddity where they try to micro-manage clock I think in some hope to reduce power consumption
<marex>
maz: the LEVEL interrupts on that platform were not originally supported at all btw ... they were only added when I ran into this on two occasions via this emulation
<marex>
I am surprised that there aren't more platforms which require this kind of emulation and suffer from similar issues
<maz>
yes, I remember this pile of crap.
<marex>
but I guess those platforms just don't micro-manage clock that way
<maz>
sane platforms implement level support, full stop.
<maz>
honestly, I would simply increment the clk refcount each time a level interrupt is mapped, and leave it that way.
<maz>
no level, no additional cost.
<marex>
maz: to be blunt, I would just keep the clock running, neither of the platforms which need these level interrupts are battery powered
<maz>
suits me.
<marex>
and this clock micro-management seems dubious to me too
<marex>
I mean, how much can you save by turning off pincontrol block
<maz>
I think there was an email from the ST folks saying they wanted to leave it on.
<marex>
compared to this constant overhead of clock off/on back and forth, on a 650 MHz low-end core no less
<marex>
maz: yes, there was a follow up, but I didn't see the patches yet
<maz>
they'll be great, I'm sure! :D
<marex>
maz: maybe I should just send a trivial patch like that for the level IRQs and be done with it , like you suggested ?
<maz>
please do.
<marex>
maz: I do have a board instrumented for fine SoC power consumption measurement, so I could measure the difference ;-)
<maz>
at least that will get the conversation going.
<marex>
all right, I'll get the patch out like tomorrow-ish, I need to finish another patch today
<marex>
thanks !
<maz>
no hurry. it has been broken forever, it can wait another few days!
<marex>
maz: should I actually slap Fixes: tag on it ?
<marex>
I can't tell here ... is that a bug if the splat only happens with RT patch on and not with mainline ?
<maz>
up to you, really. this is really niche, and people using these SoCs rarely care about upgrading their kernel.
<maz>
but RT is upstream now, so I'd definitely consider it a bug.
<marex>
maz: people using the SoM care about keeping their LTS kernel versions up to date
<marex>
the SoM where this is an issue anyway
<maz>
well, if you think it is valuable, stick a Fixes: tag on it then.
<marex>
it is either 5.10.y or 5.15.y and damn up to date
nsaenz has quit [Remote host closed the connection]
<marex>
maz: I just don;t want to annoy greg with pushing stuff which is borderline feature
<maz>
Greg picks stuff that I never tagged for stable. and if he shouts, I'll talk to him myself.
nsaenz has joined #armlinux
<broonie>
Yeah, no need to worry about stable rules these days.
<marex>
broonie: what ?
<maz>
broonie: I used to look at what was going in. I gave up.\
<broonie>
marex: Like maz says they're getting very enthusiastic about picking stuff for stable these days, there's a bot which automatically tries to identify things that vaugely look like fixes and it's quite enthustiastic.
<marex>
broonie: I noticed there are patches which shouldn't be there, that complaint was going on for a while
<broonie>
maz: I still scan the bot stuff since that's the main risk (though I have caught Greg picking stuff that I nacked for the bot).
<marex>
I just carefully tag patches with Fixes:, but it seems any patch with "fix" in its subject gets sucked in, so I started avoiding those in what are not stable fixes
<marex>
grumb
<javierm>
yeah, I've noticed many times patches that would actually cause a regression if backported without other patches from the same series
<javierm>
when that happens I answer that shouldn't be backported but never check if that was the case
headless has joined #armlinux
<maz>
I guess one of the issues is that -stable serves as the foundation for distro kernels, and that they backports a lot of stuff. in a way, this makes these distros more robust. but it makes the -spable kernels more flaky if used standalone.
jlinton has quit [Ping timeout: 250 seconds]
<broonie>
It also encourages people to go back to manually picking patches for their production kernels after they get burned :/
<marex>
I only found two cases when something went wrong, one was during broonie vacation , oh well
<marex>
the other was some etnaviv detail which got backported too soon
<broonie>
There's been a few in the Intel audio drivers at least.
<marex>
it did indeed encourage certain people to be very vocal about cementing themselves on ancient version, but it was enough to put those issues into perspective -- 2 issues in a year seems OK
<marex>
broonie: sigh :(
<javierm>
yes, I believe the net benefit is still positive. The Fedora kernel is basically vanilla -stable and I would say is pretty stable
<marex>
javierm: the net benefit is absolutelly positive
<marex>
stable (LTS) seems like the thing industrial users want
<marex>
slow moving, no surprises (much), update once every few years