paulk-leonov-spa has quit [Ping timeout: 260 seconds]
paulk-leonov has joined #linux-sunxi
yann|work has joined #linux-sunxi
<sbbg>
typically, when a driver went wrong, mostly the logs are printed by printk(), accessible in dmesg, right?
<sbbg>
It's just kind of disturbing to find out that dynamic frequency scaling cannot work for pineh64 board in X for me. I'm wondering about if I can do anything.
abelvesa has quit [Quit: leaving]
abelvesa has joined #linux-sunxi
AneoX has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
craigo has quit [Ping timeout: 240 seconds]
florian_kc has joined #linux-sunxi
reinforce has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
paulk-leonov has quit [Ping timeout: 244 seconds]
paulk-leonov has joined #linux-sunxi
florian_kc is now known as florian
paulk-leonov has quit [Ping timeout: 244 seconds]
paulk-leonov has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 256 seconds]
Mangy_Dog has joined #linux-sunxi
mauz555 has joined #linux-sunxi
paulk-leonov has quit [Ping timeout: 256 seconds]
paulk-leonov has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 260 seconds]
paulk-leonov has quit [Excess Flood]
paulk-leonov has joined #linux-sunxi
paulk-leonov has quit [Excess Flood]
ganbold has joined #linux-sunxi
paulk-leonov has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 246 seconds]
iyzsong has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-sunxi
paulk-leonov has quit [Ping timeout: 264 seconds]
paulk-leonov has joined #linux-sunxi
paulk-leonov has quit [Excess Flood]
paulk-leonov has joined #linux-sunxi
victhor has joined #linux-sunxi
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Remote host closed the connection]
parazyd has quit [Remote host closed the connection]
matthias_bgg has joined #linux-sunxi
parazyd has joined #linux-sunxi
dev1990 has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
Kasreyn has quit [Ping timeout: 265 seconds]
Kasreyn has joined #linux-sunxi
<sunshavi>
KotCzarny: without music connnection also drops. I have seen that when testing opippc as wifi repeater
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-sunxi
<KotCzarny>
you might want to find a 100% repeatable test
<KotCzarny>
but i've seen that direct ethernet connection between oranges or bananas is often flaky
<KotCzarny>
adding any ethernet switch makes it work better
dddddd has joined #linux-sunxi
<sunshavi>
KotCzarny: usb to ethernet helps also. But one less usb available for other purposes.
daregap has quit [Quit: daregap]
<sunshavi>
i have all usb ports used. usb-otg for fel, one for bluetooth dongle, one for hdd, one for wifi. And sometimes I use opipc on my car. So usb-hub not a possibility
<KotCzarny>
why not?
<sunshavi>
when i need to drive. too much thinks to do before i start driving the car
<sunshavi>
s/thinks/things/
<KotCzarny>
maybe your problem is powering then?
<KotCzarny>
wifi+hdd can eat a bit
<KotCzarny>
+ethernet
<sunshavi>
not hdd on a car yet, just uSD
<sunshavi>
no ethernet on the car yet
<KotCzarny>
anyway, check if adding ethernet switch helps
<sunshavi>
but. You could get the idea. same happens when i put the opipc on my roof far extending wifi for my children playing there now @ quarantine time
<sunshavi>
sometimes for using with usb-to-ethernet. J just unplug the bluetooth dongle
<KotCzarny>
for now you are debugging a problem, not whole solution at home
<KotCzarny>
and the problem is finding why the ethernet drops sometimes
<KotCzarny>
unless i misunderstood
<sunshavi>
yes thats the problem
<sunshavi>
ok. today I am going to turn on it @ the router place for having it connected by a switch
<sunshavi>
and see how it behaves
<sunshavi>
thinking a little bit about it. finally that connection is going to consume wifi. another alternative could be putting the usb-ethernet dongle on the opi+2e. That would count as a switch?
<KotCzarny>
nope
<KotCzarny>
maybe a bit, depending on the usbdongle quality
<sunshavi>
when i put usb-ethernet on opipc connection never drops
<KotCzarny>
if it's autonegotiation failing, you would need different manufacturers
<plaes>
sunshavi: can you show the dmesg logs for dwmac?
<sunshavi>
probably here in a switch. It could just be a hiccups. But on my case i need to give ip adress again on opi+2e. for reconnecting happens from opipc to opipc+2e
<sunshavi>
So. That's the main difference
<KotCzarny>
i would bet on some electrical problem
<KotCzarny>
in soc or the board
<KotCzarny>
or cabling
<sunshavi>
cabling not. reason usb-ethernet work reliably
<sunshavi>
problem could be also on opi+2e thinking a little bit further
<sunshavi>
also remember thinkpad with the same connection to opi+2e never failed. Thinkpad was connected that way for more than a year
<sunshavi>
problem could be on opipc or on opi+2e. I am going to check dwmac on opi+2e
<sunshavi>
I have this on opi+2e: dwmac-sun8i 1c30000.ethernet eth0: Link is Down
<sunshavi>
which one started the drop?
<KotCzarny>
you would need to get clocks synchronized to guess that
<sunshavi>
then. I am going to sync both clocks with world time now
<sunshavi>
time slew seems to have been minimal: ntpd: time slew -0.017143s
<sunshavi>
after drops happens again. how Could I know which one was first?
<KotCzarny>
compare dmesgs?
<sunshavi>
does dmesg have time?
gaston1980 has joined #linux-sunxi
<sunshavi>
yes. it has
<sunshavi>
ok. connecting again and trying again
<sunshavi>
as time slew was minimal. It seems issue is on opipc. But when connection drops I am going to confirm that
<[TheBug]>
in newer versions 'dmesg -T' gives you dmesg output with time, older versions you would have to calculate time your self
tnovotny has joined #linux-sunxi
<sunshavi>
TheBug: I have just calculated it
<sunshavi>
sorry dmesg -T works
macc24 has quit [Quit: WeeChat 2.8]
macc24 has joined #linux-sunxi
craigo has joined #linux-sunxi
<sunshavi>
brb. probably when i am going to be back at home drop should have been happened.
florian has joined #linux-sunxi
tllim has joined #linux-sunxi
florian has quit [Ping timeout: 246 seconds]
macc24 has quit [Ping timeout: 246 seconds]
florian has joined #linux-sunxi
RichardG867 has quit [Quit: Keyboard not found, press F1 to continue]
florian has quit [Read error: Connection reset by peer]
florian has joined #linux-sunxi
tnovotny has quit [Ping timeout: 246 seconds]
macc24 has quit [Ping timeout: 246 seconds]
andy25225 has quit [Ping timeout: 260 seconds]
andy25225 has joined #linux-sunxi
macc24 has joined #linux-sunxi
return0e has quit []
return0e has joined #linux-sunxi
return0e has quit [Read error: Connection reset by peer]
return0e has joined #linux-sunxi
nashpa_ has joined #linux-sunxi
nashpa has quit [Ping timeout: 256 seconds]
damex has quit [Quit: damex]
damex has joined #linux-sunxi
tnovotny has joined #linux-sunxi
aloo_shu has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 260 seconds]
gediz0x539 has joined #linux-sunxi
<gediz0x539>
hi all. I'm trying to increase spi clock frequency on A13 to boot to the linux faster from an spi nor flash. currently im working on pretty much up to date uboot, 2020.04 and I could not change speed with sspi/sf probe commands and I have also tried increase spi-max-frequency (to 24 mhz) on dts to no avail. I have tweaked spi registers located at 0x01c05000 with "mw" command but I'm unable to read back what I write using "md". I'm s
<gediz0x539>
ure the registers I'm adjusting are R/W. any suggestions?
AneoX has joined #linux-sunxi
<[TheBug]>
gediz0x539: people here are in many different time zones so you may not get answer for many hours, if you are serious about wanting an answer you should idle here until at least tomorrow so anyone who may be able to help has a chance to answer you.
tuxd3v has quit [Quit: Leaving]
<gediz0x539>
[TheBug]: thanks a lot, I know. I actually lurk here a lot. im in no hurry but if I somehow get an advice it'd be good. otherwise, if I find something significant I'll contribute it to the wiki.
return0e has quit [Read error: Connection reset by peer]
<karlp>
the warning is 10 minutes before the link flap though?
macc24 has quit [Quit: WeeChat 2.8]
Mangy_Dog has quit [Ping timeout: 256 seconds]
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
yann|work has quit [Ping timeout: 265 seconds]
<sunshavi>
karlp: the promiscuos warning is inocuos on my use case
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
<karlp>
so your "proof" is what then?
<megi>
time
<sunshavi>
coul I get a better backtrace when this happens?. Which part of the kernel source code is involved here?
<sunshavi>
10m was the time i took the connection to drop
<sunshavi>
karlp: megi is right about 'time'
<karlp>
assuming those have sufficienctly synched clocks, if it's still taking 7 seconds to detect link downs between them that's jsut out of step timeouts, I wouldn't call it a smoking gun
<sunshavi>
karlp: when music happens that my signal for a connection drop
<sunshavi>
sorry when music stops
<karlp>
but that's x time after it really drops based on how much your players buffer...
<sunshavi>
i am cooking. connection drops. And I came back to machine and do the dmesg cmd. I was reassuring which device has the issue (just in case)
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #linux-sunxi
psydread has left #linux-sunxi [#linux-sunxi]
florian has quit [Ping timeout: 244 seconds]
florian has joined #linux-sunxi
<sunshavi>
playes buffers is not important, music just stops cos opipc can not send the sound to opi+2e. buffer is not part of it
psydread has joined #linux-sunxi
florian has quit [Remote host closed the connection]
lkcl has joined #linux-sunxi
AneoX has quit [Ping timeout: 264 seconds]
AneoX has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
ldevulder__ has quit [Ping timeout: 246 seconds]
lurchi_ is now known as lurchi__
KotCzarny has quit [Ping timeout: 240 seconds]
mauz555 has quit [Read error: Connection reset by peer]
aloo_shu has quit [Read error: Connection reset by peer]