| View previous topic :: View next topic |
| Author |
Message |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22746
|
 Posted: Wed Jan 24, 2018 2:58 am Post subject: |
 |
|
| NeddySeagoon wrote: | | Code: | | @@ -1282,7 +1307,7 @@ |
I'm not sure what the ,7 is. I would guess its the character position on the line. |
The first ,7 is the number of lines in the hunk before the patch is applied. The second ,7 is the number of lines in the hunk after the patch is applied. In this case, it means that there were 7 lines (counting context), and the patch removed as many lines as it added, so there are still 7 afterward. A patch that deleted lines and did not replace them would have a larger number in the first field than in the second. A patch that added more lines than it removed would have a larger number in the second field than in the first. |
|
| Back to top |
|
 |
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Thu Jan 25, 2018 12:00 pm Post subject: |
|
|
Hello,
I've just posted a v1.2.0 release of my bootable 64-bit Gentoo image for the RPi3 on GitHub (here).
A changelog from the prior release image may be viewed here, but in summary:- Migrated to Gentoo profile 17.0; all packages rebuilt.
- A new 17.0 profile binhost (https://isshoni.org/pi64pie) setup, and referenced in /etc/portage/make.conf.
- The SPI interface is now on by default (in the image itself that is; the sys-boot/rpi3-64bit-firmware package default has not changed). You can easily turn this off again, by editing /boot/config.txt, if you need the affected GPIO lines.
- The necessary binaries for using your RPi3 to disable the Intel Management Engine are now bundled with the image. Together with the above change, this allows your system to be used to run me_cleaner 'out of the box' (provided you have the correct hardware clip and wires, of course). Users uninterested in this particular application are unaffected, and need take no action.
- Various ebuild tidy-ups.
- All packages brought up-to-date against the Gentoo tree, as of 13 January 2018.
The Pi-Top variant image has also been updated to v1.2.0 / profile 17.0.
Impact of Migration to Profile 17.0
This is a significantly different release to the previous v1.1.3, not so much because of the applications it contains (although these have been updated), but because it is built on a newer Gentoo profile (17.0) than before (13.0). Profiles are changed rarely in Gentoo, for they determine how your entire system is built, often in backwards-incompatible ways: for example, in 17.0, the gcc compiler defaults to creating position independent executables (aka, 'pie'), which it did not do before (for most users).
Accordingly (and as recommended), all packages have been rebuilt under the new profile for the v1.2.0 image, and, to avoid confusion, a new binhost has been created to house these, at https://isshoni.org/pi64pie. This is now the binhost that will receive weekly autoupdates, going forward.
The old 13.0 binhost, at https://isshoni.org/pi64, will be retained for historical interest (at least for a while), but will no longer be autoupdated.
A new custom profile, rpi3:default/linux/arm64/17.0/desktop/rpi3, has also been released. As with the rpi3:default/linux/arm64/13.0/desktop/rpi3 profile which it replaces, this 'inherits' from the default desktop profile, and adds the necessary RPi3-specific elements (USE flags, masks etc.) to facilitate a trouble-free arm64 build.
As such, if you are on any earlier release (v1.0.0 through v1.1.3) and wish to upgrade, running genup is not sufficient - please instead follow the instructions below (users downloading the new v1.2.0 image directly of course need take no special action, your system is already set up correctly).
As always, any problems feel free to contact me by email (sakaki@deciban.com), or post in this thread, for support.
Upgrading Manually to v1.2.0
These instructions may also be read on GitHub.
Note that if you are running a downloaded image >= 1.2.0, you need take no action, your system is already up-to-date. What follows is only for users on versions 1.1.0 thru 1.1.3 who wish to upgrade.
On the other side of the coin, if you are still running one of the very early v1.0.{0,1,2} releases of the image, you should first follow the manual upgrade instructions to 1.1.0 on GitHub (if you have not already done so), and once that has been completed, come back here to upgrade to v1.2.0.
First, make sure you have at least 2GiB of free space on your RPi3's filesystem (use "df -h" to check), and that you are using at least version 6.4.0 of gcc (use "gcc-config --list-profiles" to check; look for the version marked with the asterisk). Then, if that all looks good, proceed to update your ebuild repositories. As root, issue: | Code: | | pi64 ~ # emaint sync --auto |
You should now find you have a new custom profile available. Switch to it: | Code: | | pi64 ~ # eselect profile set "rpi3:default/linux/arm64/17.0/desktop/rpi3" |
You also need to switch your binary package host ('binhost'), to use the new 17.0 variant mentioned above. To do so, issue: | Code: | | pi64 ~ # nano -w /etc/portage/make.conf |
and modify the line that currently reads: | Code: | | PORTAGE_BINHOST="https://isshoni.org/pi64" |
so it now reads instead: | Code: | | PORTAGE_BINHOST="https://isshoni.org/pi64pie" |
Leave the rest of the file as-is. Save, and exit nano.
Now you can update the core build system. Do not follow the advice in the official news article to rebuild gcc, binutils and glibc individually (if you do, you'll end up building them locally, rather than pulling the new binaries from the binhost, which will take a long time). Instead, issue: | Code: | | pi64 ~ # emerge --ask --verbose sys-devel/gcc sys-devel/binutils sys-libs/glibc |
Check (when the above command prompts you for confirmation) that you will indeed be installing binary packages - this is a good indication you have set things up correctly.
Once this completes, rebuild your entire system for profile 17.0. Almost all of the required 900 or so packages should be available on the new binhost you just switched to, so this should only take a few hours (unless you have added many additional packages to the image yourself). Issue: | Code: | pi64 ~ # nice emerge --ask --verbose --emptytree --with-bdeps=y @world
pi64 ~ # nice emerge @preserved-rebuild |
then: | Code: | | pi64 ~ # dispatch-conf |
to resolve any proposed configuration file changes (for the most part, if you had a reasonably up-to-date 13.0 profile system to start with, typing z to 'zap' (discard) most of these proposed changes should be safe; a lot of packages have been re-installed here, but you want to keep your prior configuration, not roll it back to 'shipped defaults').
Once done, reboot your system. Then log in again as root, and issue:Once this has completed, congratulations, you have migrated to the (profile 17.0) v1.2.0 release! From this point, the automated weekly genup run should keep your system correctly up-to-date.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Thu Jan 25, 2018 8:05 pm Post subject: |
|
|
Seems that kernel make is not possible for the MPTCP implemented on gentoo 64 rpi3 
I'we get some non-critical errors (I suppose)
and one Critical:
| Code: | CC net/ipv4/tcp_output.o
net/ipv4/tcp_output.c: In function ‘__pskb_trim_head’:
net/ipv4/tcp_output.c:1295:11: warning: ‘return’ with a value, in function returning void
return 0;
^
net/ipv4/tcp_output.c:1285:6: note: declared here
void __pskb_trim_head(struct sk_buff *skb, int len)
^~~~~~~~~~~~~~~~
net/ipv4/tcp_output.c:1321:9: warning: ‘return’ with a value, in function returning void
return len;
^~~
net/ipv4/tcp_output.c:1285:6: note: declared here
void __pskb_trim_head(struct sk_buff *skb, int len)
^~~~~~~~~~~~~~~~
net/ipv4/tcp_output.c: In function ‘tcp_trim_head’:
net/ipv4/tcp_output.c:1332:17: error: void value not ignored as it ought to be
delta_truesize = __pskb_trim_head(skb, len);
^
make[2]: *** [scripts/Makefile.build:295: net/ipv4/tcp_output.o] Error 1
make[1]: *** [scripts/Makefile.build:553: net/ipv4] Error 2
make: *** [Makefile:988: net] Error 2
|
Whole log with all non-critical messages of the kernel make can be found here
https://paste.pound-python.org/show/sYTt2EdDngOMM6OPSVua/ |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Thu Jan 25, 2018 9:13 pm Post subject: |
|
|
orion777,
As I read it the function causing the fatal build problem on your (manually patched) kernel is the one which had a failed hunk apply (__pskb_trim_head)? Looks like the return type got switched from int to void somewhere, as NeddySeagoon has already noted:
| NeddySeagoon wrote: | orion777,
The code around what looks like the failed hunk is
| Code: | /* This is similar to __pskb_pull_head() (it will go to core/skbuff.c
* eventually). The difference is that pulled data not copied, but
* immediately discarded.
*/
static int __pskb_trim_head(struct sk_buff *skb, int len)
{
struct skb_shared_info *shinfo;
int i, k, eat;
eat = min_t(int, len, skb_headlen(skb));
if (eat) {
__skb_pull(skb, eat); |
It looks like the failed hunk was trying to drop the static but instead of finding | Code: | | static void __pskb_trim_head(struct sk_buff *skb, int len) |
the original fire contains
| Code: | | static int __pskb_trim_head(struct sk_buff *skb, int len) |
That is the function has been changed from static void, to static int, which defeats patch.
Do you feel lucky?
Remove the static from | Code: | | static int __pskb_trim_head(struct sk_buff *skb, int len) |
with ${EDITOR} and save the change.
That's educated guesswork. You can keep all the pieces if I'm wrong  |
If you have mapped it back to void return type (per the original failed hunk), that would explain the compiler error, when it tries to assign the return value to delta_truesize:
| Code: | net/ipv4/tcp_output.c:1332:17: error: void value not ignored as it ought to be
delta_truesize = __pskb_trim_head(skb, len); |
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Fri Jan 26, 2018 8:32 pm Post subject: |
|
|
| Sakaki wrote: |
If you have mapped it back to void return type (per the original failed hunk), that would explain the compiler error, when it tries to assign the return value to delta_truesize:
| Code: | net/ipv4/tcp_output.c:1332:17: error: void value not ignored as it ought to be
delta_truesize = __pskb_trim_head(skb, len); |
|
The MCTP patch try to search
| Code: | -static void __pskb_trim_head(struct sk_buff *skb, int len)
+void __pskb_trim_head(struct sk_buff *skb, int len) |
but net/ipv4/tcp_output.c contains
| Code: | | static int __pskb_trim_head(struct sk_buff *skb, int len) |
1. So I was replacing static int __pskb_trim_head(struct sk_buff *skb, int len) by static void __pskb_trim_head(struct sk_buff *skb, int len) to be able to apply patch.
2. Then the MPTCP patch was applied and it replaces static void __pskb_trim_head(struct sk_buff *skb, int len) by void __pskb_trim_head(struct sk_buff *skb, int len)
So what I have to do? Do I have to replace void __pskb_trim_head(struct sk_buff *skb, int len) back to initial static int __pskb_trim_head(struct sk_buff *skb, int len) ? Looks strange, because MPTCP patch was done this..
[Moderator edit: fixed [code] tag. Do not quote unbalanced tags. -Hu] |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Fri Jan 26, 2018 9:53 pm Post subject: |
|
|
Revert your source tree, then just remove the static qualifier on the function, so its first line becomes: | Code: | | int __pskb_trim_head(struct sk_buff *skb, int len) |
That's what the failed hunk is trying to do (i.e., remove the static), it's just that the return type has changed since it was written (commit 7162fb242).
Then, apply the patchset. Ignore the failed hunk, and try building as usual.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Sun Jan 28, 2018 2:17 pm Post subject: |
|
|
Ok, folder /usr/src/linux was manually deleted.
Than:
| Code: |
git clone --depth 1 https://github.com/raspberrypi/linux.git -b rpi-4.10.y
cd linux
make distclean
make bcmrpi3_defconfig
make menuconfig
> CPU Power Management > CPU Frequency scaling --- Default CPUFreq governor (powersave) ---> Ondemand
|
Than copy of /linux directory was prepared by copying /usr/src/linux to /usr/src/linux_mptcp
Than:
| Code: |
cd /usr/src/linux_mptcp
wget http://multipath-tcp.org/patches/mptcp-v4.10-d9c9f9273eb1.patch
cd /usr/src/linux_mptcp/net/ipv4/
|
Than tcp_output.c was edited manually: static int __pskb_trim_head(struct sk_buff *skb, int len) replaced by int __pskb_trim_head(struct sk_buff *skb, int len)
than:
| Code: | cd /usr/src/linux_mptcp/
patch -p1 < mptcp-v4.10-d9c9f9273eb1.patch |
Now I ignore 1 out of 46 hunks FAILED -- saving rejects to file net/ipv4/tcp_output.c.rej
So now .config need to be configured to implement mptcp functions:
| Code: | cd /usr/src/linux_mptcp/
make menuconfig
│ -> Networking support (NET [=y]) │
│ -> Networking options │
│ -> TCP/IP networking (INET [=y]) │
│ (1) -> The IPv6 protocol (IPV6 [=m]) to KERNEL (or DISABLE)
then
Networking support (NET [=y])
Networking options
TCP/IP networking (INET [=y])
[*] IP: advanced router
[*] IP: policy routing
[*] MPTCP protocol
[*] MPTCP: advanced path-manager control --->
<*> MPTCP Full-Mesh Path-Manager
and
Networking support (NET [=y])
Networking options
TCP/IP networking (INET [=y])
[*] TCP: advanced congestion control --->
<*> MPTCP COUPLED CONGESTION CONTROL (!!Can't be found in menuconfig!!)
<*> MPTCP Opportunistic Linked Increase
make |
make was successful!! 
But make modules_install can't work:
| Quote: | ...
INSTALL drivers/media/rc/ir-jvc-decoder.ko
cp: cannot stat 'drivers/media/rc/ir-jvc-decoder.ko': No such file or directory
INSTALL drivers/media/rc/ir-lirc-codec.ko
cp: cannot stat 'drivers/media/rc/ir-lirc-codec.ko': No such file or directory
INSTALL drivers/media/rc/ir-mce_kbd-decoder.ko
...
|
So, is it possible to make_modulesinstall from folder /usr/src/linux_mptcp/, which is different from /usr/src/linux/? |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sun Jan 28, 2018 4:14 pm Post subject: |
|
|
It should work fine no matter where your kernel tree is located, provided you are in the top level directory of that tree when you are issuing the various 'make' commands.
Have any kernel modules built at all? Check: | Code: | # cd /usr/src/linux_mptcp/
# find . -type f -name '*.ko' |
Does that print a long list of module pathnames?
You can also try building the modules explicitly: | Code: | # cd /usr/src/linux_mptcp/
# make modules
# make modules_install |
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Sun Jan 28, 2018 7:55 pm Post subject: |
|
|
Command | Code: | | find . -type f -name '*.ko' |
returns NOTHING!
Very strange..
While make starts to build modules..
Ok, now I have to wait until complete.
Maybe I was wrong when specify make -j5 ? Because it is strange that modules was not builded together with kernel at make -j5.. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54596
Location: 56N 3W
|
| Posted: Sun Jan 28, 2018 8:55 pm Post subject: |
|
|
orion777,
That usually means that make broke and you missed the error message.
Run make with no -j option and it will stop as soon as it fails.
If the kernel is already built, make will discover that and not actually build anything.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Sun Jan 28, 2018 9:06 pm Post subject: |
|
|
Yes, I run:
make modules and it was finished succesfully.
than make and it returns an error very quickly
| Code: | pi64 /usr/src/linux_mptcp # make
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CHK kernel/config_data.h
CC net/ipv4/tcp_output.o
net/ipv4/tcp_output.c:1285:5: error: conflicting types for ‘__pskb_trim_head’
int __pskb_trim_head(struct sk_buff *skb, int len)
^~~~~~~~~~~~~~~~
In file included from ./include/net/mptcp.h:46:0,
from net/ipv4/tcp_output.c:39:
./include/net/tcp.h:387:6: note: previous declaration of ‘__pskb_trim_head’ was here
void __pskb_trim_head(struct sk_buff *skb, int len);
^~~~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:295: net/ipv4/tcp_output.o] Error 1
make[1]: *** [scripts/Makefile.build:553: net/ipv4] Error 2
make: *** [Makefile:988: net] Error 2
pi64 /usr/src/linux_mptcp #
|
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54596
Location: 56N 3W
|
| Posted: Sun Jan 28, 2018 9:11 pm Post subject: |
|
|
orion777,
The kernel did not build.
| Code: | net/ipv4/tcp_output.c:1285:5: error: conflicting types for ‘__pskb_trim_head’
int __pskb_trim_head(struct sk_buff *skb, int len)
^~~~~~~~~~~~~~~~
In file included from ./include/net/mptcp.h:46:0,
from net/ipv4/tcp_output.c:39:
./include/net/tcp.h:387:6: note: previous declaration of ‘__pskb_trim_head’ was here
void __pskb_trim_head(struct sk_buff *skb, int len); |
Your new patch applied but did the wrong thing. Do you see it ?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Tue Jan 30, 2018 5:16 pm Post subject: |
|
|
Vanilla tcp_output.c contains
| Code: | | static void __pskb_trim_head(struct sk_buff *skb, int len) |
Gentoo tcp_output.c contains (as Sakaki specifies commit https://github.com/torvalds/linux/commit/7162fb242cb8322beb558828fd26b33c3e9fc805 )
| Code: | | static int __pskb_trim_head(struct sk_buff *skb, int len) |
MPTCP patch is prepared for the vanilla sources.. So it try to replace
| Code: | | static void __pskb_trim_head(struct sk_buff *skb, int len) |
to
| Code: | void __pskb_trim_head(struct sk_buff *skb, int len)
|
So here we have a problem:
1. If after patching the string is void __pskb_trim_head(struct sk_buff *skb, int len) as required by the MPTCP, than the gentoo kernel make fails with the error:
| Code: | CC net/ipv4/tcp_output.o
net/ipv4/tcp_output.c: In function ‘__pskb_trim_head’:
net/ipv4/tcp_output.c:1295:11: warning: ‘return’ with a value, in function returning void
return 0;
^
net/ipv4/tcp_output.c:1285:6: note: declared here
void __pskb_trim_head(struct sk_buff *skb, int len)
^~~~~~~~~~~~~~~~
net/ipv4/tcp_output.c:1321:9: warning: ‘return’ with a value, in function returning void
return len;
^~~
net/ipv4/tcp_output.c:1285:6: note: declared here
void __pskb_trim_head(struct sk_buff *skb, int len)
^~~~~~~~~~~~~~~~
net/ipv4/tcp_output.c: In function ‘tcp_trim_head’:
net/ipv4/tcp_output.c:1332:17: error: void value not ignored as it ought to be
delta_truesize = __pskb_trim_head(skb, len);
^
make[2]: *** [scripts/Makefile.build:295: net/ipv4/tcp_output.o] Error 1
make[1]: *** [scripts/Makefile.build:553: net/ipv4] Error 2
make: *** [Makefile:988: net] Error 2 |
2. If the string is manually changed to int __pskb_trim_head(struct sk_buff *skb, int len) as required by the gentoo, than kernel make fails with the error:
| Code: | net/ipv4/tcp_output.c:1285:5: error: conflicting types for ‘__pskb_trim_head’
int __pskb_trim_head(struct sk_buff *skb, int len)
^~~~~~~~~~~~~~~~
In file included from ./include/net/mptcp.h:46:0,
from net/ipv4/tcp_output.c:39:
./include/net/tcp.h:387:6: note: previous declaration of ‘__pskb_trim_head’ was here
void __pskb_trim_head(struct sk_buff *skb, int len);
^~~~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:295: net/ipv4/tcp_output.o] Error 1
make[1]: *** [scripts/Makefile.build:553: net/ipv4] Error 2
make: *** [Makefile:988: net] Error 2
pi64 /usr/src/linux_mptcp # |
So we have self-excluding solutions, because both solutions results in critical conflicts.. How to solve it - I dont know. Maybe I have to use vanilla sources on RPI3? I'm not sure that it will work.. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54596
Location: 56N 3W
|
| Posted: Tue Jan 30, 2018 6:23 pm Post subject: |
|
|
orion777,
It looks like there is another step required.
The gentoo kernel contains | Code: | | static int __pskb_trim_head(struct sk_buff *skb, int len). |
That is also in the Pi patched 4.9.y, so lets go with that being what's required.
The file ./include/net/tcp.h in the patched kernel, contains | Code: | | void __pskb_trim_head(struct sk_buff *skb, int len); |
Change the void to int there.
That entry in the file is a function prototype. It allows users to call the function without having the entire function definition available.
The actual function definition contains return statements, so it certainly returns something to its callers.
Its then up to the caller what it does with the value.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Tue Jan 30, 2018 6:30 pm Post subject: |
|
|
Edit: oops, NeddySeagoon already answered this while I was typing. Sorry for the duplicate reply ><
orion777,
I haven't read your patchset, but here's what I guess is going on:
In the original 4.10 kernel, tcp_output.c defines the C function__pskb_trim_head as follows: | Code: | static void __pskb_trim_head(struct sk_buff *skb, int len)
{
/* function body */
}
|
Note this function tagged as static, meaning that it is not visible outside its translation unit (~= file = tcp_output.c).
However, one of the patchset authors probably thought, "hello, that's a useful function, I'd like to reuse it in another file". And to do so, they introduced two patch components, one to remove the static qualifier from __pskb_trim_head in tcp_output.c (let's call that hunk A), and another to declare the function (make its prototype visible so it can easily be used in other files) in tcp.h, let's call that hunk B. The prototype injected into tcp.h by hunk B was (note the semicolon): | Code: | | void __pskb_trim_head(struct sk_buff *skb, int len); |
All of which presumably worked fine. Then along came commit 7162fb242 and messed things up, by changing the return value of the static function. After this commit, the vanilla definition in tcp_output.c became: | Code: | static int __pskb_trim_head(struct sk_buff *skb, int len)
{
/* function body */
return len;
}
|
It is to this modified base that you try to apply the patchset. It works well enough for the most part: but the changed return value means that hunk A fails to apply. Importantly however, hunk B has taken effect, so you now have, in tcp.h: | Code: | | void __pskb_trim_head(struct sk_buff *skb, int len); |
but in tcp_output.c: | Code: | static int __pskb_trim_head(struct sk_buff *skb, int len)
{
/* function body */
return len;
} |
You then (manually) fix up tcp_output.c, removing the static, so it reads:
| Code: | int __pskb_trim_head(struct sk_buff *skb, int len)
{
/* function body */
return len;
}
|
and try compiling. But this fails, since you have conflicting return types for the function (int in tcp_output.c, and void in tcp.h).
tldr; Therefore... if you also fix up the declaration, in tcp.h, to match what is in tcp_output.c, so: | Code: | | int __pskb_trim_head(struct sk_buff *skb, int len); |
you'll probably find it'll work. Or compile, anyway ^-^
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Feb 04, 2018 5:54 pm Post subject: |
|
|
I'm using Sakaki's overlay and seeing things like "- â/usr" in my emerges. How to correct the font?
To be more clear I see this in my desktop terminal , logged into the pi via ssh.
| Code: | Saving to: â/usr/portage/packages/net-wireless/blueman-2.0.4.tbz2.partialâ
|
|
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sun Feb 04, 2018 7:27 pm Post subject: |
|
|
Tony0945,
what does "eselect locale show" print if you run it on your ssh client box (assuming it is a Gentoo system)?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Feb 04, 2018 9:21 pm Post subject: |
|
|
| Code: | tony@MSI ~ $ eselect locale show
LANG variable in profile:
en_US
|
and on the pi: | Code: | pi64 ~ # eselect locale show
LANG variable in profile:
en_GB.utf8
|
On the client:
| Code: | tony@MSI ~ $ eselect locale list
Available targets for the LANG variable:
[1] C
[2] POSIX
[3] en_US *
[4] en_US.iso88591
[5] en_US.utf8
[ ] (free form)
|
I thought I was on one of the other en_US's. I'll try en_US.utf8. I vaguely remember switching because of weird characters in sensors -F.
Right now building everything. Following your guide to upgrading the pi. It's doing emerge -e world. I did a revdep-rebuild.sh on the client and it's rebuilding 957 packages! Well, I hadn't done an emerge -e world after moving to profile 17.0 just the library update.
Weird thing is that although started later, the client, re-compiling, is catching up to the pi which is just doing binary installs.
Aside from the slow builds, I installed wxGTK overnight, I'm very happy with your pi64 implementation. Is this the right thread for questions or should I start a new one?
Results of sensors -f on en_US.utf8: | Code: | SMBUSMASTER 0: +138.2°F
PCH_CHIP_CPU_MAX_TEMP: +32.0°F
PCH_CHIP_TEMP: +32.0°F
PCH_CPU_TEMP: +32.0°F
|
What's with the angstrom units? |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sun Feb 04, 2018 10:58 pm Post subject: |
|
|
Tony0945,
this thread is fine for questions regarding the image.
Now you have your client box on en_US.utf8, you could try switching the RPi3 to that also. On your RPi3, edit /etc/locale.gen, and uncomment: | Code: | en_US ISO-8859-1
en_US.UTF-8 UTF-8 |
Leave the rest of the file as is. Then run: | Code: | pi64 ~ # locale-gen
pi64 ~ # eselect locale set en_US.utf8
pi64 ~ # source /etc/profile |
Both sides of the ssh connection should now match. Hopefully that will resolve your font-mapping issues.
As to the updates, a fast PC rebuilding packages for which the source is already downloaded will be able to do a full-system emerge reasonably quickly. The Pi still has to download the new binaries, which will take some time (libreoffice is ~100MiB for example), and then do the Portage install bookkeeping. Compiling everything on the RPi3 image from scratch, without distcc, would take about a fortnight though ^-^ so it's still worth going with the binaries.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Feb 04, 2018 11:44 pm Post subject: |
|
|
Thanks Sakaki,
Angstrom trouble seems to another local problem. They appear when I putty in from Windows but not when I log in natively on the Linux client.
Windows fonts being beyond the scope of this forum, I'll follow up elsewhere. Note I like logging in to any of my computers, waking up another with wakeonlan (doesn't seem to work on the pi so I leaving it running constantly, it's only 5 watts, right?).
Is there that much difference between en_GB and en_US?
Another more important question: "How to adjust settings for a 1200x1080 60Hz TV as monitor?" I had the overscan sort of controlled on Raspian, but the config.txt there said "Unless using a TV as monitor", but that's my use case, using the pi in place of the Roku with my own custom software. That's why I installed wxGTK. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54596
Location: 56N 3W
|
| Posted: Sun Feb 04, 2018 11:53 pm Post subject: |
|
|
Tony0945,
The Pi does not support WoL.
en_GB gives you a £ where you would have a #.
A few other things are moved around and a US keyboard has one less key than a GB keyboard.
A en_US key map under an en_GB keyboard is annoying but I can get by. I have to remember that I have at least one moved character in some of my passwords.
The Pi uses a framebufer console. You could try the 'daft laddie' approach.
Turn off the overscan. That's a hangover from CRT displays anyway. All it does is to stretch/shrink the image
Set the framebuffer to the resolution you want in /boot/config.txt then stand well back :)
Or you could use this page
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Feb 05, 2018 12:36 am Post subject: |
|
|
Thanks, Neddy. I will switch to en_US.
What about en_NZ and en_AU? More variant keyboards or currency symbols? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54596
Location: 56N 3W
|
| Posted: Mon Feb 05, 2018 12:42 am Post subject: |
|
|
Tony0945,
I don't know. Everything defaults to a USA keymap until you fix it :)
I've had to learn to to use a UK keyboard on top of a USA keymap every time I forget to do the setup.
I've not tried any of the others, except dvorak-uk, which I use now.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
antonlacon
Apprentice
Joined: 27 Jun 2004
Posts: 257
|
| Posted: Wed Feb 14, 2018 6:11 am Post subject: |
|
|
| Any attempts to use kernel 4.14? VC4 was ported to it this week. Should be sitting in the RasPi Org's 4.14 branch on github. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Wed Feb 14, 2018 10:18 am Post subject: |
|
|
antonlacon,
thanks for the heads-up. I'll have a look at 4.14 this week.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
