SMT_ID or APIC_ID caching
On a P4 with HT, I'm trying to get the logical processor ID (SMT_ID) for the currently executing thread in kernel mode. The SMT_ID is part of the APIC_ID which is in EBX[24:16] after calling cpuid with EAX=1. Is the SMT_ID or APIC_ID per_cpu cached by the kernel anywhere? Thanks, -bryan - 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: KLive: Linux Kernel Live Usage Monitor
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote: > The idea isn't bad but lots of people could think that this is some kind > of home-phoning or spy software. I guess lots of people would turn this > feature off...and of course you can't enable it by default. But combined > with an automatic oops/panic/bug-report this would be _very_ useful I > think. I think this is useful and would personally participate if it were a config tweak. There are a couple of issues that come to mind. 1. Possibly paranoia, but given the apparent numbers of people with malicious intent on the Internet and knowing that there are some financially motivated to make Linux kernel developers over confident in they're work, I'm not sure I'd trust or use the data unless it was somehow authenticated. 2. Some of us sit behind corporate firewalls and proxies that have oppressive rules that would have made Stalin proud. The solution must be proxy aware and if it used HTTP, even better because it's more likely to work anywhere. The proxy settings could also be a .config thing. 3. Again security; I haven't cleared this with my corporate superiors but I'm not sure they'll like the fact that anyone could intercept the data and compute how many people in the company are running Linux test kernels. I know this almost sounds anti-open but we're breaking them in slowly to the model and I don't think they are ready for this one just yet. :) -bryan - 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: kgdb on EM64T
George Anzinger [mailto:[EMAIL PROTECTED] wrote: > >Well, I checked, it is "int $3". Why then the panic? If you try the >boot with kgdb (i.e. wait) and the do: >(gdb) disass gdb_interrupt >What do you find at +75? Below is the console from the session it is interesting that gdb is not able to access the memory. I let it continue and then ctrl-c broke it later in the boot cycle and tried disass again with the same result. Feel free to flog me if this is stupid but I have just one EM64T machine (test) and I'm using a regular P4 machine as dev. I build the test kernel on the EM64T machine and then copy the updated sources, object files, and images via NFS to the dev machine. I believe I read in the kgdb doc that it was possible to use to different architecture machines for test and dev although there wasn't any information about how to do it. This is probably the source of the OS/ABI warning. I can probably get the mothership to send me another EM64T machine if need be. vincent:/home/bwilkers/proj/linux-2.6.13-rc4-mm1 # gdb vmlinux GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 0x80503b50 in ?? () warning: no shared library support for this OS / ABI (gdb) disass gdb_interrupt Dump of assembler code for function gdb_interrupt: 0x80247009 : Cannot access memory at address 0x80247009 (gdb) c Continuing. Bootdata ok (command line is root=/dev/sda2 kgdb console=kgdb) Linux version 2.6.13-rc4-mm1-perfmon-em64t ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #43 SMP Sat Aug 27 15:56:14 MDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e6000 - 0010 (reserved) BIOS-e820: 0010 - 3fe2f800 (usable) BIOS-e820: 3fe2f800 - 3fe3f832 (ACPI NVS) BIOS-e820: 3ff1 - 3ff3 (reserved) BIOS-e820: 3ff3 - 3ff4 (ACPI data) BIOS-e820: 3ff4 - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fed13000 - fed1a000 (reserved) BIOS-e820: fed1c000 - feda (reserved) ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) - 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/
kgdb on EM64T
Thanks you Tom and George for the tips on using kgdb with 2.6.13-rc4-mm1. I almost have it working but kgdb seems to have a few issues. I can get it running from the dev machine using the kgdb and console=kgdb boot options on the test kernel. The kernel waits as it should and when I attach with "target remote /dev/ttyS0" and I can continue the boot but eventually it gets to a point in the boot where it frees unused kernel memory successfully and then a warning, "unable to open an initial console", followed by, "Kernel panic - not syncing: Attempted to kill init!" Removing the console=kgdb boot option and the machine boots all the way to run level 5. I tried to break into kgdb at this point using the $echo -e "\003" > /dev/ttyS0 from the dev machine but the test kernel panics at gdb_interrupt+75 when it receives anything on the serial port. Hmmm... I'm wondering if I'm maybe just the first to try this on EM64T (kernel builds in the arch/x86_64 tree). Any suggestions welcome. -bryan - 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/
kgdbwait in 2.6.13-rc4-mm1?
Is there an equivalent kernel boot option for kgdbwait in 2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait. Is there any documentation other than the source for the flavor of KGDB that is included in the akpm kernel patch? Thanks, -bryan - 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/
