search for: ckt20

...88 id=1) (internal failure, 1 successful auths): user=<username>, method=PLAIN, rip=rip, lip=lip, session=<session> Is this something that Dovecot should be able to handle, or is it strictly Debian/libc/MySillyMistake related? #uname -a Linux server 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux #dovecot --version 2.2.13 #dpkg -l | grep -E 'dovecot-core|libc6|linux-image' ii dovecot-core 1:2.2.13-12~deb8u1 amd64 ii libc6:amd64 2.19-18+deb8u3 amd64 ii libc6-i386 2.1...

...12-30 as 2015-12-30 was the > > last time I upgraded without any problems according to my dpkg.log. > > This upgrade looks to only have upgraded the hypervisor? > > As in I see: > > domU "bug" "uname -a": > Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) > x86_64 GNU/Linux > > domU "working" "uname -a": > Linux working 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 > (2016-01-02) x86_64 GNU/Linux > > So same version? What was the earlier version of the hypervisor? > I forgot to...

Hi, A while ago I sent an email regarding these "*ETOOMANYREFS* Too many references: cannot splice." that we've seen since Debian updated the Jessie kernel to 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 while older kernels, like 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 showed no errors at all. I was wondering if no one else is getting these errors, or if you know any workarounds that might probe useful, apart from downgrading the kernel...

...0, Tommi Airikka wrote: > Hi, > > I patched the deb8u2 source with all four patches and built a new deb. .. snip.. > > Next, I upgraded dom0 with the new linux-image deb and rebooted the machine. > > dom0 "uname -a": > Linux dom0 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2a~test > (2016-02-04) x86_64 GNU/Linux > > domU 'bug' "uname -a": > Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2a~test > (2016-02-04) x86_64 GNU/Linux > > And now everything seems to work. No more "Failed to obtain physical IRQ&quo...

...t; wrote: > >> Hi, >> >> >> A while ago I sent an email regarding these "*ETOOMANYREFS* Too many >> references: cannot splice." that we've seen since Debian updated the Jessie >> kernel to >> >> 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 >> >> while older kernels, like 3.16.0-4-amd64 #1 SMP Debian >> 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 showed no errors at all. >> >> I was wondering if no one else is getting these errors, or if you know any >> workarounds that...

On Wed, 2016-02-03 at 15:28 -0500, Konrad Rzeszutek Wilk wrote: > > > And I wonder if the XEN_DOMCTL_irq_permission aka, > > > xc_domain_irq_permission > > > had been called. I remember that at some point we missed it for > > > Xend.. > > > > > False alarm. > > It was all in Linux. Attached are four patches (the first two > are for

...30 as 2015-12-30 was the > > last time I upgraded without any problems according to my dpkg.log. > > This upgrade looks to only have upgraded the hypervisor? > > As in I see: > > domU "bug" "uname -a": > Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) > x86_64 GNU/Linux > > domU "working" "uname -a": > Linux working 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 > (2016-01-02) x86_64 GNU/Linux > > So same version? What was the earlier version of the hypervisor? In my case, dom...

...se issues known and important enough, roadmap, bug reports? Should I start working for Redhat as I don't have the resources myself, but I can help with some money towards a crowed fund or bounty. Maybe my software is outdated? virsh 1.2.9 ceph version 0.80.10 libguestfs-tools 1:1.28.1-1 3.16.7-ckt20-1+deb8u2 My current workarounds for full storage exports: virsh domfsfreeze $quest sleep 2 virsh domblklist $quest rbd snap create --snap snapshot $blkdevice virsh domfsthaw $quest rbd export $blkdevice at snapshot - | xz -1 | ssh -p 222 $user@$server "dd of=/$location/$blkdevice$snapshot-$da...

...se issues known and important enough, roadmap, bug reports? Should I start working for Redhat as I don't have the resources myself, but I can help with some money towards a crowed fund or bounty. Maybe my software is outdated? virsh 1.2.9 ceph version 0.80.10 libguestfs-tools 1:1.28.1-1 3.16.7-ckt20-1+deb8u2 My current workarounds for full storage exports: virsh domfsfreeze $quest sleep 2 virsh domblklist $quest rbd snap create --snap snapshot $blkdevice virsh domfsthaw $quest rbd export $blkdevice at snapshot - | xz -1 | ssh -p 222 $user@$server "dd of=/$location/$blkdevice$snapshot-$da...

...is Ugalde <forondarena at gmail.com> wrote: > Hi, > > > A while ago I sent an email regarding these "*ETOOMANYREFS* Too many > references: cannot splice." that we've seen since Debian updated the Jessie > kernel to > > 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 > > while older kernels, like 3.16.0-4-amd64 #1 SMP Debian > 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 showed no errors at all. > > I was wondering if no one else is getting these errors, or if you know any > workarounds that might probe useful, apart...

...:812: d14: Forcing read-only access to MFN fbff1 (XEN) mm.c:812: d14: Forcing read-only access to MFN fbff1 (XEN) mm.c:812: d14: Forcing read-only access to MFN fbff1 (XEN) mm.c:812: d0: Forcing read-only access to MFN fbff1 dom0 "uname -a": Linux dom0 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) x86_64 GNU/Linux domU "bug" "uname -a": Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) x86_64 GNU/Linux domU "working" "uname -a": Linux working 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02)...

...AM" Message without any Error-message, just a blank screen. Technical Data of the Server: CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (with VT-x) MEMORY: 64GB RAM (Memtest reports no Errors) HDD: SSD as Software-Raid Debian-Version: 8.2 (Jessie) with all Updates System/Dom0-Kernel: 3.16.7-ckt20-1 / 3.16+63 I have also tried the Kernels from Backports: 4.2.6-3-bpo8+2 and 4.3.3-2-bpo8+1 ... makes no difference According to other Bug-reports, etc. in the Internet I tried to set Parameters in the Grub-Command-line (/etc/default/grub : GRUB_CMDLINE_XEN_DEFAULT) followed by an update-gru...