> On 17 Jul 2004, at 21:21, Ian Pratt wrote:
> > It would be very interesting to hear whether you get the problem
> > with the 2.6.7 xen linux. It might give us a clue as to whether
> > the problem is with the backend blk driver or within the domain
> > itself (the 2.6.7 implementation is completely different).
> I can certainly give the 2.6.7 guest another try. I did have it
> booting, but I didn't persist with it long enough to tell if there was
> fs corruption -- there seemed to be issues loading modules, and when I
> compiled everything in, I got a gpf when racoon tried to use a PF_KEY
> socket. I'll try and get some useful dumps for both these problems.
I haven't tried loading modules, but I can't think why it
wouldn't work (assuming the mechanism is basically the same as
BTW: what's racoon, and what's a PF_KEY socket?
> > I've checked in a fix. It should work fine with LVM and loop
> > devices again.
> All seems well with that fix, with domain 0 using LVs, and exporting
> them to other domains. I'll give the machine some load and see what
Thanks for the confirmation.
> > Nothing obviously wrong here, though could you try the simpler:
> > module /boot/vmlinuz-2.4.26-xen0 root=/dev/sda1 ro console=ttyS0
> > What happens if you run a getty on /dev/ttyS0 ?
> That module line gives the same symptoms. I do have a getty on ttyS0,
> and I see the login banner from it, but can't log in.
There was a bug along these lines, but it's believed fixed. If
you're using the latest repo, that's a concern.
> Actually I do have problems with Linux 2.6.6 on the same system. Once
> the kernel initialises the serial driver, the port settings appear to
> change -- I get the symptoms of incorrect baud rate. When userspace
> starts, it seems to switch back (although I have to reset my terminal).
> The hardware is a Dell 1650, with console redirection on, but
> redirection after boot disabled.
With the default configuration, xen owns the serial uart at all
times, so linux shouldn't be able to mess with the baud rate
> Domain 0 runs debian testing -- would I need to disable the calls to
> setserial in the initscripts, or should they just fail safely?
I'm not sure how setserial works -- presumably it tries to do
ioctls on /dev/ttyS0 rather than trying to inb/outb the uart
directly? The former should just be ignored by the xencons ttyS0
driver and do no harm. If the latter, it's possible that it is
messing things up as the the default configuration is to allow
dom0 any IO privs it asks for.
Disabling them seems safest in the first instance.
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
Xen-devel mailing list