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
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
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
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
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
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
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
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
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:
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:
10 matches
Mail list logo
