Jack, I am doing a port of kdb x86_64 from your 2.6.8 patch to a vendor kernel 2.6.10. The system boots and I can enter KDB properly. I had to make alot of changes to traps.c (and add a kdb_call to entry.S) for the trap handlers to enter KDB properly. Without the trap handler changes, the active processes were not being saved properly which caused all kinds of havok. This may be an SMP only symptom.
After these changes to get KDB to appear to work properly I have a couple of problems. First I am using an SMP kernel. calling kdb() works, and when a breakpoint occurs (int3) kdb is entered. But then If I type go, and the same breakpoint occurs again, I get the notification: 92.168.1.150 login: root Instruction(i) breakpoint #0 at 0xffffffff8013d13b (adjusted) 0xffffffff8013d13b sys_getuid: int3 Entering kdb (current=0x000001007e7e27d0, pid 1983) on processor 3 due to Breakpoint @ 0xffffffff8013d13b [3]kdb> goo 1 out of 4 cpus in kdb, waiting for the rest, timeout in 10 second(s) ...3 cpus are not in kdb, their state is unknown Instruction(i) breakpoint #0 at 0xffffffff8013d13b (adjusted) 0xffffffff8013d13b sys_getuid: int3 Entering kdb (current=0x000001007e7e27d0, pid 1983) on processor 3 due to Breakpoint @ 0xffffffff8013d13b [3]kdb> goo Ever see that during testing? (did you try SMP?) Note sys_getuid will be called several times by the login application. I have run into another interesting problem that you may be aware of. CONFIG_FRAME_POINTERS is disallowed with x86_64 architecture (lib/Kconfig.debug). I think this results in funky backtraces, something like (it is possible something else is broken besides the frame pointers): SP RIP Function (args) 0x1007ff01c48 0x0000010002c558e0 <unknown>+0x10002c558e0 0x1007ff01c50 0x000001007ff01d48 <unknown>+0x1007ff01d48 0x1007ff01c58 0x0000000000000002 <unknown>+0x2 0x1007ff01c60 0x000001007eded488 <unknown>+0x1007eded488 0x1007ff01c68 0x00000100032ef070 <unknown>+0x100032ef070 0x1007ff01c70 0x000001007fea15c0 <unknown>+0x1007fea15c0 0x1007ff01c78 0x0000000000000002 <unknown>+0x2 0x1007ff01c80 0x000001007eded380 <unknown>+0x1007eded380 0x1007ff01c88 0x000000767eded488 <unknown>+0x767eded488 0x1007ff01c90 0xffffffff807375c0 _einittext+0xee49 Those addresses are all user addresses. I havn't dug into it much but it looks like the backtrace is tracking some other junk instead of the kernel function stack. I asked around here and someone mentioned the community kernel.org tree disallows frame pointers for x86_64 because they are broken. Suggestion was to use dwarf instead. This seems like an ugly choice to me :) Any ideas? regards -steve On Tue, 2005-06-07 at 23:52, Jack F Vogel wrote: > On Tue, Jun 07, 2005 at 07:17:56PM -0700, Chait Tumuluri wrote: > > Hi folks, > > > > Is there a port for x86_64, Linux 2.6.11 out there? > > > > I tried using the 2.6.11-common3 with the 2.6.8 arch-specific > > kdb patch and it fails during bootup (where it frees up unused > > kernel memory). The same behavior with 2.6.9 arch-specific patch > > as well. > > > > TIA for any insights or patches. > > > > Regards, > > -Chait. > > Well I did the 2.6.8 patch, however my job has me > very busy the last six months, none of it devoted > to kdb :( > > I will try and take a look at the current kernel. > > What is the failure mode during boot, a panic, a > hang? > > Regards, > > Jack > > --------------------------- > Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe. --------------------------- Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
