TX1 -- swapon failed: Function not implemented
Hey, I'm trying to add swap to my TX1. I'm running the newest jetpack. I have tried mounting swap from a partition on a sata external and I've tried allocating a swapfile on flash and mounting that. Both give me the following error. swapon failed: Function not implemented I've seen a couple places talking about how to add swap to the tk1. I've also seen that this is probably a kernel option that needs to be enabled. Do I have to recompile the kernel with this option or is there an easier/faster way? Thanks, Nathan
Hey, I'm trying to add swap to my TX1.

I'm running the newest jetpack.

I have tried mounting swap from a partition on a sata external and I've tried allocating a swapfile on flash and mounting that.

Both give me the following error.

swapon failed: Function not implemented

I've seen a couple places talking about how to add swap to the tk1.
I've also seen that this is probably a kernel option that needs to be enabled.

Do I have to recompile the kernel with this option or is there an easier/faster way?

Thanks,
Nathan

#1
Posted 12/04/2015 05:45 PM   
CONFIG_SWAP is not set in the TX1 defconfig, so I think you'll have to rebuild the kernel. It's not something that you can load as a module.
CONFIG_SWAP is not set in the TX1 defconfig, so I think you'll have to rebuild the kernel. It's not something that you can load as a module.

#2
Posted 12/04/2015 08:04 PM   
It looks like CONFIG_SWAP requires a built-in non-module feature (without this you cannot use swap). I'm going to guess it's important enough that it makes its way back in at the next kernel release. Under "make menuconfig" (or whatever your favorite config tool is), go into "General setup" and then look for "Support for paging of anonymous memory (swap)". It's a bit of a chore to set up, but you'll need both Aarch64 and gnueabihf/ARMv7 cross compile tool chains.
It looks like CONFIG_SWAP requires a built-in non-module feature (without this you cannot use swap). I'm going to guess it's important enough that it makes its way back in at the next kernel release.

Under "make menuconfig" (or whatever your favorite config tool is), go into "General setup" and then look for "Support for paging of anonymous memory (swap)".

It's a bit of a chore to set up, but you'll need both Aarch64 and gnueabihf/ARMv7 cross compile tool chains.

#3
Posted 12/04/2015 08:12 PM   
Ugh, looks like this is my project this weekend then. I'll post what I get after I finish. Thanks, Nathan
Ugh, looks like this is my project this weekend then.

I'll post what I get after I finish.

Thanks,
Nathan

#4
Posted 12/04/2015 08:37 PM   
Recent posts from folks recompiling the kernel, see [url]https://devtalk.nvidia.com/default/topic/894945/jetson-tx1/jetson-tx1/post/4741750/#4741750[/url]
Recent posts from folks recompiling the kernel, see https://devtalk.nvidia.com/default/topic/894945/jetson-tx1/jetson-tx1/post/4741750/#4741750
#5
Posted 12/04/2015 08:55 PM   
I have the kernel (Linux tegra-ubuntu 3.10.96-tegra #1 SMP PREEMPT Tue May 17 16:29:05 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux) and observe the message "swapon failed: Function not implemented" indicating that the kernel still needs to be compiled with CONFIG_SWAP. Since TK1 with 32bit kernel is reported to support swap (I do not have TK1 access), is there a reason why CONFIG_SWAP is not enabled on the latest kernel? I am planning to re-compile the kernel and would like to understand what are the side-effects of enabling CONFIG_SWAP. I am worried for the fact that the latest version "sudo dpkg --print-architecture" returns arm64* which means that the memory is loaded much more than previously loaded 32 bit applications. Under this assumption there has to be a reason for CONFIG_SWAP not to be enabled. Cheers * I am not 100% confident about arm64, due to the fact that on the previous kernel I forced the dpkg to accept arm64.
I have the kernel (Linux tegra-ubuntu 3.10.96-tegra #1 SMP PREEMPT Tue May 17 16:29:05 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux) and observe the message "swapon failed: Function not implemented" indicating that the kernel still needs to be compiled with CONFIG_SWAP.

Since TK1 with 32bit kernel is reported to support swap (I do not have TK1 access), is there a reason why CONFIG_SWAP is not enabled on the latest kernel? I am planning to re-compile the kernel and would like to understand what are the side-effects of enabling CONFIG_SWAP.

I am worried for the fact that the latest version "sudo dpkg --print-architecture" returns arm64* which means that the memory is loaded much more than previously loaded 32 bit applications. Under this assumption there has to be a reason for CONFIG_SWAP not to be enabled.

Cheers

* I am not 100% confident about arm64, due to the fact that on the previous kernel I forced the dpkg to accept arm64.

#6
Posted 07/14/2016 07:08 PM   
I think swap on or off is just a preference in how someone expects to use the device. Could you elaborate on the question about "the memory is loaded much more than previously loaded 32 bit applications"? Regarding 32-bit versus 64-bit on a JTX1: The kernel is 64-bit, it is the user space which is optionally 32-bit or 64-bit. The ARMv8-a 64-bit supports 64-bit and 32-bit, although not both at the same time (there is a separate CPU mode which can be switched in or out). The 32-bit can be referred to as ARMv8 (no "-a"), or alternatively aarch32 or arm32. The aarch32 accepts any of the older ARMv7 code, but the ARMv8 compiler might produce 32-bit code which is only "mostly" compatible for older pure ARMv7 systems (such as JTK1). The result is that anything ARMv7 will run on JTX1, but things compiled for JTX1 in 32-bit mode may not run on a JTK1 32-bit. 32-bit ARMv7 works on 32-bit aarch32. The analogy that x86_64 desktop systems are 64-bit, but have 32-bit compatibility (e.g., i686) available is much the same on Jetson...a 64-bit system ([i]where both CPU and user space are 64-bit[/i]) can have 32-bit compatibility as well. The package manager on either desktop systems or Jetson would need to be told it is ok to look for 32-bit versions of packages, as it wouldn't know the two architectures are compatible without telling it so (plus 64-bit is preferable if both 32 and 64-bit are available). I have found flaws in this on Jetson though, there are some user space 32-bit armhf packages which should show up once the package manager is told of the compatibility, but it seems something in the package manager may not understand all of the subtleties. This is basically a package manager issue and not specific to Jetson. Keep in mind that there has been a lot of 32-bit ARMv7 hardware used out there, but 64-bit is very new. The case of forcing 64-bit availability in the package manager when user space is 32-bit is invalid. If talking about cross compilers, a 32-bit user space Jetson could have a 32-bit compiler which outputs 64-bit code, but the compiler itself would still be 32-bit.
I think swap on or off is just a preference in how someone expects to use the device. Could you elaborate on the question about "the memory is loaded much more than previously loaded 32 bit applications"?

Regarding 32-bit versus 64-bit on a JTX1: The kernel is 64-bit, it is the user space which is optionally 32-bit or 64-bit. The ARMv8-a 64-bit supports 64-bit and 32-bit, although not both at the same time (there is a separate CPU mode which can be switched in or out). The 32-bit can be referred to as ARMv8 (no "-a"), or alternatively aarch32 or arm32. The aarch32 accepts any of the older ARMv7 code, but the ARMv8 compiler might produce 32-bit code which is only "mostly" compatible for older pure ARMv7 systems (such as JTK1). The result is that anything ARMv7 will run on JTX1, but things compiled for JTX1 in 32-bit mode may not run on a JTK1 32-bit. 32-bit ARMv7 works on 32-bit aarch32.

The analogy that x86_64 desktop systems are 64-bit, but have 32-bit compatibility (e.g., i686) available is much the same on Jetson...a 64-bit system (where both CPU and user space are 64-bit) can have 32-bit compatibility as well. The package manager on either desktop systems or Jetson would need to be told it is ok to look for 32-bit versions of packages, as it wouldn't know the two architectures are compatible without telling it so (plus 64-bit is preferable if both 32 and 64-bit are available). I have found flaws in this on Jetson though, there are some user space 32-bit armhf packages which should show up once the package manager is told of the compatibility, but it seems something in the package manager may not understand all of the subtleties. This is basically a package manager issue and not specific to Jetson. Keep in mind that there has been a lot of 32-bit ARMv7 hardware used out there, but 64-bit is very new.

The case of forcing 64-bit availability in the package manager when user space is 32-bit is invalid. If talking about cross compilers, a 32-bit user space Jetson could have a 32-bit compiler which outputs 64-bit code, but the compiler itself would still be 32-bit.

#7
Posted 07/14/2016 09:00 PM   
Before getting into side topics let me re-state my questions: 1. Is there a reason why CONFIG_SWAP is not enabled on the kernel for TX1 but enabled on TK1? 2. What are the side-effects of enabling CONFIG_SWAP while compiling the kernel for overall Jetson functionality? Cheers
Before getting into side topics let me re-state my questions:

1. Is there a reason why CONFIG_SWAP is not enabled on the kernel for TX1 but enabled on TK1?

2. What are the side-effects of enabling CONFIG_SWAP while compiling the kernel for overall Jetson functionality?

Cheers

#8
Posted 07/15/2016 01:26 AM   
1. I think that is just nobody thought to enable it...though I could be wrong. 2. I enabled swap and have not noticed any instability related to it. The difficulty is that this must be an integrated feature, so both the Image and modules must be re-built with a new CONFIG_LOCALVERSION. So far I've only been able to build integrated features correctly using the version 4.8 compiler chain available with the driver documentation in the "baggage" subdirectory...all compiler versions newer than that end up failing on an illegal instruction (I've not figured out the exact code location it does this, but have tried Linaro 4.9, 5.2, and 5.3...the task would be much easier with a JTAG debugger, I do not believe kgdboc is suitable this early in the boot process for the debugging). This error does not depend on any particular feature that I know of.
1. I think that is just nobody thought to enable it...though I could be wrong.

2. I enabled swap and have not noticed any instability related to it. The difficulty is that this must be an integrated feature, so both the Image and modules must be re-built with a new CONFIG_LOCALVERSION. So far I've only been able to build integrated features correctly using the version 4.8 compiler chain available with the driver documentation in the "baggage" subdirectory...all compiler versions newer than that end up failing on an illegal instruction (I've not figured out the exact code location it does this, but have tried Linaro 4.9, 5.2, and 5.3...the task would be much easier with a JTAG debugger, I do not believe kgdboc is suitable this early in the boot process for the debugging). This error does not depend on any particular feature that I know of.

