Hello: We have a piece of kernel code that calls some system calls in kernel context (from a process with mm and a daemonized kernel thread that does not have mm). This works fine on IA64 and i386 architectures. When I try this on x86-64 kernel on Opteron machines, it results in immediate crash. I have tried standard _syscall() macros from asm/unistd.h. The system panics when returning from the system call. The disassembled code shows that gcc has often a hard time deciding which registers (32-bit or 64-bit) it will use. For example, it puts the system call number to eax, while it should put it to rax. However, this register thing is not a problem. I have tried my own gcc hand-crafted inline assembly and glibc inline syscall assembly that results in "correct" disassembled code. The result is always the same -- kernel crash when calling a function defined by _syscall() macros or when using an "inline" block defined by glibc macros. Attached please find a test module that tries to call the umask() (JUST TO DEMONSTRATE a problem) via the syscall machanism. Both methods (the _syscall1() marco and GLIBC INLINE_SYCALL() were used. The assembly dump of the umask() called via _syscall(1) and via INLINE_SYSCALL() as well as the disassembly of umask() from glibc are provided in a separate attachement. The crash dump (captured with a serial console) is provided along with disassembly of the main module function. It seems that segmentation is changed during the syscall and not restored properly, or some other REALLY BAD THING happens. The entry.S for x86_64 architecture is very informative, but I am not an expert in Opteron architecture and I do not know how the syscall instruction is supposed to work. Can someone explain the reason for the crash? Can you think of a workaround? Comments and ideas are very welcome (except of the kind that it can be implemented in the user space or with a help of a user proxy process). Thanks. Please CC to me. I am not subscribed to the lists. Additional info: uname -a Linux dev83 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64 x86_64 x86_64 GNU/Linux cat /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 240 stepping : 1 cpu MHz : 1394.254 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips : 2778.72 TLB size : 1088 4K pages clflush size : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 240 stepping : 1 cpu MHz : 1394.254 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips : 2785.28 TLB size : 1088 4K pages clflush size : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 6137491456 84901888 6052589568 0 12132352 22863872 Swap: 1048698880 0 1048698880 MemTotal: 5993644 kB MemFree: 5910732 kB MemShared: 0 kB Buffers: 11848 kB Cached: 22328 kB SwapCached: 0 kB Active: 37588 kB ActiveAnon: 7232 kB ActiveCache: 30356 kB Inact_dirty: 3816 kB Inact_laundry: 0 kB Inact_clean: 0 kB Inact_target: 8280 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 5993644 kB LowFree: 5910732 kB SwapTotal: 1024120 kB SwapFree: 1024120 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB -- ---------------------------------------- Constantine Gavrilov Kernel Developer Qlusters Software Ltd 1 Azrieli Center, Tel-Aviv Phone: +972-3-6081977 Fax: +972-3-6081841 ----------------------------------------