• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    chrismade got a reaction from Igor in Upgrading cubox-i Buster from Kernel 5.7.y to 5.8.y breaks ethernet   
    I'm currently in contact with maintainers of this driver "at803x" - the first assumption that just a single line regarding the device ID (see my post above ... modules.aliases, which btw is created by depmod) was missing in the driver source was (unfortunately) wrong. The driver for this device has been widely reworked from 5.7.x (rather simple, only recognizing AT8030 and AT8035) to 5.8.x (now rather complex and supporting much more devices from that family beyond 8030/8035) - 
    Another finding was that NOT ALL cuboxes are impacted -  already reported by Igor that his regression box is still ok.
    From my collection 2 out of 3 are working ok also with 5.8.x kernel and higher
    This one has issues (stopped working after upgrade to 5.8.x)
    SolidRun i4P TV-300-D
    while these are still working
    SolidRun 4x4 300-D 
    SolidRun i2EXW 300-D 
    if the (last 3 bytes from) MAC address is just incrementing during production then the one box having issues is in between the two which are working - 
    The two which are working have WiFi and the one which has issues does not -  but that does not fit to the post above from "Armbian User" who reported issues on a WiFi version
    There might be one more thing
    find /sys -name phy_id
    reported on the systems which work (on 5.8.x and beyond)
    while my system which breaks reports
    which has two differences:
    after /devices/ we see /soc0/ instead of /platform/
    and further in the path
    /2188000.ethernet-1:04/ instead of /2188000.ethernet-1:00/
    device tree seems to be the same for all 
    there are small differences - and these seem to matter - 
    if someone still reads this post ... and wants to contribute ... and has a system which broke from upgrading 5.7.x > 5.8.x *kindly check on your system* and post results here - for
    find /sys -name phy_id
    which is always an important part of troubleshooting to sort apart systems which still work and those which break - and to find reliable criteria which belongs to which group