Problems with l4linux

[Adam Lackorzynski]

On Wed Oct 29, 2008 at 16:25:49 +1300, Valery V. Sedletski wrote:
> 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?).

Breakpoint addresses are virtual.

Anyway, I found the reason. L4Linux had so much privileges that it was
able able to write MSRs which allowed it to setup the Sysenter-MSRs.
Normally this is trapped and handled. The kernel allows writing MSRs for
special purpose stuff, this was triggered here. The wrmsr's are in
enable_sep_cpu in arch/x86/vdso/vdso32-setup.c, if you comment them out
it should work.
 
> >> >> >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?

I would guess not.

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

It's in drivers/pcmcia/rsrc_nonstatic.c:434



Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/