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
Pali has quit [Ping timeout: 246 seconds]
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
Tokamak has quit [Ping timeout: 250 seconds]
Tokamak has joined #armlinux
Grimler has quit [Ping timeout: 246 seconds]
Grimler has joined #armlinux
Tokamak_ has joined #armlinux
Tokamak has quit [Ping timeout: 246 seconds]
apritzel_ has quit [Ping timeout: 246 seconds]
frieder has quit [Ping timeout: 258 seconds]
Tokamak_ has quit [Ping timeout: 244 seconds]
Tokamak has joined #armlinux
frieder has joined #armlinux
Tokamak has quit [Ping timeout: 255 seconds]
Tokamak has joined #armlinux
Tokamak has quit [Ping timeout: 244 seconds]
Tokamak has joined #armlinux
Tokamak has quit [Remote host closed the connection]
Tokamak has joined #armlinux
Tokamak_ has joined #armlinux
Tokamak_ has quit [Remote host closed the connection]
Tokamak_ has joined #armlinux
Tokamak has quit [Ping timeout: 246 seconds]
iivanov has joined #armlinux
cbeznea has joined #armlinux
rvalue has quit [Ping timeout: 258 seconds]
sakman has quit [Remote host closed the connection]
Crassus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Amit_T has joined #armlinux
headless has quit [Quit: Konversation terminated!]
Turingtoast has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<mwalle>
specifying "earlycon" on the commandline twice will trigger the WARN() register_console() (at least on arm or if CONFIG_ACPI_SPCR_TABLE is not enabled). Is that a bug or expected behavior?
sheb has joined #armlinux
headless has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
jlinton has quit [Quit: Client closed]
NonaSuomy has joined #armlinux
headless has quit [Quit: Konversation terminated!]
sicelo_ has quit [Quit: Bye!]
prabhakarlad has quit [Quit: Client closed]
machaddr has joined #armlinux
jlinton has joined #armlinux
cbeznea has quit [Quit: Leaving.]
Turingtoast has joined #armlinux
NonaSuomy has quit [Ping timeout: 256 seconds]
jlinton has quit [Quit: Client closed]
Turingtoast has quit [Client Quit]
machaddr_ has joined #armlinux
machaddr has quit [Ping timeout: 260 seconds]
cbeznea has joined #armlinux
machaddr_ is now known as machaddr
monstr has quit [Remote host closed the connection]
iivanov has quit [Quit: Leaving...]
NonaSuomy has joined #armlinux
headless has joined #armlinux
Turingtoast has joined #armlinux
tre has quit [Remote host closed the connection]
jlinton has joined #armlinux
c1728p9 has joined #armlinux
<ardb>
arnd: tmlind, i'm not convinced going further down the SMP_ON_UP() rabbit hole is worth the effort, given that the hang occurs in the middle of a cpufreq transition, and that CONFIG_MUSB_PIO_ONLY=y appears to make the stall go away
<ardb>
i.e., too many seemingly entirely unrelated symptoms to make sense of this
<ardb>
the only thing that could be useful at this point is better info regarding what's keeping task context from making progress
<arnd>
ardb: not sure, it still feels like the best lead to me, given that we have narrowed the bisection down to a few instructions. I was hoping that if he can figure out which of the macro changes triggers it, it will suddenly make sense.
<arnd>
the next best alternative I see is to give up and address it by throwing out the entire patching for V6 along with the SMP+V6 Kconfig
<ardb>
i would not object to that on principle, but it doesn't seem like a great way to address this particular issue, given that we have no idea whether it causes it or simply unmasks it
<ardb>
arnd: i'm not going to object if you really want to merge it now, but i'm not sure i understand the sudden rush
cleger has quit [Quit: Leaving]
<arnd>
ardb: it's mainly about having something that glibc can build on. We spent a lot of time debating over the usr ABI, and this is all resolved now. I previously objected to the glibc port being merged while the kernel port is in progress, but don't want to hold that one up now
<ardb>
fair enough
<ardb>
i think most of the boot related questions can be addressed (and fixed) later
<arnd>
obviously they could decide to just merge glibc port anyway based on us saying that the kernel ABI is final, but having it actually merged is a cleaner approach.
<arnd>
ok
<ardb>
what i don't like is the magic numbers in the image, even though there is no bare metal boot ABI, only ELF or EFI
headless has quit [Quit: Konversation terminated!]
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<ardb>
so as long as doing the merge now does not prevent those from being removed later, i'm fine with it
NonaSuomy has quit [Ping timeout: 276 seconds]
<arnd>
ardb: did you send that as reply on the list for v11? I don't see any reply from you about it
<arnd>
ardb: your reply looks completely garbled in gmail, though it's fine in the lore.kernel.org archive, I wonder if they had the same problem reading it