Hello list,
I''ve been receiving these bug traces in my kernel logs since
switching from Debian''s kernel/xen packages to compiling my own
kernel/xen. They don''t seem to cause any visible trouble so I
didn''t
bother to report them before, but I thought I''d report them today. The
bug traces do not occur when using Debian packages.
[ 1423.038710] Pid: 31, comm: xenwatch Not tainted
3.0.0-rc4-custom-xen-amd64+ #1
[ 1423.038713] Call Trace:
[ 1423.038718] [<ffffffff8131bd1d>] ? __schedule_bug+0x3e/0x52
[ 1423.038722] [<ffffffff8132153a>] ? schedule+0x90/0x64e
[ 1423.038727] [<ffffffff81006b4d>] ? xen_force_evtchn_callback+0x9/0xa
[ 1423.038732] [<ffffffff810071b2>] ? check_events+0x12/0x20
[ 1423.038737] [<ffffffff811fcfd5>] ? read_reply+0xa4/0x123
[ 1423.038742] [<ffffffff8106060f>] ? add_wait_queue+0x3c/0x3c
[ 1423.038747] [<ffffffff811fd0f9>] ? xs_talkv+0xa5/0x167
[ 1423.038752] [<ffffffff811fd61a>] ? xenbus_write+0x73/0x94
[ 1423.038756] [<ffffffff811fd6d6>] ? xenbus_printf+0x9b/0xbf
[ 1423.038761] [<ffffffff811b8927>] ? xen_pcibk_publish_pci_dev+0xa2/0xa2
[ 1423.038766] [<ffffffff811b8a4a>] ?
xen_pcibk_publish_pci_root+0x123/0x180
[ 1423.038771] [<ffffffff810e5f99>] ? virt_to_head_page+0x6/0x29
[ 1423.038775] [<ffffffff811fd6e2>] ? xenbus_printf+0xa7/0xbf
[ 1423.038780] [<ffffffff811ba648>] ?
xen_pcibk_publish_pci_roots+0x7f/0xab
[ 1423.038785] [<ffffffff811b8d56>] ? xen_pcibk_setup_backend+0x1e4/0x252
[ 1423.038791] [<ffffffff811b9258>] ? xen_pcibk_xenbus_probe+0xde/0xfe
[ 1423.038795] [<ffffffff811fe2ce>] ? xenbus_dev_probe+0x6f/0xf6
[ 1423.038800] [<ffffffff81230589>] ? driver_probe_device+0xa8/0x138
[ 1423.038805] [<ffffffff81230688>] ? __driver_attach+0x6f/0x6f
[ 1423.038810] [<ffffffff8122f617>] ? bus_for_each_drv+0x47/0x7b
[ 1423.038814] [<ffffffff812304aa>] ? device_attach+0x6f/0x8f
[ 1423.038818] [<ffffffff8122fddb>] ? bus_probe_device+0x1f/0x37
[ 1423.038823] [<ffffffff8122e771>] ? device_add+0x3e7/0x587
[ 1423.038828] [<ffffffff8103f759>] ? get_parent_ip+0x9/0x1b
[ 1423.038832] [<ffffffff812371b9>] ? pm_runtime_init+0xb5/0xc9
[ 1423.038837] [<ffffffff811fe5f8>] ? xenbus_probe_node+0x137/0x1d5
[ 1423.038842] [<ffffffff811fe81e>] ? xenbus_dev_changed+0x157/0x189
[ 1423.038847] [<ffffffff8103f759>] ? get_parent_ip+0x9/0x1b
[ 1423.038852] [<ffffffff811fcf00>] ? xenwatch_thread+0xf5/0x126
[ 1423.038856] [<ffffffff8106060f>] ? add_wait_queue+0x3c/0x3c
[ 1423.038861] [<ffffffff811fce0b>] ? xenbus_thread+0x211/0x211
[ 1423.038865] [<ffffffff8105ff6e>] ? kthread+0x76/0x7e
[ 1423.038869] [<ffffffff813295a4>] ? kernel_thread_helper+0x4/0x10
[ 1423.038874] [<ffffffff813286b3>] ? int_ret_from_sys_call+0x7/0x1b
[ 1423.038879] [<ffffffff813233e5>] ? retint_restore_args+0x5/0x6
[ 1423.038883] [<ffffffff813295a0>] ? gs_change+0x13/0x13
[ 1423.039097] BUG: scheduling while atomic: xenwatch/31/0x00000002
[ 1423.039147] Modules linked in: tun xt_physdev iptable_filter
ip_tables x_tables parport_pc ppdev lp parport bluetooth rfkill
cpufreq_userspace cpufreq_pow
ersave cpufreq_stats cpufreq_conservative mperf binfmt_misc fuse nfsd
exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge stp ext3
jbd loop firewire
_sbp2 firewire_core crc_itu_t cxgb3 mdio i2c_i801 i2c_core mxm_wmi
psmouse evdev pcspkr serio_raw thermal_sys wmi button acpi_processor
ext4 mbcache jbd2 crc
16 dm_mod sg sd_mod sr_mod crc_t10dif cdrom ahci libahci mvsas libsas
sky2 libata scsi_transport_sas scsi_mod [last unloaded:
scsi_wait_scan]
Haven''t really checked and confirmed, but they seem to occur on
starting and stopping VMs.
Xen:
# hg log|head
changeset: 23632:33717472f37e
tag: tip
user: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
date: Tue Jun 28 18:15:44 2011 +0100
summary: libxc: Squash xc_e820.h (and delete) into xenctrl.h
Kernel:
# git log|head
commit 3dc33d5af47bd3e216f71f47f1f4c7ea4578cca4
Merge: bd687c5 bccaeaf
Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date: Thu Jun 23 17:10:21 2011 -0700
Liwei
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jul-12 13:50 UTC
Re: [Xen-devel] BUG: scheduling while atomic: xenwatch
On Wed, Jun 29, 2011 at 09:24:20PM +0800, Liwei wrote:> Hello list, > I''ve been receiving these bug traces in my kernel logs since > switching from Debian''s kernel/xen packages to compiling my own > kernel/xen. They don''t seem to cause any visible trouble so I didn''t > bother to report them before, but I thought I''d report them today. The > bug traces do not occur when using Debian packages.Thanks for reporting it. I''ve a patch for it ready. What tree did you pull from?> > [ 1423.038710] Pid: 31, comm: xenwatch Not tainted > 3.0.0-rc4-custom-xen-amd64+ #1 > [ 1423.038713] Call Trace: > [ 1423.038718] [<ffffffff8131bd1d>] ? __schedule_bug+0x3e/0x52 > [ 1423.038722] [<ffffffff8132153a>] ? schedule+0x90/0x64e > [ 1423.038727] [<ffffffff81006b4d>] ? xen_force_evtchn_callback+0x9/0xa > [ 1423.038732] [<ffffffff810071b2>] ? check_events+0x12/0x20 > [ 1423.038737] [<ffffffff811fcfd5>] ? read_reply+0xa4/0x123 > [ 1423.038742] [<ffffffff8106060f>] ? add_wait_queue+0x3c/0x3c > [ 1423.038747] [<ffffffff811fd0f9>] ? xs_talkv+0xa5/0x167 > [ 1423.038752] [<ffffffff811fd61a>] ? xenbus_write+0x73/0x94 > [ 1423.038756] [<ffffffff811fd6d6>] ? xenbus_printf+0x9b/0xbf > [ 1423.038761] [<ffffffff811b8927>] ? xen_pcibk_publish_pci_dev+0xa2/0xa2 > [ 1423.038766] [<ffffffff811b8a4a>] ? xen_pcibk_publish_pci_root+0x123/0x180 > [ 1423.038771] [<ffffffff810e5f99>] ? virt_to_head_page+0x6/0x29 > [ 1423.038775] [<ffffffff811fd6e2>] ? xenbus_printf+0xa7/0xbf > [ 1423.038780] [<ffffffff811ba648>] ? xen_pcibk_publish_pci_roots+0x7f/0xab > [ 1423.038785] [<ffffffff811b8d56>] ? xen_pcibk_setup_backend+0x1e4/0x252 > [ 1423.038791] [<ffffffff811b9258>] ? xen_pcibk_xenbus_probe+0xde/0xfe > [ 1423.038795] [<ffffffff811fe2ce>] ? xenbus_dev_probe+0x6f/0xf6 > [ 1423.038800] [<ffffffff81230589>] ? driver_probe_device+0xa8/0x138 > [ 1423.038805] [<ffffffff81230688>] ? __driver_attach+0x6f/0x6f > [ 1423.038810] [<ffffffff8122f617>] ? bus_for_each_drv+0x47/0x7b > [ 1423.038814] [<ffffffff812304aa>] ? device_attach+0x6f/0x8f > [ 1423.038818] [<ffffffff8122fddb>] ? bus_probe_device+0x1f/0x37 > [ 1423.038823] [<ffffffff8122e771>] ? device_add+0x3e7/0x587 > [ 1423.038828] [<ffffffff8103f759>] ? get_parent_ip+0x9/0x1b > [ 1423.038832] [<ffffffff812371b9>] ? pm_runtime_init+0xb5/0xc9 > [ 1423.038837] [<ffffffff811fe5f8>] ? xenbus_probe_node+0x137/0x1d5 > [ 1423.038842] [<ffffffff811fe81e>] ? xenbus_dev_changed+0x157/0x189 > [ 1423.038847] [<ffffffff8103f759>] ? get_parent_ip+0x9/0x1b > [ 1423.038852] [<ffffffff811fcf00>] ? xenwatch_thread+0xf5/0x126 > [ 1423.038856] [<ffffffff8106060f>] ? add_wait_queue+0x3c/0x3c > [ 1423.038861] [<ffffffff811fce0b>] ? xenbus_thread+0x211/0x211 > [ 1423.038865] [<ffffffff8105ff6e>] ? kthread+0x76/0x7e > [ 1423.038869] [<ffffffff813295a4>] ? kernel_thread_helper+0x4/0x10 > [ 1423.038874] [<ffffffff813286b3>] ? int_ret_from_sys_call+0x7/0x1b > [ 1423.038879] [<ffffffff813233e5>] ? retint_restore_args+0x5/0x6 > [ 1423.038883] [<ffffffff813295a0>] ? gs_change+0x13/0x13 > [ 1423.039097] BUG: scheduling while atomic: xenwatch/31/0x00000002 > [ 1423.039147] Modules linked in: tun xt_physdev iptable_filter > ip_tables x_tables parport_pc ppdev lp parport bluetooth rfkill > cpufreq_userspace cpufreq_pow > ersave cpufreq_stats cpufreq_conservative mperf binfmt_misc fuse nfsd > exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge stp ext3 > jbd loop firewire > _sbp2 firewire_core crc_itu_t cxgb3 mdio i2c_i801 i2c_core mxm_wmi > psmouse evdev pcspkr serio_raw thermal_sys wmi button acpi_processor > ext4 mbcache jbd2 crc > 16 dm_mod sg sd_mod sr_mod crc_t10dif cdrom ahci libahci mvsas libsas > sky2 libata scsi_transport_sas scsi_mod [last unloaded: > scsi_wait_scan] > > Haven''t really checked and confirmed, but they seem to occur on > starting and stopping VMs. > Xen: > # hg log|head > changeset: 23632:33717472f37e > tag: tip > user: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > date: Tue Jun 28 18:15:44 2011 +0100 > summary: libxc: Squash xc_e820.h (and delete) into xenctrl.h > > Kernel: > # git log|head > commit 3dc33d5af47bd3e216f71f47f1f4c7ea4578cca4 > Merge: bd687c5 bccaeaf > Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > Date: Thu Jun 23 17:10:21 2011 -0700 > > Liwei > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12 July 2011 21:50, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> > Thanks for reporting it. I''ve a patch for it ready.Hmm, where? In the latest pull?> > What tree did you pull from?# git branch xen/next-2.6.32 * xen/next-3.0 # cat .git/config ----snip---- [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git ----snip---- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jul-12 19:04 UTC
Re: [Xen-devel] BUG: scheduling while atomic: xenwatch
On Wed, Jul 13, 2011 at 02:57:43AM +0800, Liwei wrote:> On 12 July 2011 21:50, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > Thanks for reporting it. I''ve a patch for it ready. > > Hmm, where? In the latest pull?git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/xen-pciback-0.6.2 Look for patch commit 52ff6d79b45e68fadad3a93a937171863a7cf451 Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Mon Jul 11 13:18:09 2011 -0400 xen/pciback: Reshuffle the spinlock to not trigger BUG: scheduling while atomic.> > > > > What tree did you pull from? > > # git branch > xen/next-2.6.32 > * xen/next-3.0OK, so Jeremy''s. Do a cherrypick on that and you should be set.> > # cat .git/config > ----snip---- > [remote "origin"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > ----snip----_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 July 2011 03:04, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/xen-pciback-0.6.2 > > Look for patch > commit 52ff6d79b45e68fadad3a93a937171863a7cf451 > Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Date: Mon Jul 11 13:18:09 2011 -0400 > > xen/pciback: Reshuffle the spinlock to not trigger BUG: scheduling while atomic. >Ah, I see it.> > OK, so Jeremy''s. Do a cherrypick on that and you should be set.Actually, I''d like to ask what''s the difference between Jeremy''s and your tree? Usually I''d choose whichever has the latest commits since there are still a few quirks that I hope would be ironed out in the recent patches. Your "testing" branch seems to be the newest and contains the most number of patches at the moment. Can I try running on that? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jul-12 19:54 UTC
Re: [Xen-devel] BUG: scheduling while atomic: xenwatch
On Wed, Jul 13, 2011 at 03:29:53AM +0800, Liwei wrote:> On 13 July 2011 03:04, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/xen-pciback-0.6.2 > > > > Look for patch > > commit 52ff6d79b45e68fadad3a93a937171863a7cf451 > > Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > Date: Mon Jul 11 13:18:09 2011 -0400 > > > > xen/pciback: Reshuffle the spinlock to not trigger BUG: scheduling while atomic. > > > > Ah, I see it. > > > > > OK, so Jeremy''s. Do a cherrypick on that and you should be set. > > Actually, I''d like to ask what''s the difference between Jeremy''s and > your tree? Usually I''d choose whichever has the latest commits sinceRight now I think base wise we are the same. However we have two different patchqueues - Jeremy has some paravirt spinlock code and tracing code. I''ve some cleanups and new drivers. I am going to stick his patches in when he reposts them.> there are still a few quirks that I hope would be ironed out in the > recent patches. > > Your "testing" branch seems to be the newest and contains the most > number of patches at the moment. Can I try running on that?Of course. The #testing is what I am going to stick in #linux-next once they go through some testing. It also has some extra patches that are not yet ready for 3.1 but need testing. The #linux-next is what is queued up for 3.1 and it also has bugfixes for 3.0. The #master is .. oh, I should refresh it. It should have #linux-next + some patches for 3.2. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 July 2011 03:54, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> > Right now I think base wise we are the same. However we have two > different patchqueues - Jeremy has some paravirt spinlock code and > tracing code. I''ve some cleanups and new drivers. > > I am going to stick his patches in when he reposts them. >OK> > Of course. The #testing is what I am going to stick in #linux-next once > they go through some testing. It also has some extra patches that > are not yet ready for 3.1 but need testing. > > The #linux-next is what is queued up for 3.1 and it also has > bugfixes for 3.0. > > The #master is .. oh, I should refresh it. It should have #linux-next > + some patches for 3.2. > >Yeah, I''m kind of confused with regards to which branch is which. That clears it up! Just to let you know, with your latest testing branch, the xenwatch scheduling bug is effectively gone, so I guess the patch worked. =) There are still some weird quirks around: 1. HVM Windows 7 with PCI passthrough refuses to shutdown, somehow qemu treats it as a domain reboot. If I do a xl destroy, the whole system reboots (not sure how I can find out what happens though since my mainboard does not have a hardware serial port. Can xen log to a file?) 2. With 16G of memory and Dom0 memory set to 1G, trying to start the above 8G Windows 7 HVM while any other VM is running (I tried it with one VM using 1G) causes some bug trace to occur (haven''t had the chance to copy that one down) and qemu starts but does nothing. Doing xl destroy will cause 1. to occur. 3. On high (full) CPU and disk utilisation, the whole system will sometimes reboot. 4. Somehow with this new kernel/xen combination, my pfSense domain does not receive DHCP requests sent from other domains, requests from other computers in the network outside of xen are received though. Non broadcast traffic works though. 5. The network performance of this kernel/xen combination compared to before is almost half. 6. The WAN bridge to my pfSense appliance goes down (pings suddenly stop) after a while. Rebooting the pfSense domain restores it for a while. Removing and re-adding the domain''s tap interface to/from the bridge solves it permanently for the domain session. This has always been a problem, not sure where the bug is originating from though since different versions and combinations of Debian/kernel/xen/pfSense has never solved it. And no indication of the problem occurring except all WAN traffic stops. I''m just listing it here in case someone has any idea about what''s happening in each case. I''ll do a proper bug report for each case when I''ve collected enough information (not even sure if 1, 2 and 3 could be my hardware problem; 4 and 6 could be pfSense or Debian''s fault as well). Thanks for the great work so far! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jul-14 17:46 UTC
Re: [Xen-devel] BUG: scheduling while atomic: xenwatch
On Thu, Jul 14, 2011 at 11:44:11PM +0800, Liwei wrote:> On 13 July 2011 03:54, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > Right now I think base wise we are the same. However we have two > > different patchqueues - Jeremy has some paravirt spinlock code and > > tracing code. I''ve some cleanups and new drivers. > > > > I am going to stick his patches in when he reposts them. > > > > OK > > > > > Of course. The #testing is what I am going to stick in #linux-next once > > they go through some testing. It also has some extra patches that > > are not yet ready for 3.1 but need testing. > > > > The #linux-next is what is queued up for 3.1 and it also has > > bugfixes for 3.0. > > > > The #master is .. oh, I should refresh it. It should have #linux-next > > + some patches for 3.2. > > > > > > Yeah, I''m kind of confused with regards to which branch is which. That > clears it up! > > > Just to let you know, with your latest testing branch, the xenwatch > scheduling bug is effectively gone, so I guess the patch worked. =)For the bugs you outlined, you might want to try 4.1.1 just to double-check. I''ve had some strange issues with Xen-Unstable that I hadn''t tracked down.> > > There are still some weird quirks around: > 1. HVM Windows 7 with PCI passthrough refuses to shutdown, somehow > qemu treats it as a domain reboot. If I do a xl destroy, the whole > system reboots (not sure how I can find out what happens though since > my mainboard does not have a hardware serial port. Can xen log to a > file?)You can buy a PCI/PCIe type serial card. That is what I am using for the non-serial supplied boxes.> > 2. With 16G of memory and Dom0 memory set to 1G, trying to start the > above 8G Windows 7 HVM while any other VM is running (I tried it with > one VM using 1G) causes some bug trace to occur (haven''t had the > chance to copy that one down) and qemu starts but does nothing. Doing > xl destroy will cause 1. to occur.This is with PCI passthrough or without?> > 3. On high (full) CPU and disk utilisation, the whole system will > sometimes reboot.That is .. not good. I think you need to buy that PCI card so we can get to the bottom of this.> > 4. Somehow with this new kernel/xen combination, my pfSense domain > does not receive DHCP requests sent from other domains, requests from > other computers in the network outside of xen are received though. Non > broadcast traffic works though. > > 5. The network performance of this kernel/xen combination compared to > before is almost half.What is "before" ?> > 6. The WAN bridge to my pfSense appliance goes down (pings suddenly > stop) after a while. Rebooting the pfSense domain restores it for aDo you see any messages in Dom0 about the NIC going offline? IF you run udevadm monitor --kernel --udev --property do you see anything showing up when the bridge goes down?> while. Removing and re-adding the domain''s tap interface to/from the > bridge solves it permanently for the domain session. This has always > been a problem, not sure where the bug is originating from though > since different versions and combinations of Debian/kernel/xen/pfSense > has never solved it. And no indication of the problem occurring except > all WAN traffic stops. > > I''m just listing it here in case someone has any idea about what''s > happening in each case. I''ll do a proper bug report for each case when > I''ve collected enough information (not even sure if 1, 2 and 3 could > be my hardware problem; 4 and 6 could be pfSense or Debian''s fault as > well). > > > Thanks for the great work so far!_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15 July 2011 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> > For the bugs you outlined, you might want to try 4.1.1 just to double-check. > > I''ve had some strange issues with Xen-Unstable that I hadn''t tracked down.I remember trying 4.1.1 before (that''s the released version right?), but PCI passthrough worked very badly (frequent BSODs, passthrough Intel audio will go crazy after a while). Will give it another try on my next reboot though.>> >> >> There are still some weird quirks around: >> 1. HVM Windows 7 with PCI passthrough refuses to shutdown, somehow >> qemu treats it as a domain reboot. If I do a xl destroy, the whole >> system reboots (not sure how I can find out what happens though since >> my mainboard does not have a hardware serial port. Can xen log to a >> file?)Just finished some testing. Seems like the system will reboot as long as that particular HVM is shut down for the second time. So the system reboot and the HVM not shutting down are (maybe) two separate problems.> > You can buy a PCI/PCIe type serial card. That is what I am using for > the non-serial supplied boxes.Alright, just purchased one off eBay.>> >> 2. With 16G of memory and Dom0 memory set to 1G, trying to start the >> above 8G Windows 7 HVM while any other VM is running (I tried it with >> one VM using 1G) causes some bug trace to occur (haven''t had the >> chance to copy that one down) and qemu starts but does nothing. Doing >> xl destroy will cause 1. to occur. > > This is with PCI passthrough or without?With PCI passthrough. But using today''s kernel+xen combination, it seemed to have disappeared.>> >> 3. On high (full) CPU and disk utilisation, the whole system will >> sometimes reboot. > > That is .. not good. I think you need to buy that PCI card so > we can get to the bottom of this.OK, will provide more details once the card arrives.>> >> 4. Somehow with this new kernel/xen combination, my pfSense domain >> does not receive DHCP requests sent from other domains, requests from >> other computers in the network outside of xen are received though. Non >> broadcast traffic works though.Solved with today''s kernel+xen combination as well.>> >> 5. The network performance of this kernel/xen combination compared to >> before is almost half. > > What is "before" ?That will be the kernel+xen combinations in the original bug report on this thread and prior to that: # hg log|head changeset: 23632:33717472f37e tag: tip user: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> date: Tue Jun 28 18:15:44 2011 +0100 summary: libxc: Squash xc_e820.h (and delete) into xenctrl.h Kernel: # git log|head commit 3dc33d5af47bd3e216f71f47f1f4c7ea4578cca4 Merge: bd687c5 bccaeaf Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Thu Jun 23 17:10:21 2011 -0700>> >> 6. The WAN bridge to my pfSense appliance goes down (pings suddenly >> stop) after a while. Rebooting the pfSense domain restores it for a > > Do you see any messages in Dom0 about the NIC going offline? IF you run > udevadm monitor --kernel --udev --property do you see anything showing > up when the bridge goes down?Nope, nothing happened at all. I''m going to try passing-through the WAN interface into pfSense, that should ascertain whether xen is directly involved or not.> >> while. Removing and re-adding the domain''s tap interface to/from the >> bridge solves it permanently for the domain session. This has always >> been a problem, not sure where the bug is originating from though >> since different versions and combinations of Debian/kernel/xen/pfSense >> has never solved it. And no indication of the problem occurring except >> all WAN traffic stops. >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel