sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv | Matrix: #riscv:catircservices.org
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
elms has quit [Server closed connection]
elms has joined #riscv
powderhorn has quit [Ping timeout: 246 seconds]
GenTooMan has quit [Ping timeout: 248 seconds]
GenTooMan has joined #riscv
gruetzkopf has quit [Server closed connection]
gruetzkopf has joined #riscv
esv_ has joined #riscv
esv_ is now known as esv
aerkiaga has joined #riscv
aerkiaga has quit [Client Quit]
Tenkawa has quit [Quit: Was I really ever here?]
hightower3 has joined #riscv
hightower4 has quit [Ping timeout: 246 seconds]
Gravis_ is now known as Gravis
stolen has joined #riscv
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
rah has quit [Server closed connection]
rah has joined #riscv
davidlt has joined #riscv
pabs3 has joined #riscv
Jackneill_ has joined #riscv
yosef` has joined #riscv
yosef` has quit [Ping timeout: 246 seconds]
BootLayer has joined #riscv
billchenchina has joined #riscv
hrberg_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
hrberg has joined #riscv
Jackneill_ has quit [Ping timeout: 246 seconds]
junaid_ has joined #riscv
vagrantc has quit [Quit: leaving]
MaxGanzII_ has joined #riscv
BootLayer has quit [Quit: Leaving]
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
yosef` has joined #riscv
billchenchina has quit [Remote host closed the connection]
BootLayer has joined #riscv
crabbedhaloablut has joined #riscv
mlaga97_ has quit [Server closed connection]
mlaga97 has joined #riscv
davidlt has quit [Ping timeout: 246 seconds]
Wickram has joined #riscv
junaid_ has quit [Remote host closed the connection]
yosef` has quit [Quit: Ping timeout (120 seconds)]
GenTooMan has quit [Ping timeout: 246 seconds]
loki_val has joined #riscv
crabbedhaloablut has quit [Ping timeout: 245 seconds]
jrtc27 has quit [Server closed connection]
jrtc27 has joined #riscv
muurkha has quit [Server closed connection]
muurkha has joined #riscv
GenTooMan has joined #riscv
junaid_ has joined #riscv
monoidog has joined #riscv
junaid_ has quit [Remote host closed the connection]
davidlt has joined #riscv
Andre_Z has joined #riscv
junaid_ has joined #riscv
grgy has quit [Server closed connection]
grgy has joined #riscv
Tenkawa has joined #riscv
BootLayer has quit [Quit: Leaving]
ntwk has quit [Read error: Connection reset by peer]
ntwk has joined #riscv
Tenkawa has quit [Quit: ... ... ... ... ...]
Tenkawa has joined #riscv
cousteau has joined #riscv
GenTooMan has quit [Ping timeout: 246 seconds]
BootLayer has joined #riscv
junaid_ has quit [Ping timeout: 250 seconds]
Andre_Z has quit [Quit: Leaving.]
d0g has joined #riscv
junaid_ has joined #riscv
d0g has quit [Remote host closed the connection]
monoidog has quit [Ping timeout: 246 seconds]
indy has quit [Ping timeout: 248 seconds]
GenTooMan has joined #riscv
junaid_ has quit [Ping timeout: 244 seconds]
junaid_ has joined #riscv
jmdaemon has quit [Ping timeout: 246 seconds]
ntwk has quit [Quit: ntwk]
ntwk has joined #riscv
<Tenkawa> mps: I definitely see that performance difference
<Tenkawa> I think I have also found a pattern on these drives
junaid_ has quit [Remote host closed the connection]
<Tenkawa> Drives that don't seem to be having the problem or have less problem only have the 512 byte mode available at all.
<Tenkawa> LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)
<Tenkawa> The others have 4096 available to them as well
<Tenkawa> even when not in use they are having the problems more
<mps> you mean GPT have 512 sector size
<Tenkawa> I've noticed something something else
<Tenkawa> mps: no.. the nvme drive
<mps> ah
<Tenkawa> If you don't have a microsd in the unit the load avg runs much higher
<Tenkawa> even if not in use
<mps> my nvme have 512
GenTooMan has quit [Ping timeout: 245 seconds]
<Tenkawa> idling with the microsd ejected: 10:39:26 up 9 min, 2 users, load average: 0.54, 0.25, 0.11
<Tenkawa> (waits for a few minutes to coalesce)
<Tenkawa> 10:40:38 up 10 min, 2 users, load average: 0.23, 0.22, 0.11
<Tenkawa> just in one minute after inserted
<Tenkawa> it will eventually drop to 0
<Tenkawa> but if I took it back out it stays high
<Tenkawa> this is the other side effect I've noticed
<mps> interesting
<Tenkawa> y 10:41:57 up 12 min, 2 users, load average: 0.06, 0.17, 0.09
<Tenkawa> yeah that quickly
<Tenkawa> I'm going to test the sane on my other jh7110 shortly and see if it does the same to the load avg
bjoto1 is now known as bjoto
Stat_headcrabed has joined #riscv
GenTooMan has joined #riscv
aerkiaga has joined #riscv
indy_ has joined #riscv
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #riscv
MaxGanzII_ has quit [Ping timeout: 246 seconds]
mwette has quit [Remote host closed the connection]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
GenTooMan has quit [Ping timeout: 246 seconds]
mwette has joined #riscv
<mps> Tenkawa: I confirm, load without mmc inserted is above 0.50, while when inserted it is 0.00
<Tenkawa> Yeah.. odd spin condition eh?
<mps> now will reboot and check again
vagrantc has joined #riscv
<Tenkawa> Unfortunately my Star64 JH7110 was erroring soon as I inserted a microsd so I couldn't try to compare it
<mps> and I had to blacklist jh7110_crypto module, kernel crashes sometimes when loading it
<Tenkawa> Thats what aurel32 mentioned. I've had it disabled in my config dso I never hit that one
<Tenkawa> s/dso/so
GenTooMan has joined #riscv
aerkiaga has quit [Remote host closed the connection]
seds has quit [Server closed connection]
seds has joined #riscv
Jackneill_ has joined #riscv
junaid_ has joined #riscv
stolen has quit [Quit: Connection closed for inactivity]
MaxGanzII_ has joined #riscv
EchelonX has joined #riscv
billchenchina has joined #riscv
junaid_ has quit [Ping timeout: 255 seconds]
Wickram has quit [Quit: WeeChat 4.0.4]
FL4SHK has joined #riscv
<davidlt> Tenkawa, mps, this was reported on the kernel mailing list. AFAIK StarFive is looking into it.
<Tenkawa> davidlt: thanks for the info.. got a url for the mailing list thread?
<Tenkawa> I want to try to follow it
<Tenkawa> oh tha crypto one.. yeah I knew about that one.. I'm more interested in the cpu load one I discovered
<Tenkawa> s/tha/the
<davidlt> Tenkawa, ah sorry, didn't read all the channel log. If you think there is an issue, report it.
<Tenkawa> I haven't seen anyone report it yet however I just narrowed it down to the microsd this morning so now I might be able to report it
<Tenkawa> (or at least the microsd being involved)
<davidlt> I am not an expert here, but IIRC there could be pins to detect microSD card. Maybe something is constantly polling?
<Tenkawa> I think it is a polling issue.. with no sd it spins
<davidlt> I think it's CD pin. Here is something interesting: https://groups.google.com/g/linux.kernel/c/bsK80uCsKtQ
<davidlt> So there is polling mode to detect sd card in some drivers.
<davidlt> Have no idea what's inside StarFive eMMC.
<Tenkawa> yeah its an odd one
<Tenkawa> I need one in mine now anyway since I plan on migrating to an xfs root so it "mitigates" it.. but its a workaround lol
<Tenkawa> Since xfs booting still needs chainloading
<Tenkawa> (Unless its been added in the newest u-boot/OpenSBI)
<davidlt> Tenkawa, looking at their schematics I see CD pin is wired.
<davidlt> SD_SDIO0_CD_GPIO41
<davidlt> I don't see it listed in DTS
<Tenkawa> intriguing
<davidlt> There is "cd-gpios", description: The card detection will be done using the GPIO provided.
<davidlt> ah, but it has "broken-cd;"
<davidlt> which means "There is no card detection available; polling must be used."
Bluefoxicy has quit [Ping timeout: 255 seconds]
Bluefoxicy has joined #riscv
junaid_ has joined #riscv
esv has quit [Ping timeout: 245 seconds]
esv has joined #riscv
esv has quit [Client Quit]
<Tenkawa> There we go... much better
<Tenkawa> root@vf2:~#
<Tenkawa> /dev/nvme0n1p1 on / type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
<Tenkawa> now I have my preferred filesystem
<Tenkawa> mps: the next interesting part of that microsd discovery... have to eject/reinsert every boot to drop the load
<Tenkawa> davidlt: that does seem to go with the disconnected polling
<Tenkawa> now the pivoltal question... how to fix that so that a "physical" reseating is not needed every boot
leah2 has quit [Ping timeout: 245 seconds]
<Tenkawa> er pivotal
junaid_ has quit [Remote host closed the connection]
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
Trifton has quit [Quit: Error: no route to host]
agent314 has joined #riscv
leah2 has joined #riscv
ntwk has quit [Quit: ntwk]
arnd has quit [Server closed connection]
arnd has joined #riscv
billchenchina- has joined #riscv
billchenchina has quit [Read error: Connection reset by peer]
junaid_ has joined #riscv
GenTooMan has quit [Ping timeout: 248 seconds]
GenTooMan has joined #riscv
agent314 has quit [Ping timeout: 250 seconds]
agent314 has joined #riscv
sympt has quit [Server closed connection]
sympt has joined #riscv
jmdaemon has joined #riscv
jmdaemon has quit [Ping timeout: 246 seconds]
davidlt has quit [Ping timeout: 245 seconds]
<Esmil> ok, finally figured out why i keep getting the 'nvme0: I/O 640 QID 5 timeout, completion polled' errors on my VF2: CONFIG_INIT_ON_ALLOC_DEFAULT_ON
<Esmil> with that enabled my nvme drive works, so it seems like the starfive pcie driver (or nvme driver) is leaving garbage in some allocations :/
<Tenkawa> Esmil: did you see the above findings with microsd/nvme and high load?
<Esmil> no
<Tenkawa> mps and I have recreated this..
<Tenkawa> if you look with a nvme only the idle load average is probably running aroumd .5
<Tenkawa> after you plugin a microsd it drops to 0
<Tenkawa> until next boot
<Tenkawa> s/aroumd/around
<Tenkawa> I had been wondering what was causing the high idle
Jackneill_ has quit [Ping timeout: 246 seconds]
BootLayer has quit [Quit: Leaving]
Narrat has joined #riscv
<Tenkawa> I've also found that the only NVMe drives that seem to work with low IO errors are ones without 4096 blocksize even available (not just in use)
<Tenkawa> were you getting the IO errors with CONFIG_INIT_ON_ALLOC_DEFAULT_ON on or off?
billchenchina- has quit [Remote host closed the connection]
JSharp has quit [Server closed connection]
JSharp has joined #riscv
<Esmil> off fails =y works
<Tenkawa> Not the same here
<Tenkawa> I would check your drve's blocksize capabilties... that seems to be the most consistent finding I've found so far. 8 different models... only ones that had no problems could "only" use 512 blocksize
<Tenkawa> The 4096 ones even if they weren't enabled still had problems
<Esmil> No it's quite consistent. The same drive, same kernel config fails without it, but works with it on
<Tenkawa> zcat /proc/config.gz | grep CONFIG_INIT_ON_ALLOC_DEFAULT_ON
<Tenkawa> # CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set
junaid_ has quit [Remote host closed the connection]
<Tenkawa> haven't had a IO error since 6.5 (yours and aurels builds came out)
<Esmil> yeah, but even with it off you might get lucky that the allocations just happens to be zero or something that works
<Tenkawa> no.. on my other unit I get them all the time with the other testing scenario
<Esmil> try enabling CONFIG_INIT_ON_ALLOC_DEFAULT_ON and see if it changes anything
<Tenkawa> Ok let me find one of my other drives
<Tenkawa> Since this one is not having any errors it wont help here
<Tenkawa> Time to wait for the compile... afk for a while
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
zjason` has joined #riscv
zjason has quit [Ping timeout: 250 seconds]
cwittlut has quit [Server closed connection]
cwittlut has joined #riscv
ahs3_ has quit [Server closed connection]
ahs3 has joined #riscv
<mps> Tenkawa: I don't have to eject/reinsert mmc on boot, if it is inside load is normal when keep it inserted before booting
<Tenkawa> mps: not here.. soon as I reboot the load goes back up... We are using different u-boot and opensbi setups too if I remember correctly
<Tenkawa> Hopefully this next kernel tweak will allow the faster mvmes to run better
<mps> I test mainline u-boot and mostly use vendor/starfive u-boot, and I think behavior is same
<mps> which kernel tweak?
<Tenkawa> Esmil posted it above
<mps> CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y ?
<Tenkawa> yeah
<Tenkawa> Seems an odd fix that a kernel hardening change would affect disk io though
<mps> (Heisenberg)
<Tenkawa> but yeah.. a lot of oddities ....
<Tenkawa> and uncertainty
<mps> I could now rebuild with this enabled
<Tenkawa> I am just disappointed the other JH7110's (Pine64) aren't going to get USB mainline support in time for 6.6
<Tenkawa> So they are effectively going to have to wait.
<mps> merge window for 6.6 is not yet closed
<gurki> welp its a pine. ppl have low expectations for these to begin with.
<mps> at least less patches will be needed with 6.6 kernel
<Tenkawa> gurki: Noone/entites of resources seem to be there to take it on...
<gurki> Tenkawa: i dont by pine hardware since it always ends up the same way
<gurki> buy*
<Tenkawa> gurki: Yeah
<Tenkawa> Its got potential.. but so disorganized
ntwk has joined #riscv
EchelonX has quit [Quit: Leaving]
frkzoid has joined #riscv
freakazoid332 has quit [Ping timeout: 248 seconds]
<mps> Tenkawa: I don't see any change with CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
<Tenkawa> Yeah it seemed like a strange option to have any effect to me too
<Tenkawa> I am still going to try it on a drive though just to be thorough....
<Tenkawa> At the rate everything is going and what I have scheduled it will probably be tuesday.. I'm leaving in the morning for a camping trip
<mps> also I need a day without keyboard/screen combo
guerby has quit [Ping timeout: 248 seconds]
gurki has quit [Server closed connection]
gurki has joined #riscv
guerby has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
guerby has quit [Ping timeout: 246 seconds]
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
loki_val has quit []
<deathmist> anyone else seeing broken ethernet on next-20230831 with VisionFive 2? I'm seeing starfive-dwmac logs of e.g. "16030000.ethernet: unsupported interface -22" & "probe of 16030000.ethernet failed with error -22" which are similarly also repeated for 16040000.ethernet as well, rebooting a few times didn't change anything
<deathmist> I've been thinking of hopping off from -next now that most important patches are in mainline pending the v6.6-rc1 tag so perhaps this was my signal ;)
<deathmist> hm nvm all of these changes also landed there (https://github.com/torvalds/linux/commits/master/drivers/net/ethernet/stmicro/stmmac) so ig there's no escape for now except reverting the commit(s) that broke it as I certainly don't know how to fix it :/
<deathmist> ok so my last known working build was next-20230828 and the only change between that and next-20230831 was a014c35556b9045ece8426df2b38eb3c5e1c1aa0 which I already linked, there's a good chance it'll just work if I revert that for now
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
<Esmil> deathmist: you can try this https://github.com/esmil/linux/tree/jh7110
<Esmil> it's 6.5 + jh7110 patches that's going into 6.6 + pcie and some more from the mailing list
<deathmist> that likely will boot and work since it won't have that super recent change, I'll try the revert first
<deathmist> but thanks, I've been interested in something like this and was probably going to do the same but on top of latest mainline so I wouldn't have to do so much work of hunting down the patches etc