Could you try and obtain a stack trace of the locked up guest with e.g.:

  $> /usr/lib/xen/bin/xenctx -s System.map.2.6.25... <domain-id>

Also, was there anything on the guest's xen console when it locked up?

hi,

> Could you try and obtain a stack trace of the locked up guest with e.g.:
> 
>   $> /usr/lib/xen/bin/xenctx -s System.map.2.6.25... <domain-id>

given,

xm list
	Name                     ID   Mem VCPUs      State   Time(s)
	Domain-0                  0   512     2     r-----    124.3
	f9test                    7   512     1     -b----      8.4

 /usr/lib64/xen/bin/xenctx -s /boot/System.map-2.6.21.7-3.fc8xen 7
	rip: ffffffff806170ca 
	rsp: ffffffff805c9f40
	rax: 00000000	rbx: ffffffff8020c2b8	rcx: ffffffff806170ca	rdx: ffffffff806170ca
	rsi: 00000000	rdi: 00000001	rbp: ffffffff805c9f58
	 r8: 00000000	 r9: ffffffff	r10: 0000000c	r11: 00000246
	r12: ffffffff80210011	r13: ffffffffffffffff	r14: ffffffff805f6b60	r15: 00000000
	 cs: 0000e033	 ds: 00000000	 fs: 00000000	 gs: 00000000

> Also, was there anything on the guest's xen console when it locked up?

nope.  the moment i try to, e.g., save to file, it simply locks up, without any
additional 'peep'

Hi. We need some additional information to reproduce and investigate the problem:

> attempts to ssh to DomU are simply refused.

Is this before or after domU being destroyed and restarted?


> attempts to connect @ Dom0 'xm console ...' return only,
> 
> 	PCI: Fatal: No config space access function found
> 	i8042.c: No controller found.
> 	IO APIC resources could be not be allocated.
> 
> and the console freezes, requiring an 'xm destroy'.

Is this after the domain restart?

Before the problem is reproduced, do you get a working login prompt on 'xm console'?

Are you editing the file through ssh or on 'xm console'?

What editor are you using? (some editors may not work properly under 'xm console')

Could you confirm if you get exactly the same behaviour when other files are
edited instead of ifcfg-eth0? This way we can exclude the possibility of
networking scripts  dropping the network after this file is edited, making the
guest unreachable through ssh.

Writing to the disk without using a text editor also makes the bug reproducible?
Example: when typing commands such as:

 echo some text > /tmp/somefile
 cat /etc/fedora-release > /tmp/otherfile

hi,

> > attempts to ssh to DomU are simply refused.
> 
> Is this before or after domU being destroyed and restarted?

after.  the *first* attempt to ssh to the DomU after a fresh kickstart'd install
works ok.

> > attempts to connect @ Dom0 'xm console ...' return only,
> > 
> > 	PCI: Fatal: No config space access function found
> > 	i8042.c: No controller found.
> > 	IO APIC resources could be not be allocated.
> > 
> > and the console freezes, requiring an 'xm destroy'.
> 
> Is this after the domain restart?

yes.  after the aforementioned required 'xm destroy ...', and the next
re-attempt @ 'xm create ...'

> Before the problem is reproduced, do you get a working login prompt on 'xm
console'?

haven't tried that ... i've found 'xm console' to be finicky, and most always
use ssh.

> Are you editing the file through ssh or on 'xm console'?

through ssh.

> What editor are you using? (some editors may not work properly under 'xm console')

in this case, 'joe'.

but, ANY write, to ANY directory -- using any other editor, a "cat >>" or "echo
>>" to a file, even a 'touch ...' causes the freezes

> Could you confirm if you get exactly the same behaviour when other files are
> edited instead of ifcfg-eth0?

yes. any other file causes the problem ...

> This way we can exclude the possibility of
> networking scripts  dropping the network after this file is edited, making the
> guest unreachable through ssh.

understood. see above.

> Writing to the disk without using a text editor also makes the bug reproducible?

yes. see above.

