Problems with l4linux

[Valery V. Sedletski]

On Tue, 28 Oct 2008 17:48:44 +0100, Adam Lackorzynski wrote:

>> >Rather not. Can you tell me at which position the f.2 is in user-land?
>> >That would be interesting.
>> > 
>> 
>> This is the result of executing "tf.2" in kernel debugger:
>> 
>> thread:   f.02 <001e0801>               prio: a0  mcp: ff  mode: Con
>> state: 001 ready    %dl
>> 001e0804     into
>> wait for:           polling:            rcv descr:
>> lcked by: ---.--                        timeout  :
>> cpu time:   2.000 ms                    timeslice: 4000/10000 ╣s
>> pager   :   f.00        cap: ---.--     utcb: ffe34200
>> preemptr:   0.00        not monitored   ready lnk:  ???.??   5.00
>>                                         prsnt lnk:   f.04   f.00
>> EAX=00000000  ESI=001e0801  DS=0023
>> EBX=a0051454  EDI=00000000  ES=0023     iret
>> ECX=0000000d  EBP=afeffe40  GS=0043     lea    0x0(%esi),%esi
>> EDX=afeffe58  ESP=c03c17ec  SS=0010
>> trap 13 (General Protection), error 00000070, from kernel mode
>> CS=0008  EIP=f003622b  EFlags=00203246
>> 001e0815     cli
>> c03c17ec f003622b 00000008 00203246 [eacff102] 00000073 00203296 afeffe00 0000007b
>> 001e0818     into
>> 
>> the [eacff102] dword was highlighted in backtrace. So, as I understood
>> this, this marks current stack frame. Here we see that previous stack
>> frame is ip=0xf003622b, cs=0x8, eflags=0x00203246 is respectively ip,
>> cs and eflags taken off from the stack by previous iret instruction.
>> Current iret must take off the next frame: eip=0xeacff102, cs=0x73,
>> eflags=0x00203296. Here we can see that selector cs=0x73 is ring3 and
>> eip is 0xeacff102. 
>
>Yep, ok, cs value is bogus. Now we need to find out why, cs should be
>1b. (8 is kernel code, so ok.) Maybe I find the time to reproduce this
>but on the other side it does not happen when the IOPL3 option is off,
>right?
> 

CS is incorrect? That's why it traps... I tried to set breakpoint before TRAP d in linux 
(in ioport.c when it writes "Got %d out of %d I/O ports") -- set "-wait" in fiasco command 
line and when it broke in kernel debugger after fiasco started, tried to set breakpoint:

bi addr=4054ec 
b+ bpn=1
br bpn=1 task=f

But after I said "g" in the debugger it didn't stopped at the breakpoint, only broke in TRAP d. What I do incorrectly?
Maybe,  bi addr=4054ec sets the breakpoint at phys address, not to linear of task f? How then I can
set to linear (or convert linear to physical?).

PS: If needed, I can make bootable iso image with my setup. Is it needed?

>> an address 001e0800 (into) is not in CS segment of vmlinux executable
>> (no such address in objdump output) So, what is it? Corrupt stack? Or
>> it is not a return address but something different?
>
>It's the thread-ID, so nothing to disassemble :)
>

Yes, I thought of it, but was not sure :)

>> >> >I guess not. Which address? Anyway, I guess it should ioremap those...
>> >> >
>> ....
>> >
>> >Some of those addresses are quite low but unfortunately I don't have an
>> >idea what they're used for.
>> >
>> 
>> The Cardbus controller uses these addresses, according to windows Device manager: 
>> 
>> 0xb8008000-0xb8008fff
>> 0xfebff000-0xfebfffff
>> 0xfabff000-0xfebfefff
>> 0x000db000-0x000dbfff
>> 
>> and modem itself uses none, only i/o and irq
>> 
>> Also, I searched logs and found that piece:
>> 
>> Oct 21 04:54:14 localhost kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
>> Oct 21 04:54:14 localhost kernel: cs: memory probe 0xb8000000-0xb80fffff:  l4x ioremap: Requested region at b8010000 [0x1000 
>> Bytes]
>> Oct 21 04:54:14 localhost kernel: cs: memory probe 0x70000000-0x700fffff: excluding 0x70000000-0x700fffff
>> Oct 21 04:54:14 localhost kernel: cs: warning: no high memory space available!
>> 
>> (This was in the log with info level (there are also error and warning levels)), so, as I understood, this is not fatal.
>> Also here are ioremaps, so, they are present.
>
>Looks like this stuff is doing someting quite special, at least when
>looking at the code that is producing those log lines. I fear it's not
>easily doable to get this going.
>

Hmm... Sad. -- I wanted to experiment with it while the inet access working, but I turns that I can't. But interestingly, 
bluetooth comport is working and GPRS access to internet through it either. So, I could try this through bluetooth and
my phone, if not PCMCIA. Bad but not worst ;) Anyway, I can try pcmcia modem again when TRAP d will be resolved,
a warning with High memory access may be not so important and it will work. Or not?

PS:
I searched L4linux sources for string "no high memory space" and found nothing. Strange. Could you point me
where it is, please?