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
rvalue has quit [Ping timeout: 264 seconds]
heat has quit [Remote host closed the connection]
heat has joined #armlinux
rvalue has joined #armlinux
haritzondo is now known as haritz
haritz has quit [Changing host]
haritz has joined #armlinux
hanetzer has joined #armlinux
haritzondo has joined #armlinux
haritz has quit [Ping timeout: 252 seconds]
haritz has joined #armlinux
haritzondo has quit [Ping timeout: 256 seconds]
haritz has quit [Changing host]
haritz has joined #armlinux
qpla has quit [Read error: Connection reset by peer]
heat has quit [Remote host closed the connection]
heat has joined #armlinux
apritzel has quit [Ping timeout: 268 seconds]
heat has quit [Remote host closed the connection]
heat has joined #armlinux
basel_ has joined #armlinux
basel_ has quit [Quit: Leaving]
jclsn has quit [Ping timeout: 264 seconds]
jclsn has joined #armlinux
amitk has quit [Ping timeout: 264 seconds]
heat has quit [Remote host closed the connection]
heat has joined #armlinux
cbeznea has joined #armlinux
amitk has joined #armlinux
iivanov has joined #armlinux
mvaittin has joined #armlinux
iivanov has quit []
iivanov has joined #armlinux
iivanov_ has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
<biju>
I have a machine where arm64 udp performance is extremely worse on single processor compared dual core processor ( 89Mbps vs 940 Mbps) (with packet loss 91% vs 0.1%)
<biju>
Any idea for this performance issue? Default ARM64 configuration is for SMP
<ukleinek>
biju: I'd address the packet loss issue first. That might resolve the performance issue en passant.
<biju>
Run time I am using cpuonline to make it OFF line CPU to make single core
<bjdooks>
could the network part not notice a cpu offline and still try and delivery irqs there? otherwise sounds like a weird problem, maybe synchronisation still trying to talk to other cores?
headless has joined #armlinux
<ukleinek>
or a race condition that trashes dma descriptors when feeding the network device from two CPUs?
<ukleinek>
bjdooks: one cpu is the good case, not the bad one.
* ukleinek
reread and no, bjdooks is right
frieder has joined #armlinux
<bjdooks>
i'd say syncrhonisation issue then
<geertu>
biju: Does it matter which CPU you offline?
<maz>
spelling out the SoC and the network driver would help (this smells of Marvell stuff)
<bjdooks>
I think marvell smell whatever
<ukleinek>
..ooOO(hey, other vendors do weird stuff, too)
<bjdooks>
also, doesn't cpu0 tend to be the one favoured for irq delivery?
<biju>
geertu: Whatever the CPU, packet loss is 90%
<maz>
also trying with maxcpus=1 would be interesting.
<ukleinek>
broonie: for the renaming spi_master -> spi_controller, would you prefer replacing "struct spi_master *master" by "struct spi_controller *master" or "struct spi_controller *ctlr"?
<geertu>
biju: Does sound like a problem with IRQ delivery, falling back to polling, and having missed lots of packets in the mean time
<geertu>
Does /proc/interruots advance accordingly?
* ukleinek
bets /proc/interruots doesn't change at all during all these tests :-)
<geertu>
Let's try /proc/interrupts instead (and make sure CONFIG_PROC_FS=y, and /proc is mounted, and ... ;-)
<biju>
maz: maxcpus=1 same packet loss(91%)
iivanov_ has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
<maz>
very much looks like mvpp2 to me.
heat_ has joined #armlinux
heat has quit [Ping timeout: 260 seconds]
<ukleinek>
biju: seeking for help here and not answering the resulting questions makes a rude impression.
<biju>
ukleinek: I an checking cat /proc/interrups, I went out to drop my son to school
<ukleinek>
biju: one of the key questions you missed is: "spelling out the SoC and the network driver would help (this smells of Marvell stuff)"
<biju>
it is Renesas RAVB driver
<biju>
and SoC is RZ/V2L
<biju>
which is dual cortex a-55
<biju>
geertu: it is ~ 1798107 vs 550168
<biju>
for eth0 irq
<biju>
higher number is for dual core
sszy has joined #armlinux
prabhakar has joined #armlinux
prabhakarlad has joined #armlinux
<biju>
I see this IRQ is changed during udp testing on UP. IPI5: 237 IRQ work interrupts
sakman has joined #armlinux
<biju>
on a single core machine why IPI is changing?
ezulian has joined #armlinux
headless has quit [Quit: Konversation terminated!]
russ has quit [Ping timeout: 256 seconds]
sakman has quit [Ping timeout: 246 seconds]
mripard has joined #armlinux
apritzel has joined #armlinux
russ has joined #armlinux
psydroid has joined #armlinux
ezulian has quit [Ping timeout: 252 seconds]
bjoto has quit [Ping timeout: 245 seconds]
bjoto has joined #armlinux
heat_ has quit [Remote host closed the connection]
apritzel has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
apritzel has joined #armlinux
a3f has joined #armlinux
shoragan has joined #armlinux
<deathcamel57>
Anyone willing to take a look at my NOR flash issue from yesterday?
frieder has joined #armlinux
<apritzel>
deathcamel57: which one? I couldn't find anything in the logs ...
<deathcamel57>
I was wondering if anyone could give me some tips on how to debug why my NOR flash isn't working. I'm seeing the SPI controller for it being loaded and the version of it detected. However, the kernel never probes for the JEDEC ID. Here's some various configuration stuff for reference: https://gist.github.com/DeathCamel58/96cfb550cf27b01e520e5c57fb79fda5
bjoto has quit [Ping timeout: 264 seconds]
bjoto has joined #armlinux
<milkylainen>
cfi cmdset?
<deathcamel57>
Enabling CFI and all of the CFI command sets results in the same.
<deathcamel57>
Looks like spi_nor_probe is never called
<bjdooks>
is there a device tree entry?
<deathcamel57>
I have the device tree part related to the NOR at the link
sakman has joined #armlinux
qpla has joined #armlinux
alpernebbi has quit [Ping timeout: 260 seconds]
<broonie>
ukleinek: It's pointless to do the renaming without renaming associated variables.
<broonie>
deathcamel57: Does the controller understand the chip select that got passed in properly? This will be something in the DT parsing stuff.
alpernebbi has joined #armlinux
<deathcamel57>
Maybe? I'll look into it some. I'm using the `hisi-sfc-v3xx` driver in the kernel, which was ACPI only, but I added an `of_match_table` to allow my non-ACPI device to use it.
mvaittin has quit [Ping timeout: 256 seconds]
<deathcamel57>
Looking into drivers>spi>spi-fsl-qspi.c, it doesn't look like the reference SPI driver cares about the chipselect. spi-hisi-sfc-v3xx doesn't seem to care either. Do SPI drivers care about that, or is that handled elsewhere?
bjoto has quit [Ping timeout: 255 seconds]
bjoto has joined #armlinux
iivanov has quit []
mvaittin has joined #armlinux
iivanov has joined #armlinux
<geertu>
deathcamel57: drivers/spi/spi-hisi-sfc-v3xx.c does not procide lowlevel SPI ops, only mem_ops
<geertu>
Also, the driver may rely on earlier initialization by ACPI.
<deathcamel57>
Shouldn't that driver allow access to a mtd device it's connected to? I'm not seeing any uses of this driver to reference.
<ukleinek>
broonie: ack
headless has joined #armlinux
mvaittin has quit [Ping timeout: 268 seconds]
amitk_ has joined #armlinux
lag has quit [Read error: Connection reset by peer]