pabs has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 480 seconds]
evgeny_boger1 has quit [Ping timeout: 480 seconds]
sunshavi_ has joined #linux-sunxi
dikiy has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
dikiy has quit [Read error: Connection reset by peer]
dikiy has joined #linux-sunxi
dikiy has quit [Ping timeout: 480 seconds]
gnarface__ has joined #linux-sunxi
gnarface is now known as Guest1014
gnarface__ is now known as gnarface
Guest1014 has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
<wens>
apritzel: brain dump on h3/h5 usb host not having phy: IIRC the host would always have VBUS enabled, and that could conflict with MUSB's assumption that it had control over VBUS
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
evgeny_boger has joined #linux-sunxi
apritzel has joined #linux-sunxi
evgeny_boger has quit [Quit: evgeny_boger]
evgeny_boger has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
cnxsoft has quit []
apritzel has joined #linux-sunxi
evgeny_boger has quit [Quit: evgeny_boger]
apritzel_ has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
apritzel_ has quit [Ping timeout: 480 seconds]
szemzoa has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
dikiy has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
grming has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
JohnDoe_71Rus has quit []
Mangy_Dog has quit [Ping timeout: 480 seconds]
dikiy_ has joined #linux-sunxi
dikiy has quit [Ping timeout: 480 seconds]
dikiy_ has quit []
dikiy has joined #linux-sunxi
<dikiy>
How can I track instant reboots? I already connected a Serial console, set the debug level to 8, but was not able to catch nothing
<dikiy>
In other ocasion I would say it is because of overheating, but the temp. sensors dont report nothing abnormal
<dikiy>
The device is PinePhone (Allwinner A64 SoC)
<dikiy>
it occurs on playing videos
<DuClare>
Do you have pstore? That's where you may find messages from just before reboot
JohnDoe_71Rus has joined #linux-sunxi
<dikiy>
I grab all the output from serial console
<dikiy>
Didnt hear about pstore, could it help? Can it catch something that serial console cant?
<DuClare>
In theory. If something is printed to serial console, what guarantees that the buffers are flushed before the system resets? Dig deep in code and find out, maybe.
<dikiy>
the interesting fact is, that if the crash occures (need some time to occure), then after rebbot it only needs few minutes
<dikiy>
and after second and third, and so on
szemzoa has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft has quit []
Mangy_Dog has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
<libv>
dikiy: and the quick repeat crashes are also due to video?
<libv>
have you tried blacklisting the driver, and then trying to reproduce the issue?
<dikiy>
libv: yes
<dikiy>
I was playing some 1080p video with mpv
<dikiy>
with GPU accel enabled: VO: [gpu] 1920x1080 yuv420p
<dikiy>
libv: which driver should I blacklit? BTW, I doubt the 1080p can be played without acceleration
dikiy has quit [Read error: Connection reset by peer]
vagrantc has joined #linux-sunxi
freemangordon has quit [Quit: Leaving.]
dikiy has joined #linux-sunxi
freemangordon has joined #linux-sunxi
<libv>
dikiy: can you reproduce it with smaller videos?
<libv>
i think the module is sunxi-cedrus.ko, but i do not have a sunxi system up and running to verify
<libv>
check your lsmod
<jernej>
dikiy: with mpv you most probably don't use HW accelerated video decoding
<jernej>
for that to actually work, you need patched ffmpeg and mpv build from latest development branch
<jernej>
on the other hand, latest stable gstreamer should work with H264, MPEG2 and VP8.
<anarsoul>
jernej: is there any progress with merging ffmpeg patches?
apritzel has quit [Ping timeout: 480 seconds]
<dikiy>
jernej: I can not imagine, that PP manages 1080p without lags without HW decoding
<dikiy>
libv: I will try to do it with smaller one
<dikiy>
jernej: as I paste before, mpv says VO: [gpu] (whatever this means :)
<jakllsch>
that's just video output going through GL
<anarsoul>
dikiy: that's vo (video output). It uses gpu for colorspace conversion and scaling
<dikiy>
oh, so A64 can do 1080p h264 decoding only with CPU? wow
<anarsoul>
I guess depends on codec and bitrate
<anarsoul>
it can do 720p for sure
<anarsoul>
but you don't want to use sw decoding if you running off battery :)
<dikiy>
libv: sunxi-cedrus is loaded, yes
<dikiy>
how can I test if HW decoding is enabled or disabled?
<dikiy>
I think I figured it out... it is disabled
evgeny_boger has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
dikiy has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
<jernej>
anarsoul: no, not yet. RPi4 also has stateless (request api) hevc driver, but it needs improved handling (async, not a step locked approach). So current plan is to extend RPi ffmpeg patches to cover AW and RK too and send that instead.