Messages in this thread |  | | | Date | Sun, 8 May 2005 12:28:18 -0400 | | From | Jeff Dike <> | | Subject | Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops |
| |
On Sun, May 08, 2005 at 01:18:32AM +0100, Al Viro wrote: > Hrm...
I had a lot of these fixed already. These will be mostly in the fixlets patch.
> a) stub.S handling breaks on O= builds. Actually, your unprofile > breaks there - it's bypassing the machinery that deals with include path.
This? $(patsubst -pg,,$(patsubst -fprofile-arcs -ftest-coverage,,$(1)))
I don't see any connection to include paths there.
> b) stub_segv.c on amd64 includes <signal.h>. Not a good idea...
x86_64 doesn't, but i386 does. Fixed now.
> c) sysdep-x86_64/checksum.h in -rc4 has csum_partial_copy_from_user() > that needs updating (AFAICS, you have that in your patchset, but it hadn't > reached Linus)
Fixed.
> d) ip_compute_csum() prototype is missing (same file) > j) ip_compute_csum should be exported on amd64.
OK, I need to look at this a bit more.
> e) #define UPT_SYSCALL_RET(r) UPT_RAX(r) is needed in amd64 ptrace.h
Fixed.
> f) take a good look at UPT_SET() in the same file ;-)
Sigh. Fixed now.
> g) CFLAGS_csum-partial.o := -Dcsum_partial=arch_csum_partial in > sys-x86_64/Makefile needs to be removed.
Fixed.
> h) Makefile.rules should be included _after_ SYMLINKS = in the same > file.
Fixed.
> i) sys-x86_64/delay.c needs exports of __udelay() and __const_udelay(), > include of linux/module.h and barriers in your delay loop bodies (or games > with volatile - anything that would guarantee that gcc won't decide to optimize > the entire loop away). The last part applies to i386 as well.
Looks to me like it all applies to i386 too, except that __delay looks unoptimizable.
It also looks to me like I could implement __udelay as n=... ; __delay(n);
And also never mind the fact that __udelay and __const_udelay are identical.
> k) sys-x86_64/syscalls.c needs include "kern.h"
Fixed now.
> l) elf-i386.h should include <asm/user.h>, not "user.h"
Fixed now.
> m) elf-x86_64.h lacks R_X86_64_... definitions
Fixed now.
> n) WTF _is_ that #ifdef TIF_IA32 in there? Aside of the trailing \, > we could as well put #error there - free-floating clear_thread_flag(TIF_IA32);> outside of any function body will have that effect anyway.
The trailing \ aside, which is fixed, that's a reminder for me when I add the 32-bit compatibility code.
> o) in drivers/chan_kern.c we have several printf(KERN_ERR "..."); > these should become printk, as they clearly had been intended. As it is, > they give instant panic if we ever call them.
Oops. This requires a bit of thought. Offhand, I think they need to be printf, because that early in boot, printk'd stuff may not reach the screen if UML exits then.
> p) TOP_ADDR in Kconfig_x86_64 got lost in transmission - your patchset > has it, but same patch in Linus' tree does not.
Fixed
> > I've got patches for everything except (a); that one is really nasty. I hope > to sort it out by tonight; if not, I'll just send what I've got by now.
OK, send me what you have, and if we've fixed the same thing differently, I choose one or the other.
Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |