narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - Publicly Logged on https://irclog.whitequark.org/linux-amlogic
Darkmatter66 has quit [Ping timeout: 244 seconds]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 245 seconds]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 268 seconds]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 245 seconds]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 246 seconds]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 245 seconds]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #linux-amlogic
afaerber has joined #linux-amlogic
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #linux-amlogic
jelly has quit [Read error: Connection reset by peer]
Darkmatter66 has quit [Ping timeout: 272 seconds]
jelly-home has joined #linux-amlogic
Darkmatter66 has joined #linux-amlogic
jelly-home is now known as jelly
Darkmatter66 has quit [Ping timeout: 268 seconds]
Darkmatter66 has joined #linux-amlogic
<khilman> xdarklight: looks like a bug in my lab is resulting in no kernel modules installed into the ramdisk, a lot fewer drivers are probed, so that's a pretty big difference
<khilman> in neither case do they rely on networking for the basic boot test though, so that's why they both are PASS
<khilman> I think the lab-baylbre one is getting to shell also, it's just getting cut off from the end of the log for some reason. If it didnt' reach a shell problem, it would not have been marked PASS
vagrantc has joined #linux-amlogic
<xdarklight> khilman: so I didn't break it - which is good I believe :)
<xdarklight> that "shell output cut off" problem also seems to affect the Khadas VIM for example: https://storage.kernelci.org/next/master/next-20190814/arm64/defconfig/gcc-8/lab-baylibre/boot-meson-gxl-s905x-khadas-vim.html
Darkmatter66 has quit [Ping timeout: 244 seconds]
Darkmatter66 has joined #linux-amlogic
<BlueMatt> hmm, anyone seen this: "NETDEV WATCHDOG: eth0 (meson8b-dwmac): transmit queue 0 timed out"
<BlueMatt> may be hardware at fault, but left a server dead for a bit before i noticed
<BlueMatt> on odroid-c2
<BlueMatt> it then "meson8b-dwmac c9410000.ethernet eth0: Reset adapter." but never resumed responding to pings
<BlueMatt> strangely enough, after the reset, it was still responding to ARP requests, but wouldn't actually process any packets
<BlueMatt> in the sense that attempts to send generated a send() failure
<BlueMatt> eg "snmpd[6778]: send response: Failure in sendto"
<BlueMatt> I suppose, at the least, treat it as a bug report in that resetting the adapter after a fault doesn't succeed in bringing it back up
<xdarklight> BlueMatt: I have not seen this before. maybe ccaione or jbrunet (who have also spent time debugging the MAC driver) have an idea
<xdarklight> also it's likely that this is related to the dwmac core (Ethernet MAC IP block which Amlogic buys from Synopsys instead of implementing their own) instead of the Amlogic specific extensions (meson8b-dwmac, which mostly consist of clock settings and PHY interface control)
<xdarklight> there are some guys on the netdev mailing list which are supporting the stmmac driver (the driver for the dwmac core), so you may ask there as well
vagrantc has quit [Quit: leaving]