Em Fri, Aug 24, 2012 at 05:32:21PM +0400, Andrey Wagin escreveu:
> Hello Arnaldo,
>
> What do you think about this series?
>
> It has been fixed according with your comments to the previous
> patches. Are you going to take it?
I've put them in a perf/sleep branch in my tree, waiting on Frédéric
There is no consideration for pfmemalloc_match() in get_partial(). If we don't
consider that, we can't restrict access to PFMEMALLOC page mostly.
We may encounter following scenario.
Assume there is a request from normal allocation
and there is no objects in per cpu cache and no node partial slab
* Alan Cox wrote:
> On Fri, 24 Aug 2012 05:08:45 +0100
> Matthew Garrett wrote:
>
> > On Thu, Aug 23, 2012 at 03:32:50PM -0600, David Ahern wrote:
> >
> > > Why not add support for the missing functions (on_exit, getsid,
> > > psignal and getline) to Bionic instead of perf?
> >
> > Many vend
On Friday 24 August 2012 19:05:53 wbrana wrote:
> On 8/24/12, Martin Nybo Andersen wrote:
> > What I'd hate even more is rendering my old working hardware useless by
> > removing x86-32 support from the kernel. To reason the removal by saying
> > "Microsoft plans to do it" just makes me go bonkers
On Thursday 23 August 2012 08:13 PM, Laxman Dewangan wrote:
On Thursday 23 August 2012 08:23 PM, Mark Brown wrote:
On Wed, Aug 22, 2012 at 03:15:12PM +0530, Laxman Dewangan wrote:
Hi Rabin,
Is it resolved the issue you mentioned?
He replied to your mail pointing out that it generated a lockdep
* Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 24, 2012 at 11:00:31AM +0200, Jiri Olsa escreveu:
>
> > tools/perf/util/test-attr.c | 142
> > ++
> > tools/perf/util/test-attr.py| 272
> >
On Thursday 23 August 2012 08:13 PM, Laxman Dewangan wrote:
On Thursday 23 August 2012 08:23 PM, Mark Brown wrote:
On Wed, Aug 22, 2012 at 03:15:12PM +0530, Laxman Dewangan wrote:
Hi Rabin,
Is it resolved the issue you mentioned?
He replied to your mail pointing out that it generated a lockdep
On 08/23/2012 11:54 AM, Brian Gerst wrote:
>
>> - wastes time of developers who can spend their time supporting X32
>> instead of x86-32 or support x86-64 only as 99% of users will be able
>> to run x86-64 software if x86-32 will be dropped
>
> The x86-32 arch is mature and well maintained, and s
Hi Linus,
Please find below a set of block related fixes for the 3.6 rc series. It
contains:
- Improvements to the buffered and direct write IO plugging from
Fengguang.
- Abstract out the mapping of a bio in a request, and use that to
provide a blk_bio_map_sg() helper. Useful for mapping jus
On Friday 24 August 2012, wbrana wrote:
>On 8/24/12, Martin Nybo Andersen wrote:
>> What I'd hate even more is rendering my old working hardware useless by
>> removing x86-32 support from the kernel. To reason the removal by
>> saying "Microsoft plans to do it" just makes me go bonkers...
>
>Your
On 8/24/12, Martin Nybo Andersen wrote:
> That's right, but new hardware, that I wish to use with the old machines
> might
> not because of no backporting of new drivers. Same goes for new software
> utilising newer kernel features.
Which new hardware and which old machine do you want to use?
> T
On Wed, Aug 22, 2012 at 07:42:14PM +0800, Jianpeng Ma wrote:
> Hi,
> I used the $DBGMT/dynamic_debug/control to control printing
> debuginfo.But When i wote multiple queries which has at least one didn't
> match,
> the result is ok which no error can return.
> So i think i wrote corre
On Fri, Aug 24, 2012 at 04:16:39PM +0100, Jan Beulich wrote:
> >>> On 24.08.12 at 10:55, Alex Shi wrote:
> > While TLB_FLUSH_ALL gets passed as 'end' argument to
> > flush_tlb_others(), the Xen code was made to check its 'start'
> > parameter. That may give a incorrect op.cmd to MMUEXT_INVLPG_MULT
On Fri, Aug 24, 2012 at 04:23:39PM +0800, Bill Huang wrote:
> When doing shutdown on Tegra20/Tegra30, we need to read/write PMIC
> registers through I2C to perform the power off sequence. Unfortunately,
> sometimes we'll fail to shutdown due to I2C timeout on Tegra20. And the
> cause of the timeout
On Friday 24 August 2012 20:18:49 wbrana wrote:
> On 8/24/12, Martin Nybo Andersen wrote:
> > That's right, but new hardware, that I wish to use with the old machines
> > might
> > not because of no backporting of new drivers. Same goes for new software
> > utilising newer kernel features.
>
> Wh
In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
statement.
In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
but selects USB_SUPPORT which leads to the error for udl Kconfig:
$ yes "" | make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drive
On Fri, Aug 24, 2012 at 12:14:48AM -0700, Kent Overstreet wrote:
[..]
> > > -static struct dm_rq_clone_bio_info *alloc_bio_info(struct mapped_device
> > > *md)
> > > -{
> > > - return mempool_alloc(md->io_pool, GFP_ATOMIC);
> > > -}
> > > -
> > > -static void free_bio_info(struct dm_rq_clone_bio_
On Fri, Aug 24, 2012 at 03:05:00PM +0100, Krystian Garbaciak wrote:
> DA906x PMIC provides ADC for voltage and temperature monitoring.
>
Hi Krystian,
DA906x seems to be a bad choice for a name. It covers DA906[0-9] and possibly
even DA906[A-Z]. The only chip really in existence seems to be DA9064
From: Michal Nazarewicz
This commit removes USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED
Kconfig options. Since now kernel allows many UDC drivers to be
compiled, those options may turn to no longer be valid. For
instance, if someone decides to build UDC that supports super
speed and UDC that
On Mon, Aug 20, 2012 at 9:26 AM, Jiang Liu wrote:
> Hi Bjorn,
> I have made following changes according to your suggestions,
> 1) get rid of the "pci_" prefix for access functions.
> 2) rename pci_pcie_capability_change_{word|dword}() to
> pcie_capability_clear_and_
On 08/22/2012 01:07 PM, Mark Brown wrote:
> On Mon, Aug 20, 2012 at 12:37:44PM -0600, Stephen Warren wrote:
>> On 08/20/2012 12:14 PM, Mark Brown wrote:
>
>>> Why not just pull the patch in via the regulator tree? The
>>> idea of merging the entire regulator drivers branch into the
>>> Tegra tree
2 small patches sent out for review.
-Robert
Robert Richter (2):
oprofile, s390: Fix uninitialized memory access when writing to
oprofilefs
oprofile: Remove 'WQ on CPUx, prefer CPUy' warning
arch/s390/oprofile/init.c | 10 +-
drivers/oprofile/cpu_buffer.c | 11 +++---
On 08/21, Oleg Nesterov wrote:
>
> > task_work_add(struct task_struct *task, struct callback_head *twork, bool
> > notify)
> > {
> > do {
> > twork->next = ACCESS_ONCE(task->task_works);
> > if (unlikely(twork->next == TWORK_EXITED))
> > return -ESRC
Under certain workloads we see the following warnings:
WQ on CPU0, prefer CPU1
WQ on CPU0, prefer CPU2
WQ on CPU0, prefer CPU3
It warns the user that the wq to access a per-cpu buffers runs not on
the same cpu. This happens if the wq is rescheduled on a different cpu
than where the buffer is l
If oprofilefs_ulong_from_user() is called with count equals zero, *val
remains unchanged. Depending on the implementation it might be
uninitialized. Fixing users of oprofilefs_ulong_ from_user().
We missed these s390 changes with:
913050b oprofile: Fix uninitialized memory access when writing to
On Fri, Aug 24, 2012 at 11:17:20AM -0700, H. Peter Anvin wrote:
>
> Speaking as one of the x86 maintainers... we are currently deciding the
> cost/benefit tradeoff around removing i386 support. I don't mean
> general x86-32 support, I mean i386 as opposed to i486, Pentium, and so on.
Random ques
On 8/24/12, Martin Nybo Andersen wrote:
> I want to use *my* old machines (hey, I payed for them) on whatever new
> hardware I can plug into them. I'm not an oracle and can't see into the
> future, however USB has evolved, for instance, and will probably still do --
Your 32-bit machines will be li
On Thu, 2012-08-23 at 23:26 -0500, Mouse Dresden wrote:
> Hello I hope that this question is not to mundane.
>
> A while ago I encountered this error message on a hard drive of mine.
> I managed to clean up the problem and run smartctl and the disk is
> clean, but such errors can be very problemat
Hi All,
We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
working with 3.6-rc3. It seems the last working kernel was based on
commit 10c63c9, and it first stopped working with a kernel based on
commit 23dcfa6. There are only a few ALSA commits between those
revisions, so h
* Felipe Balbi [120823 03:38]:
> From: Vikram Pandita
>
> Software flow control register bits were not defined correctly.
>
> Also clarify the IXON and IXOFF logic to reflect what userspace wants.
>
> Cc: sta...@vger.kernel.org
> Tested-by: Shubhrajyoti D
> Signed-off-by: Vikram Pandita
> Si
> (Of course, I'm rather doubtful that NASA would ever be willing to use
> Linux on something like the Curiosity Mars Rover, but I could imagine
> Linux being used in a non-mission critcal system on the ISS)
GOAS, RACSI... not entirely non-mission critical stuff either.
And the ST8 project co
From: "John W. Linville"
Date: Fri, 24 Aug 2012 12:13:31 -0400
> This batch of fixes is intended for 3.6...
>
> Johannes Berg gives us a pair of iwlwifi fixes. One corrects some
> improperly defined ifdefs that lead to crashes and BUG_ONs. The other
> prevents attempts to read SRAM for devices
Hi,
I'm sending an email to discuss how to remove spinlock from a whole process of
open/read/close of efi_pstore.
[Problem]
Current efi_pstore calls kmalloc() in a read callback while holding a spinlock,
efivar->lock, in an open callback.
This means efi_pstore may deadlock if it sleeps in kmal
In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
statement.
In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
but selects USB_SUPPORT which leads to the error for udl Kconfig:
$ yes "" | make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drive
The qxl-virtio driver implements a QXL driver using VirtIO as transport, thus
enabling the use of QXL/Spice in non-PCI architectures. In the actual QXL
driver, all communication between Host and Guest is done through PCI shared
memory.
Signed-off-by: Erlon R. Cruz
Signed-off-by: Fabiano Fidêncio
Some useless troll said:
> nouveau is useless garbage as most open source graphics drivers.
Coming to an open source mailing list like LKML just to bitch about open
source being garbage? Come on...at least entertain us with better
subtlety.
I'm ready to ignore this guy, how about everyone else?
On Wed, Aug 22, 2012 at 09:26:41AM +0200, Rene Buergel wrote:
>
> > > - Although i removed the dependency from ezusb to usb_serial,
> > > ezusb.c still resides in drivers/usb/serial.
> > > Can you give me a hint, where to put it instead?
> > > I would like to do that with an additional patch
On Thu, Aug 23, 2012 at 1:34 PM, John Drescher wrote:
> Over the last few weeks I have done some reliability testing with
> mdraid6 on a machine with 2 lsi mptsas controllers and 13 SATA I
> drives. My testing involved physically hot removing a drive forcing
> the raid to grab a spare and rebuild.
On Fri, Aug 24, 2012 at 11:31 AM, Justin Piszcz wrote:
> Hello,
>
> Thoughts?
..
Going back to XFS.
EXT4 appears unstable after more than 16TB is on the array (of 60TB ext4fs).
Justin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
ESA has the Leon series (SPARC)...
Theodore Ts'o wrote:
>On Fri, Aug 24, 2012 at 11:17:20AM -0700, H. Peter Anvin wrote:
>>
>> Speaking as one of the x86 maintainers... we are currently deciding
>the
>> cost/benefit tradeoff around removing i386 support. I don't mean
>> general x86-32 support,
Heh... I just read about Android Nexus One phones being used as satellite
controllers.
Theodore Ts'o wrote:
>On Fri, Aug 24, 2012 at 11:17:20AM -0700, H. Peter Anvin wrote:
>>
>> Speaking as one of the x86 maintainers... we are currently deciding
>the
>> cost/benefit tradeoff around removing i
* Felipe Balbi [120823 03:38]:
> nobody needs to access the uart_omap_port structure
> other than omap-serial.c file. Let's move that
> structure definition to the C source file in order
> to prevent anyone from accessing our structure.
>
> Tested-by: Shubhrajyoti D
> Signed-off-by: Felipe Balbi
>>> On 24.08.12 at 20:17, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 24, 2012 at 04:16:39PM +0100, Jan Beulich wrote:
>> >>> On 24.08.12 at 10:55, Alex Shi wrote:
>> > While TLB_FLUSH_ALL gets passed as 'end' argument to
>> > flush_tlb_others(), the Xen code was made to check its 'start'
>> > par
On 08/23/2012 10:04 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Thu, Aug 23, 2012 at 02:24:32AM +0200, Sasha Levin wrote:
>>> I think the almost trivial nature of hlist hashtables makes this a bit
>>> tricky and I'm not very sure but having this combinatory explosion is
>>> a bit dazzling when the
On Friday 24 August 2012 20:59:33 wbrana wrote:
> On 8/24/12, Martin Nybo Andersen wrote:
> > I want to use *my* old machines (hey, I payed for them) on whatever new
> > hardware I can plug into them. I'm not an oracle and can't see into the
> > future, however USB has evolved, for instance, and w
> And, btw, maybe I didn't catch this earlier, but why is in all
> user-visible options the thing called "cpu0_*"? Wouldn't it be better
> to
> call it "bsp_*"?
The kernel parameter was called bsp_hotplug before. It was changed to
cpu0_hotplug in v5 to keep uniform cpu0/CPU0 names.
Thanks.
-Fen
On Fri, Aug 24, 2012 at 11:05:05AM +0100, Catalin Marinas wrote:
> On Fri, Aug 24, 2012 at 01:52:50AM +0100, Michael Wang wrote:
> > On 08/17/2012 12:33 PM, Michael Wang wrote:
> > > From: Michael Wang
> > >
> > > This patch replaces list_for_each_continue_rcu() with
> > > list_for_each_entry_con
On 08/24/2012 10:24 AM, Arend van Spriel wrote:
On 08/23/2012 04:58 PM, Aaron Lu wrote:
On Wed, Aug 22, 2012 at 10:11 PM, Arend van Spriel
wrote:
A quick search using google did not provide clues. Regardless if
there is
anything inserted the hang occurs.
Gr. AvS
Also, your .config might be
Hi guys,
I've been looking for some particular email in my mailbox when
found the patch below (it's dated as August 2011 ;) and think
it's still valid for kernel. Actually there were two patches,
and the second patch was unifying x86-32 with x86-64 but it
was doable as far as I remember.
Anyway,
Hello, Sasha.
On Fri, Aug 24, 2012 at 09:47:19PM +0200, Sasha Levin wrote:
> > I think this is problematic. It looks exactly like other existing
> > DEFINE macros yet what its semantics is different. I don't think
> > that's a good idea.
>
> I can switch that to be DECLARE_HASHTABLE() if the is
On Fri, Aug 24, 2012 at 08:13:58PM +0100, Alan Cox wrote:
> > (Of course, I'm rather doubtful that NASA would ever be willing to use
> > Linux on something like the Curiosity Mars Rover, but I could imagine
> > Linux being used in a non-mission critcal system on the ISS)
>
> GOAS, RACSI... not
On Fri, Aug 24, 2012 at 11:58:47PM +0400, Cyrill Gorcunov wrote:
...
>
> Signed-off-by: Ian Campbell
Crap, forgot to CC Ian. Sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger
* Arnd Bergmann [120807 02:21]:
> On Tuesday 07 August 2012, Balaji T K wrote:
> >
> > Add OMAP MMC related device tree data for OMAP5.
> >
> > Signed-off-by: Balaji T K
> > ---
>
> Acked-by: Arnd Bergmann
Applying this into omap devel-dt branch.
Tony
--
To unsubscribe from this list: send
On Fri, Aug 24, 2012 at 03:58:56PM -0400, Theodore Ts'o wrote:
> BTW, it turns out I was wrong about Linux being used on Mars.
> Apparently Linux was used on the Mars Global Surveyor, as well as the
> Sprit and Opportunity rovers
citation? My recollection was that they were running VxWorks.
* Vaibhav Hiremath [120815 04:24]:
> Ideally in common SoC dtsi file should set all modules
> to "disabled" state and it should get enabled in respective
> EVM/Board dts file as per usage.
>
> This patch sets default status of all modules to "disabled"
> state in am33xx.dtsi file. Currently there
* Felipe Balbi [120823 03:37]:
> current code only works because struct uart_port
> is the first member on the uart_omap_port structure.
>
> If, for whatever reason, someone puts another
> member as the first of the structure, that cast
> won't work anymore. In order to be safe, let's use
> a con
Hello,
On Thu, Aug 23, 2012 at 10:04:00PM -0700, Kent Overstreet wrote:
> > > struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct
> > > bio_set *bs)
> > > {
> > > + unsigned front_pad;
> > > + unsigned inline_vecs;
> > > unsigned long idx = BIO_POOL_NONE;
> > > struct bio_vec
On Fri, 24 Aug 2012, Stefano Stabellini wrote:
> On Fri, 24 Aug 2012, Thomas Gleixner wrote:
> > And how exactly are they allocated between from pgt_buf w/o increasing
> > pgt_buf_end ?
>
> So let's suppose that we change the check in mask_rw_pte to be:
>
> pfn >= pgt_buf_start && pfn < pgt_buf_e
On 08/24/2012 09:59 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Fri, Aug 24, 2012 at 09:47:19PM +0200, Sasha Levin wrote:
>>> I think this is problematic. It looks exactly like other existing
>>> DEFINE macros yet what its semantics is different. I don't think
>>> that's a good idea.
>>
>> I can
On Fri, Aug 24, 2012 at 04:06:42PM -0400, Dave Jones wrote:
> On Fri, Aug 24, 2012 at 03:58:56PM -0400, Theodore Ts'o wrote:
>
> > BTW, it turns out I was wrong about Linux being used on Mars.
> > Apparently Linux was used on the Mars Global Surveyor, as well as the
> > Sprit and Opportunity ro
Hello,
On Thu, Aug 23, 2012 at 10:55:54PM -0700, Kent Overstreet wrote:
> > Why aren't we turning off __GFP_WAIT instead? e.g. What if the caller
> > has one of NUMA flags or __GFP_COLD specified?
>
> Didn't think of that. The reason I did it that way is I wasn't sure if
> just doing &= ~__GFP_W
On Fri, Aug 24, 2012 at 9:12 AM, Dave Airlie wrote:
> On Fri, Aug 24, 2012 at 5:13 PM, Jani Nikula wrote:
>> On Fri, 24 Aug 2012, Stephen Rothwell wrote:
>>> Hi Dave,
>>>
>>> Today's linux-next merge of the drm tree got a conflict in
>>> drivers/gpu/drm/i915/intel_modes.c between commit 4eab8136
Hello, Sasha.
On Fri, Aug 24, 2012 at 10:11:55PM +0200, Sasha Levin wrote:
> > If this implementation is about the common trivial case, why not just
> > have the usual DECLARE/DEFINE_HASHTABLE() combination?
>
> When we add the dynamic non-resizable support, how would DEFINE_HASHTABLE()
> look?
Hello,
On Thu, Aug 23, 2012 at 11:24:18PM -0700, Kent Overstreet wrote:
> > I'd prefer simply adding @bioset to bio_clone() so that the caller
> > always has to make the choice consciously. We're updating all the
> > callers anyway.
>
> Possibly, but the btrfs code uses bio_clone() and there fs_
* Arnd Bergmann [120823 10:27]:
> On Thursday 23 August 2012, Arnd Bergmann wrote:
> > On Wednesday 22 August 2012, Russell King - ARM Linux wrote:
> > > In any case, what we should be doing here as well is moving the headers
> > > included by drivers for platform data out of the arch/arm/mach/ su
On 12.08.24, Theodore Ts'o wrote:
> Random question. As I recall the Space Shuttle and the International
> Space Station was only using 80386's because they have to be hardened
> against radiation/cosmic rays, as well as all of the other mechnical
> and thermal stresses associated with being in a
Hello, Kent.
On Fri, Aug 24, 2012 at 12:05:08AM -0700, Kent Overstreet wrote:
> > I'm pretty sure I sound like a broken record by now, but
> >
> > * How was this tested?
> >
> > * What are the implications and possible dangers?
>
> I've said all that on list, but I gather what you really wanted
On 08/24/2012 01:25 PM, Borislav Petkov wrote:
> On Fri, Aug 24, 2012 at 04:06:42PM -0400, Dave Jones wrote:
>> On Fri, Aug 24, 2012 at 03:58:56PM -0400, Theodore Ts'o wrote:
>>
>> > BTW, it turns out I was wrong about Linux being used on Mars.
>> > Apparently Linux was used on the Mars Global Su
On Thu, Aug 23, 2012 at 05:26:10PM +, Arnd Bergmann wrote:
> On Thursday 23 August 2012, Arnd Bergmann wrote:
> > On Wednesday 22 August 2012, Russell King - ARM Linux wrote:
> > > In any case, what we should be doing here as well is moving the headers
> > > included by drivers for platform dat
On Fri, Aug 24, 2012 at 02:57:41PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 24, 2012 at 11:17:20AM -0700, H. Peter Anvin wrote:
> >
> > Speaking as one of the x86 maintainers... we are currently deciding the
> > cost/benefit tradeoff around removing i386 support. I don't mean
> > general x86-32
On Thu, Aug 23, 2012 at 11:35:11AM +, Arnd Bergmann wrote:
> About two third of the platform header files included in device drivers
> are not related to platform_data according to what I found. Most of them
> are also wrong (hardcoding interrupt numbers or addresses, headers
> included by acci
Hello,
On Fri, Aug 24, 2012 at 03:30:49AM -0700, Kent Overstreet wrote:
> > I complained about this in the last posting and in the previous patch.
> > Please respond. Martin, are you okay with these integrity changes?
>
> I did respond. I said more before, but in short the old
> bio_integrity_sp
On 08/24/2012 10:33 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Fri, Aug 24, 2012 at 10:11:55PM +0200, Sasha Levin wrote:
>>> If this implementation is about the common trivial case, why not just
>>> have the usual DECLARE/DEFINE_HASHTABLE() combination?
>>
>> When we add the dynamic non-resizable
On 08/23/2012 06:28 PM, Minchan Kim wrote:
> Okay, then, why do you think the patchsets are culprit?
> I didn't look the cleanup patch series of Xiao at that time
> so I can be wrong but as I just look through patch of
> "zcache: optimize zcache_do_preload", I can't find any fault
> because zcache_
Hello, Martin.
On Thu, Aug 23, 2012 at 10:25:47PM -0400, Martin K. Petersen wrote:
> However, I'm not sure I like the overall approach of the new splitting.
> Instead of all this cloning, slicing and dicing of bio_vecs I'd rather
> we bit the bullet and had an offset + length for the vector inside
Added CPU hot-remove support through an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
serializes hot-remove operations between ACPI hot-remove and sysfs
eject requests.
v2:
- Rebased to 3.
On Tue, 21 Aug 2012 10:23:54 -0400
Alexandre Bounine wrote:
> Modify mport device name assignment to provide clear reference to devices
> in systems with multiple Tsi721 bridges.
>
> This patch is applicable to kernel versions starting from v3.2.
This seems to imply that you think the patch sho
On Tue, 21 Aug 2012 10:23:55 -0400
Alexandre Bounine wrote:
> Modify RIO enumeration to apply RX/TX enable operations only to active
> switch ports. This will leave inactive ports in condition consistent with
> their state.
It's unclear (to me) what the effects of this are. Does it fix some
use
On Fri, 17 Aug 2012 21:18:37 -0400
Ed Cashin wrote:
> --- a/drivers/block/aoe/aoeblk.c
> +++ b/drivers/block/aoe/aoeblk.c
> @@ -279,6 +279,9 @@ aoeblk_gdalloc(void *vp)
> if (bdi_init(&d->blkq->backing_dev_info))
> goto err_blkq;
> spin_lock_irqsave(&d->lock, flags);
> +
Add support for disabling swiotlb overflow buffer using zero size swiotlb
overflow buffer to help test disable overflow scenarios to find drivers that
don't check dma mapping errors. Add kernel error message to track overflow
buffer triggers to understand how often overflow buffer gets used. Add
de
These patches are against tip/x86/fpu. Few cleanups and more improtantly
this series introduces the non-lazy FPU restore mechanism for processors
supporting xsave feature. More details in the individual patch changelogs.
Thanks.
Suresh Siddha (6):
x86, fpu: drop_fpu() before restoring new state
Few lines below we do drop_fpu() which is more safer. Remove the
unnecessary user_fpu_end() in save_xstate_sig(), which allows
the drop_fpu() to ignore any pending exceptions from the user-space
and drop the current fpu.
Signed-off-by: Suresh Siddha
---
arch/x86/include/asm/fpu-internal.h | 17
Instead of using unlazy_fpu() check if user_has_fpu() and set/clear
the host TS bits so that the lguest works fine with both the
lazy/non-lazy FPU host models with minimal changes.
Signed-off-by: Suresh Siddha
Cc: Rusty Russell
---
drivers/lguest/x86/core.c | 10 +++---
1 files changed, 7
Fundamental model of the current Linux kernel is to lazily init and
restore FPU instead of restoring the task state during context switch.
This changes that fundamental lazy model to the non-lazy model for
the processors supporting xsave feature.
Reasons driving this model change are:
i. Newer pr
use kernel_fpu_begin/end() instead of unconditionally accessing cr0 and
saving/restoring just the few used xmm/ymm registers.
This has some advantages like:
* If the task's FPU state is already active, then kernel_fpu_begin()
will just save the user-state and avoiding the read/write of cr0.
In
kvm's guest fpu save/restore should be wrapped around
kernel_fpu_begin/end(). This will avoid for example taking a DNA
in kvm_load_guest_fpu() when it tries to load the fpu immediately
after doing unlazy_fpu() on the host side.
More importantly this will prevent the host process fpu from being
cor
No need to save the state with unlazy_fpu(), that is about to get overwritten
by the state from the signal frame. Instead use drop_fpu() and continue
to restore the new state.
Also fold the stop_fpu_preload() into drop_fpu().
Signed-off-by: Suresh Siddha
---
arch/x86/include/asm/fpu-internal.h
On Fri, 17 Aug 2012 21:24:08 -0400
Ed Cashin wrote:
> This patch makes the frames the aoe driver uses to track the
> relationship between bios and packets more flexible and detached, so
> that they can be passed to an "aoe_ktio" thread for completion of I/O.
>
> The frames are handled much like
Hello,
On Fri, Aug 24, 2012 at 10:53:45PM +0200, Sasha Levin wrote:
> Yup, but we could be using the same API for dynamic non-resizable and static
> if
> we go with the DECLARE/hash_init. We could switch between them (and other
> implementations) without having to change the code.
I think it's b
* Felipe Balbi [120823 03:37]:
> The driver doesn't need to know about its platform_device.
>
> Everything the driver needs can be done through the
> struct device pointer. In case we need to use the
> OMAP-specific PM function pointers, those can make
> sure to find the device's platform_device
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> Hi,
>
> Changes since v1:
>
> - Fixed preempt handling in alpha idle loop
> - added ack from Geert
> - fixed stable email address, sorry :-/
>
> This time I built tested everywhere but: h8300 (compiler internal error),
> and
On Fri, Aug 24, 2012 at 9:08 PM, Josh Boyer wrote:
> Hi All,
>
> We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> working with 3.6-rc3. It seems the last working kernel was based on
> commit 10c63c9, and it first stopped working with a kernel based on
> commit 23dcfa6.
I have applied this to tip:x86/fpu, but I have also asked Suresh to
prepare a followon patch to decouple eager save from the existence of
the XSAVE instruction. It seems pretty clear that eager save is a net
benefit in the presence of the XSAVEOPT, but it isn't as clear for only
having XSAVE, as f
On Fri, Aug 24, 2012 at 11:45:45AM -0500, Nathan Zimmer wrote:
> On 08/24/2012 09:58 AM, Eric Dumazet wrote:
>> Le vendredi 24 août 2012 à 09:48 -0500, Nathan Zimmer a écrit :
>>> On Wed, Aug 22, 2012 at 11:42:58PM +0200, Eric Dumazet wrote:
On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrot
On 08/15/2012 10:28 AM, Stephen Warren wrote:
> From: Gyungoh Yoo
>
> The MAX8907 is an I2C-based power-management IC containing voltage
> regulators, a reset controller, a real-time clock, and a touch-screen
> controller.
Samuel,
Does this look OK now? (although you're probably traveling to a
On Fri, 24 Aug 2012 22:37:55 +0800
Wanpeng Li wrote:
> From: Gavin Shan
>
> While registering MMU notifier, new instance of MMU notifier_mm will
> be allocated and later free'd if currrent mm_struct's MMU notifier_mm
> has been initialized. That cause some overhead. The patch tries to
> elemina
Hello,
On Thu, Aug 23, 2012 at 04:31:43PM -0400, Naoya Horiguchi wrote:
> On Thu, Aug 23, 2012 at 05:11:25PM +0800, Fengguang Wu wrote:
> > On Wed, Aug 22, 2012 at 11:17:35AM -0400, Naoya Horiguchi wrote:
...
> > > diff --git v3.6-rc1.orig/fs/inode.c v3.6-rc1/fs/inode.c
> > > index ac8d904..874239
Hello Kurt,
On Fri, Aug 24, 2012 at 02:42:48PM +0200, Kurt Van Dijck wrote:
> On Fri, Aug 24, 2012 at 01:28:16PM +0200, Marc Kleine-Budde wrote:
> > On 08/24/2012 07:10 AM, Kurt Van Dijck wrote:
> > > Hello,
> > >
> > > I find the CAN led triggers an interesting thing.
> > >
> > > And then, this
On Thu, 23 Aug 2012 18:36:02 +0100
Will Deacon wrote:
> On Thu, Aug 23, 2012 at 06:11:56PM +0100, Michal Hocko wrote:
> > On Thu 23-08-12 17:37:13, Will Deacon wrote:
> > > The core page allocator ensures that page flags are zeroed when freeing
> > > pages via free_pages_check. A number of archit
On Thu, 23 Aug 2012 19:36:08 +0400
Glauber Costa wrote:
> When we want to duplicate a new process, dup_task_struct() will undergo
> a series of allocations. If alloc_thread_info_node() fails, we call
> free_task_struct() and return.
>
> This seems right, but it is not. free_task_struct() will no
301 - 400 of 483 matches
Mail list logo
