Pine A64+ Gigabit issue...

[rhkean]

Why does this not seem to be a big concern?

Other than the suggestion to initialize the NIC to 100mbps or plug it into a 100mbps hub, there doesn't seem to be any chatter about the fact that it hangs in a gigabit environment.


-rob

[rahlquist]

Why does this not seem to be a big concern?

Other than the suggestion to initialize the NIC to 100mbps or plug it into a 100mbps hub, there doesn't seem to be any chatter about the fact that it hangs in a gigabit environment.


-rob

Not for everyone. The other reason is it is still to early in the game to have any upsets over things not working. It is a work in progress, patience is required. 

My own testing with lenny's debian was producing full gigabit speeds for long periods of time.

[rhkean]

I may have used the wrong verbage in my initial post...

no, I don't think anyone should be upset over it.... I just expected more chatter about it... It seems to be the only real issue with the 3.10.65 kernel.
It seems like the go-to response is, "just hook it up to a 100mbps hub"... which, mind you did solve the connectivity issue and now I've got a booting debian install.

I was just surprised that there wasn't a development thread dedicated to it...

[rahlquist]

The latest kernel has no issue as far as I know. All people have to do is update using the scripts longsleep provides and there is no issue therefore no discussion?

Your verbiage is fine.

[tkaiser]

I was just surprised that there wasn't a development thread dedicated to it...

That's since none of the developers is able to reproduce the issue. It's really that easy

This is from 2 months ago: https://github.com/longsleep/build-pine6...e/issues/5

And this from a few days ago: http://forum.pine64.org/showthread.php?t...05#pid7605

[rhkean]

I was just surprised that there wasn't a development thread dedicated to it...

That's since none of the developers is able to reproduce the issue. It's really that easy

This is from 2 months ago: https://github.com/longsleep/build-pine6...e/issues/5

And this from a few days ago: http://forum.pine64.org/showthread.php?t...05#pid7605

thanks for the links... I just noticed this post (at midnight), so I review them tomorrow.

I can reproduce:
debian-mate-jessie-20160422-lenny.raposo-longsleep-pine64-8GB.img

ethernet to TP-Link TL-SG1008D 8-Port Gigabit Desktop Switch
boot
switch to tty1
login
apt-get update

--------------
OR
use longsleep's simple image from 4/23
replace initrd with ubuntu's arm64 netboot initrd (tweek to uEnv.txt required)
boot (with UART)
start install
will hang during download

I switched out the gigabit switch for an old 100mbps switch, and I haven't hung once.

[tkaiser]

debian-mate-jessie-20160422-lenny.raposo-longsleep-pine64-8GB.img
...
use longsleep's simple image from 4/23
replace initrd with ubuntu's arm64 netboot initrd

Nice. And useless to continue if you use questionable approaches. If you want to help nail the problem down it's the best to use longsleep's most advanced OS image from here and not modified stuff.

Networking behaviour is not only dependant on kernel/driver settings but device tree definitions (TX/RX delay) also so by using outdated/unknown/questionable OS image approaches it doesn't really help to get an idea what's happening (wrong).

[rhkean]

I'm not really clear on what is questionable here...
* that debian-mate image was the most recent until yesterday, when the 5/1 image was uploaded to pine.org
* the most recent longsleep simple image is dated 4/23 (therefore, I have his latest DTB, you know, the 2 dtb's that are loaded at 21mb and 22mb sector locations of the SD card after the ATF and SCP blobs)

as for the "os image" that you refer to, I've opened up his scripts to see what they do, which is to download the Ubuntu's core rootfs
see his script here: https://github.com/longsleep/build-pine6..._rootfs.sh
which is ONE of the suggested ways by debian to boot an arm64 system for the first time as noted here: https://wiki.debian.org/Arm64Port#Official_Debian_port

OTHER suggested ways of booting an arm64 system the first time at that link are to use an existing kernel, combined with debootstrab to build a rootfs

And the 3rd option is to install with the installer.
to do this, you have to get debian's netboot initrd loaded so that it can launch the installer.... this is what I did.
since, if I'm not mistaken,
* longsleep's kernel has the nic drivers built-in rather than loaded as a module...
* it's clear from his scripts that his init looks for a rootfs on part2... if found it does a switch root, else drops to a busybox shell

so, to use debian's official initrd, is NOT questionable.

Nothing I've done here is questionable.... I may have overlooked a step or misunderstood something...
but it's ALL repeatable and follows documented approaches...
that, by definition, is NOT questionable.

that being said... If I've done something wrong.... please, feel free to politely point out what and/or where I've done something incorrectly.

[tkaiser]

Ok, everything's ok, just stay on 100 MBits/sec if you feel that's the right way to proceed. In other words: unfortunately this problem seems not to be solveable

The 'questionable' part was about using 3rd party OS image approaches. With every further OS image (lenny stuff) or DIY approaches the chances to nail problems down are further minimized. So unless you choose the OS image I already recommended at least I won't have a single look into

[rhkean]

debian-mate-jessie-20160422-lenny.raposo-longsleep-pine64-8GB.img
...
use longsleep's simple image from 4/23
replace initrd with ubuntu's arm64 netboot initrd

Nice. And useless to continue if you use questionable approaches. If you want to help nail the problem down it's the best to use longsleep's most advanced OS image from here and not modified stuff.

Networking behaviour is not only dependant on kernel/driver settings but device tree definitions (TX/RX delay) also so by using outdated/unknown/questionable OS image approaches it doesn't really help to get an idea what's happening (wrong).

I installed the Ubuntu image from this link.

apt-get update while plugged into my gigabit switch:  reported 178b/s  (bytes per second)
I ctl-c'd it after 2 1/2 minutes on the 2nd source.
shutdown
plugged into 10mbps switch
ran the entire process under 30 seconds