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
I am testing now 4.9.96+ on rpi3 B+
it's working correctly
(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.
*/
(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
Any progress on the units ethernet and stock GPU stability? Amazon prices are finally dropping so i think i can afford one
GPU was never a problem, and all other serious issues seems to be fixed
(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
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?
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
(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.
(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
(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 :/
Yeah, what they did was banana policy in perfection!
(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.
(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
(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