On 01/03/2011 04:31 PM, Markus Duft wrote:
> Hi!
>
> Another question: Shouldn't the APIC version be 0x14 for CPUs since P4/Xeon?
> At least according to the Intel docs, since then the xAPIC is used, which has
> 0x14 as version (see intel manuals, vol 3a "10.4.8 Local
Hi!
Another question: Shouldn't the APIC version be 0x14 for CPUs since P4/Xeon? At
least according to the Intel docs, since then the xAPIC is used, which has 0x14
as version (see intel manuals, vol 3a "10.4.8 Local APIC Version Register".
reading the APIC version register yields 0x11 for all C
On 01/03/2011 02:00 PM, Jan Kiszka wrote:
> [ please keep CCs ]
>
> Am 03.01.2011 13:27, Markus Duft wrote:
>> On 01/03/2011 01:15 PM, Markus Duft wrote:
>>> On 01/03/2011 12:15 PM, Jan Kiszka wrote:
>>> [snip]
>> [snip]
>>> actually, i find that Te
On 01/03/2011 01:15 PM, Markus Duft wrote:
> On 01/03/2011 12:15 PM, Jan Kiszka wrote:
> [snip]
[snip]
> actually, i find that Ted Harkington was right: in 0.11.1 i can debug 32 bit
> code with qemu-system-x86_64 well enough (which means i debugged all the 32
> bit part of my kern
On 01/03/2011 12:15 PM, Jan Kiszka wrote:
[snip]
>>
>> 1) is this a problem with qemu or was qemu "fixed" and gdb has a problem?
>>(that's why i CCd the gdb list ;)).
>> 2) is there any plan to fix this issue?
>> 3) is there some kind of workaround i can use (i'd be happy with an
>> ugly/unsup
Hi!
I have been playing a little with this: I'm writing a kernel for both x86 and
x86-64. While doing so, i'd like to debug the kernel using qemu (and it's gdb
stub) and gdb. This worked very well until qemu-0.11.1 (gdb version does not
seem to play any role...). From there on, debugging the 64
