[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-users] RE: [Xen-devel] Run X in other domains?
( Replying to xen-users instead of old sourceforge list. ) On Mon, 2005-04-18 at 17:53 +0100, Ian Pratt wrote: > > Initially I made some progress with the pre-built kernel > > binaries (from the current 2.0.5 release). The xenU kernel > > lacks PCI support, and X reports "Cannot open /dev/tty0" > > using it in domain 1. I switched to the xen0 kernel for PCI > > support, and then X reported "Cannot find a free VT". > > > > The output from lspci lists everything but the VGA card in > > domain 0, unless "lspci -H 1" is used. In other domains, > > lspci reports only the VGA card and "lspci -H 1" reports "You > > need to be root to have access to I/O ports". However X > > still starts OK in domain 0, which surprised my. > > I've confirmed that "xm dmesg" includes "Hiding PCI device > > 01:00.0 from DOM0" after passing "physdev_dom0_hide=01:00.1" to Xen. > > I can see how you could start a very simple VGA-only Xserver -- by > default dom0 happens to have access to the bottom 1MB of memory, which > is enough to get a VGA Xserver working. OK, I wasn't familiar with this. However I've checked XFree86.0.log from domain 0 for memory reports, and these two lines indicate more than 1MB is available, which may be a problem: (II) SIS(0): Using 15808K of framebuffer memory ... (II) SIS(0): VESA VBE Total Mem: 16384 kB > > I've followed Ian's advice, rebuilding Linux 2.6.10 with the > > default xenU configuration eith XEN_PHSDEV_ACCESS added (to > > automatically enable > > DUMMY_CONSOLE) plus PCI support. However my kernel crashes > > immediately after "Freeing unused kernel memory", even when I > > pass "xencons=ttyS". > > Perhaps the build broke somehow, or it's configuration is invalid? > > I think you'll need to look through the oops message to see what's going > on. I've included a relevant section below - I could post the whole output as a gzip attachment if it would help? > You could try setting xencons=off just to rule xencons out. The domain still exits, albeit silently without console output. However I have found that I need the suggested "xencons=ttyS" to avoid an additional line of kernel output "Warning: unable to open an initial console". > I presume you've granted the PCI device to the other domain in it's > config file? I hoped that the line "pci = [ '01,00,00' ]" in my previous post was sufficient? Cheers, Sean. Xen console output section from new domain: Oops: 0000 [#1] PREEMPT Modules linked in: CPU: 0 EIP: 0061:[<c0227a02>] Not tainted VLI EFLAGS: 00010246 (2.6.10xenU-mod) EIP is at visual_init+0x72/0x1c0 eax: 00000000 ebx: c00e6e00 ecx: 00000000 edx: c00e6e00 esi: 00000000 edi: 00000001 ebp: 00000000 esp: c0023e94 ds: 007b es: 007b ss: 0069 Process init (pid: 1, threadinfo=c0022000 task=c03b69e0) Stack: 00000000 000000d0 c00e6e00 00000000 c0227bf1 00000000 00000001 00000000 c00c9bc0 00000000 00000000 c1365000 00400000 c022b1e8 00000000 ffffffed c00dab80 00000001 c021aa6d c1365000 c00dab80 c0023ef0 00000102 c1365000 Call Trace: [<c0227bf1>] vc_allocate+0xa1/0x1b0 [<c022b1e8>] con_open+0x48/0xc0 [<c021aa6d>] tty_open+0x24d/0x2d0 [<c021a820>] tty_open+0x0/0x2d0 [<c015e96a>] chrdev_open+0xea/0x1d0 [<c0343324>] free_area_init_core+0xb4/0x300 [<c0343324>] free_area_init_core+0xb4/0x300 [<c015486a>] dentry_open+0x15a/0x240 [<c0343324>] free_area_init_core+0xb4/0x300 [<c0154708>] filp_open+0x68/0x70 [<c0154989>] get_unused_fd+0x39/0xe0 [<c0154af9>] sys_open+0x49/0x90 [<c0109658>] syscall_call+0x7/0xb Code: 40 6d 36 c0 a1 2c 6d 36 c0 89 42 28 8b 14 b5 80 7e 36 c0 85 d2 74 0a 8b 04 b5 40 6d 36 c0 89 50 28 8b 14 b5 40 6d 36 c0 8b 42 28 <8b> 18 85 db 74 35 89 1c 24 e8 80 8c f0 ff 85 c0 0f 84 09 01 00 <0>Kernel panic - not syncing: Attempted to kill init! <0>Rebooting in 1 seconds.. -- Sean Atkinson <sean@xxxxxxxxxxxxxx> Netproject _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |