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
PeterChen has joined #armlinux
gpiccoli has quit [Quit: Quit...]
gpiccoli has joined #armlinux
apritzel has quit [Ping timeout: 245 seconds]
PeterChen has quit [Remote host closed the connection]
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #armlinux
rockosov has quit [Ping timeout: 272 seconds]
rockosov has joined #armlinux
tlwoerner has quit [Ping timeout: 268 seconds]
tlwoerner has joined #armlinux
nsaenz has joined #armlinux
System_Error has quit [Remote host closed the connection]
nsaenz has quit [Remote host closed the connection]
<krzk>
PeterChen: if you do not send it to maintainers, no one will apply it, so no need for pinging :)
<krzk>
PeterChen: There is a guide in kernel about new soc upstreaming also telling where to send the patch and the difference between review process and sneding for merging
nsaenz has joined #armlinux
<krzk>
PeterChen: please read maintainer-soc really thorough, because it explains it. Useful to read also maintainer-soc-clean-dts
nsaenz has quit [Client Quit]
<PeterChen>
krzk: thanks, let me read it.
<arnd>
PeterChen: I'm sorry I dropped the ball on this, should have replied earlier. I'm still trying to pick up the final bits for the merge window and should be able to get to it soon
<maz>
PeterChen: I would have appreciated being CC'd on this, since I reviewed some of the previous versions. not cc'ing reviewers isn't very good practice.
nsaenz has joined #armlinux
psydroid2 has joined #armlinux
<PeterChen>
maz: I am sorry about it, I will cc you if there is another version.
<PeterChen>
arnd: thanks
apritzel has joined #armlinux
sibis has quit [Remote host closed the connection]
CrashTestDummy has joined #armlinux
CrashTestDummy has quit [Client Quit]
siak has joined #armlinux
<ajb-linaro>
is there anywhere I can go spurlunking in the kernel to find out why IO tasks are unkillable and unstraceable?
siak_ has joined #armlinux
siak has quit [Ping timeout: 272 seconds]
<arnd>
ajb-linaro: I would start by looking at /proc/$PID/stack, which should give you a backtrace if it's stuck in the kernel
<ajb-linaro>
ardb I guess waiting and never waking up after the PCI device is re-enabled ^
<ardb>
arnd: ^^^
ardb has quit [Quit: Updating details, brb]
ardb has joined #armlinux
<ajb-linaro>
ardb: sorry about that ;-)
<ardb>
no worries, first time this happened :-)
monstr has joined #armlinux
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 252 seconds]
monstr has quit [Ping timeout: 252 seconds]
nsaenz has joined #armlinux
siak_ has quit [Remote host closed the connection]
siak has joined #armlinux
fvincenzo has joined #armlinux
<arnd>
ajb-linaro: right, this is just the normal uninterruptible wait for an I/O device in blk_wait_io(). There is no timeout and no way to kill the task. The observer behavior is very similar for a device that is completely stuck (no longer causing interrupts) and one that is just really slow (writing lots of data to a slow SD card)
<arnd>
what type of device are you reading from?
<ajb-linaro>
arnd: virtio-block device using a virtio-pci transport
<ajb-linaro>
^ that is how the test toggles the PCI Command Register's Bus Master Enabling and I guess it never recovers
siak_ has joined #armlinux
<arnd>
ajb-linaro: I can see how turning off DMA while the block layer is waiting for a DMA completion will cause it to wait forever, but I'm not sure if that is actually the problem.
siak__ has joined #armlinux
siak has quit [Remote host closed the connection]
siak_ has quit [Ping timeout: 248 seconds]
tsc1 has quit [Read error: Connection reset by peer]
apritzel has quit [Remote host closed the connection]
tsc1 has joined #armlinux
mvaittin has quit [Ping timeout: 265 seconds]
PeterChen has quit [Remote host closed the connection]
PeterChen has joined #armlinux
sally_ is now known as sally
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #armlinux
haritz is now known as saimazoon
biju has joined #armlinux
<biju>
geertu: can-transceiver-phy can-phy0: /can-phy0: failed to get mux-state (0)
<arnd>
mmind00: are the commits the identical? I can merge your pull request, but I worry that this would make things worse if 'git merge' ends up doing the revert on top of the original commit once it gets to torvalds. Not sure if that's still a problem in git these days, but I've seen it happen in the past
<arnd>
if two identical patches are in different branches, just leaving them there is usually easier
<mmind00>
arnd: yes the commits are identical ... just the Signed-off-by is different of course ... and the linux-next scripts complained
<mmind00>
arnd: ok, if leaving it in works, then ignore the pull-request please :-)