On Mon, 2012-07-09 at 11:11 +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8106e-1.fw
> Version: 0.0.1
[...]
As someone already pointed out, this message was not correctly encoded.
The character encoding was specified as an empty string
(Content-Encoding header) or whitespace (Subject):
>
This is now pretty straightforward: instead of using bool, just pass
an integer. For backwards compatibility ramoops.ecc=1 means 16 bytes
ECC (using 1 byte for ECC isn't much of use anyway).
Suggested-by: Arve Hjønnevåg
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram.c| 22
Nowadays we can use prz->ecc_size as a flag, no need for the special
member in the prz struct.
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram_core.c | 10 --
include/linux/pstore_ram.h |1 -
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git
The struct members were never used anywhere outside of
persistent_ram_init_ecc(), so there's actually no need for them
to be in the struct.
If we ever want to make polynomial or symbol size configurable,
it would make more sense to just pass initialized rs_decoder
to the persistent_ram init
Please ignore,
It is sent by mistake. :(
Sorry for the noise.
On Tue, Jul 10, 2012 at 08:55:53AM +0900, Minchan Kim wrote:
> Since lumpy reclaim was introduced at 2.6.23, it helped higher
> order allocation.
> Recently, we removed it at 3.4 and we didn't enable compaction
> forcingly[1]. The
From: Ben Hutchings
Date: Tue, 10 Jul 2012 00:47:06 +0100
> I built on x86_64...
As did I :-)
> But it's not an important bug in mainline (yet) so perhaps we can treat
> it as only required in stable.
I think this is the best thing to do for now.
--
To unsubscribe from this list: send the
On Mon, Jul 09, 2012 at 04:45:59PM -0700, Anton Vorontsov wrote:
> Hi all,
>
> Just a few patches left from the series that used to add configurable
> ECC size for pstore/ram backend. Most patches were merged into -next,
> and this is just a resend of the leftovers.
Oh, I fogot: actually, it's
On Mon, 2012-07-09 at 11:11 +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8411-1.fw
> Version: 0.0.3
[...]
Applied.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
On Mon, 2012-07-09 at 11:11 +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8168f-1.fw
> Version: 0.0.5
[...]
Applied.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
On Mon, 9 Jul 2012, Will Deacon wrote:
> On Mon, Jul 09, 2012 at 01:25:23PM +0100, Michal Hocko wrote:
> > On Wed 04-07-12 15:32:56, Will Deacon wrote:
> > > When allocating and returning clear huge pages to userspace as a
> > > response to a fault, we may zero and return a mapping to a previously
Since lumpy reclaim was introduced at 2.6.23, it helped higher
order allocation.
Recently, we removed it at 3.4 and we didn't enable compaction
forcingly[1]. The reason makes sense that compaction.o + migration.o
isn't trivial for system doesn't use higher order allocation.
But the problem is that
On Mon, Jul 9, 2012 at 3:21 PM, Bjorn Helgaas wrote:
> What bad things would happen if I just appended your patch to the end
> of this series? Would that break bisection in some scenario?
Should be ok. it should not break bisection.
Don't think sizing is working for 1k before.
Thanks
Yinghai
Hi all,
Just a few patches left from the series that used to add configurable
ECC size for pstore/ram backend. Most patches were merged into -next,
and this is just a resend of the leftovers.
(Note that pstore/trace patches go on top of this series.)
Thanks,
---
fs/pstore/ram.c|
On Mon, 9 Jul 2012, Joe Perches wrote:
> > So, nack, don't start enforcing your own coding style and preferences in
> > checkpatch.pl.
>
> Not just my opinion.
>
> https://lkml.org/lkml/2008/12/23/138
>
> Date: Tue, 23 Dec 2008 10:08:50
On Mon, 2012-07-09 at 20:39 -0300, Herton Ronaldo Krzesinski wrote:
> On Mon, Jul 09, 2012 at 03:31:51PM +0100, Ben Hutchings wrote:
> > 3.2-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Eric Dumazet
> >
> > [ Upstream commit
On Wed, Jun 27, 2012 at 08:40:12AM -0400, Steven Rostedt wrote:
> On Tue, 2012-06-26 at 16:23 -0700, Anton Vorontsov wrote:
> > @@ -219,6 +232,8 @@ static int func_set_flag(u32 old_flags, u32 bit, int
> > set)
> >
> > return 0;
> > }
> > + if (bit == TRACE_FUNC_OPT_PSTORE)
> >
Quoting Andrew Morton (a...@linux-foundation.org):
> On Fri, 6 Jul 2012 13:09:07 +0400
> Glauber Costa wrote:
>
> > When we change the namespace tag of a sysfs entry, the associated dentry
> > is still kept around. readdir() will work correctly and not display the
> > old entries, but open()
On Mon, 2012-07-09 at 16:32 -0700, Joe Perches wrote:
> Then you've changed semantics and I think you need to
> fix it.
>
> A dev_ call is not guaranteed to be a complete
> message.
>
> There are dev_ and netdev_ calls
> followed by pr_cont.
>
> Maybe these could be fixed up and then they could
On Mon, 9 Jul 2012 15:35:26 -0700 (PDT)
Hugh Dickins wrote:
> Here's three little shmem/tmpfs patches against v3.5-rc6.
> Either the first should go in before v3.5 final, or it should not go
> in at all. The second and third are independent of it: I'd like them
> in v3.5, but don't have a
On Mon, Jul 09, 2012 at 03:31:51PM +0100, Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Eric Dumazet
>
> [ Upstream commit 16b0dc29c1af9df341428f4c49ada4f626258082 ]
>
> Trying to "modprobe dummy
include/linux/rbtree.h included some basic usage instructions, while
Documentation/rbtree.txt had some more complete and easier to follow
instructions. Replacing the former with a reference to the latter.
Signed-off-by: Michel Lespinasse
---
include/linux/rbtree.h | 67
The recently added code to use rbtrees in sysctl did not follow the proper
rbtree interface on insertion - it was calling rb_link_node() which
inserts a new node into the binary tree, but missed the call to
rb_insert_color() which properly balances the rbtree and establishes all
expected rbtree
This small module helps measure the performance of rbtree insert and erase.
Additionally, we run a few correctness tests to check that the rbtrees have
all desired properties:
- contains the right number of nodes in the order desired,
- never two consecutive red nodes on any path,
- all paths to
The root node of an rbtree must always be black. However, rb_insert_color()
only needs to maintain this invariant when it has been broken - that is,
when it exits the loop due to the current (red) node being the root.
In all other cases (exiting after tree rotations, or exiting due to
an existing
- Use the newly introduced rb_set_parent_color() function to flip the color
of nodes whose parent is already known.
- Optimize rb_parent() when the node is known to be red - there is no need
to mask out the color in that case.
- Flipping gparent's color to red requires us to fetch its
rbtree users must use the documented APIs to manipulate the tree
structure. Low-level helpers to manipulate node colors and parenthood
are not part of that API, so move them to lib/rbtree.c
Signed-off-by: Michel Lespinasse
---
include/linux/rbtree.h | 16
lib/rbtree.c
Empty nodes have no color. We can make use of this property to
simplify the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE
macros. Also, we can get rid of the rb_init_node function which had
been introduced by commit 88d19cf37952a7e1e38b2bf87a00f0e857e63180
to avoid some issue with the
In __rb_erase_color(), we often already have pointers to the nodes
being rotated and/or know what their colors must be, so we can
generate more efficient code than the generic __rb_rotate_left()
and __rb_rotate_right() functions.
Signed-off-by: Michel Lespinasse
---
lib/rbtree.c | 154
In __rb_erase_color(), when the current node is red or when flipping
the sibling's color, the parent is already known so we can use the
more efficient rb_set_parent_color() function to set the desired color.
Signed-off-by: Michel Lespinasse
---
lib/rbtree.c | 10 +-
1 files changed, 5
In __rb_erase_color(), we have to select one of 3 cases depending on the
color on the 'other' node children. If both children are black, we flip
a few node colors and iterate. Otherwise, we do either one or two
tree rotations, depending on the color of the 'other' child opposite
to 'node', and
In rb_insert_color(), we can do better than calling __rb_rotate_left()
and __rb_rotate_right() to handle tree rotations: we already have
pointers to all relevant nodes, and know their colors (either because
we want to adjust it, or because we've tested it, or we can deduce it
as black due to the
In __rb_erase_color(), we were always setting a node to black after
exiting the main loop. And in one case, after fixing up the tree to
satisfy all rbtree invariants, we were setting the current node to root
just to guarantee a loop exit, at which point the root would be set to
black. However this
It is a well known property of rbtrees that insertion never requires
more than two tree rotations. In our implementation, after one loop
iteration identified one or two necessary tree rotations, we would iterate
and look for more. However at that point the node's parent would always
be black,
I recently started looking at the rbtree code (with an eye towards
improving the augmented rbtree support, but I haven't gotten there
yet). I noticed a lot of possible speed improvements, which I am now
proposing in this patch set.
Patches 1-4 are preparatory: remove internal functions from
No problem :-)
On Tue, Jul 10, 2012 at 4:33 AM, Greg KH wrote:
> On Sun, Jul 08, 2012 at 06:25:47PM +0900, Toshiaki Yamane wrote:
>> This change is inspired by checkpatch.
>>
>> Signed-off-by: Toshiaki Yamane
>> ---
>> drivers/staging/asus_oled/asus_oled.c |6 +++---
>> 1 files changed, 3
On Tue, 2012-07-10 at 00:40 +0200, Kay Sievers wrote:
> On Tue, Jul 10, 2012 at 12:29 AM, Joe Perches wrote:
> > On Tue, 2012-07-10 at 00:10 +0200, Kay Sievers wrote:
> >> On Mon, Jul 9, 2012 at 11:42 PM, Joe Perches wrote:
> >> > On Sun, 2012-07-08 at 19:55 +0200, Kay Sievers wrote:
> >> >
> >>
On Mon, 2012-07-09 at 15:55 -0700, David Rientjes wrote:
> So, nack, don't start enforcing your own coding style and preferences in
> checkpatch.pl.
Not just my opinion.
https://lkml.org/lkml/2008/12/23/138
Date: Tue, 23 Dec 2008 10:08:50
(sorry, keyboard splat)
On Tuesday, July 10, 2012 01:01:31 AM Andrew Morton wrote:
> On Tue, 10 Jul 2012 00:54:54 +0200
> Christian Lamparter wrote:
> > On Monday, July 09, 2012 11:59:39 PM Andrew Morton wrote:
> > > On Fri, 6 Jul 2012 14:30:16 -0700
> > > Greg KH wrote:
> > >
> > > > On Fri,
On Fri, 6 Jul 2012 13:09:07 +0400
Glauber Costa wrote:
> When we change the namespace tag of a sysfs entry, the associated dentry
> is still kept around. readdir() will work correctly and not display the
> old entries, but open() will still succeed, so will reads and writes.
>
> This will no
On Tuesday, July 10, 2012 01:01:31 AM Andrew Morton wrote:
> On Tue, 10 Jul 2012 00:54:54 +0200
> Christian Lamparter wrote:
>
> > On Monday, July 09, 2012 11:59:39 PM Andrew Morton wrote:
> > > On Fri, 6 Jul 2012 14:30:16 -0700
> > > Greg KH wrote:
> > >
> > > > On Fri, Jul 06, 2012 at
On Tue, 10 Jul 2012 00:54:54 +0200
Christian Lamparter wrote:
> On Monday, July 09, 2012 11:59:39 PM Andrew Morton wrote:
> > On Fri, 6 Jul 2012 14:30:16 -0700
> > Greg KH wrote:
> >
> > > On Fri, Jul 06, 2012 at 11:23:52PM +0200, Christian Lamparter wrote:
> > > > The idea of moving rebind
On Mon, Jul 09 2012 at 10:57am -0400,
Mike Snitzer wrote:
> blk_set_stacking_limits() is intended to allow stacking drivers to build
> up the limits of the stacked device based on the underlying devices'
> limits. But in the case of 'max_sectors' the default of
> BLK_DEF_MAX_SECTORS (1024)
On Mon, 9 Jul 2012, Joe Perches wrote:
> Huh? Maybe I misunderstand you.
>
> $ cat sizeof.c
> #include
> #include
> #include
>
> struct foo {
> int bar[20];
> char *baz;
> };
>
> int main(int argc, char **argv)
> {
> struct foo bar;
> struct foo *baz;
>
>
On Monday, July 09, 2012 11:59:39 PM Andrew Morton wrote:
> On Fri, 6 Jul 2012 14:30:16 -0700
> Greg KH wrote:
>
> > On Fri, Jul 06, 2012 at 11:23:52PM +0200, Christian Lamparter wrote:
> > > The idea of moving rebind procedure into pm.complete
> > > was taken from the usb-subsystem, which has
shmem_add_to_page_cache() has three callsites, but only one of them
wants the radix_tree_preload() (an exceptional entry guarantees that
the radix tree node is present in the other cases), and only that site
can achieve mem_cgroup_uncharge_cache_page() (PageSwapCache makes it a
no-op in the other
Most of the DRM drivers appear to be missing the .compat_ioctl file
operation entry necessary for 32-bit application compatibility.
This patch uses drm_compat_ioctl for all drivers which don't have
their own, and which are using drm_ioctl for .unlocked_ioctl.
This leaves
When adding the page_private checks before calling shmem_replace_page(),
I did realize that there is a further race, but thought it too unlikely
to need a hurried fix.
But independently I've been chasing why a mem cgroup's memory.stat
sometimes shows negative rss after all tasks have gone: I
Revert 4fb5ef089b28 ("tmpfs: support SEEK_DATA and SEEK_HOLE").
I believe it's correct, and it's been nice to have from rc1 to rc6;
but as the original commit said:
I don't know who actually uses SEEK_DATA or SEEK_HOLE, and whether it
would be of any use to them on tmpfs. This code adds 92 lines
On Mon, 9 Jul 2012 23:13:50 +0900
JoonSoo Kim wrote:
> >> In my kernel image, __alloc_pages_direct_compact() is not inlined by gcc.
My gcc-4.4.4 doesn't inline it either.
> I think __alloc_pages_direct_compact() can't be inlined by gcc,
> because it is so big and is invoked two times in
On Tue, Jul 10, 2012 at 12:29 AM, Joe Perches wrote:
> On Tue, 2012-07-10 at 00:10 +0200, Kay Sievers wrote:
>> On Mon, Jul 9, 2012 at 11:42 PM, Joe Perches wrote:
>> > On Sun, 2012-07-08 at 19:55 +0200, Kay Sievers wrote:
>> >
>> >> At the same time the CPU#2 prints the same warning with a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/09/2012 05:34 PM, vgo...@redhat.com wrote:
> Phillip, do let me know if I should put your signed-off-by also in the
> patch.
Sure, kernel side looks good. My original util-linux patches also added a -u
update mode to kpartx, which I think is
On 07/09/2012 02:20 AM, Raghavendra K T wrote:
@@ -484,6 +484,13 @@ struct kvm_vcpu_arch {
u64 length;
u64 status;
} osvw;
+
+ /* Pause loop exit optimization */
+ struct {
+ bool pause_loop_exited;
+ bool
On Mon, Jul 9, 2012 at 3:31 PM, Geert Uytterhoeven wrote:
> Hi Bjorn (or Björn?),
>
> On Mon, Jul 9, 2012 at 11:20 PM, Bjorn Helgaas wrote:
>> There are some PCI-related regressions here that I'd like to fix, but
>> I don't know where to start. For example, these:
>>
>>> +
Greg Kroah-Hartman wrote:
> On Sun, Jul 08, 2012 at 07:55:55PM +0200, Kay Sievers wrote:
> > On Sat, 2012-07-07 at 07:04 +1000, Michael Neuling wrote:
> > > Whole kmsg below.
> >
> > I guess I have an idea now what's going on.
> >
> > > 4,47,0;WARNING: at
> > >
On Mon, 2012-07-09 at 15:23 -0700, David Rientjes wrote:
> On Mon, 9 Jul 2012, a...@linux-foundation.org wrote:
>
> > From: Joe Perches
> > Subject: checkpatch: Add acheck for use of sizeof without parenthesis
> >
> > Kernel style uses parenthesis around sizeof.
> >
>
> Nack, there's a
Here's three little shmem/tmpfs patches against v3.5-rc6.
Either the first should go in before v3.5 final, or it should not go
in at all. The second and third are independent of it: I'd like them
in v3.5, but don't have a clinching argument: see what you think.
[PATCH 1/3] tmpfs: revert
On 07/09/2012 02:20 AM, Raghavendra K T wrote:
+bool kvm_arch_vcpu_check_and_update_eligible(struct kvm_vcpu *vcpu)
+{
+ bool eligible;
+
+ eligible = !vcpu->arch.plo.pause_loop_exited ||
+ (vcpu->arch.plo.pause_loop_exited&&
+
On Tue, 2012-07-10 at 00:10 +0200, Kay Sievers wrote:
> On Mon, Jul 9, 2012 at 11:42 PM, Joe Perches wrote:
> > On Sun, 2012-07-08 at 19:55 +0200, Kay Sievers wrote:
> >
> >> At the same time the CPU#2 prints the same warning with a continuation
> >> line, but the buffer from CPU#1 can not be
On 07/09/2012 02:20 AM, Raghavendra K T wrote:
Currently Pause Looop Exit (PLE) handler is doing directed yield to a
random VCPU on PL exit. Though we already have filtering while choosing
the candidate to yield_to, we can do better.
Problem is, for large vcpu guests, we have more probability
From: Julia Lawall
Date: Sun, 8 Jul 2012 13:37:43 +0200
> From: Julia Lawall
>
> If list_for_each_entry, etc complete a traversal of the list, the iterator
> variable ends up pointing to an address at an offset from the list head,
> and not a meaningful structure. Thus this value should not
From: Julia Lawall
Date: Sun, 8 Jul 2012 13:37:39 +0200
> From: Julia Lawall
>
> If list_for_each_entry, etc complete a traversal of the list, the iterator
> variable ends up pointing to an address at an offset from the list head,
> and not a meaningful structure. Thus this value should not
From: Julia Lawall
Date: Sun, 8 Jul 2012 13:37:38 +0200
> From: Julia Lawall
>
> If list_for_each_entry, etc complete a traversal of the list, the iterator
> variable ends up pointing to an address at an offset from the list head,
> and not a meaningful structure. Thus this value should not
On Mon, 9 Jul 2012, a...@linux-foundation.org wrote:
> From: Joe Perches
> Subject: checkpatch: Add acheck for use of sizeof without parenthesis
>
> Kernel style uses parenthesis around sizeof.
>
Nack, there's a difference between "sizeof *task" and
"sizeof(struct task_struct)". The former
On Mon, Jul 9, 2012 at 3:43 PM, Yinghai Lu wrote:
> On Mon, Jul 9, 2012 at 1:32 PM, Bjorn Helgaas wrote:
>>
>> Note that the bridge window assignment code, e.g., pbus_size_io(), should
>> pay attention to dev->io_window_1k, too, but I didn't fix that.
>
> Please check attached patch that will
"Steven J. Magnani" writes:
>> Hm, not really, if the file handle is including parent ino. ext2 will
>> get the latest parent ino, because it checks parent of inode of file
>> handle.
>
> Can you point me to the code for this? The code I see looks pretty
> congruent to what I think the FAT code
On Fri, 6 Jul 2012 09:33:54 -0700
Kevin Hilman wrote:
> Requesting a threaded interrupt without a primary handler and without
> IRQF_ONESHOT is dangerous, and after commit 1c6c6952 (genirq: Reject
> bogus threaded irq requests), these requests are rejected. This
> causes ->probe() to fail, and
On Mon, Jul 9, 2012 at 11:42 PM, Joe Perches wrote:
> On Sun, 2012-07-08 at 19:55 +0200, Kay Sievers wrote:
>
>> At the same time the CPU#2 prints the same warning with a continuation
>> line, but the buffer from CPU#1 can not be flushed to the console, nor
>> can the continuation line printk()s
Signed-off-by: Axel Lin
---
drivers/regulator/max8952.c | 59 +++
1 file changed, 4 insertions(+), 55 deletions(-)
diff --git a/drivers/regulator/max8952.c b/drivers/regulator/max8952.c
index ea58a44..355ca7b 100644
--- a/drivers/regulator/max8952.c
+++
Hi,
On Mon, Jul 09, 2012 at 11:39:47AM -0700, Greg KH wrote:
> On Fri, Jul 06, 2012 at 12:40:38PM +0200, Miguel Gómez wrote:
> > The piece of code that checks for LCDA in xgifb_probe() just checks for some
> > register values but doesn't really do anything in response to them (the
> > actions
>
On Tue, 2012-07-10 at 06:34 +0900, OGAWA Hirofumi wrote:
> "Steven J. Magnani" writes:
>
> >> Ah, i_ino. I was talking about i_pos. Well, so, what happens if the
> >> child was renamed to other parent on NFS server machine (not via nfs
> >> client)? The file handle would be including the old
On Fri, 6 Jul 2012 14:30:16 -0700
Greg KH wrote:
> On Fri, Jul 06, 2012 at 11:23:52PM +0200, Christian Lamparter wrote:
> > The idea of moving rebind procedure into pm.complete
> > was taken from the usb-subsystem, which has similar
> > problems with reattaching devices during/after
> > resume.
On Wed, May 30, 2012 at 2:46 AM, Kuninori Morimoto
wrote:
> If driver requests probe deferral,
> it will be added to deferred_probe_pending_list
> by driver_deferred_probe_add(), but, it used list_add().
> Because of that, deferred probe will be run as reversed order.
> This patch uses
On Mon, Jul 9, 2012 at 9:31 PM, Linus Walleij wrote:
> On Mon, Jul 9, 2012 at 1:22 PM, Mark Brown
> wrote:
>
>> Since users must be explicitly provided with a GPIO number in order to
>> request one the overwhelmingly common case for failing to request will
>> be that the required GPIO driver has
From: Gao feng
Date: Mon, 09 Jul 2012 16:15:29 +0800
> 于 2012年07月09日 15:45, Eric Dumazet 写道:
>> From: Eric Dumazet
>>
>> dev->priomap is allocated by extend_netdev_table() called from
>> update_netdev_tables().
>> And this is only called if write_priomap() is called.
>>
>> But if
From: ebied...@xmission.com (Eric W. Biederman)
Date: Mon, 09 Jul 2012 13:52:43 -0700
>
> The bonding debugfs support has been broken in the presence of network
> namespaces since it has been added. The debugfs support does not handle
> multiple bonding devices with the same name in different
From: ebied...@xmission.com (Eric W. Biederman)
Date: Mon, 09 Jul 2012 13:51:45 -0700
>
> It was recently reported that moving a bonding device between network
> namespaces causes warnings from /proc. It turns out after the move we
> were trying to add and to remove the /proc/net/bonding
On Mon, 2012-07-09 at 11:50 +0530, Raghavendra K T wrote:
> Currently Pause Looop Exit (PLE) handler is doing directed yield to a
> random VCPU on PL exit. Though we already have filtering while choosing
> the candidate to yield_to, we can do better.
Hi, Raghu.
> Problem is, for large vcpu
On Mon, Jul 9, 2012 at 1:32 PM, Bjorn Helgaas wrote:
>
> Note that the bridge window assignment code, e.g., pbus_size_io(), should
> pay attention to dev->io_window_1k, too, but I didn't fix that.
Please check attached patch that will fix pbus_size_io.
You may fold the patch in your patch, or
On Sun, 2012-07-08 at 19:55 +0200, Kay Sievers wrote:
> At the same time the CPU#2 prints the same warning with a continuation
> line, but the buffer from CPU#1 can not be flushed to the console, nor
> can the continuation line printk()s from CPU#2 be merged at this point.
> The consoles are
On 07/09/2012 10:54 AM, Jussi Kivilinna wrote:
> Quoting Randy Dunlap :
>
>> On 07/02/2012 12:23 AM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20120629:
>>>
>>
>>
>> on i386:
>>
>>
>> ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined!
>>
>
> This is caused by commit
A simple user space utility to resize an existing partition. It tries to read
the start of partiton from sysfs.
This is a real quick dirty patch I used for my testing. I am sure there
are better and faster ways of getting to partition "start" from device
and partition number.
Signed-off-by:
PCI's final quirks (pci_fixup_final) are currently invoked by
pci_apply_final_quirk() which traverses the platform's list of PCI
devices. The calling mechanism, and to some point the use of the device
list, limits the quirk invocations to a single instance during boot. As
such, hot-plugable
Hi,
Few people have pinged me in rencent past about status of this patch, hence,
this is V4 of patch which adds support for online resizing of a partition.
This patch is based on previously posted patches by Phillip Susi.
There are two patches. Out of which one is kernel patch and other one is
The PCI subsystem's final fixups are executed once during boot, after the
pci-device is found. As long as the system does not support hot-plug,
specifying __init is fine.
With hot-plug, either physically based hot-plug events or pseudo hot-plug
events such as "echo 1 > /sys/bus/pci/rescan", it
PCI's final quirks (pci_fixup_final) are currently invoked by
pci_apply_final_quirk() which traverses the platform's list of PCI
devices. The calling mechanism limits the quirk invocations to a single
instance during boot. As such, hot-plugable devices do not have their
associated final quirks
The PCI subsystem's final fixups are executed once during boot, after the
pci-device is found. As long as the system does not support hot-plug,
specifying __init is fine.
With hot-plug, either physically based hot-plug events or pseudo hot-plug
events such as "echo 1 > /sys/bus/pci/rescan", it
The PCI subsystem's final fixups are executed once during boot, after the
pci-device is found. As long as the system does not support hot-plug,
specifying __init is fine.
With hot-plug, either physically based hot-plug events or pseudo hot-plug
events such as "echo 1 > /sys/bus/pci/rescan", it
The PCI subsystem's final fixups are executed once during boot, after the
pci-device is found. As long as the system does not support hot-plug,
specifying __init is fine.
With hot-plug, either physically based hot-plug events or pseudo hot-plug
events such as "echo 1 > /sys/bus/pci/rescan", it
PCI's quirk types 'pci_fixup_enable', 'pci_fixup_resume',
'pci_fixup_suspend', and 'pci_fixup_resume_early' can not be __init or
__devinit; they must be in normal text because they can be called at any
time.
This patch removes the '__init' section annotation of such quirks.
Signed-off-by: Myron
__nv_msi_ht_cap_quirk() acquires a temporary reference via
'pci_get_bus_and_slot()' that is never released.
This patch releases the temporary reference.
Signed-off-by: Myron Stowe
---
drivers/pci/quirks.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git
It's a bit ugly that we have two possible call sites for the quirk: either
inside do_one_fixup_debug() or directly in pci_do_fixups().
This patch restructures pci_do_fixups()'s quirk invocations in the style
of initcall_debug_start() and initcall_debug_report().
Signed-off-by: Myron Stowe
---
Add a new operation code (BLKPG_RESIZE_PARTITION) to the BLKPG ioctl that
allows altering the size of an existing partition, even if it is currently
in use.
This patch converts hd_struct->nr_sects into sequence counter because
One might extend a partition while IO is happening to it and update
From: Corey Minyard
The macros just called BUG(), but that results in unused variable
warnings all over the place, like in the IPMI driver. The build
regression emails were annoying me, so here's the fix. I have
not even compile tested this, but it's rather obvious.
Signed-off-by: Corey
"Steven J. Magnani" writes:
>> Ah, i_ino. I was talking about i_pos. Well, so, what happens if the
>> child was renamed to other parent on NFS server machine (not via nfs
>> client)? The file handle would be including the old i_ino, and the old
>> i_ino on file handle is still vaild as old
Hi Bjorn (or Björn?),
On Mon, Jul 9, 2012 at 11:20 PM, Bjorn Helgaas wrote:
> There are some PCI-related regressions here that I'd like to fix, but
> I don't know where to start. For example, these:
>
>> + drivers/pci/quirks.c: error: implicit declaration of function 'ioread32'
>>
From: "John W. Linville"
Date: Mon, 9 Jul 2012 15:28:18 -0400
> Please accept these fixes for the 3.5 stream...
Pulled, thanks John.
--
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
From: Bjorn Helgaas
Date: Mon, 09 Jul 2012 14:32:14 -0600
> The generic code to read P2P bridge windows is functionally equivalent
> to the sparc-specific pci_cfg_fake_ranges(), so use the generic code.
>
> The "if (!res->start) res->start = ..." removed from the I/O window code
> here was an
From: Corey Minyard
The inb/outb macros for CRIS are broken from a number of points of
view, missing () around parameters and they have an unprotected if
statement in them. This was breaking the compile of IPMI on CRIS
and thus I was being annoyed by build regressions, so I fixed them.
Plus I
On 09/07/12 23:03, Linus Walleij wrote:
On Mon, Jul 9, 2012 at 10:59 PM, Lee Jones wrote:
Before we can use any domain allocated IRQ, we need to first create a
map between the Hardware IRQ (hwirq) and the Linux Virtual IRQ (virq).
We do this with a helper function provided by the AB8500 IRQ
Hi Geert,
There are some PCI-related regressions here that I'd like to fix, but
I don't know where to start. For example, these:
> + drivers/pci/quirks.c: error: implicit declaration of function 'ioread32'
> [-Werror=implicit-function-declaration]: => 3154:2
> + drivers/pci/quirks.c:
101 - 200 of 1424 matches
Mail list logo
