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