#9
Posted 07/15/2016 02:08 AM   
We will enable CONFIG_SWAP in coming release, so you can experiment with swap space if you wish. In the meantime, you can rebuild the kernel with CONFIG_SWAP support. Thanks
We will enable CONFIG_SWAP in coming release, so you can experiment with swap space if you wish.

In the meantime, you can rebuild the kernel with CONFIG_SWAP support.

Thanks

#10
Posted 07/22/2016 05:59 AM   
Facing this problem with JetPack 3.1 on Jetson Tx1. What is the workaround? How do I enable CONFIG_SWAP without having to rebuild the kernel?
Facing this problem with JetPack 3.1 on Jetson Tx1.
What is the workaround? How do I enable CONFIG_SWAP without having to rebuild the kernel?

#11
Posted 07/26/2017 01:23 PM   
Rebuilding the kernel is the only way. Swap is something which goes into the base image, not as a module (not every feature can be a module, swap is one of those). As long as you start with "/proc/config.gz" as the starting configuration, and set the CONFIG_LOCALVERSION to match the existing suffix of "uname -r", you can enable swap and build the Image file and simply copy it over (though I suggest always using a second extlinux.conf boot entry and preserving the original Image file...rename your new image and point your new boot entry at this). Some changes to a base kernel configuration might mandate changing the CONFIG_LOCALVERSION and building modules again, but I believe adding swap does not require this.
Rebuilding the kernel is the only way. Swap is something which goes into the base image, not as a module (not every feature can be a module, swap is one of those). As long as you start with "/proc/config.gz" as the starting configuration, and set the CONFIG_LOCALVERSION to match the existing suffix of "uname -r", you can enable swap and build the Image file and simply copy it over (though I suggest always using a second extlinux.conf boot entry and preserving the original Image file...rename your new image and point your new boot entry at this). Some changes to a base kernel configuration might mandate changing the CONFIG_LOCALVERSION and building modules again, but I believe adding swap does not require this.

#12
Posted 07/26/2017 04:29 PM   
@linuxdev Thank you... I think this shall do.
@linuxdev

Thank you... I think this shall do.

#13
Posted 07/26/2017 06:28 PM   
I am also getting this error; swapon failed: Function not implemented below is the details on my env L4T 28.1.0 Board: t210ref Ubuntu 16.04 LTS Kernel Version: 4.4.38-tegra @kayccc mentioned that CONFIG_SWAP will be enabled in the coming release. I assume this did not happen? I'm working through this example https://www.youtube.com/watch?v=jABmGKA-TN0 but I do not see where to set CONFIG_SWAP Thanks for your help
I am also getting this error;

swapon failed: Function not implemented

below is the details on my env

L4T 28.1.0
Board: t210ref
Ubuntu 16.04 LTS
Kernel Version: 4.4.38-tegra

@kayccc mentioned that CONFIG_SWAP will be enabled in the coming release. I assume this did not happen? I'm working through this example


but I do not see where to set CONFIG_SWAP
Thanks for your help

#14
Posted 09/19/2017 03:44 PM   
CONFIG_SWAP did not make its way into R28.1, so you will need to build a kernel for this (you can't do it as a module).
CONFIG_SWAP did not make its way into R28.1, so you will need to build a kernel for this (you can't do it as a module).

#15
Posted 09/19/2017 06:55 PM   
Scroll To Top

Add Reply