Re: Compiling kernel-3.4.xxx with gcc-9.x. Need some help.
Hi Greg, (Sending again as seems like I had rich-text available by mistake, so likely my message is rejected) On Tue, 30 Mar 2021 at 15:40, Greg KH wrote: > > On Tue, Mar 30, 2021 at 03:23:10PM +0200, Fawad Lateef wrote: > > So can I still use kernel-3.4 compiled with gcc-5.5, and boot full > > user-space with gcc-9.1? > > Yes, of course. > > > I was expecting it to be possible but might not work due to > > incompatibility? As I know that when I tried to compile buildroot-2019 > > (with latest version of openssl and others) it needs kernel headers > > and then I likely can't use 3.4 kernel. > > buildroot might be different, as that is how you are building your whole > system, but there is no dependency on the kernel and userspace to use > the same version of the compiler. Otherwise everyone would have to > rebuild the world for every time they updated their kernel, this isn't > the BSDs :) > I tried booting the userspace compiled with gcc-9.1 and kernel compiled with gcc-5.5. But seems like the kernel 3.4.111 is not compatible with user-space compiled with gcc-9.1. During boot getting error: "FATAL: kernel too old." (from init I believe) and then kernel Panics. Log (part) below: -- [ 26.242878] registered taskstats version 1 [ 26.247522] axp20_buck3: incomplete constraints, leaving on [ 26.253314] axp20_buck2: incomplete constraints, leaving on [ 26.259161] axp20_ldo4: incomplete constraints, leaving on [ 26.264877] axp20_ldo3: incomplete constraints, leaving on [ 26.270581] axp20_ldo2: incomplete constraints, leaving on [ 26.276299] axp20_ldo1: incomplete constraints, leaving on [ 26.282059] sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01 00:00:00 UTC (1262304000) [ 26.291136] Freeing init memory: 160K FATAL: kernel too old [ 26.308118] usb 3-1.1: New USB device found, idVendor=148f, idProduct=5572 [ 26.315022] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 26.322322] usb 3-1.1: Product: 802.11 n WLAN [ 26.326730] usb 3-1.1: Manufacturer: Ralink [ 26.330908] usb 3-1.1: SerialNumber: 1.0 [ 26.335055] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 26.335061] [ 26.344221] [] (unwind_backtrace+0x1/0x90) from [] (panic+0x6f/0x15c) [ 26.352400] [] (panic+0x6f/0x15c) from [] (do_exit+0x5ff/0x600) [ 26.360057] [] (do_exit+0x5ff/0x600) from [] (do_group_exit+0x25/0x78) [ 26.368318] [] (do_group_exit+0x25/0x78) from [] (__wake_up_parent+0x1/0x18) [ 26.377101] [] (__wake_up_parent+0x1/0x18) from [] (ret_fast_syscall+0x1/0x44) [ 26.386064] CPU1: stopping [ 26.388781] [] (unwind_backtrace+0x1/0x90) from [] (handle_IPI+0x157/0x170) [ 26.397477] [] (handle_IPI+0x157/0x170) from [] (gic_handle_irq+0x3f/0x40) [ 26.406085] [] (gic_handle_irq+0x3f/0x40) from [] (__irq_svc+0x3b/0x5c) [ 26.414427] Exception stack(0xef065f88 to 0xef065fd0) [ 26.419476] 5f80: ffed 0001 1037d000 ef064000 c04d3c08 [ 26.427648] 5fa0: ef064000 ef064000 c04a9a10 ef064018 3b9aca00 ef065fd0 [ 26.435817] 5fc0: c000d469 c000d46a 6033 [ 26.440870] [] (__irq_svc+0x3b/0x5c) from [] (default_idle+0x1a/0x1c) [ 26.449048] [] (default_idle+0x1a/0x1c) from [] (cpu_idle+0x91/0x98) [ 26.457135] [] (cpu_idle+0x91/0x98) from [<40480bd9>] (0x40480bd9) [ 26.464181] Rebooting in 10 seconds.. [ 36.72] Restarting Linux version 3.4.113 (flateef@flateef-XPS-13-9360) (gcc version 5.5.0 (Buildroot 2016.02-00152-g83a8d925e-dirty) ) #1 SMP Wed Mar 24 00:29:58 CET 2021 [ 36.82] --------- Can I do something to make them work together? Thanks Fawad Lateef > thanks, > > greg k-h
Re: Compiling kernel-3.4.xxx with gcc-9.x. Need some help.
Hi Arnd, On Mon, 29 Mar 2021 at 22:06, Arnd Bergmann wrote: > > On Mon, Mar 29, 2021 at 9:23 PM Fawad Lateef wrote: > > > > On Mon, 29 Mar 2021 at 06:57, Greg KH wrote: > > > > > > On Sun, Mar 28, 2021 at 10:20:50PM +0200, Fawad Lateef wrote: > > > > Hi > > > > > > > > I am using an Olimex A20 SOM with NAND and due to some binary blob for > > > > NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo > > > > here: https://github.com/linux-sunxi/linux-sunxi) > > > > > > Please work with the vendor that is forcing you to use this obsolete and > > > insecure kernel version. You are paying for that support, and they are > > > the only ones that can support you. > > > > > > > The problem is vendor Olimex now have eMMC based SOM which is > > supported by mainline kernel _but_ they still selling NAND SOM and > > only supporting 3.4 kernel (as this is the only latest version from > > sunxi with NAND support, after that sunxi is now moved away from NAND > > too). > > From a very quick look at the git history, I can tell that A20 NAND driver > support was added in linux-4.8. Have you actually tried a modern kernel? > I tried compiling and booting kernel v4.4 (from sunxi repo on github) but unable to make it boot. Stuck at "Starting kernel". By the way I am booting from RAM (using the sunxi usbboot/usb-otg option). You mentioned that it's supported from linux-4.8 (from your quick look at git history); can you tell me which driver/files? As I was able to see some sort of sunxi NAND driver even in v4.4 kernel (https://lxr.missinglinkelectronics.com/linux+v4.4/drivers/mtd/nand/sunxi_nand.c). When I tried to compare with the sunxi-3.4 kernel code, I found that the kernel has code for "nfc" but no reference to "nfd" (I don't know what they are referring to). The sunxi 3.4 kernel NAND driver at quick look seems quite different. (https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.4/drivers/block/sunxi_nand) I will try the v4.8 or above kernel. > There is also a howto document at > https://linux-sunxi.org/Mainline_NAND_Howto > I somehow missed this earlier :( And the prerequisite says kernel 4.10 above and some extra patch set). Will look into it too. Thanks for the link > The olimex board specific dts files seem to be missing the entry for > the nand controller. If you have trouble figuring out how to enable that > from the howto above, Olimex should be able to prove a small patch > for it. > Will see. As above link have some details regarding this which might be helpful. > > > > I am currently using buildroot-2016 and gcc-5.5 for building the > > > > kernel and every other package needed. > > > > > > > > Now the requirement is to move to the latest version of gcc-9.x, so > > > > that we can have glibc++ provided by the gcc-9.1 toolchain. > > > > > > > > Main problem for moving to later versions of buildroot is the kernel > > > > 3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the > > > > gcc-9.1 requirement is mandatory so now have to look into compiling > > > > linux-3.4 with gcc-9.1 or above. > > There is no need to compile user space and kernel with the same compiler. > So can I still use kernel-3.4 compiled with gcc-5.5, and boot full user-space with gcc-9.1? I was expecting it to be possible but might not work due to incompatibility? As I know that when I tried to compile buildroot-2019 (with latest version of openssl and others) it needs kernel headers and then I likely can't use 3.4 kernel. I will still give it a try. Thanks again > Arnd
Re: Compiling kernel-3.4.xxx with gcc-9.x. Need some help.
Hi Greg, On Mon, 29 Mar 2021 at 06:57, Greg KH wrote: > > On Sun, Mar 28, 2021 at 10:20:50PM +0200, Fawad Lateef wrote: > > Hi > > > > I am using an Olimex A20 SOM with NAND and due to some binary blob for > > NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo > > here: https://github.com/linux-sunxi/linux-sunxi) > > Please work with the vendor that is forcing you to use this obsolete and > insecure kernel version. You are paying for that support, and they are > the only ones that can support you. > The problem is vendor Olimex now have eMMC based SOM which is supported by mainline kernel _but_ they still selling NAND SOM and only supporting 3.4 kernel (as this is the only latest version from sunxi with NAND support, after that sunxi is now moved away from NAND too). > > I am currently using buildroot-2016 and gcc-5.5 for building the > > kernel and every other package needed. > > > > Now the requirement is to move to the latest version of gcc-9.x, so > > that we can have glibc++ provided by the gcc-9.1 toolchain. > > > > Main problem for moving to later versions of buildroot is the kernel > > 3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the > > gcc-9.1 requirement is mandatory so now have to look into compiling > > linux-3.4 with gcc-9.1 or above. > > > > Now I need some help. > > > > -- Is it realistic to expect 3.4 kernel compiling and boot > > successfully with gcc-9.1? > > No. It took a lot of work and effort just to get the 4.4.y kernel to > work with that gcc version. > Ok, thanks for the information. Any pointers on what to look at if I had to go this route for 3.4 kernel? > Again, please work with the company that you are already paying for > support from, they can do this for you. > >From Olimex they say it's an open hardware platform, so I really can't expect them to do anything for it. (https://www.olimex.com/Products/SOM/A20/A20-SOM/ NAND version) Thanks and regards, Fawad Lateef > good luck! > > greg k-h
Re: Compiling kernel-3.4.xxx with gcc-9.x. Need some help.
On Sun, 28 Mar 2021 at 22:49, Andy Shevchenko wrote: > > > > On Sunday, March 28, 2021, Fawad Lateef wrote: >> >> Hi >> >> I am using an Olimex A20 SOM with NAND and due to some binary blob for >> NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo >> here: https://github.com/linux-sunxi/linux-sunxi) >> >> I am currently using buildroot-2016 and gcc-5.5 for building the >> kernel and every other package needed. >> >> Now the requirement is to move to the latest version of gcc-9.x, so >> that we can have glibc++ provided by the gcc-9.1 toolchain. >> >> Main problem for moving to later versions of buildroot is the kernel >> 3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the >> gcc-9.1 requirement is mandatory so now have to look into compiling >> linux-3.4 with gcc-9.1 or above. >> >> Now I need some help. >> >> -- Is it realistic to expect 3.4 kernel compiling and boot >> successfully with gcc-9.1? > > > Pretty much, but i’m not sure the patches will be acceptable by upstream / > stable. Upstream patch is not really a concern as we are already running a non-upstream kernel from sunxi. > >> >> -- Secondly, till now I am able to compile until the point when its >> going to generate the vmlinuz image, it failed with error at LD stage: >> arm-none-linux-gnueabihf-ld: no machine record defined >> >> Last few lines from compile log: >> >> --- >> include/linux/init.h:267:24: note: in expansion of macro ‘__initcall’ >> 267 | #define module_init(x) __initcall(x); >> |^~ >> net/sunrpc/auth_gss/auth_gss.c:1721:1: note: in expansion of macro >> ‘module_init’ >> 1721 | module_init(init_rpcsec_gss) >> | ^~~ >> In file included from include/linux/kernel.h:20, >> from include/linux/spinlock.h:55, >> from include/linux/mmzone.h:7, >> from include/linux/gfp.h:4, >> from include/linux/slab.h:12, >> from net/sunrpc/auth_gss/svcauth_gss.c:40: >> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’ >> because it conflicts with attribute ‘const’ [-Wattributes] >>22 | int ilog2_NaN(void); >> | ^~~ >> LD net/sunrpc/auth_gss/auth_rpcgss.o >> LD net/sunrpc/auth_gss/built-in.o >> LD net/sunrpc/built-in.o >> LD net/built-in.o >> LD vmlinux.o >> MODPOST vmlinux.o >> GEN .version >> CHK include/generated/compile.h >> UPD include/generated/compile.h >> CC init/version.o >> In file included from include/linux/kernel.h:20, >> from include/linux/cache.h:4, >> from include/linux/time.h:7, >> from include/linux/stat.h:60, >> from include/linux/module.h:10, >> from init/version.c:10: >> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’ >> because it conflicts with attribute ‘const’ [-Wattributes] >>22 | int ilog2_NaN(void); >> | ^~~ >> LD init/built-in.o >> LD .tmp_vmlinux1 >> arm-none-linux-gnueabihf-ld: no machine record defined >> Makefile:875: recipe for target '.tmp_vmlinux1' failed >> make: *** [.tmp_vmlinux1] Error 1 >> --- >> >> >> After some investigation I found that the MACHINE_START macro from >> arch/arm/include/asm/mach/arch.h is optimised by compiler and removed >> from the object file during compilation of >> "arch/arm/plat-sunxi/core.c" due to the error here: >> >> --- >> >> flateef@flateef-XPS-13-9360:~/src/tmp/linux-custom-venus-gc-9.2$ make >> ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- EXTRAVERSION=-custom1 >> uImage LOADADDR="0x40008000" -j4 >> CHK include/linux/version.h >> CHK include/generated/utsrelease.h >> make[1]: 'include/generated/mach-types.h' is up to date. >> CALLscripts/checksyscalls.sh >> CHK include/generated/compile.h >> CC arch/arm/plat-sunxi/core.o >> In file included from include/linux/kernel.h:20, >> from arch/arm/plat-sunxi/core.c:20: >> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’ >> because it co
Compiling kernel-3.4.xxx with gcc-9.x. Need some help.
l_param __setup_##unique_id \
| ^~~~
include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
252 | __setup_param(str, fn, fn, 1)
| ^
arch/arm/mm/mmu.c:136:1: note: in expansion of macro ‘early_param’
136 | early_param("cachepolicy", early_cachepolicy);
| ^~~
AS arch/arm/kernel/head.o
LD arch/arm/kernel/built-in.o
AS arch/arm/mm/cache-v7.o
AS arch/arm/mm/tlb-v7.o
AS arch/arm/mm/proc-v7.o
LD arch/arm/mm/built-in.o
AS arch/arm/lib/copy_page.o
AS arch/arm/lib/csumpartialcopyuser.o
AR arch/arm/lib/lib.a
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
In file included from include/linux/kernel.h:20,
from include/linux/cache.h:4,
from include/linux/time.h:7,
from include/linux/stat.h:60,
from include/linux/module.h:10,
from init/version.c:10:
include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
because it conflicts with attribute ‘const’ [-Wattributes]
22 | int ilog2_NaN(void);
| ^~~
LD init/built-in.o
LD .tmp_vmlinux1
KSYM.tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM.tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
XZKERN arch/arm/boot/compressed/piggy.xzkern
CC arch/arm/boot/compressed/misc.o
CC arch/arm/boot/compressed/decompress.o
CC arch/arm/boot/compressed/string.o
In file included from include/linux/kernel.h:20,
from
arch/arm/boot/compressed/../../../../lib/xz/xz_private.h:15,
from
arch/arm/boot/compressed/../../../../lib/decompress_unxz.c:145,
from arch/arm/boot/compressed/decompress.c:50:
include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
because it conflicts with attribute ‘const’ [-Wattributes]
22 | int ilog2_NaN(void);
| ^~~
SHIPPED arch/arm/boot/compressed/lib1funcs.S
SHIPPED arch/arm/boot/compressed/ashldi3.S
AS arch/arm/boot/compressed/lib1funcs.o
AS arch/arm/boot/compressed/ashldi3.o
AS arch/arm/boot/compressed/piggy.xzkern.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-3.4.113-custom1
Created: Sun Mar 28 20:27:03 2021
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:1869496 Bytes = 1825.68 KiB = 1.78 MiB
Load Address: 40008000
Entry Point: 40008000
Image arch/arm/boot/uImage is ready
-
-- I still can't boot the kernel on the platform. I believe its
because there were lots of warning like above (unused const variables
etc) and might have removed some other code/functions OR macros?
So please suggest what I can do for compiling working kernel-3.4 with gcc-9.
Thanks in advance,
-- Fawad Lateef
Fwd: Unhandled fault: imprecise external abort (0x1406) when loading xhci_pci.ko - uPD720202, PEX8605, iMX6Q and linux-4.19.25
001 f000 ec922000 0142 000c c022d148 [ 573.379687] 3ec0: ec34e710 ea477660 d1ef8db8 0003 ec907021 ea24f088 [ 573.389856] 3ee0: ec9f1550 0101 0002 0040 ec923f00 [ 573.400109] 3f00: 600b0013 ea1146e8 ec02a180 006000c0 c084ad90 006000c0 0ff0 [ 573.410362] 3f20: 000c 793301cc 0009 0020 ec907000 0002 [ 573.420529] 3f40: ff9c c023bbdc 000a0002 793301cc ff9c 0009 c0d05148 ff9c [ 573.430784] 3f60: ec907000 c0219ef0 0142 ec923fb0 00020002 0006 0100 [ 573.441038] 3f80: 0001 793301cc be9c8950 02018390 0142 c0101204 ec922000 [ 573.451292] 3fa0: 0142 c01011d4 be9c8950 ff9c be9c8950 000a0002 [ 573.461546] 3fc0: be9c8950 02018390 0142 0200f368 0002 b6f65e6c 000c [ 573.471799] 3fe0: be9c8918 b6f967a0 b6e96bc8 800f0010 ff9c [ 573.482096] [] (xhci_bus_resume [xhci_hcd]) from [] (hcd_bus_resume+0x54/0x1a4) [ 573.493967] [] (hcd_bus_resume) from [] (usb_resume_both+0xa0/0x134) [ 573.504653] [] (usb_resume_both) from [] (__rpm_callback+0x158/0x1ec) [ 573.515335] [] (__rpm_callback) from [] (rpm_callback+0x20/0x80) [ 573.523082] [] (rpm_callback) from [] (rpm_resume+0x4d8/0x6b4) [ 573.530656] [] (rpm_resume) from [] (__pm_runtime_resume+0x60/0x8c) [ 573.538665] [] (__pm_runtime_resume) from [] (usb_autoresume_device+0x14/0x3c) [ 573.547634] [] (usb_autoresume_device) from [] (usbdev_open+0xb0/0x214) [ 573.555993] [] (usbdev_open) from [] (chrdev_open+0xd8/0x1ac) [ 573.563488] [] (chrdev_open) from [] (do_dentry_open+0x114/0x38c) [ 573.571328] [] (do_dentry_open) from [] (path_openat+0x2b0/0x1304) [ 573.579251] [] (path_openat) from [] (do_filp_open+0x6c/0xd8) [ 573.586741] [] (do_filp_open) from [] (do_sys_open+0x150/0x1f0) [ 573.594405] [] (do_sys_open) from [] (__sys_trace_return+0x0/0x10) [ 573.602322] Exception stack(0xec923fa8 to 0xec923ff0) [ 573.607378] 3fa0: be9c8950 ff9c be9c8950 000a0002 [ 573.615558] 3fc0: be9c8950 02018390 0142 0200f368 0002 b6f65e6c 000c [ 573.623737] 3fe0: be9c8918 b6f967a0 b6e96bc8 [ 573.628795] Code: e597214c e5926000 e3a02000 ee072f9a (e3c66004) [ 573.634894] ---[ end trace 2247f322516b4181 ]--- # Thanks in advance, -- Fawad Lateef
Re: Question regarding RT patches for ARM
Hi Sebastian, On 17 May 2017 at 18:02, Sebastian Andrzej Siewior <bige...@linutronix.de> wrote: > On 2017-05-17 07:45:39 [-0700], Eric Nelson wrote: >> Hi Fawad, > Hi Fawad, > >> On 05/17/2017 06:40 AM, Fawad Lateef wrote: >> > > > I'm not sure about the unhandled page fault, but the stalls may be >> > > > because of the SDMA driver. >> > > > >> > > > See this patch in the Freescale/NXP community for kernel 4.1: >> > > > https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch > > That is something I see for the first time. The description says that it > leads to this stall but it fails to explain _how_ it got there. > >> > > Thanks for the patch link. I will give it a try. >> > >> > Talked to hardware manufacturer and they applied the patch. >> > >> > Still that SDMA is only used for NOR flash and only u-boot and its >> > environment are stored in nor flash. So not sure if that is going to >> > help in any case. >> > >> >> SDMA is used for much more than NOR flash (SSI, USB, and sometimes >> UARTs). >> >> > So I would really like few more suggestions OR confirmations about ARM >> > (cortex-A9 based imx6) (preemept)-RT support/patches are stable and >> > can be used for final products. >> > >> >> I don't have any experience with the RT patches on 4.9 or later >> kernels, but do know that they're being used on i.MX6 with the >> vendor kernels (3.10.x, 4.1.x). > > I just looked into a few boot logs and it seems the Phyflex board (imx6 > quad) bootet v4.9.27-rt18, run cyclictest including some tests and > nothing produced this "unhandled page fault" you mention here. This > includes the previous RT version in the v4.9 line. > Thanks, seems like RT patches are quite stable for ARM then. > Of this "page fault" happens on boot, it has to do something without > your .config + hw combination. If it happens at rune-time it is probably > triggered by a driver or an application is triggering this. > Yes, this happens at run-time and not always. Sometimes hardware just hangs/stalls. As now RT is widely used on ARM so to me seems like it something related to hardware design/setting OR application. Another question: Is RT user-space application can make kernel/system crash? As to me kernel should kill the app but let itself running _but_ not sure in the case of RT patched kernel. >> Regards, >> >> >> Eric > > Sebastian Thanks, Fawad Lateef
Re: Question regarding RT patches for ARM
Hi Sebastian, On 17 May 2017 at 18:02, Sebastian Andrzej Siewior wrote: > On 2017-05-17 07:45:39 [-0700], Eric Nelson wrote: >> Hi Fawad, > Hi Fawad, > >> On 05/17/2017 06:40 AM, Fawad Lateef wrote: >> > > > I'm not sure about the unhandled page fault, but the stalls may be >> > > > because of the SDMA driver. >> > > > >> > > > See this patch in the Freescale/NXP community for kernel 4.1: >> > > > https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch > > That is something I see for the first time. The description says that it > leads to this stall but it fails to explain _how_ it got there. > >> > > Thanks for the patch link. I will give it a try. >> > >> > Talked to hardware manufacturer and they applied the patch. >> > >> > Still that SDMA is only used for NOR flash and only u-boot and its >> > environment are stored in nor flash. So not sure if that is going to >> > help in any case. >> > >> >> SDMA is used for much more than NOR flash (SSI, USB, and sometimes >> UARTs). >> >> > So I would really like few more suggestions OR confirmations about ARM >> > (cortex-A9 based imx6) (preemept)-RT support/patches are stable and >> > can be used for final products. >> > >> >> I don't have any experience with the RT patches on 4.9 or later >> kernels, but do know that they're being used on i.MX6 with the >> vendor kernels (3.10.x, 4.1.x). > > I just looked into a few boot logs and it seems the Phyflex board (imx6 > quad) bootet v4.9.27-rt18, run cyclictest including some tests and > nothing produced this "unhandled page fault" you mention here. This > includes the previous RT version in the v4.9 line. > Thanks, seems like RT patches are quite stable for ARM then. > Of this "page fault" happens on boot, it has to do something without > your .config + hw combination. If it happens at rune-time it is probably > triggered by a driver or an application is triggering this. > Yes, this happens at run-time and not always. Sometimes hardware just hangs/stalls. As now RT is widely used on ARM so to me seems like it something related to hardware design/setting OR application. Another question: Is RT user-space application can make kernel/system crash? As to me kernel should kill the app but let itself running _but_ not sure in the case of RT patched kernel. >> Regards, >> >> >> Eric > > Sebastian Thanks, Fawad Lateef
Re: Question regarding RT patches for ARM
Hi Eric, On 17 May 2017 at 16:45, Eric Nelson <e...@nelint.com> wrote: > Hi Fawad, > > On 05/17/2017 06:40 AM, Fawad Lateef wrote: >> >> On 15 May 2017 at 16:20, Fawad Lateef <fawadlat...@gmail.com> wrote: >>> >>> Hi Eric, >>> On 15 May 2017 at 16:12, Eric Nelson <e...@nelint.com> wrote: >>>> >>>> Hi Fawad, >>>> >>>>> 发自网易邮箱大师 >>>>> On 05/15/2017 20:44, Fawad Lateef wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I am working on custom i.MX6 quad hardware and using RT patches for >>>>> almost latest stable kernel 4.9 and facing some weird system stall OR >>>>> 'unhandled page fault - exceptions'. >>>>> >>>> >>>> I'm not sure about the unhandled page fault, but the stalls may be >>>> because of the SDMA driver. >>>> >>>> See this patch in the Freescale/NXP community for kernel 4.1: >>>> >>>> https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch >>>> >>> >>> Thanks for the patch link. I will give it a try. >> >> >> Talked to hardware manufacturer and they applied the patch. >> >> Still that SDMA is only used for NOR flash and only u-boot and its >> environment are stored in nor flash. So not sure if that is going to >> help in any case. >> > > SDMA is used for much more than NOR flash (SSI, USB, and sometimes > UARTs). > Yes SDMA can be used for many devices but in our case its only set to use for NOR (to confirm I also checked sdma interrupts in system and they just 21 or so which happened during boot time). >> So I would really like few more suggestions OR confirmations about ARM >> (cortex-A9 based imx6) (preemept)-RT support/patches are stable and >> can be used for final products. >> > > I don't have any experience with the RT patches on 4.9 or later > kernels, but do know that they're being used on i.MX6 with the > vendor kernels (3.10.x, 4.1.x). > > I believe Alison Chaiken mentioned using them with 4.9 kernels: > http://elinux.org/images/4/42/IRQs-_the_Hard%2C_the_Soft%2C_the_Threaded_and_the_Preemptible.pdf > https://www.youtube.com/watch?v=-pehAzaP1eg=youtu.be=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q > Thanks for the video/link. Seems like very informative. Will check it soon. > Regards, > > > Eric Regards, Fawad Lateef
Re: Question regarding RT patches for ARM
Hi Eric, On 17 May 2017 at 16:45, Eric Nelson wrote: > Hi Fawad, > > On 05/17/2017 06:40 AM, Fawad Lateef wrote: >> >> On 15 May 2017 at 16:20, Fawad Lateef wrote: >>> >>> Hi Eric, >>> On 15 May 2017 at 16:12, Eric Nelson wrote: >>>> >>>> Hi Fawad, >>>> >>>>> 发自网易邮箱大师 >>>>> On 05/15/2017 20:44, Fawad Lateef wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I am working on custom i.MX6 quad hardware and using RT patches for >>>>> almost latest stable kernel 4.9 and facing some weird system stall OR >>>>> 'unhandled page fault - exceptions'. >>>>> >>>> >>>> I'm not sure about the unhandled page fault, but the stalls may be >>>> because of the SDMA driver. >>>> >>>> See this patch in the Freescale/NXP community for kernel 4.1: >>>> >>>> https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch >>>> >>> >>> Thanks for the patch link. I will give it a try. >> >> >> Talked to hardware manufacturer and they applied the patch. >> >> Still that SDMA is only used for NOR flash and only u-boot and its >> environment are stored in nor flash. So not sure if that is going to >> help in any case. >> > > SDMA is used for much more than NOR flash (SSI, USB, and sometimes > UARTs). > Yes SDMA can be used for many devices but in our case its only set to use for NOR (to confirm I also checked sdma interrupts in system and they just 21 or so which happened during boot time). >> So I would really like few more suggestions OR confirmations about ARM >> (cortex-A9 based imx6) (preemept)-RT support/patches are stable and >> can be used for final products. >> > > I don't have any experience with the RT patches on 4.9 or later > kernels, but do know that they're being used on i.MX6 with the > vendor kernels (3.10.x, 4.1.x). > > I believe Alison Chaiken mentioned using them with 4.9 kernels: > http://elinux.org/images/4/42/IRQs-_the_Hard%2C_the_Soft%2C_the_Threaded_and_the_Preemptible.pdf > https://www.youtube.com/watch?v=-pehAzaP1eg=youtu.be=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q > Thanks for the video/link. Seems like very informative. Will check it soon. > Regards, > > > Eric Regards, Fawad Lateef
Re: Question regarding RT patches for ARM
Hi, On 15 May 2017 at 16:20, Fawad Lateef <fawadlat...@gmail.com> wrote: > Hi Eric, > > > On 15 May 2017 at 16:12, Eric Nelson <e...@nelint.com> wrote: >> Hi Fawad, >> >>> 发自网易邮箱大师 >>> On 05/15/2017 20:44, Fawad Lateef wrote: >>> >>> Hi All, >>> >>> I am working on custom i.MX6 quad hardware and using RT patches for >>> almost latest stable kernel 4.9 and facing some weird system stall OR >>> 'unhandled page fault - exceptions'. >>> >> >> I'm not sure about the unhandled page fault, but the stalls may be >> because of the SDMA driver. >> >> See this patch in the Freescale/NXP community for kernel 4.1: >> https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch >> > > Thanks for the patch link. I will give it a try. Talked to hardware manufacturer and they applied the patch. Still that SDMA is only used for NOR flash and only u-boot and its environment are stored in nor flash. So not sure if that is going to help in any case. So I would really like few more suggestions OR confirmations about ARM (cortex-A9 based imx6) (preemept)-RT support/patches are stable and can be used for final products. Thanks > >> Regards, >> >> >> Eric > > Regards, > > Fawad Lateef
Re: Question regarding RT patches for ARM
Hi, On 15 May 2017 at 16:20, Fawad Lateef wrote: > Hi Eric, > > > On 15 May 2017 at 16:12, Eric Nelson wrote: >> Hi Fawad, >> >>> 发自网易邮箱大师 >>> On 05/15/2017 20:44, Fawad Lateef wrote: >>> >>> Hi All, >>> >>> I am working on custom i.MX6 quad hardware and using RT patches for >>> almost latest stable kernel 4.9 and facing some weird system stall OR >>> 'unhandled page fault - exceptions'. >>> >> >> I'm not sure about the unhandled page fault, but the stalls may be >> because of the SDMA driver. >> >> See this patch in the Freescale/NXP community for kernel 4.1: >> https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch >> > > Thanks for the patch link. I will give it a try. Talked to hardware manufacturer and they applied the patch. Still that SDMA is only used for NOR flash and only u-boot and its environment are stored in nor flash. So not sure if that is going to help in any case. So I would really like few more suggestions OR confirmations about ARM (cortex-A9 based imx6) (preemept)-RT support/patches are stable and can be used for final products. Thanks > >> Regards, >> >> >> Eric > > Regards, > > Fawad Lateef
Re: Question regarding RT patches for ARM
Hi Eric, On 15 May 2017 at 16:12, Eric Nelson <e...@nelint.com> wrote: > Hi Fawad, > >> 发自网易邮箱大师 >> On 05/15/2017 20:44, Fawad Lateef wrote: >> >> Hi All, >> >> I am working on custom i.MX6 quad hardware and using RT patches for >> almost latest stable kernel 4.9 and facing some weird system stall OR >> 'unhandled page fault - exceptions'. >> > > I'm not sure about the unhandled page fault, but the stalls may be > because of the SDMA driver. > > See this patch in the Freescale/NXP community for kernel 4.1: > https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch > Thanks for the patch link. I will give it a try. > Regards, > > > Eric Regards, Fawad Lateef
Re: Question regarding RT patches for ARM
Hi Eric, On 15 May 2017 at 16:12, Eric Nelson wrote: > Hi Fawad, > >> 发自网易邮箱大师 >> On 05/15/2017 20:44, Fawad Lateef wrote: >> >> Hi All, >> >> I am working on custom i.MX6 quad hardware and using RT patches for >> almost latest stable kernel 4.9 and facing some weird system stall OR >> 'unhandled page fault - exceptions'. >> > > I'm not sure about the unhandled page fault, but the stalls may be > because of the SDMA driver. > > See this patch in the Freescale/NXP community for kernel 4.1: > https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch > Thanks for the patch link. I will give it a try. > Regards, > > > Eric Regards, Fawad Lateef
Re: Question regarding RT patches for ARM
Hi Sebastian, On 15 May 2017 at 15:47, Sebastian Andrzej Siewior <sebastian.siew...@linutronix.de> wrote: > On 2017-05-15 15:09:45 [+0200], Fawad Lateef wrote: >> Hi, >> >> I am talking in general about RT patches. Like downloaded 4.9.20 from >> kernel.org and applied patch "4.9.20-rt16.patch". > > understood > >> On 15 May 2017 at 14:51, GuJiangfei <qilede...@163.com> wrote: >> > Which rt patch do you mean? >> > >> > >> > 发自网易邮箱大师 >> > On 05/15/2017 20:44, Fawad Lateef wrote: >> > >> > Hi All, >> > >> > I am working on custom i.MX6 quad hardware and using RT patches for >> > almost latest stable kernel 4.9 and facing some weird system stall OR >> > 'unhandled page fault - exceptions'. > > and you are sure that this problems are caused by the RT patch or is > there a chance that this is unrelated to the RT patch? > The hardware platform is used by many other projects/products _but_ none of them is using RT patches. So really not sure if its hardware issue, though problem can be seen only in RT version of kernel which is needed for project. >> > Just want to confirm that "are RT patches for ARM are stable OR they >> > are still experimental?" As I heard from my other colleagues that RT >> > patches are not stable for ARM and should be avoided. > > It is stable and I am not aware of any ARM / IMX specific problems. > Ok, thanks. Good to know. I actually want this sort of confirmation as till now "platform/hardware manufacturer" says RT is unstable and should not be used (as newer kernel already have low-latency) > Since this got here from kernelnewbies: I would not recommend the > Preempt-RT patch set to add to any kernel just to have fancy patches. > People use it because they need to fulfill specific requirements which > would not work without it. You might want to check some of the > documentation in the RT-wiki > https://wiki.linuxfoundation.org/realtime/documentation/start > In our case we need RT because few other hardware components (external devices) needs really strict hard-limit and we can't miss that. (BTW I should have not included kernelnewbies in the CC list, but as was asking question in general that's why included). >> > Thanks in advance, >> > >> > -- Fawad Lateef > > Sebastian Thanks, Fawad Lateef
Re: Question regarding RT patches for ARM
Hi Sebastian, On 15 May 2017 at 15:47, Sebastian Andrzej Siewior wrote: > On 2017-05-15 15:09:45 [+0200], Fawad Lateef wrote: >> Hi, >> >> I am talking in general about RT patches. Like downloaded 4.9.20 from >> kernel.org and applied patch "4.9.20-rt16.patch". > > understood > >> On 15 May 2017 at 14:51, GuJiangfei wrote: >> > Which rt patch do you mean? >> > >> > >> > 发自网易邮箱大师 >> > On 05/15/2017 20:44, Fawad Lateef wrote: >> > >> > Hi All, >> > >> > I am working on custom i.MX6 quad hardware and using RT patches for >> > almost latest stable kernel 4.9 and facing some weird system stall OR >> > 'unhandled page fault - exceptions'. > > and you are sure that this problems are caused by the RT patch or is > there a chance that this is unrelated to the RT patch? > The hardware platform is used by many other projects/products _but_ none of them is using RT patches. So really not sure if its hardware issue, though problem can be seen only in RT version of kernel which is needed for project. >> > Just want to confirm that "are RT patches for ARM are stable OR they >> > are still experimental?" As I heard from my other colleagues that RT >> > patches are not stable for ARM and should be avoided. > > It is stable and I am not aware of any ARM / IMX specific problems. > Ok, thanks. Good to know. I actually want this sort of confirmation as till now "platform/hardware manufacturer" says RT is unstable and should not be used (as newer kernel already have low-latency) > Since this got here from kernelnewbies: I would not recommend the > Preempt-RT patch set to add to any kernel just to have fancy patches. > People use it because they need to fulfill specific requirements which > would not work without it. You might want to check some of the > documentation in the RT-wiki > https://wiki.linuxfoundation.org/realtime/documentation/start > In our case we need RT because few other hardware components (external devices) needs really strict hard-limit and we can't miss that. (BTW I should have not included kernelnewbies in the CC list, but as was asking question in general that's why included). >> > Thanks in advance, >> > >> > -- Fawad Lateef > > Sebastian Thanks, Fawad Lateef
Re: Question regarding RT patches for ARM
Hi, I am talking in general about RT patches. Like downloaded 4.9.20 from kernel.org and applied patch "4.9.20-rt16.patch". Thanks -- Fawad Lateef On 15 May 2017 at 14:51, GuJiangfei <qilede...@163.com> wrote: > Which rt patch do you mean? > > > 发自网易邮箱大师 > On 05/15/2017 20:44, Fawad Lateef wrote: > > Hi All, > > I am working on custom i.MX6 quad hardware and using RT patches for > almost latest stable kernel 4.9 and facing some weird system stall OR > 'unhandled page fault - exceptions'. > > Just want to confirm that "are RT patches for ARM are stable OR they > are still experimental?" As I heard from my other colleagues that RT > patches are not stable for ARM and should be avoided. > > Thanks in advance, > > -- Fawad Lateef > > ___ > Kernelnewbies mailing list > kernelnewb...@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question regarding RT patches for ARM
Hi, I am talking in general about RT patches. Like downloaded 4.9.20 from kernel.org and applied patch "4.9.20-rt16.patch". Thanks -- Fawad Lateef On 15 May 2017 at 14:51, GuJiangfei wrote: > Which rt patch do you mean? > > > 发自网易邮箱大师 > On 05/15/2017 20:44, Fawad Lateef wrote: > > Hi All, > > I am working on custom i.MX6 quad hardware and using RT patches for > almost latest stable kernel 4.9 and facing some weird system stall OR > 'unhandled page fault - exceptions'. > > Just want to confirm that "are RT patches for ARM are stable OR they > are still experimental?" As I heard from my other colleagues that RT > patches are not stable for ARM and should be avoided. > > Thanks in advance, > > -- Fawad Lateef > > ___ > Kernelnewbies mailing list > kernelnewb...@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question regarding RT patches for ARM
Hi All, I am working on custom i.MX6 quad hardware and using RT patches for almost latest stable kernel 4.9 and facing some weird system stall OR 'unhandled page fault - exceptions'. Just want to confirm that "are RT patches for ARM are stable OR they are still experimental?" As I heard from my other colleagues that RT patches are not stable for ARM and should be avoided. Thanks in advance, -- Fawad Lateef
Question regarding RT patches for ARM
Hi All, I am working on custom i.MX6 quad hardware and using RT patches for almost latest stable kernel 4.9 and facing some weird system stall OR 'unhandled page fault - exceptions'. Just want to confirm that "are RT patches for ARM are stable OR they are still experimental?" As I heard from my other colleagues that RT patches are not stable for ARM and should be avoided. Thanks in advance, -- Fawad Lateef
Re: Suggestions needed for resolving DT issues between kernel 3.10 and 4.4
Hi, Just as an update (and for future reference for anyone having similar issue): I got this all this sorted-out. Had to change some dt-binding for device and it was mostly drivers related changes for hardware components. Mostly nothing to do with DT. Thanks Fawad Lateef -- Fawad Lateef On 3 April 2017 at 10:54, Fawad Lateef <fawadlat...@gmail.com> wrote: > Hi, > > One more thing I realised that eth0 which is working is directly out > of SOM/SOC but other 3 eth ports are connected to a internal USB > switch (so Linux should see only eth1 besides eth0). > > So seems like flash/nand chip (m25p80) and spi_ks8995 (Micrel KS8995 > Ethernet switch SPI) mainly not working. > > Thanks > > > > -- Fawad Lateef > > > On 3 April 2017 at 10:38, Fawad Lateef <fawadlat...@gmail.com> wrote: >> Hi, >> >> I am facing some issues with device-trees (I am fairly new to them) >> and need some pointers about how to approach below problem: >> >> I got some I.MX6Q based hardware (some custom made whose hardware >> details are unknown to me). Hardware shipped with 3.10.53 kernel with >> full sources and everything is working on it >> >> Trying to get one of the recent kernel working on it (linux-4.4, from >> linux-linaro-stable with rt patches). I can compile the kernel and >> boot into it using 3.10.xx kernel compiled DTB but getting Warning at >> boot-time "Outdated DT detected, suspend/resume will NOT work" and few >> main hardware components not working (mainly ethernet(s) - 1 out of 4 >> ports working though, MTD/NAND (for u-boot environment)) >> >> So I looked into compiling the DTS (from 3.10 kernel) for 4.4 and >> managed to get it compiled. Now no warning of outdated DT _but_ still >> hardware components not working. >> >> I was assuming that as hardware is still same for both kernel 3.10 and >> 4.4, so it should work, but seems like something in DT is off for 4.4 >> kernel. >> >> Any help and suggestions will be good enough for me to look into above issue. >> >> Thanks and regards, >> >> -- Fawad Lateef
Re: Suggestions needed for resolving DT issues between kernel 3.10 and 4.4
Hi, Just as an update (and for future reference for anyone having similar issue): I got this all this sorted-out. Had to change some dt-binding for device and it was mostly drivers related changes for hardware components. Mostly nothing to do with DT. Thanks Fawad Lateef -- Fawad Lateef On 3 April 2017 at 10:54, Fawad Lateef wrote: > Hi, > > One more thing I realised that eth0 which is working is directly out > of SOM/SOC but other 3 eth ports are connected to a internal USB > switch (so Linux should see only eth1 besides eth0). > > So seems like flash/nand chip (m25p80) and spi_ks8995 (Micrel KS8995 > Ethernet switch SPI) mainly not working. > > Thanks > > > > -- Fawad Lateef > > > On 3 April 2017 at 10:38, Fawad Lateef wrote: >> Hi, >> >> I am facing some issues with device-trees (I am fairly new to them) >> and need some pointers about how to approach below problem: >> >> I got some I.MX6Q based hardware (some custom made whose hardware >> details are unknown to me). Hardware shipped with 3.10.53 kernel with >> full sources and everything is working on it >> >> Trying to get one of the recent kernel working on it (linux-4.4, from >> linux-linaro-stable with rt patches). I can compile the kernel and >> boot into it using 3.10.xx kernel compiled DTB but getting Warning at >> boot-time "Outdated DT detected, suspend/resume will NOT work" and few >> main hardware components not working (mainly ethernet(s) - 1 out of 4 >> ports working though, MTD/NAND (for u-boot environment)) >> >> So I looked into compiling the DTS (from 3.10 kernel) for 4.4 and >> managed to get it compiled. Now no warning of outdated DT _but_ still >> hardware components not working. >> >> I was assuming that as hardware is still same for both kernel 3.10 and >> 4.4, so it should work, but seems like something in DT is off for 4.4 >> kernel. >> >> Any help and suggestions will be good enough for me to look into above issue. >> >> Thanks and regards, >> >> -- Fawad Lateef
Re: Suggestions needed for resolving DT issues between kernel 3.10 and 4.4
Hi, One more thing I realised that eth0 which is working is directly out of SOM/SOC but other 3 eth ports are connected to a internal USB switch (so Linux should see only eth1 besides eth0). So seems like flash/nand chip (m25p80) and spi_ks8995 (Micrel KS8995 Ethernet switch SPI) mainly not working. Thanks -- Fawad Lateef On 3 April 2017 at 10:38, Fawad Lateef <fawadlat...@gmail.com> wrote: > Hi, > > I am facing some issues with device-trees (I am fairly new to them) > and need some pointers about how to approach below problem: > > I got some I.MX6Q based hardware (some custom made whose hardware > details are unknown to me). Hardware shipped with 3.10.53 kernel with > full sources and everything is working on it > > Trying to get one of the recent kernel working on it (linux-4.4, from > linux-linaro-stable with rt patches). I can compile the kernel and > boot into it using 3.10.xx kernel compiled DTB but getting Warning at > boot-time "Outdated DT detected, suspend/resume will NOT work" and few > main hardware components not working (mainly ethernet(s) - 1 out of 4 > ports working though, MTD/NAND (for u-boot environment)) > > So I looked into compiling the DTS (from 3.10 kernel) for 4.4 and > managed to get it compiled. Now no warning of outdated DT _but_ still > hardware components not working. > > I was assuming that as hardware is still same for both kernel 3.10 and > 4.4, so it should work, but seems like something in DT is off for 4.4 > kernel. > > Any help and suggestions will be good enough for me to look into above issue. > > Thanks and regards, > > -- Fawad Lateef
Re: Suggestions needed for resolving DT issues between kernel 3.10 and 4.4
Hi, One more thing I realised that eth0 which is working is directly out of SOM/SOC but other 3 eth ports are connected to a internal USB switch (so Linux should see only eth1 besides eth0). So seems like flash/nand chip (m25p80) and spi_ks8995 (Micrel KS8995 Ethernet switch SPI) mainly not working. Thanks -- Fawad Lateef On 3 April 2017 at 10:38, Fawad Lateef wrote: > Hi, > > I am facing some issues with device-trees (I am fairly new to them) > and need some pointers about how to approach below problem: > > I got some I.MX6Q based hardware (some custom made whose hardware > details are unknown to me). Hardware shipped with 3.10.53 kernel with > full sources and everything is working on it > > Trying to get one of the recent kernel working on it (linux-4.4, from > linux-linaro-stable with rt patches). I can compile the kernel and > boot into it using 3.10.xx kernel compiled DTB but getting Warning at > boot-time "Outdated DT detected, suspend/resume will NOT work" and few > main hardware components not working (mainly ethernet(s) - 1 out of 4 > ports working though, MTD/NAND (for u-boot environment)) > > So I looked into compiling the DTS (from 3.10 kernel) for 4.4 and > managed to get it compiled. Now no warning of outdated DT _but_ still > hardware components not working. > > I was assuming that as hardware is still same for both kernel 3.10 and > 4.4, so it should work, but seems like something in DT is off for 4.4 > kernel. > > Any help and suggestions will be good enough for me to look into above issue. > > Thanks and regards, > > -- Fawad Lateef
Suggestions needed for resolving DT issues between kernel 3.10 and 4.4
Hi, I am facing some issues with device-trees (I am fairly new to them) and need some pointers about how to approach below problem: I got some I.MX6Q based hardware (some custom made whose hardware details are unknown to me). Hardware shipped with 3.10.53 kernel with full sources and everything is working on it Trying to get one of the recent kernel working on it (linux-4.4, from linux-linaro-stable with rt patches). I can compile the kernel and boot into it using 3.10.xx kernel compiled DTB but getting Warning at boot-time "Outdated DT detected, suspend/resume will NOT work" and few main hardware components not working (mainly ethernet(s) - 1 out of 4 ports working though, MTD/NAND (for u-boot environment)) So I looked into compiling the DTS (from 3.10 kernel) for 4.4 and managed to get it compiled. Now no warning of outdated DT _but_ still hardware components not working. I was assuming that as hardware is still same for both kernel 3.10 and 4.4, so it should work, but seems like something in DT is off for 4.4 kernel. Any help and suggestions will be good enough for me to look into above issue. Thanks and regards, -- Fawad Lateef
Suggestions needed for resolving DT issues between kernel 3.10 and 4.4
Hi, I am facing some issues with device-trees (I am fairly new to them) and need some pointers about how to approach below problem: I got some I.MX6Q based hardware (some custom made whose hardware details are unknown to me). Hardware shipped with 3.10.53 kernel with full sources and everything is working on it Trying to get one of the recent kernel working on it (linux-4.4, from linux-linaro-stable with rt patches). I can compile the kernel and boot into it using 3.10.xx kernel compiled DTB but getting Warning at boot-time "Outdated DT detected, suspend/resume will NOT work" and few main hardware components not working (mainly ethernet(s) - 1 out of 4 ports working though, MTD/NAND (for u-boot environment)) So I looked into compiling the DTS (from 3.10 kernel) for 4.4 and managed to get it compiled. Now no warning of outdated DT _but_ still hardware components not working. I was assuming that as hardware is still same for both kernel 3.10 and 4.4, so it should work, but seems like something in DT is off for 4.4 kernel. Any help and suggestions will be good enough for me to look into above issue. Thanks and regards, -- Fawad Lateef
Porting setjmp/longjmp to mips64 kernel issue
Hello, I am trying to implement/port the functionality of "setjmp" and "longjmp" provided by glibc in a kernel module for mips64 based embedded system; running debian with modified smp kernel 2.6.16 on 2-cores. I removed all the floating-point registers save and restore functionality from setjmp/longjmp functions as they are not used/accessable from kernel. Now the issue is: Kernel hangs at instruction "j $31" in __longjmp function whenever I try to do longjmp; the value loaded in registers (in longjmp function especially PC in $31) are the same as I got in setjmp so it should jump to correct location but I think its jmping to some other place and simply stuck there. The prints from my module before the kernel hangs is: # insmod jmptest.ko JMP test module loaded. Starting tests... 1: pj_setjmp: 14 calling first calling second pj_longjmp: 21 __longjmp: 64 pc = [c009d11c] Can someone tell me if there is something wrong in my porting/implementation __or__ give some hints ? I am attaching the code in tar.gz (I am doing cross-compilation with embedded tool chain so please adjust paths in Makefile when compiling) Thanks in Advance. -- Fawad Lateef setjmp_mips64_kern.tar.gz Description: GNU Zip compressed data
Porting setjmp/longjmp to mips64 kernel issue
Hello, I am trying to implement/port the functionality of setjmp and longjmp provided by glibc in a kernel module for mips64 based embedded system; running debian with modified smp kernel 2.6.16 on 2-cores. I removed all the floating-point registers save and restore functionality from setjmp/longjmp functions as they are not used/accessable from kernel. Now the issue is: Kernel hangs at instruction j $31 in __longjmp function whenever I try to do longjmp; the value loaded in registers (in longjmp function especially PC in $31) are the same as I got in setjmp so it should jump to correct location but I think its jmping to some other place and simply stuck there. The prints from my module before the kernel hangs is: # insmod jmptest.ko JMP test module loaded. Starting tests... 1: pj_setjmp: 14 calling first calling second pj_longjmp: 21 __longjmp: 64 pc = [c009d11c] Can someone tell me if there is something wrong in my porting/implementation __or__ give some hints ? I am attaching the code in tar.gz (I am doing cross-compilation with embedded tool chain so please adjust paths in Makefile when compiling) Thanks in Advance. -- Fawad Lateef setjmp_mips64_kern.tar.gz Description: GNU Zip compressed data
Re: Reserving a fixed physical address page of RAM.
On 11/30/06, Jon Ringle <[EMAIL PROTECTED]> wrote: Jon Ringle wrote: > Fawad Lateef wrote: > > > > > > Index: linux/arch/arm/mm/init.c > > > > === > > > --- linux.orig/arch/arm/mm/init.c 2006-11-30 > > 11:03:00.0 > > > -0500 > > > +++ linux/arch/arm/mm/init.c2006-11-30 > 11:09:09.0 -0500 > > > @@ -429,6 +429,10 @@ > > > unsigned long addr; > > > void *vectors; > > > > > > +#ifdef CONFIG_MACH_VERTICAL_RSC4 > > > + reserve_bootmem (0x0000, 0x1000); #endif > > > + > > > /* > > > * Allocate the vector page early. > > > */ > > > > > > > > > > I think you can do like this but can't say accurately > because I havn't > > worked on arm architecture and also you havn't mentioned your > > kernel-version or function (in file > > arch/arm/mm/init.c) which you are going to do call reserve_bootmem ! > > Kernel version is 2.6.16.29 and the reserve_bootmem() call > above is at the top of the function devicemaps_init(). Is there some way I can verify that the above works? I've tried the following to try to get info on the reservation: # cat /proc/iomem # cat /proc/meminfo # cat /proc/slabinfo # echo m > /proc/sysrq-trigger The only one that hints that this might have worked is the `echo m > /proc/sysrq-trigger` in that I see the reserved pages count one larger than using a kernel without this patch. Does this mean that the page I reserved won't get used by Linux for any purpose? I havn't looked at " # echo m /proc/sysrq-trigger" till now but I am almost sure that it will reserve/work because calling reserve_bootmem internally sets the bit representing physical memory page (CMIIW). -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a fixed physical address page of RAM.
On 11/30/06, Jon Ringle <[EMAIL PROTECTED]> wrote:
Fawad Lateef wrote:
> On 11/30/06, Jon Ringle <[EMAIL PROTECTED]> wrote:
> > Fawad Lateef wrote:
> > > Yes, this can be used if required physical-memory exists
> in the last
> > > part of RAM as if you use mem= then kernel will only use
> > > memory less than or equal-to and above can be used
> by drivers
> > > (or any kernel module) might be through ioremap which takes
> > > physical-address.
> >
> > Seems that using mem= has to be in 1MB increments, where I
> only need 4K.
> >
>
> No AFAIK you can specify it in KBs (see
> http://sosdg.org/~coywolf/lxr/source/Documentation/kernel-para
> meters.txt#L869)
Yes, you can specify the mem= using K notation, but there is a test in
arch/arm/mm/mm-armv.c:create_mapping() that prevents the mapping from
being created if the boundaries are not MB aligned:
if (mem_types[md->type].prot_l1 == 0 &&
(virt & 0xf || (virt + off) & 0xf || (virt + length)
& 0xf)) {
printk(KERN_WARNING "BUG: map for 0x%08lx at 0x%08lx can
not "
"be mapped using pages, ignoring.\n",
__pfn_to_phys(md->pfn), md->virtual);
return;
}
This is in linux-2.6.16.29.
Ohh ok, I don't know about this architecture related information.
>
> > >
> > > But if lets say we need only 1MB portion of specific
> physical-memory
> > > region then AFAIK it must be done by hacking in kernel
> code during
> > > memory-initialization (mem_init
> > > function) where it is marking/checking pages as/are reserved; you
> > > can simply mark you required pages as reserved too and set their
> > > count to some-value if you want to know later which pages are
> > > reserved by you. (can do this reservation work
> > > here:
> http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605).
> >
> > Do you think that the following would work to properly reserve the
> > memory. If it does, then I think I can just do a ioremap(0x0000,
> > 0x1000) to obtain a virtual address. (Ofcourse I would actually use
> > symbolic names rather than the hardcoded addesses shown here).
> >
> > Index: linux/arch/arm/mm/init.c
> > ===
> > --- linux.orig/arch/arm/mm/init.c 2006-11-30
> 11:03:00.0
> > -0500
> > +++ linux/arch/arm/mm/init.c2006-11-30 11:09:09.0 -0500
> > @@ -429,6 +429,10 @@
> > unsigned long addr;
> > void *vectors;
> >
> > +#ifdef CONFIG_MACH_VERTICAL_RSC4
> > + reserve_bootmem (0x0000, 0x1000); #endif
> > +
> > /*
> > * Allocate the vector page early.
> > */
> >
> >
>
> I think you can do like this but can't say accurately because
> I havn't worked on arm architecture and also you havn't
> mentioned your kernel-version or function (in file
> arch/arm/mm/init.c) which you are going to do call reserve_bootmem !
Kernel version is 2.6.16.29 and the reserve_bootmem() call above is at
the top of the function devicemaps_init().
reserving_bootmem in devicemaps_init will work but I think it will be
better if you do this in mem_init function (here:
http://sosdg.org/~coywolf/lxr/source/arch/arm/mm/init.c?v=2.6.16;a=arm#L620),
so that all the paging and other map related stuff completes. (CMIIW)
--
Fawad Lateef
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a fixed physical address page of RAM.
On 11/30/06, Jon Ringle [EMAIL PROTECTED] wrote:
Fawad Lateef wrote:
On 11/30/06, Jon Ringle [EMAIL PROTECTED] wrote:
Fawad Lateef wrote:
Yes, this can be used if required physical-memory exists
in the last
part of RAM as if you use mem=xxxM then kernel will only use
memory less than or equal-to xxxM and above can be used
by drivers
(or any kernel module) might be through ioremap which takes
physical-address.
Seems that using mem= has to be in 1MB increments, where I
only need 4K.
No AFAIK you can specify it in KBs (see
http://sosdg.org/~coywolf/lxr/source/Documentation/kernel-para
meters.txt#L869)
Yes, you can specify the mem= using K notation, but there is a test in
arch/arm/mm/mm-armv.c:create_mapping() that prevents the mapping from
being created if the boundaries are not MB aligned:
if (mem_types[md-type].prot_l1 == 0
(virt 0xf || (virt + off) 0xf || (virt + length)
0xf)) {
printk(KERN_WARNING BUG: map for 0x%08lx at 0x%08lx can
not
be mapped using pages, ignoring.\n,
__pfn_to_phys(md-pfn), md-virtual);
return;
}
This is in linux-2.6.16.29.
Ohh ok, I don't know about this architecture related information.
But if lets say we need only 1MB portion of specific
physical-memory
region then AFAIK it must be done by hacking in kernel
code during
memory-initialization (mem_init
function) where it is marking/checking pages as/are reserved; you
can simply mark you required pages as reserved too and set their
count to some-value if you want to know later which pages are
reserved by you. (can do this reservation work
here:
http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605).
Do you think that the following would work to properly reserve the
memory. If it does, then I think I can just do a ioremap(0x0000,
0x1000) to obtain a virtual address. (Ofcourse I would actually use
symbolic names rather than the hardcoded addesses shown here).
Index: linux/arch/arm/mm/init.c
===
--- linux.orig/arch/arm/mm/init.c 2006-11-30
11:03:00.0
-0500
+++ linux/arch/arm/mm/init.c2006-11-30 11:09:09.0 -0500
@@ -429,6 +429,10 @@
unsigned long addr;
void *vectors;
+#ifdef CONFIG_MACH_VERTICAL_RSC4
+ reserve_bootmem (0x0000, 0x1000); #endif
+
/*
* Allocate the vector page early.
*/
I think you can do like this but can't say accurately because
I havn't worked on arm architecture and also you havn't
mentioned your kernel-version or function (in file
arch/arm/mm/init.c) which you are going to do call reserve_bootmem !
Kernel version is 2.6.16.29 and the reserve_bootmem() call above is at
the top of the function devicemaps_init().
reserving_bootmem in devicemaps_init will work but I think it will be
better if you do this in mem_init function (here:
http://sosdg.org/~coywolf/lxr/source/arch/arm/mm/init.c?v=2.6.16;a=arm#L620),
so that all the paging and other map related stuff completes. (CMIIW)
--
Fawad Lateef
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a fixed physical address page of RAM.
On 11/30/06, Jon Ringle [EMAIL PROTECTED] wrote: Jon Ringle wrote: Fawad Lateef wrote: snip Index: linux/arch/arm/mm/init.c === --- linux.orig/arch/arm/mm/init.c 2006-11-30 11:03:00.0 -0500 +++ linux/arch/arm/mm/init.c2006-11-30 11:09:09.0 -0500 @@ -429,6 +429,10 @@ unsigned long addr; void *vectors; +#ifdef CONFIG_MACH_VERTICAL_RSC4 + reserve_bootmem (0x0000, 0x1000); #endif + /* * Allocate the vector page early. */ I think you can do like this but can't say accurately because I havn't worked on arm architecture and also you havn't mentioned your kernel-version or function (in file arch/arm/mm/init.c) which you are going to do call reserve_bootmem ! Kernel version is 2.6.16.29 and the reserve_bootmem() call above is at the top of the function devicemaps_init(). Is there some way I can verify that the above works? I've tried the following to try to get info on the reservation: # cat /proc/iomem # cat /proc/meminfo # cat /proc/slabinfo # echo m /proc/sysrq-trigger The only one that hints that this might have worked is the `echo m /proc/sysrq-trigger` in that I see the reserved pages count one larger than using a kernel without this patch. Does this mean that the page I reserved won't get used by Linux for any purpose? I havn't looked at # echo m /proc/sysrq-trigger till now but I am almost sure that it will reserve/work because calling reserve_bootmem internally sets the bit representing physical memory page (CMIIW). -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a fixed physical address page of RAM.
On 11/28/06, Dave Airlie <[EMAIL PROTECTED]> wrote: On 11/28/06, Jon Ringle <[EMAIL PROTECTED]> wrote: > It looks promising, however, I need to reserve a physical address area > that is well known (so that the code running on the other processor > knows where in PCI memory to write to). It appears that > dma_alloc_coherent returns the address that it allocated. Instead I need > something where I can tell it what physical address and range I want to use. > I've seen other projects just boot a 128M board with mem=120M and just use the 8MB at 120 to talk to the other processor.. Yes, this can be used if required physical-memory exists in the last part of RAM as if you use mem= then kernel will only use memory less than or equal-to and above can be used by drivers (or any kernel module) might be through ioremap which takes physical-address. But if lets say we need only 1MB portion of specific physical-memory region then AFAIK it must be done by hacking in kernel code during memory-initialization (mem_init function) where it is marking/checking pages as/are reserved; you can simply mark you required pages as reserved too and set their count to some-value if you want to know later which pages are reserved by you. (can do this reservation work here: http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605). CMIIW -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a fixed physical address page of RAM.
On 11/28/06, Dave Airlie [EMAIL PROTECTED] wrote: On 11/28/06, Jon Ringle [EMAIL PROTECTED] wrote: snip It looks promising, however, I need to reserve a physical address area that is well known (so that the code running on the other processor knows where in PCI memory to write to). It appears that dma_alloc_coherent returns the address that it allocated. Instead I need something where I can tell it what physical address and range I want to use. I've seen other projects just boot a 128M board with mem=120M and just use the 8MB at 120 to talk to the other processor.. Yes, this can be used if required physical-memory exists in the last part of RAM as if you use mem=xxxM then kernel will only use memory less than or equal-to xxxM and above can be used by drivers (or any kernel module) might be through ioremap which takes physical-address. But if lets say we need only 1MB portion of specific physical-memory region then AFAIK it must be done by hacking in kernel code during memory-initialization (mem_init function) where it is marking/checking pages as/are reserved; you can simply mark you required pages as reserved too and set their count to some-value if you want to know later which pages are reserved by you. (can do this reservation work here: http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605). CMIIW -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reuse of BIOs
On 9/8/05, David Howells <[EMAIL PROTECTED]> wrote: > > > Is it possible to reuse a BIO once the callback on it has been invoked to > indicate final completion? Or does it have to be released and another one > allocated? > The thing which I did in my virtual caching device driver is I keeps the pointer of BIO got from the kernel in my locally created BIO's private field (and fill other fields with the original BIO's Data) and sends it to other caching device and when got the end_io for that BIO (like in read from caching device and writing to target device) I put that in the queue and one of my thread directly sends that to the target device without changed except replacing the sector of caching device to the target device sector and after getting completion signal from target device, I just freed that BIO or move it to my free pool of BIOs and just call the completion for the original BIO taken back from the private field of local BIO .. This means we can reuse BIO sended to one device and then sending that to other device after getting completion signal from first device . But I can't say this about the original kernel BIO b/c I m not sending it to any of my devices -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reuse of BIOs
On 9/8/05, David Howells [EMAIL PROTECTED] wrote: Is it possible to reuse a BIO once the callback on it has been invoked to indicate final completion? Or does it have to be released and another one allocated? The thing which I did in my virtual caching device driver is I keeps the pointer of BIO got from the kernel in my locally created BIO's private field (and fill other fields with the original BIO's Data) and sends it to other caching device and when got the end_io for that BIO (like in read from caching device and writing to target device) I put that in the queue and one of my thread directly sends that to the target device without changed except replacing the sector of caching device to the target device sector and after getting completion signal from target device, I just freed that BIO or move it to my free pool of BIOs and just call the completion for the original BIO taken back from the private field of local BIO .. This means we can reuse BIO sended to one device and then sending that to other device after getting completion signal from first device . But I can't say this about the original kernel BIO b/c I m not sending it to any of my devices -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
Dear Arjan, On 8/8/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > 1) you probably should use RH support for this > 2) you forgot to attach your sourcecode / URL to that, including the >full source of your module. > I already mentioned my code and some details in my previous mail on the list Can u check and help me out or I hav to send that again And as far as Redhat Support concerns that problem is not related to Redhat because I reserved memory by placing the code in the arch/i386/mm/init.c file in one_highpage_init function not through mem= option of the kernel .. Waiting for your response and help ..... -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
On 8/8/05, Zachary Amsden <[EMAIL PROTECTED]> wrote:
>
> IIRC 2.4.21 has some highmem bugs that have since been fixed. But, it
> sounds like you might be doing something quite unusual. Code would
> definitely give people a better idea of what might be wrong.
I think you overlooked what i mentioned in P.S. ; which is
My memory reservation and later using that memory through kmap_atomic
works well on the kernels other than RHEL3 2.4.21-e.ELsmp
.. the page reservation was done in the
arch/i386/mm/init.c file in function one_highpage_init .. I have
Machine with 16GB RAM and 2 - Xeon 2.4GHz Processors .
The code which I added for memory reservation in kernel is :
void __init one_highpage_init(struct page *page, int pfn, int bad_ppro)
{
if (!page_is_ram(pfn)) {
SetPageReserved(page);
return;
}
if (bad_ppro && page_kills_ppro(pfn)) {
SetPageReserved(page);
return;
}
// Here's the code which i added for memory reservation . i m
setting 0xC4 in page->count just because i will know later that these
pages have been reserved by me ... not by kernel .
if ((unsigned long)(page - mem_map) > 0x8) {
SetPageReserved(page);
set_bit(PG_highmem, >flags);
atomic_set(>count, 0xC4);
totalhigh_pages++;
return;
}
// My code Ends here
ClearPageReserved(page);
set_bit(PG_highmem, >flags);
atomic_set(>count, 1);
__free_page(page);
totalhigh_pages++;
}
After this in my module, i simply use kmap_atomic to map the page
reserved by me and tried to use that its working perfect in
both 2.4.x series and also working in 2.6.x .
> You should definitely consider moving to 2.6 to get a better response.
>
i already moved to 2.6.x already !!! but the current requiment is to
use RHEL3 Kernel which is 2.4.21-27.ELsmp
I think its now more clear !!!! waiting for your resposes !!!
--
Fawad Lateef
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
On 8/8/05, Zachary Amsden [EMAIL PROTECTED] wrote:
IIRC 2.4.21 has some highmem bugs that have since been fixed. But, it
sounds like you might be doing something quite unusual. Code would
definitely give people a better idea of what might be wrong.
I think you overlooked what i mentioned in P.S. ; which is
My memory reservation and later using that memory through kmap_atomic
works well on the kernels other than RHEL3 2.4.21-e.ELsmp
.. the page reservation was done in the
arch/i386/mm/init.c file in function one_highpage_init .. I have
Machine with 16GB RAM and 2 - Xeon 2.4GHz Processors .
The code which I added for memory reservation in kernel is :
void __init one_highpage_init(struct page *page, int pfn, int bad_ppro)
{
if (!page_is_ram(pfn)) {
SetPageReserved(page);
return;
}
if (bad_ppro page_kills_ppro(pfn)) {
SetPageReserved(page);
return;
}
// Here's the code which i added for memory reservation . i m
setting 0xC4 in page-count just because i will know later that these
pages have been reserved by me ... not by kernel .
if ((unsigned long)(page - mem_map) 0x8) {
SetPageReserved(page);
set_bit(PG_highmem, page-flags);
atomic_set(page-count, 0xC4);
totalhigh_pages++;
return;
}
// My code Ends here
ClearPageReserved(page);
set_bit(PG_highmem, page-flags);
atomic_set(page-count, 1);
__free_page(page);
totalhigh_pages++;
}
After this in my module, i simply use kmap_atomic to map the page
reserved by me and tried to use that its working perfect in
both 2.4.x series and also working in 2.6.x .
You should definitely consider moving to 2.6 to get a better response.
i already moved to 2.6.x already !!! but the current requiment is to
use RHEL3 Kernel which is 2.4.21-27.ELsmp
I think its now more clear waiting for your resposes !!!
--
Fawad Lateef
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
Dear Arjan, On 8/8/05, Arjan van de Ven [EMAIL PROTECTED] wrote: 1) you probably should use RH support for this 2) you forgot to attach your sourcecode / URL to that, including the full source of your module. I already mentioned my code and some details in my previous mail on the list Can u check and help me out or I hav to send that again And as far as Redhat Support concerns that problem is not related to Redhat because I reserved memory by placing the code in the arch/i386/mm/init.c file in one_highpage_init function not through mem= option of the kernel .. Waiting for your response and help . -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
Hello, I m facing a problem in RHEL3 (2.4.21-5.ELsmp) kernel while using kmap_atomic on the pages reserved at the boot time At the boot time I reserved pages above 2GB for later use by my module . And when I was using those reserved pages through kmap_atomic system hangs; although kmap_atomic successfully returns me the virtual address but when I use that virtual address like in memcpy the system hangs . I m unable to findout why it is happening in RHEL3 kernel Plz help me in this regard -- Fawad Lateef P.S. My memory reservation and later using that memory through kmap_atomic works well on the kernels other than RHEL3 2.4.21-e.ELsmp .. the page reservation was done in the arch/i386/mm/init.c file in function one_highpage_init .. I have Machine with 16GB RAM and 2 - Xeon 2.4GHz Processors . - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
Hello, I m facing a problem in RHEL3 (2.4.21-5.ELsmp) kernel while using kmap_atomic on the pages reserved at the boot time At the boot time I reserved pages above 2GB for later use by my module . And when I was using those reserved pages through kmap_atomic system hangs; although kmap_atomic successfully returns me the virtual address but when I use that virtual address like in memcpy the system hangs . I m unable to findout why it is happening in RHEL3 kernel Plz help me in this regard -- Fawad Lateef P.S. My memory reservation and later using that memory through kmap_atomic works well on the kernels other than RHEL3 2.4.21-e.ELsmp .. the page reservation was done in the arch/i386/mm/init.c file in function one_highpage_init .. I have Machine with 16GB RAM and 2 - Xeon 2.4GHz Processors . - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: About Linux Device Drivers
On 8/6/05, D. ShadowWolf <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-08-05 at 22:18 +0200, Alejandro Cabrera wrote: > > > Hi > > > I'm new in the list and I'm interested in lkm, I have the Linux Device > > > Drivers 2ed. And I use the 2.6.8-2 kernel, and the modules that I create > > > I don't test in my workstation. Exist any way to run the examples > > > exposed in this book over my kernel or I need the LDD 3ed > > > thx for your patient > > > Alejandro > > > > It appears he's interested in writing modules for the Linux Kernel and has > been using the book 'Linux Device Drivers, Second Edition' as a reference, > but none of the examples in the book are compiling for him. As he's stated, > he's running kernel 2.6.8-2. > > He wants to know if there is any way to make the examples in that book work or > if he has to go pick up the new version of that book. I've not seen the > books examples myself, and I'm just trying to get up to speed on the kernel > internals myself so I can't answer his question. > > Hope the interpretation of his somewhat broken english helps :) > If ShadowWolf interpretation of Alejandro's question is right and Alejandro trying to run the LDD2 books examples on 2.6.8-2 then they won't work on 2.6.x kernel or not even compile successfully That LDD2 book is for 2.2 and 2.4 kernel series and LDD3 is for 2.6 series, so go for LDD3 for your 2.6.x kernel .. -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: About Linux Device Drivers
On 8/6/05, D. ShadowWolf [EMAIL PROTECTED] wrote: On Fri, 2005-08-05 at 22:18 +0200, Alejandro Cabrera wrote: Hi I'm new in the list and I'm interested in lkm, I have the Linux Device Drivers 2ed. And I use the 2.6.8-2 kernel, and the modules that I create I don't test in my workstation. Exist any way to run the examples exposed in this book over my kernel or I need the LDD 3ed thx for your patient Alejandro It appears he's interested in writing modules for the Linux Kernel and has been using the book 'Linux Device Drivers, Second Edition' as a reference, but none of the examples in the book are compiling for him. As he's stated, he's running kernel 2.6.8-2. He wants to know if there is any way to make the examples in that book work or if he has to go pick up the new version of that book. I've not seen the books examples myself, and I'm just trying to get up to speed on the kernel internals myself so I can't answer his question. Hope the interpretation of his somewhat broken english helps :) If ShadowWolf interpretation of Alejandro's question is right and Alejandro trying to run the LDD2 books examples on 2.6.8-2 then they won't work on 2.6.x kernel or not even compile successfully That LDD2 book is for 2.2 and 2.4 kernel series and LDD3 is for 2.6 series, so go for LDD3 for your 2.6.x kernel .. -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel page size explanation
On 7/25/05, VASM <[EMAIL PROTECTED]> wrote: > i had one question > does the linux kernel support only one default page size even if the > processor on which it is working supports multiple ? > The PAGE_SIZE depends on the architecture and it do supports different page_sizes depending on the architecture (AFAIK for almost all supported architectures) -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel page size explanation
On 7/25/05, VASM [EMAIL PROTECTED] wrote: i had one question does the linux kernel support only one default page size even if the processor on which it is working supports multiple ? The PAGE_SIZE depends on the architecture and it do supports different page_sizes depending on the architecture (AFAIK for almost all supported architectures) -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regarding KDB for REDHAT9.0
On 7/19/05, Keith Owens <[EMAIL PROTECTED]> wrote: > > Sorry, not available. RedHat do not want kdb so SGI do not do KDB > patches against RedHat distributions. Use SuSE instead, that has KDB > built in. > I want to add one more thing, you can compile your own kernel with KDB patch applied if u really want to use KDB on Redhat .. And I think you can also try to apply patch of KDB for 2.4.20 on the Redhat kenel, that might succeed if redhat havn't changed anything in the files of 2.4.20 kernel in which KDB patches or make changes ..... -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Avoiding BIGMEM support programatically.
On 7/18/05, vamsi krishna <[EMAIL PROTECTED]> wrote: > Hello All, > > I have a program working fine on a 2.6.xx-smp kernel, and the program > crashes on the same version kernel with bigmem i.e (2.6.xxx-bigmem). > What is your program ??? what it is doing ??? Can u explain ?? or send some code portion ?? b/c the BIGMEM kernel and smp/normal kenel has only a difference of HIGHMEM64G which allows system/kernel on x86 to use physical memory upto 64GB . and enabling this creates little-bit overhead on the kernel, but I don't think it will effect the working of most of the kernel modules .. > I also found that for a same executable on bigmem kernel the virtual > address's of '&_start' and '&_etext', seem to vary in every new run. > I don't know abt this, so can't say any thing > Is there any way I can avoid the kernel's bigmem virtual address > mapping programatically? and still run the program on a bigmem kernel? > I think this can be done through specifying GFP_ATOMIC flag in the memory allocation function, so that it will use ZONE_NORMAL of the kernel ... (if i m wrong, then plzz do correct me) -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Avoiding BIGMEM support programatically.
On 7/18/05, vamsi krishna [EMAIL PROTECTED] wrote: Hello All, I have a program working fine on a 2.6.xx-smp kernel, and the program crashes on the same version kernel with bigmem i.e (2.6.xxx-bigmem). What is your program ??? what it is doing ??? Can u explain ?? or send some code portion ?? b/c the BIGMEM kernel and smp/normal kenel has only a difference of HIGHMEM64G which allows system/kernel on x86 to use physical memory upto 64GB . and enabling this creates little-bit overhead on the kernel, but I don't think it will effect the working of most of the kernel modules .. I also found that for a same executable on bigmem kernel the virtual address's of '_start' and '_etext', seem to vary in every new run. I don't know abt this, so can't say any thing Is there any way I can avoid the kernel's bigmem virtual address mapping programatically? and still run the program on a bigmem kernel? I think this can be done through specifying GFP_ATOMIC flag in the memory allocation function, so that it will use ZONE_NORMAL of the kernel ... (if i m wrong, then plzz do correct me) -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regarding KDB for REDHAT9.0
On 7/19/05, Keith Owens [EMAIL PROTECTED] wrote: Sorry, not available. RedHat do not want kdb so SGI do not do KDB patches against RedHat distributions. Use SuSE instead, that has KDB built in. I want to add one more thing, you can compile your own kernel with KDB patch applied if u really want to use KDB on Redhat .. And I think you can also try to apply patch of KDB for 2.4.20 on the Redhat kenel, that might succeed if redhat havn't changed anything in the files of 2.4.20 kernel in which KDB patches or make changes . -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Panic: VFS cannot open a root device
On 7/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I already done that things , and I still getting these errors ... I dont > no what to do , and I'm getting desesperated... > > '>' > '>'You should compile in the filesystem (reiserfs?) into the kernel (* > instead > '>'of > '>'M), or put the correct module in initrd (usually done by mkinitrd). > > '>'After that run lilo, and it should boot just fine. > '>' > '>'Norbert > '>' > '>'Op zaterdag 16 juli 2005 20:57, schreef u: > '>'> > Hi , i have kernel 2.4.29 at slack 10.1 and when I upgrade my kernel > '>'to > '>'> > 2.6.11 I get these erros on booting > '>'> > > '>'> > VFS: Cannot open a root device "301" or unknow block > '>'> > please append a correct "root" boot option > '>'> > KERNEL PANIC : not syncing; VFS; Unable to mount root fs on > '>'> > unknown-block (3,1) > '>'> > > '>'> > I have compiled my kernel with my IDE support and also with my file > '>'> > system support with built-in option. > '>'> > > '>'> > My LILO.CONF > '>'> > image = /boot/vmlinuz-2.6.11 > '>'> > root = /dev/hda1 > '>'> > label = 2.6.11 > '>'> > initrd = /boot/initrd.gz > '>'> > read-only > '>'> > I saw this prob when my boot device/partition in the bootloader config was wrong or the filesystem of my root partition is not compiled as a kernel image rather compiled as module, so plz try to solve this prob by selecting your desired filesystem in kernel configuration as Y rather than M .. I hope this will work > '>'> > I'm booting with my image of kernel 2.4.29. i'm 5 days tryng > to solve > '>'> > this problem ... Upgrading from 2.4.xx kernel series to 2.6.xx series what I found is that the filesystem must be compiled into the kernel image not as a module b/c in 2.4.xx filesystem compiled as module also work And another thing is that I never succedded in booting the 2.6.xx kernel __successfully__ compiled from 2.4.xx series (distribution with default 2.4.xx series kernel like Fedora Core 1 or Redhat Linux 9) and found that my mouse won't work on 2.6.xx series kernel, but the distribution with 2.6.xx kernel series by default works fine . -- Fawad Lateef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Panic: VFS cannot open a root device
On 7/18/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I already done that things , and I still getting these errors ... I dont no what to do , and I'm getting desesperated... '' ''You should compile in the filesystem (reiserfs?) into the kernel (* instead ''of ''M), or put the correct module in initrd (usually done by mkinitrd). ''After that run lilo, and it should boot just fine. '' ''Norbert '' ''Op zaterdag 16 juli 2005 20:57, schreef u: '' Hi , i have kernel 2.4.29 at slack 10.1 and when I upgrade my kernel ''to '' 2.6.11 I get these erros on booting '' '' VFS: Cannot open a root device 301 or unknow block '' please append a correct root boot option '' KERNEL PANIC : not syncing; VFS; Unable to mount root fs on '' unknown-block (3,1) '' '' I have compiled my kernel with my IDE support and also with my file '' system support with built-in option. '' '' My LILO.CONF '' image = /boot/vmlinuz-2.6.11 '' root = /dev/hda1 '' label = 2.6.11 '' initrd = /boot/initrd.gz '' read-only '' I saw this prob when my boot device/partition in the bootloader config was wrong or the filesystem of my root partition is not compiled as a kernel image rather compiled as module, so plz try to solve this prob by selecting your desired filesystem in kernel configuration as Y rather than M .. I hope this will work '' I'm booting with my image of kernel 2.4.29. i'm 5 days tryng to solve '' this problem ... Upgrading from 2.4.xx kernel series to 2.6.xx series what I found is that the filesystem must be compiled into the kernel image not as a module b/c in 2.4.xx filesystem compiled as module also work And another thing is that I never succedded in booting the 2.6.xx kernel __successfully__ compiled from 2.4.xx series (distribution with default 2.4.xx series kernel like Fedora Core 1 or Redhat Linux 9) and found that my mouse won't work on 2.6.xx series kernel, but the distribution with 2.6.xx kernel series by default works fine . -- Fawad Lateef - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