(Follow-up to comment #3)
> We need some additional information to reproduce and investigate the problem:

just checking ... any add'l info i can provide?

(In reply to comment #4)
>> Could you confirm if you get exactly the same behaviour when other files are
>> edited instead of ifcfg-eth0?
>
> yes. any other file causes the problem ...

well, something's apparently changed on my end ...

i've built up two new Dom0 (still F8) boxes, and installed Rawhide DomU, as
above, from both 9-May & 10-May date-stamped repos.

whereas the original instance(s) i'd reported abt still lock up on ANY write to
disk (just verified that again), the 'new' ones only lock up on write to 

    /etc/sysconfig/network-scripts/ifcfg-eth0

by any write method: text editor, echo >, cat >, etc.

writing to other files, now, is not apparently a problem.

i can't tell with any certainty what, if anything, is different about my Dom0s
-- they're built up using the exact same 'procedure notes'.

again, the F9 source repos are a day or so newer, and i've tried different
development repo sources (the 'new' ones are from fedora.secsup.org).

in the newly-installed, as yet not locked-up, DomU, on "open" (not write) of 

	/etc/sysconfig/network-scripts/ifcfg-eth0 

@ serial console, tail of /var/log/messages shows, simply,

	May 11 10:49:56 d3test nm-system-settings:    ifcfg-fedora: parsing
/etc/sysconfig/network-scripts/ifcfg-eth0 ... 
	May 11 10:49:56 d3test nm-system-settings:    ifcfg-fedora:     read connection
'System eth0'

on save to disk of any edit of that file, the sys just locks up, with no further
log entries.

updating to F9 release, problem continues.

NetworkManager is apparently 'involved' in the problem.  and, i note it's now ON
by default in F9.

doing,

  chkconfig NetworkManager off
  chkconfig network        on
  reboot

removes the lock-up problem of the 'newer' installs above, and allows me to edit
the .../ifcfg-eth0 as req'd.

still fails to work to fix the 'older' install.  i'm just going to ignore/delete
that one.

as for what NM *should* be doing on startup -- I simply don't know.  as such, I
can't say whether the "chkconfig ..." service swap is a _fix_ or a _workaround_.

i'll leave that to someone else here to determine.  for the moment, i'm back to
ok ...

Quite odd; is it a hardlock and not a panic?  NM pokes various network related
ioctls (including wireless ones) but I'd certainly hope the kernel would handle
that.  Try something for me:

stop NM
turn off the 'network' service
after booting up:

/usr/sbin/NetworkManager --no-daemon

and see where it hangs Xen.  What's the last line in the output?

(In reply to comment #9)
> Quite odd; is it a hardlock and not a panic?  

i'm not clear on your semantics, but, iiuc, it's a 'hardlock' ... everything
just appears to stop.

> Try something for me:
> 
> stop NM

starting with a 'fresh' F9-RELEASE install (dd'd lvm ...),

  xm create d3test.cfg
    Using config file "/etc/xen/d3test.cfg".
    Started domain d3test

checking,

  xm list | grep d3test
    d3test     6   512     1     -b----     10.5

i'm unable to connect @ console,

 xm console 5
  PCI: Fatal: No config space access function found
  i8042.c: No controller found.
  IO APIC resources could be not be allocated.

and it just sits there ...

so, destroy/create, then

  ssh 10.0.1.33
  ...
  [root@d3test ~]# 

  service NetworkManager status
    NetworkManager (pid 1205) is running...
  service NetworkManager stop
    Stopping NetworkManager daemon: 

and the system locks up and is non-responsive; i get no further ...  :-/

> turn off the 'network' service
> after booting up:
> 
> /usr/sbin/NetworkManager --no-daemon
> and see where it hangs Xen.  What's the last line in the output?

so, given the above, not sure if this is helpful,

  service NetworkManager status
    NetworkManager (pid 1247) is running...
  [root@d3test ~]# service network status
    Configured devices:
    lo eth0
    Currently active devices:
    lo eth0

  /usr/sbin/NetworkManager --no-daemon
    NetworkManager: <info>  starting...
    NetworkManager: <WARN>  nm_dbus_manager_start_service(): Could not acquire
the NetworkManager service as it is already taken.
    NetworkManager: <info>  disconnected by the system bus.
    NetworkManager: dbus_g_connection_register_g_object: assertion `connection
!= NULL' failed
    NetworkManager: <WARN>  main(): Failed to start the dbus manager.


next try,

  chkconfig NetworkManager off
  chkconfig network        on
  reboot
  ...
  ssh 10.0.1.33
  ...
  [root@d3test ~]# 

  service NetworkManager status
    NetworkManager is stopped
  service network status
    Configured devices:
    lo eth0
    Currently active devices:
    lo eth0

  /usr/sbin/NetworkManager --no-daemon
    NetworkManager: <info>  starting...
    RTNETLINK answers: File exists
    NetworkManager: <info>  eth0: Device is fully-supported using driver 'vif'.
    NetworkManager: <info>  Found new Ethernet device 'eth0'.
    NetworkManager: <info>  (eth0): exported as
/org/freedesktop/Hal/devices/net_00_16_3e_00_01_33
    NetworkManager: <info>  Trying to start the supplicant...
    NetworkManager: <info>  Trying to start the system settings daemon...
    NetworkManager: <info>  (eth0): device state change: 1 -> 2
    NetworkManager: <info>  (eth0): preparing device.
    NetworkManager: <info>  (eth0): deactivating device.

at which point it locks up, as before.

dunno if that's what you're looking for.

the 'workaround' is also readily (no surprise) implemented @ kickstart-install
adding to the ks.cfg,

   services --disabled NetworkManager(,...) --enabled network(,...)

after which, @ 1st reboot, all's ok.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.