search for: reapplied

Displaying 20 results from an estimated 229 matches for "reapplied".

2014 Apr 22
2
"Reapplying" sieve rules
I did a mistake (shame on me). While migrating accounts on a new server, I didn't pay attention to a detail: sieve_max_actions, that I set to a low value for my testings, but then forgot to raise before the migration. As a result, several redirect-only accounts have now their inbox filled with messages that should have been redirected to "real people", then discarded. Would there
2018 Jun 17
2
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sat, Jun 16, 2018 at 05:39:11PM +0200, Mike Galbraith wrote: > Greetings, > > Running a kernel with ATOMIC_SLEEP enabled in one of my VMs, I met the > splat below. I tracked it back to 4.14-stable, and bisected it there. Why does your virtual machine use a drm driver? Ah, it's a driver for virtual gpu, nice. And if you revert that patch, does everything work again? > #
2018 Jun 17
2
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sat, Jun 16, 2018 at 05:39:11PM +0200, Mike Galbraith wrote: > Greetings, > > Running a kernel with ATOMIC_SLEEP enabled in one of my VMs, I met the > splat below. I tracked it back to 4.14-stable, and bisected it there. Why does your virtual machine use a drm driver? Ah, it's a driver for virtual gpu, nice. And if you revert that patch, does everything work again? > #
2018 Jun 17
0
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: > > And if you revert that patch, does everything work again? Yes. -Mike
2018 Jun 17
2
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: > On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: > > > > And if you revert that patch, does everything work again? > > Yes. Great, Dave, care to revert this in 4.18 so I can queue up that revert in older kernels as well? thanks, greg k-h
2018 Jun 18
0
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On 17 June 2018 at 21:02, Greg KH <gregkh at linuxfoundation.org> wrote: > On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: >> On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: >> > >> > And if you revert that patch, does everything work again? >> >> Yes. > > Great, Dave, care to revert this in 4.18 so I can queue up that revert
2018 Jun 17
2
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: > On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: > > > > And if you revert that patch, does everything work again? > > Yes. Great, Dave, care to revert this in 4.18 so I can queue up that revert in older kernels as well? thanks, greg k-h
2013 Nov 15
2
[LLVMdev] asan coverage
Yes. I'm seeing this as well and it predates Kostya's change. Shows up as memory corruption or double free on Linux. On Nov 14, 2013 10:46 PM, "Alexey Samsonov" <samsonov at google.com> wrote: > FYI I've seen what looked like a memory corruption in (private) Clang > bootstrap process long before Kostya's changes were submitted. I hope I'll > have the
2013 Nov 15
2
[LLVMdev] asan coverage
No, not that I am aware of. On Nov 14, 2013, at 10:15 PM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 10:14 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> The bit code file produced by the stage 1 compiler for one of the files in the clang driver is corrupt and causes the linker for stage 2 to crash. > > Is AddressSanitizer involved in
2013 Nov 15
0
[LLVMdev] asan coverage
I was able to successfully build with r194701, so I have reapplied that along with the compiler-rt changes. Somehow we need to get to the bottom of the problem. If you can reproduce it, please help!! On Nov 14, 2013, at 11:01 PM, Eric Christopher <echristo at gmail.com> wrote: > Yes. I'm seeing this as well and it predates Kostya's change. Sho...
2013 Nov 15
2
[LLVMdev] asan coverage
I don’t know yet, but I will let you know as soon as I can. On Nov 14, 2013, at 10:18 PM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> No, not that I am aware of. > > So, if my commits did indeed trigger the failures it could be > something like binary size change that caused
2013 Nov 15
0
[LLVMdev] asan coverage
On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> wrote: > No, not that I am aware of. So, if my commits did indeed trigger the failures it could be something like binary size change that caused different code alignment or some such and which triggered a latent memory bug somewhere else. It's already late evening for you now. Will you have a chance to reapply
2014 Mar 26
1
Recreating nwfilter rules without a restart
Let's say I have some iptables rules defined to restrict guest traffic. If I restart the hosts firewall 'service iptables restart', all the guest-specific rules get blown away. Is there a way to reapply all the guest firewall rules, without restarting each individual guest? It looks like if I edit a nwfilter with `virsh nwfilter-edit` it goes and reapplies the rules to all the
2013 Nov 15
2
[LLVMdev] asan coverage
I’m waiting to see if this fixes the buildbots. Unfortunately, because they were failing all day, there are a bunch of other regressions that have come up, and I’m still working through them. It takes quite a while to run a bootstrapped LTO clang build, so it will take a while longer. I don’t have any other useful information at this point, and I share your puzzlement about how your changes
2013 Nov 15
2
[LLVMdev] asan coverage
On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote: > Hi Kostya, > > Thanks for the heads-up on this. I haven’t had a chance to look into the > details yet, but it looks like these patches may be breaking our > bootstrapped LTO build. Our buildbots have been failing all day, and we’re > still trying to figure out the problem. I’m going to
2016 Jan 25
1
Persistent tun/tap
Ok. I'm configuring my iptables scripts so that specific iptables rules for virtual network interfaces used for tinc go on tinc-up-fw and tinc-down-fw custom scripts. When I reload iptables rules manually to apply changes iptables scripts flush all chains and reapply rules and now also search in /etc/tinc/<netname>/ directories if the related virtual network interface is up and running
2013 Nov 15
2
[LLVMdev] asan coverage
The bit code file produced by the stage 1 compiler for one of the files in the clang driver is corrupt and causes the linker for stage 2 to crash. On Nov 14, 2013, at 10:13 PM, Kostya Serebryany <kcc at google.com> wrote: > What are the symptoms? > > On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> I’m waiting to see if this fixes the
2013 Nov 15
0
[LLVMdev] asan coverage
FYI I've seen what looked like a memory corruption in (private) Clang bootstrap process long before Kostya's changes were submitted. I hope I'll have the chance to investigate it soon. On Fri, Nov 15, 2013 at 10:20 AM, Bob Wilson <bob.wilson at apple.com> wrote: > I don’t know yet, but I will let you know as soon as I can. > > On Nov 14, 2013, at 10:18 PM, Kostya
2013 Nov 15
0
[LLVMdev] asan coverage
Also, when are you planing to "reapply the changes or help debug"? On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> Hi Kostya, >> >> Thanks for the heads-up on this. I haven’t had a chance to look into the >> details yet, but it looks
2019 Sep 29
3
ScalarEvolution invariants around wrapping flags
Your reasoning sounds correct to me. Let's revert for now? I don't think there is an easy fix, we'll have to do a global "must be executed" analysis to reapply the patch soundly. And that's difficult since any external functional call can call "exit(0)". -- Sanjoy On Thu, Sep 26, 2019 at 6:19 AM Tim Northover <t.p.northover at gmail.com> wrote: >