[rafhtl]

I see there is 4.9.95+ kernel update from 4.9.91+ present in xbian image (APRIL 20TH in download)
I suppose no issues solved here either (will upgrade now)
I will test usual transfer as your indications
thank you

---

I just tried xbian-config

option 6

qnap folder

and it worked!
It's the first timeit works till the end Done! (xbian copier)
Can you try also with the 4.9.95 ?

thanks

[rafhtl]

I am testing now 4.9.96+ on rpi3 B+

it's working correctly

[Nachteule]

(28th Apr, 2018 01:00 AM)rafhtl Wrote:  I am testing now 4.9.96+ on rpi3 B+

it's working correctly

You're a lucky guy

Yes. I added a patch to lan78xx driver that makes things better. But there are still critical issues in this driver. In my environment. 4.14 works much better than 4.9 (and it is a bit faster) and is more usable if I communicate to another 1GBit machine. But, if I'm sending data to a 100MBit machine, nothing worked stable as usual

Kernel 4.14.37 is build with DYNAMIC_DEBUG option enabled. So you can enable driver debug messages as follows

Terminal

echo -n 'module lan78xx +p' > /sys/kernel/debug/dynamic_debug/control
ethtool -s eth0 msglvl 255

And when things going worse, you'll get messages like this in dmesg

Code:

[Fr Apr 27 17:13:17 2018] lan78xx 1-1.1.1:1.0 eth0: can not linearize skb
[Fr Apr 27 17:13:17 2018] lan78xx 1-1.1.1:1.0 eth0: can not linearize skb
[Fr Apr 27 17:13:17 2018] lan78xx 1-1.1.1:1.0 eth0: update stats

And the main issue is that driver can not linearize socket buffer very often (still having no idea why)
Socket has to be linearized because it is send as it is directly to lan controller

Here is the comment of the linearize function, and this makes me not really happy

Code:

/* Moves tail of skb head forward, copying data from fragmented part,
* when it is necessary.
* 1. It may fail due to malloc failure.
* 2. It may change skb pointers.
*
* It is pretty complicated. Luckily, it is called only in exceptional cases.
*/

[Nachteule]

(24th Apr, 2018 02:54 AM)rafhtl Wrote:  I see there is 4.9.95+ kernel update from 4.9.91+ present in xbian image (APRIL 20TH in download)
I suppose no issues solved here either (will upgrade now)
I will test usual transfer as your indications
thank you

---

I just tried xbian-config

option 6

qnap folder

and it worked!
It's the first timeit works till the end Done! (xbian copier)
Can you try also with the 4.9.95 ?

thanks

Sorry, I have overlooked this posting

[Exnor]

Any progress on the units ethernet and stock GPU stability? Amazon prices are finally dropping so i think i can afford one

[Nachteule]

GPU was never a problem, and all other serious issues seems to be fixed

[Exnor]

(7th Apr, 2018 03:59 AM)Nachteule Wrote:  Still struggling with that kind of hardware

If Pi3B+ tends to instabilty, reducing sdram speed to 450MHz may help. To do this, please add

Code:

sdram_freq=450

to file /boot/config.txt

Unfortunately, the ethernet issues (based on new lan78xx based chip) are still not solved

But you were complaining about stock GPU clock in this post.... What did i miss?

[Nachteule]

No, not GPU clock. sd-ram clock was the culprit. The first series of Pi3B+ did not work reliable with 500MHz dram speed, so RPF made workaround: reduced clock to 450MHz

[Exnor]

(31st Jul, 2018 02:33 AM)Nachteule Wrote:  No, not GPU clock. sd-ram clock was the culprit. The first series of Pi3B+ did not work reliable with 500MHz dram speed, so RPF made workaround: reduced clock to 450MHz

Oh god i'm getting senile lol . It was "sdram_freq" written right there and somehow my brain though GPU.... (/facepalm) sorry about that.

Anyway, is this issue solved? You did say 1st series.... so i guess the current units don't have this issue? If so how can one check if they are an "old" batch or a "new" one?

Thanks again.

[Nachteule]

(31st Jul, 2018 03:05 AM)Exnor Wrote:  

(31st Jul, 2018 02:33 AM)Nachteule Wrote:  No, not GPU clock. sd-ram clock was the culprit. The first series of Pi3B+ did not work reliable with 500MHz dram speed, so RPF made workaround: reduced clock to 450MHz

Oh god i'm getting senile lol . It was "sdram_freq" written right there and somehow my brain though GPU.... (/facepalm) sorry about that.

Anyway, is this issue solved? You did say 1st series.... so i guess the current units don't have this issue? If so how can one check if they are an "old" batch or a "new" one?

Thanks again.

Issue is not solved. As already written, RPF made workaround and AFAIK this is still the situation

Sorry, no idea

[Exnor]

(31st Jul, 2018 03:09 AM)Nachteule Wrote:  Issue is not solved. As already written, RPF made workaround and AFAIK this is still the situation

Sorry, no idea

Lol thats nice... RPF launches a faulty piece of hardware :/

[Nachteule]

Yeah, what they did was banana policy in perfection!

[Exnor]

(31st Jul, 2018 03:27 AM)Nachteule Wrote:  Yeah, what they did was banana policy in perfection!

Did you notice the new model 3 A+? Would it run the current image for the 3 B+? (not that i'm interested since it only has 512 MiB of RAM and less USB ports.

Edit: Typo.

[Nachteule]

(17th Nov, 2018 04:47 AM)Exnor Wrote:  Did you notice the new model 3 A+? Would it rung the current image for the 3 B+? (not that i'm interested since it only has 512 MiB of RAM and less USB ports.

No, haven't noticed that. What a useless piece, no ethernet, only one usb port. Would be better they would work on more powerful Pi 4

I don't see any reason why current image should not work, but again, wasted time to think more about that part

[Exnor]

(17th Nov, 2018 05:14 AM)Nachteule Wrote:  

(17th Nov, 2018 04:47 AM)Exnor Wrote:  Did you notice the new model 3 A+? Would it rung the current image for the 3 B+? (not that i'm interested since it only has 512 MiB of RAM and less USB ports.

No, haven't noticed that. What a useless piece, no ethernet, only one usb port. Would be better they would work on more powerful Pi 4

I don't see any reason why current image should not work, but again, wasted time to think more about that part

Hehe, that was 4 years ago