* 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
v3 (https://patchwork.kernel.org/patch/9519383/). Sorry for
> the inconvenience.
As per the interdiff below v2->v3 did not change the code in any way, only the
name of the function and a comment, so you can add this to v3 as well:
Reported-by: Ingo Molnar
Tested-by: Ingo Molnar
Th
* James Bottomley wrote:
> On Mon, 2017-01-16 at 10:22 +0100, Ingo Molnar wrote:
> > * James Bottomley wrote:
> >
> > > On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote:
> > > > So there's a new mpt3sas SCSI driver boot regression, introduced
>
* James Bottomley wrote:
> On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote:
> > So there's a new mpt3sas SCSI driver boot regression, introduced in
> > this merge window, which made one of my servers unbootable.
>
> We're not reverting a fix that would caus
t alone does not help:
7ff723ad0f87 scsi: mpt3sas: Unblock device after controller reset
So it's reverting 18f6084a989b (while keeping ata_12_16_cmd() around to enable
the
7ff723ad0f87 fix) that does the trick.
Thanks,
Ingo
>
>From 0734e6d2a7f757172d6b
* Josh Poimboeuf wrote:
> On Sat, Apr 16, 2016 at 11:03:32AM +0200, Ingo Molnar wrote:
> >
> > * Josh Poimboeuf wrote:
> >
> > > > I don't think we know yet if there's a reliable way to turn the bug off.
> > > >
> > > >
* Josh Poimboeuf wrote:
> > I don't think we know yet if there's a reliable way to turn the bug off.
> >
> > Also, according to the gcc guys, this bug won't always result in a
> > truncated function, and may sometimes just make some inline function
> > call sites disappear:
> >
> > https://g
* Denys Vlasenko wrote:
> > In fact, the following patch seems to fix it:
> >
> > diff --git a/include/scsi/scsi_transport_fc.h
> > b/include/scsi/scsi_transport_fc.h
> > index bf66ea6..56b9e81 100644
> > --- a/include/scsi/scsi_transport_fc.h
> > +++ b/include/scsi/scsi_transport_fc.h
> > @@
* William Breathitt Gray wrote:
> On Wed, Apr 13, 2016 at 09:26:02AM +0200, Ingo Molnar wrote:
> >What's the practical motivation of this? What exact hardware is this for?
> >
> >Thanks,
> >
> > Ingo
>
> The PC/104 bus is equivalent to the ISA
* William Breathitt Gray wrote:
> This patchset is based on top of commit 3a3a5fece6f2 ("fs: kernfs: Replace
> CURRENT_TIME by current_fs_time()") of the driver-core-testing branch of
> the driver-core repository.
>
> The introduction of the ISA_BUS option in commit b3c1be1b789c
> ("base: isa:
hide places where vmalloc() et al are added to files
> but the include of vmalloc.h is forgotten.
Good idea.
Acked-by: Ingo Molnar
> Based in Linus' tree of today.
>
> There are probably more places that need vmalloc.h included, but this passes
> 64
> bit and 32 bit al
* Oleg Nesterov wrote:
> On 12/23, Ingo Molnar wrote:
> >
> > * Oleg Nesterov wrote:
> >
> > > Initially I thought that this is obviously wrong, irqsave/irqrestore
> > > assume that "flags" is owned by the caller, not by the lock. An
* Oleg Nesterov wrote:
> On 12/23, Oleg Nesterov wrote:
> >
> > Perhaps we should ask the maintainers upstream? Even if this works, I am
> > not sure this is _supposed_ to work. I mean, in theory spin_lock_irqave()
> > can be changed as, say
> >
> > #define spin_lock_irqsave(lock, flags)
* David Ahern wrote:
> On 6/23/13 3:09 AM, Ingo Molnar wrote:
> >If an IO driver is implemented properly then it will batch up requests for
> >the controller, and gets IRQ-notified on a (sub-)batch of buffers
> >completed.
> >
> >If there's any spinning don
* Jens Axboe wrote:
> - With the former note, the app either needs to opt in (and hence
> willingly sacrifice CPU cycles of its scheduling slice) or it needs to
> be nicer in when it gives up and goes back to irq driven IO.
The scheduler could look at sleep latency averages of the task in
* Linus Torvalds wrote:
> On Sun, Jun 23, 2013 at 12:09 AM, Ingo Molnar wrote:
> >
> > The spinning approach you add has the disadvantage of actively wasting
> > CPU time, which could be used to run other tasks. In general it's much
> > better to make s
* Matthew Wilcox wrote:
>
> A paper at FAST2012
> (http://static.usenix.org/events/fast12/tech/full_papers/Yang.pdf) pointed
> out the performance overhead of taking interrupts for low-latency block
> I/Os. The solution the author investigated was to spin waiting for each
> I/O to complete. T
* Linus Torvalds wrote:
> I couldn't find an example of that in a quick look, it's
> fairly uncommon to have non-conflicting merges that had
> semantic - but not contextual - conflicts. [...]
This:
git log --grep='Semantic merge\|Semantic conflict'
gives over a dozen examples of such sema
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> so please tell me Jeff. If Greg, who is the super-maintainer of your
>> code area, and who deals with your code every day and changes it
>> every minute and hour, simply did not Cc: the SCSI list - how
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
>> so i'm still totally befuddled why you think that there was anything
>> particularly wrong or unhelpful about me replying to the specific
>> pull request that introduced a particular breakage into the kernel.
>> Had i mailed to lkml with a terse "ker
* James Bottomley <[EMAIL PROTECTED]> wrote:
> Are you seriously telling us that it required too much investigation
> on your part to figure out that something with a compile failure in
> drivers/scsi might belong on the scsi list?
This is getting silly. Let me repeat it, because IMO it's real
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> it would have been totally appropriate for me to just send a mail to lkml
>> with the proper subject line about the breakage. (I might even have
>> decided to stay completely silent about the issue and
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> ===
>> --- linux.orig/drivers/scsi/lpfc/lpfc_init.c
>> +++ linux/drivers/scsi/lpfc/lpfc_init.c
>> @@ -1894,7 +1894,7 @@ lpfc_p
* Bob Tracy <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >
> > * Bob Tracy <[EMAIL PROTECTED]> wrote:
> >
> > > > Current state of the source tree is the 6f37ac... version, so I'll
> > > > start backing out the above diffs in
* Bob Tracy <[EMAIL PROTECTED]> wrote:
> > Current state of the source tree is the 6f37ac... version, so I'll
> > start backing out the above diffs in related groups and continue
> > until I've got a working kernel. For lack of an obvious target,
> > I'll start with the seemingly innocuous ch
* Bob Tracy <[EMAIL PROTECTED]> wrote:
> > I'm struggling to see how any of those could have broken block
> > device mounting on alpha. Are you sure you bisected right?
>
> Based on what's in that commit, it *does* appear something went wrong
> with bisection. If the implicated commit is the
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > then the test of whether I bisected correctly is as simple as
> > applying the commit and seeing if things break, because I'm running
> > on the kernel corresponding to
> > 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give
> > that
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of
> > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
> > git-bisect bad 6f37ac793d6ba7b35d338f791974166f67fdd9ba
> > # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a
* Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> This softlockup is seen in the 2.6.24-rc4 either and looks like a
> message because this is seen while running tbench and machine
> continues running other test's after the softlockup messages and some
> times seen with the bootup,
* Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > So 2.6.24-rc3 was OK and 2.6.24-rc3-git2 is not?
>
> Yes, the 2.6.24-rc3 was Ok and this is seen from 2.6.24-rc3-git2/3/4.
just to make sure: this is a real lockup and failed bootup (or device
init), not just a message, right?
Ingo
-
T
* Bob Tracy <[EMAIL PROTECTED]> wrote:
> Finally got back in town. Starting the git-bisect process. I've got
> a relatively slow network connection, and the PWS 433au isn't exactly
> what I would call "fast" by modern standards, so bear with me while I
> get things set up and crank through t
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Memory management
>
> Subject : [bug] SLUB & freeing locks
> References : http://lkml.org/lkml/2007/7/26/90
> Last known good : ?
> Submitter : Ingo Molnar <[EMAIL PROTECTED]>
> Caused-B
yeah ... cannot remember why i have done it originally :-|
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Ingo
On Wed, 10 Aug 2005, James Bottomley wrote:
> Ingo,
>
> This has been in the workqueue code in day one, for no real reason that
> I can see. We just tripp
33 matches
Mail list logo
