Problems with l4linux
adam at os.inf.tu-dresden.de
Mon Oct 27 01:06:43 CET 2008
On Thu Oct 23, 2008 at 21:54:08 +1300, Valery V. Sedletski wrote:
> On Wed, 22 Oct 2008 19:12:59 +0200, Adam Lackorzynski wrote:
> >Ok. There's an option in the Fiasco configuration to let you set IOPL3
> >(and thus lets you do cli/sti). This is an extra option because if you
> >enable it Linux can stop the machine. Anyway, that sould fix the X
> Now I switched on Fiasco option about IOPL 3 and an error with cli disappeared,
> but another problem -- GPF somewhere in Fiasco. The serial log is like this:
> loader | vmlinuz26: Starting application using libld-l4.s.so
> loader | [36mvmlinuz26,#f: Loading binary[m
> rtc | Date:23.10.2008 Time:08:17:15
> loader | vmlinuz26,#f: Loading ldso
> loader | vmlinuz26,#f: Starting libld-l4.s.so at 000138e0 via 0000cbe8
> l4lx | [34;1m======> L4Linux 2.6 starting... <========[0m
> l4lx | Linux version 2.6.26-l4-svn120-dirty2 (root at localhost) (gcc version 4
> l4lx : .2.2 20071128 (prerelease) (4.2.2-3mdv2008.0)) #7 Thu Oct 23 21:07:12
> l4lx : PETST 2008
> l4lx | Binary name: vmlinuz26
> l4lx | Linux kernel command line (8 args): mem=100M video=l4fb:refreshsleep:
> l4lx : 200 l4fb.nograb=1 load_ramdisk=1 ramdisk_size=40960 root=/dev/ram l4e
> l4lx : nv_rd=(nd)/tftpboot/drops/ramdisk/drops-fp.rd panicblink=0
> l4lx | Image: 00400000 - 007b9000 [3812 KiB].
> l4lx | Areas: Text: 00400000 - 006c3000 [2828kB] (a bit longer)
> l4lx | Data: 006c3000 - 006e46d8 [133kB]
> l4lx | Initdata: 006e8000 - 00726000 [248kB]
> l4lx | BSS: 00728000 - 007b8bb0 [578kB]
> l4lx | l4lx_thread_create: Created thread 0f.03 (tamer0)
> l4lx | Tamer0 is 0f.03
> l4lx | Using tamed mode.
> ROOT: Sending all ports (for cli/sti) to task #0d
> l4lx | Got 65536 out of 65536 I/O ports
> l4lx | Running at IOPL 3
> l4lx | Connecting to l4io server.
> l4lx | l4lx_thread_create: Created thread 0f.04 (cpu0)
> l4lx | main thread will be 0f.04
> l4lx | l4env_register_pointer_section: addr = 006e6000 size = 266240
> l4lx | sec-w-init: virt: 0x006e6000 to 0x00726fff [260 KiB]
> l4lx | sec-w-init: Number of physical regions: 1, 266240 Bytes
> l4lx | sec-w-init: 1: Phys: 0x012a0000 to 0x012e1000, Size: 266240
> l4lx | l4env_linux_startup thread 4.
> l4lx | main thread: received startup message.
> l4lx | Main thread running, waiting...
> l4lx | setup_l4env_memory: Forcing superpages for main memory
> l4lx | Main memory size: 100MB
> l4lx | Main memory: virt: 0x00800000 to 0x06bfffff [102400 KiB]
> l4lx | Main memory: Number of physical regions: 1, 104857600 Bytes
> l4lx | Main memory: 1: Phys: 0x06400000 to 0x0c800000, Size: 104857600
> l4lx | Filling lower ptabs...
> l4lx | mainmem = 800000
> l4lx | Done (1060 entries).
> l4lx | l4env_register_pointer_section: addr = 00728000 size = 593920
> l4lx | end: virt: 0x00728000 to 0x007b8fff [580 KiB]
> l4lx | end: Number of physical regions: 1, 593920 Bytes
> l4lx | end: 1: Phys: 0x006f2000 to 0x00783000, Size: 593920
> l4lx | l4env_rd_path: (nd)/tftpboot/drops/ramdisk/drops-fp.rd
> l4lx | Loading: (nd)/tftpboot/drops/ramdisk/drops-fp.rd
> l4lx | INITRD: Size of RAMdisk is 40960KiB
> l4lx | RAMdisk from 10000000 to 12800000 [40960KiB]
> l4lx | l4lx_thread_create: Created thread 0f.05 (timer.i0)
> [32m ---------------------------------------------------------IP: f003622b[m
> [32m--[mGeneral Protection
> [25;1H[32m[l4lx.main] (f.02) jdb: [m[K
> So, this is iret instruction somewhere on return from a syscall, if I understood correctly.
> Maybe, my Fiasco config is wrong?
Rather not. Can you tell me at which position the f.2 is in user-land?
That would be interesting.
> >(My X version also tries to get ports 0-1024 (or similar)
> >before doing the iopl thing but AFAIK this has only been added shortly.)
> -- so, in normal situation, it should not be (requesting access to some ports before doing iopl(3)),
> but if it takes the place, then for it to work, the Fiasco option mentioned must be enabled. But in
> normal situation, this option is not needed?
X is very demanding wrt permissions. More recent version should behave
> And the question: what does cli instruction do? I guess this must trigger an I/O page fault for I/O
> pages to be mapped? Am I right?
CLI disables interrupts. Allowing this in user-land is a major security
> >> >> PS: When I did "modprobe serial_cs" udev created ttyS0..ttyS3 devices but still no comm port access. So, access to video
> >> >> and comm-ports don't work but network and disks are working. Why could it be?
> >> >
> >> >Sorry, no idea with the card. It doesn't say anything strange in dmesg?
> >> >
> >> Only that serial_cs module prints the message that it could not access
> >> high memory. I hope this error disappear after linux will get I/O
> >> privileges
> >I guess not. Which address? Anyway, I guess it should ioremap those...
> According to scanpci, Cardbus controller and serial (modem) card use these addresses:
> pci bus 0x0006 cardnum 0x09 function 0x00: vendor 0x104c device 0x8031
> Texas Instruments PCIxx21/x515 Cardbus Controller
> STATUS 0x0210 COMMAND 0x0007
> CLASS 0x06 0x07 0x00 REVISION 0x00
> BIST 0x00 HEADER 0x82 LATENCY 0xa8 CACHE 0x08
> BASE0 0xb8008000 addr 0xb8008000 MEM
> BASE1 0x020000a0 addr 0x020000a0 MEM
> BASE2 0xb00a0706 addr 0xb00a0700 MEM
> BASE3 0x88000000 addr 0x88000000 MEM
> BASE4 0x8bfff000 addr 0x8bfff000 MEM
> BASE5 0x90000000 addr 0x90000000 MEM
> BASEROM 0x000044fc addr 0x00000000 not-decode-enabled
> MAX_LAT 0x05 MIN_GNT 0xc0 INT_PIN 0x01 INT_LINE 0x0a
> BYTE_0 0xc0 BYTE_1 0x17 BYTE_2 0x07 BYTE_3 0x30
> according to /proc/iomem:
> 88000000-8bffffff : PCI CardBus #07
> 90000000-93ffffff : PCI CardBus #07
> b8008000-b8008fff : yenta_socket
> b8010000-b8010fff : pcmcia_socket0
> And also it uses these I/O ports (according /proc/ioport):
> 03f8-0407 : pcmcia_socket0
> 03f8-03ff : serial
> 0400-0407 : serial
> 4400-44ff : PCI CardBus #07
> 4800-48ff : PCI CardBus #07
> 0x3f8-0x3ff is /dev/ttyS0
> 0x400-0x407 is /dev/ttyS1
Some of those addresses are quite low but unfortunately I don't have an
idea what they're used for.
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers