niceplace has quit [Remote host closed the connection]
niceplace has joined #linux-rockchip
niceplaces has joined #linux-rockchip
niceplace has quit [Ping timeout: 240 seconds]
hexdump0815 has joined #linux-rockchip
<hexdump0815>
is anyone here running a veyron (i.e. rk3288) chromebook with a recent mainline? i just upgraded my kernel to 5.10.1 and it looks like at least the screen does not seem to come back after suspend
<hexdump0815>
it was working well a few versions back i think ... in the logs i see it enter and leave the suspend, but the screen only shows a blinking cursor
<hexdump0815>
anyone else having similar issues or has an idea what might have broken it or if there are any fixes around already?
<tuxd3v>
well I used the v2.14.0 straith from the website,
<tuxd3v>
then the new driver has a peculiar behaviour..
<tuxd3v>
when things go south it resets, its maccaddress is 00:00:00:00:00:00
<tuxd3v>
I just prevented him from generate a random maccadress and crafted by hand the one I wanted
<tuxd3v>
usign the defaut window congestion algo( 'reno' ) I coudn't yet reproduce the error
<tuxd3v>
using the algo 'cubic', I succeded in reproducing the error, but it manages to recover from it later since I assigned by handthe same maddaddress the previous packets had
<tuxd3v>
err, handthe -> hand
<tuxd3v>
anarsoul, its not a clean solution, as it still manake to reset, but I only saw him reset using the 'cubic' algo for window congestion..
<tuxd3v>
with reno I made some 4 times 8 hours each, and no bug
<tuxd3v>
also is uses a lot less cpu
<anarsoul>
I see
<anarsoul>
I'll just get myself asix adapter
stikonas has quit [Remote host closed the connection]
<tuxd3v>
the mainline kernel module for it is very very old
<tuxd3v>
v 1.11.1
<tuxd3v>
the latest version is v2.14.0
<tuxd3v>
but in this version I don't like the ramdom generation of maccadress when a reset occurs..
<tuxd3v>
So I commented the functions that do that, and crafted my own maccadress, so it will assign always the same..
stikonas has joined #linux-rockchip
<tuxd3v>
also I added 'usbcore.quirks=0bda:8153:k usbcore.autosuspend=-1' just in case, but I made tests without this on bootargs
<anarsoul>
well, I guess it's better to avoid any realtek devices
<anarsoul>
the only stable rnetworking hw from realtek that I've seen is rtl8139
<anarsoul>
anything else - ethernet or wifi is unstable crap