narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - Publicly Logged on https://irclog.whitequark.org/linux-amlogic
<chewitt> brads do you have a patch for your suggested change (to make sure I understand it.. )
<chewitt> i've seen an issue where the kernel locks up when making file transfers with the Beelink GT-King devices; after a few hundred MB
<chewitt> which smells kind of similar
<chewitt> so I would like to test
camus1 has joined #linux-amlogic
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
_whitelogger has joined #linux-amlogic
warpme_ has joined #linux-amlogic
ldevulder has joined #linux-amlogic
kaspter has joined #linux-amlogic
paulk-leonov has joined #linux-amlogic
chewitt has joined #linux-amlogic
BlueMatt has joined #linux-amlogic
Tony_mac32 has joined #linux-amlogic
bengal has joined #linux-amlogic
Elpaulo has joined #linux-amlogic
GNUtoo has joined #linux-amlogic
Lyude has joined #linux-amlogic
vdehors has joined #linux-amlogic
Anessen97_0 has joined #linux-amlogic
niceplace has joined #linux-amlogic
acw4 has joined #linux-amlogic
Linnaea has joined #linux-amlogic
bas25 has joined #linux-amlogic
yann has joined #linux-amlogic
psydruid has joined #linux-amlogic
return0e[m] has joined #linux-amlogic
rtp has joined #linux-amlogic
l-as has joined #linux-amlogic
ccaione has joined #linux-amlogic
khilman has joined #linux-amlogic
lvrp16 has joined #linux-amlogic
saintdev has joined #linux-amlogic
jbrunet has joined #linux-amlogic
cyrozap has joined #linux-amlogic
zkrx has joined #linux-amlogic
afaerber has joined #linux-amlogic
gaspode has joined #linux-amlogic
repk has joined #linux-amlogic
The_Coolest has joined #linux-amlogic
ndufresne has joined #linux-amlogic
tlwoerner has joined #linux-amlogic
probono has joined #linux-amlogic
xdarklight has joined #linux-amlogic
ldts has joined #linux-amlogic
ddevault has joined #linux-amlogic
angerman has joined #linux-amlogic
robogoat has joined #linux-amlogic
sputnik_ has joined #linux-amlogic
PPA has joined #linux-amlogic
steev has joined #linux-amlogic
random_yanek has joined #linux-amlogic
narmstrong has joined #linux-amlogic
Darkmatter66_ has joined #linux-amlogic
brads has joined #linux-amlogic
vagrantc has joined #linux-amlogic
TheAssassin has joined #linux-amlogic
buzzmarshall has joined #linux-amlogic
phh has joined #linux-amlogic
JerryXiao has joined #linux-amlogic
maciejjo has joined #linux-amlogic
ChanServ has joined #linux-amlogic
commavir has joined #linux-amlogic
adema has joined #linux-amlogic
jelly has joined #linux-amlogic
AUser has joined #linux-amlogic
_whitelogger has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
buzzmarshall has quit [Remote host closed the connection]
wens has joined #linux-amlogic
bengal has quit [Ping timeout: 264 seconds]
bengal has joined #linux-amlogic
<chewitt> thanks, will have a poke shortly
_whitelogger has joined #linux-amlogic
random_yanek has quit [Ping timeout: 260 seconds]
sputnik_ has quit [Read error: Connection reset by peer]
sputnik_ has joined #linux-amlogic
random_yanek has joined #linux-amlogic
Barada has joined #linux-amlogic
chewitt has quit [Quit: Adios!]
kaspter has quit [Ping timeout: 272 seconds]
kaspter has joined #linux-amlogic
cottsay has joined #linux-amlogic
<cottsay> Hi, folks. I've been having some issues with u-boot on my ODROID-N2 booting a kernel via EFI. This worked previously, and after some bisecting, I've determined that it's related to the hardware RNG.
<cottsay> The first bad commit is e4837da782, which is a merge commit. From the most recent RC of u-boot, if I revert 6da749d8b3 (which enables the hardware RNG on Meson devices, from what I can tell), I'm able to start the kernel via EFI.
<cottsay> The problem must be in the merge, because 6da749d8b3 boots just fine as well. Is this a known issue? Is it specific to the G12B?
<jbrunet> brads, narmstrong: If ONESHOT should not be set, I'd like to understand why. The kernel says`IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
<jbrunet> * irq line disabled until the threaded handler has been run. `
<jbrunet> * Used by threaded interrupts which need to keep the
<jbrunet> keeping the hard irq disabled until both the hard and threaded irq handler are done seems to make sense.
<jbrunet> brads: did the RT folks give you details as to why this is causing a deadlock ?
<jbrunet> I'm confused about how allowing the irq to re-arm earlier would solve a locking issue (and not make it worse)
<narmstrong> jbrunet: if ONESHOT is kept, the irq is kept as hard irq in RT mode, and not moved to a thread irq, so either the hard irq handler must be fixed to work in RT mode, either the irq handler must be fixed to work without ONESHOT
<brads> jbrunet: they suggested that meson_mmc_irq runs in hard interupt context which is not RT safe. When they looked further it was not running force threaded and suggested the patch above so resolve. I did some testing and no longer saw stalls using mmc and the deadlock detection no longer flagged it as a problem during boot
<brads> From the stack trace they also first suggested it was related to led control (ie maybe a conflict between heartbeat led and mmc led function in the mmc driver - eg for refernece https://pastebin.com/W7VHy1V8
<narmstrong> The RT mode moves all the hard irq handlers into threads, except the ones with IRQF_NO_THREAD/IRQF_PERCPU/IRQF_ONESHOT
<narmstrong> There is no strong reasons to keep the mmc irq handler into hard irq
<jbrunet> @narmstrong: sure fixing would be nice. I'm happy to do it -
<jbrunet> The fact is nothing says ONESHOT is going to the irq any "harder" than it is
<brads> 5.9-rc is the first release where RT is being implemented into mainline for arm64 (it is already there for other archs)
<jbrunet> That's not what the kernel code says ... if it does more than that, then kernel code/comment should be updated
<narmstrong> jbrunet: the only way to keep the IRQF_ONESHOT feature ( irq line disabled until the threaded handler has been run) is to not migrate it to a thread
cmeerw has joined #linux-amlogic
<brads> jbrunet, narmstrong: I also like the idea of having the interupt threaded (I think, im no expert) so that I can schedule them on the cpu of my liking via affinity settings so as to not to disturb my realtime processes
<jbrunet> I'm not confortable re-enabling the irq until the processing of the current one is done. The RT issue does not seems related that. RT does not move IRQF_ONESHOT to to thread and that might be a problem but it does not make it safe when it comes to this driver.
<jbrunet> RT is able to move hard irq to thread even there is a threaded part, but not if the the IRQ is re-armed after the thread has run ...
<jbrunet> Looks like a pitfall to me ...
<jbrunet> brads: Please send the patch to the ML and include the RT folks ... I'm sure they'll
<jbrunet> be able to make sense out of this
<brads> ok I see, thanks for the details and will do. I can ask them to join the channel maybe if you would like to discuss here.
<brads> jbrunet: they did ask to be cc'ed in on the discussion
<jbrunet> No - ML is the right place for this
<brads> ok Thanks :)
<jbrunet> No other can find it and refer to it later on
<jbrunet> s/No/So
<jbrunet> Thanks to you :)
paulk-leonov has quit [Ping timeout: 272 seconds]
paulk-leonov has joined #linux-amlogic
<cottsay> Hi again. In reference to the u-boot issue I brought up a couple of hours ago with the ODROID-N2, I pulled out my ODROID-C4 and I can see the same problem. Same workaround: reverting 6da749d8b3 allows the system to boot, so it's likely the same regression is affecting both systems.
vicencb has joined #linux-amlogic
<narmstrong> cottsay: hi, on linux ?
<narmstrong> cottsay: oh, I missed the previous messages
<narmstrong> cottsay: can you be more precise about the boot failure ?
<narmstrong> cottsay: is it linux or u-boot failing ?
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-amlogic
emOne has joined #linux-amlogic
emOne has quit []
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-amlogic
kaspter has quit [Excess Flood]
kaspter has joined #linux-amlogic
emOne has joined #linux-amlogic
camus1 has joined #linux-amlogic
emOne_ has joined #linux-amlogic
<emOne_> which mainline kernels work with panfrost?
<emOne_> some complained that 5.9 was worse than 5.8
<emOne_> oops wrong channel
kaspter has quit [Ping timeout: 272 seconds]
camus1 is now known as kaspter
emOne has quit [Ping timeout: 240 seconds]
<emOne_> narmstrong: Can things like the video decoders and HEVC (when it will be ready) be used in older kernels like 5.4?
<emOne_> or will I have to use the newest mainline kernel for that?
<narmstrong> emOne_: 5.4 only has mpeg2 decoding, to have h264 and vp9 you’ll need a newer kernel
<emOne_> thank you
emOne_ has quit [Remote host closed the connection]
Barada has quit [Quit: Barada]
sputnik_ has quit [Ping timeout: 260 seconds]
Barada has joined #linux-amlogic
emOne has joined #linux-amlogic
Barada has quit [Quit: Barada]
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-amlogic
chewitt has joined #linux-amlogic
Darkmatter66 has joined #linux-amlogic
Darkmatter66_ has quit [Ping timeout: 256 seconds]
ldevulder_ has joined #linux-amlogic
ldevulder has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-amlogic
emOne has quit [Remote host closed the connection]
<cottsay> narmstrong: Sorry for the delay. The error comes just after GRUB tries to boot the kernel: `EFI stub: ERROR: Unable to construct new device tree.`
<narmstrong> cottsay: could you report this to Heinrich Schuchardt on the uboot mailing list ?
<narmstrong> And maybe #u-boot to xypron
<cottsay> narmstring: Will do. Thanks for the referral.
aballier has joined #linux-amlogic
vicencb has quit [Quit: Leaving.]
vicencb has joined #linux-amlogic
camus1 has joined #linux-amlogic
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
vicencb has quit [Quit: Leaving.]
TheAssassin has quit [Ping timeout: 240 seconds]
TheAssassin has joined #linux-amlogic
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
trem has joined #linux-amlogic
kaspter has quit [Ping timeout: 240 seconds]
camus1 has joined #linux-amlogic
camus1 is now known as kaspter
sputnik_ has joined #linux-amlogic
vicencb has joined #linux-amlogic
ccaione has quit [Ping timeout: 240 seconds]
narmstrong has quit [Ping timeout: 272 seconds]
bas25 has quit [Ping timeout: 244 seconds]
warpme_ has quit [Ping timeout: 272 seconds]
steev has quit [Ping timeout: 260 seconds]
angerman has quit [Ping timeout: 260 seconds]
warpme_ has joined #linux-amlogic
bas25 has joined #linux-amlogic
narmstrong has joined #linux-amlogic
angerman has joined #linux-amlogic
steev has joined #linux-amlogic
ccaione has joined #linux-amlogic
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #linux-amlogic
trem has quit [Quit: Leaving]
cmeerw has quit [Ping timeout: 244 seconds]
sputnik_ has quit [Ping timeout: 256 seconds]
vicencb has quit [Quit: Leaving.]
kaspter has quit [Ping timeout: 260 seconds]
camus1 has joined #linux-amlogic
camus1 is now known as kaspter
narmstrong has quit [Read error: Connection reset by peer]
bas25 has quit [Read error: Connection reset by peer]
khilman has quit [Read error: Connection reset by peer]
warpme_ has quit [Read error: Connection reset by peer]
lvrp16 has quit [Ping timeout: 240 seconds]
saintdev has quit [Ping timeout: 240 seconds]
angerman has quit [Ping timeout: 260 seconds]
narmstrong has joined #linux-amlogic
angerman has joined #linux-amlogic
warpme_ has joined #linux-amlogic
lvrp16 has joined #linux-amlogic
bas25 has joined #linux-amlogic
khilman has joined #linux-amlogic
saintdev has joined #linux-amlogic
narmstrong has quit [Ping timeout: 256 seconds]
narmstrong has joined #linux-amlogic
warpme_ has quit [Quit: Connection closed for inactivity]