> > 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 kBAh, OK. Thinking about this further, this still doesn''t worry me as the VESA BIOS isn''t using the pci device table to find the card. As dom0 is fully privileged its able to map the memory.> > > 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?I think you''ll need to add a bit of debugging to the relevant functions, or better, use the gdb server to have a poke around.> > 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".Can you login via ssh? What does dmesg show?> > 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?Is that really the bus location of the graphics card? Ian _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 2005-04-19 at 09:29 +0100, Ian Pratt wrote:> > > 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 > > Ah, OK. Thinking about this further, this still doesn''t worry me as the > VESA BIOS isn''t using the pci device table to find the card. As dom0 is > fully privileged its able to map the memory.Fair enough.> > > 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? > > I think you''ll need to add a bit of debugging to the relevant functions, > or better, use the gdb server to have a poke around.I''m afraid I''ve only recently caught up with Xen so I probably can''t help too much with development just yet, and I guess that would belong on xen-devel anyway. Also I haven''t noticed any details regarding gdb server usage anywhere, so I''m not sure about that either.> > > 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". > > Can you login via ssh? What does dmesg show?With my modified kernel new domains crash before init, so SSH never gets a chance. The console output only ever shows the initial boot as far as "Freeing unused kernel memory" before the debug output about the crash. I could include all this in full but wasn''t sure if the attachment would be OK.> > > 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? > > Is that really the bus location of the graphics card?As far as I can tell - X, scanpci & lspci all seem to agree. Cheers, Sean. -- Sean Atkinson <sean@netproject.com> Netproject _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Nice to see more interest in this issue ;-), I''m still trying to look into this as well, but I have so little time to play with it :-(> > Can you login via ssh? What does dmesg show? > > With my modified kernel new domains crash before init, so SSH never gets > a chance. The console output only ever shows the initial boot as far as > "Freeing unused kernel memory" before the debug output about the crash. > I could include all this in full but wasn''t sure if the attachment would > be OK.What settings are you including in your domU kernel config? I had similar problems when I was building with fbcon included, do you have vesafb built-in? And fbcon? I had more luck when I went for a more modular kernel, (matroxfb, and fbcon build as modules, no vesa built-in framebuffer). I am able to boot into dom1, and am able to insert the matroxfb module, thus I can cat data to /dev/fb0, showing that it is accessable. However, as soon as I insmod fbcon, it oopses. The system was still working though, so I was able to track it down, it seems VT subsystem is not properly initialised :-( When I have some time, I''ll be looking into VT initialisation to see where it goes wrong. Anyways, this was all on -unstable, so not sure about 2.0.5 right now. Basically my experiments have shown two problems when trying to start X: 1) X needs a VT to run, and I''ve been unable to get a working dom1 with VT. 2) After patching X to not need a VT, I ran into some IO access problem (not sure about the message anymore, but should be in the devel list archives somewhere, as well as a reference to the patch). It did not seem like a big problem, but I''ve not been able to get past it yet :-( I tried to patch and rebuilt X again, but could not get a stable version anymore... Regards, Mark. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 2005-04-19 at 22:15 +0000, Mark Hurenkamp wrote:> What settings are you including in your domU kernel config? I had similar > problems when I was building with fbcon included, do you have vesafb > built-in? And fbcon?All I deliberately changed from the default xenU config was enabling CONFIG_XEN_PHYSDEV_ACCESS & CONFIG_PCI. This automatically set a bunch of other options to ''y'', including _INPUT, _VT, _VT_CONSOLE, _VGA_CONSOLE & _DUMMY_CONSOLE (as recommended). No VESA/FB configs set.> I had more luck when I went for a more modular kernel, (matroxfb, and fbcon > build as modules, no vesa built-in framebuffer). > > I am able to boot into dom1, and am able to insert the matroxfb module, thus I > can cat data to /dev/fb0, showing that it is accessable. However, as soon as > I insmod fbcon, it oopses. The system was still working though, so I was able > to track it down, it seems VT subsystem is not properly initialised :-( > When I have some time, I''ll be looking into VT initialisation to see where it > goes wrong. > Anyways, this was all on -unstable, so not sure about 2.0.5 right now.I''m afraid I have to move onto other things right now, so I can''t look into these details either I''m afraid.> Basically my experiments have shown two problems when trying to start X: > 1) X needs a VT to run, and I''ve been unable to get a working dom1 with VT. > 2) After patching X to not need a VT, I ran into some IO access problem (not > sure about the message anymore, but should be in the devel list archives > somewhere, as well as a reference to the patch). It did not seem like a big > problem, but I''ve not been able to get past it yet :-( I tried to patch and > rebuilt X again, but could not get a stable version anymore...Your experience seems similar to Gerd Knorr''s, both indicating X is at least partly to blame. I plan to wait until the X fixes are available before testing Xen against them, so we might at least hope that X is behaving before worrying about debugging Xen. In the mean time of course if anybody makes any progress it would be great to hear about it ... Cheers, Sean. -- Sean Atkinson <sean@netproject.com> Netproject _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users