* Alan Cox wrote:
> On Mon, 8 Jan 2018 11:08:36 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote:
> > > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman
> > > wrote:
> > > > In at least one place (mpls) you are patching a fast path. Compile
reakage.
>
> It's really that simple. That's what "no regressions" means. We don't
> accept changes that cause regressions. This one did.
Yeah, absolutely - for the revert:
Acked-by: Ingo Molnar
as I doubt we have enough time to root-case this properly.
Thanks,
Ingo
* Linus Torvalds wrote:
> In other words: what will happen is that distros start getting bootup problem
> reports six months or a year after we've done it, and *if* they figure out
> it's
> the irq enabling, they'll disable it, because they have no way to solve it
> either.
>
> And core dev
* Thomas Gleixner wrote:
> The pending interrupt issue happens, at least on my test boxen, mostly on
> the 'legacy' interrupts (0 - 15). But even the IOAPIC interrupts >=16
> happen occasionally.
>
>
> - Spurious interrupts on IRQ7, which are triggered by IRQ 0 (PIT/HPET). On
>one of the a
n in -tip and -next for some time, but were clearly
too
optimistic about that.
So, should we revert the hw-retrigger change:
a9b4f08770b4 x86/ioapic: Restore IO-APIC irq_chip retrigger callback
... until we managed to fix CONFIG_DEBUG_SHIRQ=y? If you'd like to revert it
upstream straight away:
Acked-by: Ingo Molnar
Thanks,
Ingo
* Luis R. Rodriguez wrote:
> On Mon, Jul 6, 2015 at 5:44 PM, Luis R. Rodriguez wrote:
> > If we really wanted to we could consider arch_phys_wc_add()
>
> I mean adding a __arch_phys_wc_add() which does not check for pat_enabled().
>
> > and
> > deal with that this will not check for pat_enabl
* Andy Walls wrote:
> On Fri, 2015-06-26 at 10:45 +0200, Ingo Molnar wrote:
> > * Luis R. Rodriguez wrote:
> >
> > > On Thu, Jun 25, 2015 at 08:51:47AM +0200, Ingo Molnar wrote:
> > > >
> > > > * Luis R. Rodriguez wrote:
> > > >
* Luis R. Rodriguez wrote:
> On Thu, Jun 25, 2015 at 08:49:22AM +0200, Ingo Molnar wrote:
> >
> > * Luis R. Rodriguez wrote:
> >
> > > From: "Luis R. Rodriguez"
> > >
> > > WARN() may confuse users, fix that. ipath_init_one() is par
* Luis R. Rodriguez wrote:
> On Thu, Jun 25, 2015 at 08:51:47AM +0200, Ingo Molnar wrote:
> >
> > * Luis R. Rodriguez wrote:
> >
> > > From: "Luis R. Rodriguez"
> > >
> > > On built-in kernels this warning will always splat as this
* Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> On built-in kernels this warning will always splat as this is part
> of the module init. Fix that by shifting the PAT requirement check
> out under the code that does the "quasi-probe" for the device. This
> device driver relies on an
* Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> WARN() may confuse users, fix that. ipath_init_one() is part the
> device's probe so this would only be triggered if a corresponding
> device was found.
>
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/infiniband/hw/ipath/ipath_
* Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> On built-in kernels this will always splat. Fix that.
>
> Reported-by: Fengguang Wu [0-day test robot]
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
> 1 file changed, 4 insertions
* Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> On built-in kernels this will always splat. Fix that.
>
> Reported-by: Fengguang Wu [0-day test robot]
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/media/pci/ivtv/ivtvfb.c | 6 --
> 1 file changed, 4 insertions(+), 2 dele
* Borislav Petkov wrote:
> On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote:
> > Nope, well the driver requires huge amounts of work to work with PAT, that
> > work will likely never be done, so hence the warning. Its our compromise as
> > only 2 drivers will live on Linux li
* Andy Lutomirski wrote:
> On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote:
> >
> > >>> On 12.06.15 at 01:23, wrote:
> > > There are two usages on MTRRs:
> > > 1) MTRR entries set by firmware
> > > 2) MTRR entries set by OS drivers
> > >
> > > We can obsolete 2), but we have no control over 1)
* Maarten Lankhorst wrote:
> Well they've helped me with some of the changes and contributed some
> code and/or fixes, but if acked-by is preferred I'll use that..
Such contributions can be credited in the changelog, and/or copyright
notices, and/or the code itself. The signoff chain on the o
* Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is quite
> +simple. [...]
'TTM' here reads like a person - but in reality it's the TTM graphics
subsystem, right?
Please clarify this portion of the text.
Thanks,
Ingo
--
To unsubscribe f
* Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes si
* Randy Dunlap wrote:
> On 08/24/10 01:45, Ingo Molnar wrote:
> >
> > * Mauro Carvalho Chehab wrote:
> >
> >> Linus,
> >>
> >> Please pull from:
> >> ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
> &g
ntly in randconfig tests - see the fix below.
Thanks,
Ingo
------->
>From c56aef270d7ec01564c632c1f7ebab6b8f9f032c Mon Sep 17 00:00:00 2001
From: Ingo Molnar
Date: Tue, 24 Aug 2010 10:41:33 +0200
Subject: [PATCH] V4L/DVB: mantis: Fix IR_CORE dependency
This build bu
* Randy Dunlap wrote:
> From: Randy Dunlap
>
> Add slab.h to fix ak881x build:
>
> drivers/media/video/ak881x.c:265:error: implicit declaration of function
> 'kzalloc'
> drivers/media/video/ak881x.c:265:warning: assignment makes pointer from
> integer without a cast
> drivers/media/video/ak
* David T. L. Wong wrote:
> Ingo Molnar wrote:
> >Hi,
> >
> >FYI, there's a new build failure on 32-bit x86 caused by the new
> >max2165 tuner driver:
> >
> >drivers/built-in.o: In function `max2165_set_params':
> >max2165.c:(.text+0x48629
Hi,
FYI, there's a new build failure on 32-bit x86 caused by the new max2165
tuner driver:
drivers/built-in.o: In function `max2165_set_params':
max2165.c:(.text+0x486293): undefined reference to `__floatunsidf'
max2165.c:(.text+0x4862bc): undefined reference to `__floatunsidf'
max2165.c:(.text
* Mauro Carvalho Chehab wrote:
> Em Mon, 21 Sep 2009 20:23:45 +0200
> Ingo Molnar escreveu:
>
> >
> > * Mauro Carvalho Chehab wrote:
> >
> > > This series also contains several new drivers:
> > >
> > >- new driver for NXP saa7164;
-->
>From 67a0d8c7dfdf2de72ddec3d821ae87a80ecaed83 Mon Sep 17 00:00:00 2001
From: Ingo Molnar
Date: Mon, 21 Sep 2009 20:14:47 +0200
Subject: [PATCH] media: video: Fix build in saa7164
-tip testing found that the x86 build (64-bit allyesconfig) fails due to:
LD vmlinux.o
drivers/built-in.o:(.bss+0x4
* Ingo Molnar wrote:
> FYI, latest upstream (2.6.29-rc8) fails to build with the
> attached config:
>
> MODPOST 531 modules
> ERROR: "dibusb_dib3000mc_frontend_attach"
> [drivers/media/dvb/dvb-usb/dvb-usb-dibusb-mc.ko] undefined!
> ERROR: "dibusb_dib30
ser, load average: 3.97, 1.10, 0.37
Tested-by: Ingo Molnar
Thanks!
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Arnd Bergmann wrote:
> On Wednesday 04 February 2009, Jaswinder Singh Rajput wrote:
> > On Wed, 2009-02-04 at 17:43 +1100, Herbert Xu wrote:
> > > > -#include
> > > > +#include
> > > > #include
> > >
> > > Awesome, you've just broken the userspace build of kvm as the
> > > file linux/types
* Jaswinder Singh Rajput wrote:
> On Sat, 2009-01-24 at 18:26 +0530, Jaswinder Singh Rajput wrote:
> > The following changes since commit aa52dcf69565512e7d285c1c40dc6e56aab6f789:
> > Ingo Molnar (1):
> > Merge branch 'x86/urgent'
> >
>
* Sam Ravnborg wrote:
> On Sun, Jan 18, 2009 at 08:37:41AM +1100, David Woodhouse wrote:
> > On Sun, 2009-01-18 at 01:47 +0530, Jaswinder Singh Rajput wrote:
> > > --- a/include/linux/dvb/audio.h
> > > +++ b/include/linux/dvb/audio.h
> > > @@ -24,9 +24,8 @@
> > > #ifndef _DVBAUDIO_H_
> > > #de
30 matches
Mail list logo
