* Re: [PATCH v4 1/5] net: Introduce new feature setting ops
From: David Miller @ 2011-02-07 20:51 UTC (permalink / raw)
To: bhutchings; +Cc: mirq-linux, netdev
In-Reply-To: <1297107597.4077.8.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 07 Feb 2011 19:39:57 +0000
> On Thu, 2011-02-03 at 15:21 +0100, Michał Mirosław wrote:
>> This introduces a new framework to handle device features setting.
>> It consists of:
>> - new fields in struct net_device:
>> + hw_features - features that hw/driver supports toggling
>> + wanted_features - features that user wants enabled, when possible
>> - new netdev_ops:
>> + feat = ndo_fix_features(dev, feat) - API checking constraints for
>> enabling features or their combinations
>> + ndo_set_features(dev) - API updating hardware state to match
>> changed dev->features
>> - new ethtool commands:
>> + ETHTOOL_GFEATURES/ETHTOOL_SFEATURES: get/set dev->wanted_features
>> and trigger device reconfiguration if resulting dev->features
>> changed
>> + ETHTOOL_GSTRINGS(ETH_SS_FEATURES): get feature bits names (meaning)
>>
>> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: Xtables2 A7 spec draft
From: James Nurmi @ 2011-02-07 20:50 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1102011817480.7729@obet.zrqbmnf.qr>
(inline)
Comments are made as maintainer of GoNetlink, a 'not-C' language;
disregard as desired.
On Wed, Feb 2, 2011 at 2:04 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
>
> I am posting the Xtables2 Netlink interface specification, draft 7
> for comments.
>
> Additionally, further documentation and toolchain around
> it is available through the project page at
>
> http://jengelh.medozas.de/projects/xtables/
>
> * User Documentation Chapter 1: Architectural Differences
> * Developer Documentation Part 1: Netlink interface (WIP)
> This is copied below to facilitate inline replies
> --8<--
>
> Netlink interface
>
> 1 Concepts
>
> This section is non-normative and should instead show the flow of
> thought and give reasons as to why the specification was
> conceived the way it is, and where the component problems are.
>
> 1.1 Nesting representation
>
> The common element in Xtables is the ruleset, represented as a
> tree structure with ordering constraints at some levels:
>
> ruleset (unordered tables)
> \__ table (unordered chains)
> | \__ chain (ordered rules)
> | | \__ rule (ordered actions)
> | | | \__ match (unordered data)
> | | | | \__ config-data
> | | | | | \__ bin params
> | | | | \__ state-data
> | | | | \__ nlattrs
> | | | \__ match...
> | | | \__ target (unordered data)
> | | | | \__ config-data
> | | | \__ target...
> | | | \__ verdict...
> | | \__ rule...
> | \__ chain...
> \__ table...
>
> A more concrete example, here is a small ruleset, encoded into
> XML (just one of many possible representations):
>
> <table>
> <chain name="INPUT">
> <rule idx="1">
> <match acidx="1" name="hashlimit" rev="1" csize="120">
> <config-data>...</config-data>
> <state-data>...</state-data>
> </match>
> <target acidx="2" name="TOS" rev="1">
> ...
> </target>
> <verdict acidx="3" name="ACCEPT" />
> </rule>
> </chain>
> </table>
>
> There are different ways to encode such a tree structure into a
> serialized stream. In many Netlink protocols, children attributes
> are encapsulated (a. k. a. “nested”, though we will avoid this
> term to avoid double-use) and treated as a whole as a parent's
> opaque data. It cannot be told apart from normal data. (Like
> writing “<chain> <rule> ... </rule> </chain>” in
> XML.) We will call this format “Encapsulated Encoding”.
>
> To encode an attribute's length, struct nlattr only has a 16-bit
> field, which means the attribute header plus payload is limited
> to 64 KB. This is easily exceedable with the encapsulated
> encoding as chains are collected rules in a chain, for example.
> The problem is aggreviated by the kernel's Netlink handler only
> allocating sk_buffs a page size worth, which leaves few room for
> extension data. In the worst case, the usable payload for
> attributes is around 3600 bytes only. In light of xt_u32's
> private data block being 1984 bytes already, that means that you
> won't be able to fit two -m u32 invocations nested in a single
> rule into a dump.
>
> Certain voices in the community call for the obsoletion of such
> data blobs and replace them by Netlink attributes; there are no
> objections to doing so. However, the problem of size-limited
> sk_buffs applies to opaque data of any kind, and Netlink
> attributes fall within that.
I'm all for of opaque data-blobs where the user is not expected to
understand the data underneath (FILE handles), but only so far as they
can be safely serialized to alternate processes for collection of
additional data (no *pointers, and only TLV styled abstractions)
>
> The Xtables2 Netlink protocol encodes each node of information as
> a standalone attribute, to be called Flat Encoding, that is
> appended (a. k. a. “chained”) to the data stream. By avoiding
> encapsulated attributes, it is possible to split messages at much
> finer levels, and provides for attributes that happen to use
> opaque data with a maximally-sized buffer.
>
> 1.2 Nest markers<sub:Nest-markers>
>
> Since Netlink messages do have a 32-bit quantity to store the
> messagelength, rulesets of roughly up to 4 GB are possibile,
> which is currently regarded as sufficient. The largest (while
> still being meaningful) rulesets seen to date in the industry
> weighed in at approximately 150 MB.
While managing tables/rules/etc atomically should be priority #1, I'm
not certain if optimizing the protocol for this makes a lot of sense
for either the user or kernel contexts.
>
> Whereas encapsulated attribute encoding automatically provided
> for boundaries, this is realized using dummy attributes in the
> chained approach. The start of a nesting level can be implicitly
> represented by the presence of the attribute that would have
> otherwise been used for encapsulated nesting. For declaring an
> end of a nest level, an extra attribute is needed:
>
> • “chain { rule; rule; ... }” \Leftrightarrow CHAIN RULE RULE ...
> STOP
>
> 1.3 Attribute limitations in nfnetlink
>
> Netlink, being just a base protocol, does not specify what comes
> after the nlmsghdr, or how it is ordered. This is left up to the
> subprotocols based on Netlink. nfnetlink has two effective
> shortcomings (due to its parser) that shall be held in mind:
>
> • Attribute ordering is ignored and lost
(GoNetlink doesn't adhere to this belief; I didn't realize there was
any standardization of this approach outside of the libnfnetlink
implementation, and so assumed I'd be screwed if I followed it.)
>
> • No support for more than one attribute with the same type
> within a message
ditto
> 1.4 Summary of transform<sub:Summary-of-transform>
>
> Essentially there is a 1:1 transform on the XML-like tree shown
> above, to:
>
> NFXTM_CHAIN_ENTRY<name=INPUT,usertid=1>
> NFXTM_RULE_ENTRY<idx=1,usertid=1>
> NFXTM_MATCH_ENTRY<acidx=1,name=hashlimit,rev=1,usertid=2>
> NFXTM_CONFIG_DATA
> NFXTM_ARB_DATA<whatever>
> NFXTM_ARB_DATA<more arbitrary data>
> NFXTM_STOP
> NFXTM_STATE_DATA
> NFXTM_ATTR_DATA<nlattrs>
> NFXTM_ATTR_DATA<more nlattrs>
> NFXTM_STOP
> NFXTM_STOP
> NFXTM_TARGET_ENTRY<acidx=2,name=TOS,rev=0,usertid=3>
> ...
> NFXTM_STOP
> NFXTM_VERDICT_ENTRY<acidx=3,name=ACCEPT,usertid=3>
> NFXTM_STOP
> NFXTM_STOP
> NFXTM_STOP
>
> 1.5 Extra sequence numbers<sub:Extra-sequence-numbers>
>
> Netlink also does not specify any message ordering, though it
> does provide an nlmsg_seq field with which message order can at
> least be determined. The problem is that nothing specifies what
> nlmsg_seq should be in reply messages. It is assumed that the
> sequence number is linked, i. e. that a reply's number should be
> the same as the request's number, to do message matching (vague
> hint by netlink(7) manpage).
RFC 3549 (2.3.2.1) seems to support you in that the usage of sequence
numbers is undefined; My experience has been to expect the response to
match the request and dispatch accordingly -- since thats the 'norm',
and netlink shouldn't ever fail, I'd actually rather see the protocol
use NLM_F_MULTI, NLM_F_ATOMIC pair, with an internal
sequence/timestamp for clients that really need an atomic state.
>
> Even if that were decidedly so, that brings along a problem. In
> NLM_F_MULTI-style dumps, all messages would have the same
> nlmsg_seq. To counter this, multi messages will have an
> NFXT-specific sequence counter (NFXTA_SEQNO) in addition,
> especially since ordering is so much more crucial in Xtables than
> it is in other parts of networking.
That, to me, is fine -- netlink is an encapsulation from my view,
MULTI is the right way to do long messages.
>
> 1.6 Improved granularity error reporting
>...
As a non-C implementation, I'd prefer constant error (class) with
flags (bitfield), but expect to rewrite a lot of constants anyhow.
> 1.7 Multi-type responses
> ...
Most RTNetlink protocols (which will be a similar user base I imagine)
make assumptions on the response type based on the query type; In go,
for example, there is no generic, so re-decomposing a response becomes
expensive.
Personally, I would prefer that responses be limited solely to the
query I provided or an error, not something with multiple (possibly
confounding?) types.
> ...
> 3 Attributes
>
> The meaning of attributes depends upon the message and logical
> nesting level in which they appear. Their type however remains
> the same, such that a single Netlink attribute validation policy
> object (struct nla_policy) can be used for all message types.
>
> A table of all known attributes:
>
>
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | Value | Mnemonic | C type | NLA type | Notes |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | 1 | NFXTA_SEQNO | unsigned int | NLA_U32 | Section [sub:Extra-sequence-numbers] |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | tba | NFXTA_ERRNO | int | NLA_U32 | Generic system errno (Exxx) |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | ... | NFXTA_XTERRNO | int | NLA_U32 | NFXT errno (NFXTE_*) |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_ERRSTR | char [] | NLA_NUL_STRING | Arbitrary |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_USERTID | unsigned int | NLA_U32 | Arbitrary, retained verbatim |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_CHAIN_NAME | char [] | NLA_NUL_STRING | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_RULE_IDX | unsigned int | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_ACTION_IDX | unsigned int | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_NAME | char [] | NLA_NUL_STRING | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_REVISION | uint8_t | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_HOOKNUM | unsigned int | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_PRIORITY | int | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_NFPROTO | uint8_t | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_OFFSET | unsigned int | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_LENGTH | size_t | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_HOOKMASK | unsigned int | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_SIZE | size_t | NLA_U32 | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
> | | NFXTA_NEW_NAME | char [] | NLA_NUL_STRING | |
> +--------+-------------------+---------------+-----------------+--------------------------------------+
W/r/t the NUL_STRING's -- is there a good reason to use a NUL'd
strings for NAME/etc, given the length is known? Wouldn't it make more
sense to simply require a byte string and apply the null internally? I
see this frequently in Netlink, and imagine it's a kernel consistency
thing?
>
>
> The kernel ignores attributes with value 0 during validation, so
> it was left unused.
>
> 4 Error types<sec:Error-types>
>
>
> +--------+---------------------+-------------------------------------------+
> | Value | Mnemonic | Description |
> +--------+---------------------+-------------------------------------------+
> +--------+---------------------+-------------------------------------------+
> | 0 | NFXTE_SUCCESS | No error |
> +--------+---------------------+-------------------------------------------+
> | 1 | NFXTE_CHAIN_EXIST | Chain already exists |
> +--------+---------------------+-------------------------------------------+
> | 2 | NFXTE_CHAIN_NOENT | Chain does not exist |
> +--------+---------------------+-------------------------------------------+
> | 3 | NFXTE_RULESET_LOOP | Ruleset contains a loop |
> +--------+---------------------+-------------------------------------------+
> | 4 | NFXTE_EXT_HOOKMASK | Rule invoked from incompatible hook |
> +--------+---------------------+-------------------------------------------+
> | | NFXTE_PROMO_STATUS | Promotion/demotion state already achieved |
> +--------+---------------------+-------------------------------------------+
>
>
> 5 Message types
> ...
My biggest concern here seems as already pointed out -- the use of
STOP && deep nesting in messages; Every time a STOP occurs in an
internal message, it's semantically equivalent to the completion of an
NF_F_MULTI no?
I see the advantage of a trivial protocol, but wouldn't it be much
simpler to have a 'bigger' protocol (table/chain/rule) with an
optional ATOMIC guarantee?
I don't see anywhere else guaranteeing tables/matches/rules will be
managed (as a set) with atomicity [I'm probably wrong], so doing it in
the protocol feels awkward.
There area LOT of definitions of atomicity, ordering, etc within this
area, making me feel like doing that 'up one level' and in smaller
pieces might make for more manageable interface
Still, this all looks like phenomenal progress, and I look forward to
seeing it move on.
James
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 2/5] mingw: work around irregular failures of unlink on windows
From: Heiko Voigt @ 2011-02-07 20:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: kusmabite, Johannes Sixt, Pat Thoyts, msysgit, git,
Johannes Schindelin
In-Reply-To: <20110207204818.GA63976@book.hvoigt.net>
If a file is opened by another process (e.g. indexing of an IDE) for
reading it is not allowed to be deleted. So in case unlink fails retry
after waiting for some time. This extends the workaround from 6ac6f878.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
compat/mingw.c | 31 +++++++++++++++++++++++++++++--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index a7e1c6b..4a1c218 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -3,6 +3,8 @@
#include <conio.h>
#include "../strbuf.h"
+static const int delay[] = { 0, 1, 10, 20, 40 };
+
int err_win_to_posix(DWORD winerr)
{
int error = ENOSYS;
@@ -116,12 +118,38 @@ int err_win_to_posix(DWORD winerr)
return error;
}
+static inline int is_file_in_use_error(DWORD errcode)
+{
+ switch(errcode) {
+ case ERROR_SHARING_VIOLATION:
+ case ERROR_ACCESS_DENIED:
+ return 1;
+ }
+
+ return 0;
+}
+
#undef unlink
int mingw_unlink(const char *pathname)
{
+ int ret, tries = 0;
+
/* read-only files cannot be removed */
chmod(pathname, 0666);
- return unlink(pathname);
+ while ((ret = unlink(pathname)) == -1 && tries < ARRAY_SIZE(delay)) {
+ if (!is_file_in_use_error(GetLastError()))
+ break;
+ /*
+ * We assume that some other process had the source or
+ * destination file open at the wrong moment and retry.
+ * In order to give the other process a higher chance to
+ * complete its operation, we give up our time slice now.
+ * If we have to retry again, we do sleep a bit.
+ */
+ Sleep(delay[tries]);
+ tries++;
+ }
+ return ret;
}
#undef open
@@ -1257,7 +1285,6 @@ int mingw_rename(const char *pold, const char *pnew)
{
DWORD attrs, gle;
int tries = 0;
- static const int delay[] = { 0, 1, 10, 20, 40 };
/*
* Try native rename() first to get errno right.
--
1.7.4.34.gd2cb1
^ permalink raw reply related
* [PATCH v4 1/5] mingw: move unlink wrapper to mingw.c
From: Heiko Voigt @ 2011-02-07 20:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: kusmabite, Johannes Sixt, Pat Thoyts, msysgit, git,
Johannes Schindelin
In-Reply-To: <20110207204818.GA63976@book.hvoigt.net>
The next patch implements a workaround in case unlink fails on Windows.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
compat/mingw.c | 8 ++++++++
compat/mingw.h | 11 +++--------
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index bee6054..a7e1c6b 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -116,6 +116,14 @@ int err_win_to_posix(DWORD winerr)
return error;
}
+#undef unlink
+int mingw_unlink(const char *pathname)
+{
+ /* read-only files cannot be removed */
+ chmod(pathname, 0666);
+ return unlink(pathname);
+}
+
#undef open
int mingw_open (const char *filename, int oflags, ...)
{
diff --git a/compat/mingw.h b/compat/mingw.h
index cafc1eb..970d743 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -119,14 +119,6 @@ static inline int mingw_mkdir(const char *path, int mode)
}
#define mkdir mingw_mkdir
-static inline int mingw_unlink(const char *pathname)
-{
- /* read-only files cannot be removed */
- chmod(pathname, 0666);
- return unlink(pathname);
-}
-#define unlink mingw_unlink
-
#define WNOHANG 1
pid_t waitpid(pid_t pid, int *status, unsigned options);
@@ -174,6 +166,9 @@ int link(const char *oldpath, const char *newpath);
* replacements of existing functions
*/
+int mingw_unlink(const char *pathname);
+#define unlink mingw_unlink
+
int mingw_open (const char *filename, int oflags, ...);
#define open mingw_open
--
1.7.4.34.gd2cb1
^ permalink raw reply related
* Re: ANNOUNCE: NVIDIA HDMI audio documentation
From: Anssi Hannula @ 2011-02-07 20:49 UTC (permalink / raw)
To: Stephen Warren; +Cc: alsa-devel@alsa-project.org
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0310F5FC8D@HQMAIL01.nvidia.com>
On 07.02.2011 19:39, Stephen Warren wrote:
> Anssi Hannula wrote:
>> On 04.02.2011 00:37, Stephen Warren wrote:
>>> I have written a document re: how to understand and trouble-shoot issues
>>> with audio-over-HDMI on NVIDIA GPUs. It's available at:
>>>
>>> ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.html
>>
>> A nice document, thanks :)
>>
>> A couple of comments:
>
> Thanks very much for the feedback.
>
>> ...
>>> 12.4. Verify Your ELD Is Valid
>>
>> This section has "44100 48000 88200" multiple times.
>
> I'm having trouble finding this. Can you quote a bit more text to highlight
> exactly where/what the problem is?
The examples have:
> sad0_rates [0xe0] 44100 48000 88200
> HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 20
While you are not claiming they are correct, it would probably be best
to mention that in the text (and/or in the issues chapter).
>> Maybe one should mention that those are currently shown incorrectly (as
>> per "[alsa-devel] HDA - hdmi_show_short_audio_desc puts wrong rates in
>> eld#N").
>
> Am I correct that this isn't patched yet? I couldn't see anything that
> touched this in the git log, nor any following to this email:
>
> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-January/035557.html
Yes, the issue is not yet fixed.
I planned to provide a patch but I haven't had the time to do it yet
after all.
> Thanks again.
--
Anssi Hannula
^ permalink raw reply
* Re: [PATCH] cache-tree: do not cache empty trees
From: Junio C Hamano @ 2011-02-07 20:48 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jonathan Nieder, git, Ilari Liusvaara, Jakub Narebski,
Dmitry S. Kravtsov, Shawn Pearce
In-Reply-To: <20110207095713.GA19653@do>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Perhaps it's not a good approach after all. What I wanted was to make
> pre-1.8.0 tolerate empty trees created by 1.8.0. Perhaps it's better
> to just let pre-1.8.0 refuse to work with empty trees, forcing users
> to upgrade to 1.8.0?
I don't think we saw even something remotely resembles an agreement that
empty tree is a good thing to have yet. Why are you rushing things?
^ permalink raw reply
* [PATCH] mtd/nand: move pointer dereferencing after the actual check in verify_bbt_descr
From: Stanislav Fomichev @ 2011-02-07 20:48 UTC (permalink / raw)
To: dwmw2; +Cc: linux-mtd
Signed-off-by: Stanislav Fomichev <kernel@fomichev.me>
---
drivers/mtd/nand/nand_bbt.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 6ebd869..a1e8b30 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -1101,12 +1101,16 @@ static void mark_bbt_region(struct mtd_info *mtd, struct nand_bbt_descr *td)
static void verify_bbt_descr(struct mtd_info *mtd, struct nand_bbt_descr *bd)
{
struct nand_chip *this = mtd->priv;
- u32 pattern_len = bd->len;
- u32 bits = bd->options & NAND_BBT_NRBITS_MSK;
+ u32 pattern_len;
+ u32 bits;
u32 table_size;
if (!bd)
return;
+
+ pattern_len = bd->len;
+ bits = bd->options & NAND_BBT_NRBITS_MSK;
+
BUG_ON((this->options & NAND_USE_FLASH_BBT_NO_OOB) &&
!(this->options & NAND_USE_FLASH_BBT));
BUG_ON(!bits);
--
1.7.1
^ permalink raw reply related
* [PATCH v4 0/5] make open/unlink failures user friendly on windows using retry/abort
From: Heiko Voigt @ 2011-02-07 20:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: kusmabite, Johannes Sixt, Pat Thoyts, msysgit, git,
Johannes Schindelin
In-Reply-To: <7vmxo6pxyi.fsf@alter.siamese.dyndns.org>
This is the fourth iteration of my patch series with hopefully all the
mentioned issues addressed.
On Wed, Dec 15, 2010 at 12:45:09PM -0800, Junio C Hamano wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
> > Perhaps instead we would be better of with something like an xunlink
> > (etc) in wrapper.c that deals with this on all platforms (and make
> > sure that unlink sets errno to EBUSY correctly if it doesn't already)?
>
> That is superficially similar to the way we let xread() silently handle
> short read to give us an easier to use API. Especially, the part to
> silently retry for a few times is similar to xread() recovering by
> repeating short reads.
>
> I do not think "ask the user one last time" part belongs to such a
> wrapper, though.
I think we should currently keep this Windows specific because this is the
only system where such problems occur in practise. If we find later on
that other systems are affected with the same problem we can still move
the functions to another more public place. But without proper testing
whether it helps on other setups as well putting this into a more
prominent place does not make sense, IMO.
Cheers Heiko
Heiko Voigt (4):
mingw: move unlink wrapper to mingw.c
mingw: work around irregular failures of unlink on windows
mingw: make failures to unlink or move raise a question
mingw: add fallback for rmdir in case directory is in use
Johannes Schindelin (1):
mingw_rmdir: set errno=ENOTEMPTY when appropriate
compat/mingw.c | 168 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
compat/mingw.h | 14 ++---
2 files changed, 173 insertions(+), 9 deletions(-)
--
1.7.4.34.gd2cb1
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/5] genirq: Add IRQ affinity notifiers
From: Ben Hutchings @ 2011-02-07 20:44 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: David Miller, netdev, linux-net-drivers, therbert
In-Reply-To: <alpine.LFD.2.00.1101221735080.31804@localhost6.localdomain6>
On Sat, 2011-01-22 at 17:38 +0100, Thomas Gleixner wrote:
> B1;2401;0cOn Wed, 19 Jan 2011, David Miller wrote:
> > You said you had stuff before Ben's patches, and that's why you needed
> > to provide me with an -rc1 relative version of his commits.
>
> I hope a rc2 relative version works as well :)
>
> > If that's not the case, then yes it would work just fine.
> >
> > Just give me the URL to pull from, thanks!
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/numa
>
> @Ben: Your patch was pretty white space damaged. Please be more
> careful next time.
Oh, I see that struct irq_affinity_notify members were indented with
spaces; is that what you mean? Sorry, I've no idea how that happened.
Anyway, thanks for applying this.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: ext4: Fix data corruption with multi-block writepages support
From: Ted Ts'o @ 2011-02-07 20:44 UTC (permalink / raw)
To: Milan Broz; +Cc: Matt, Linux Kernel, linux-ext4
In-Reply-To: <4D503A06.3010403@redhat.com>
On Mon, Feb 07, 2011 at 07:29:26PM +0100, Milan Broz wrote:
>
> So it was ext4 only bug in ext4_end_bio(),
> dm-crypt per-cpu code was just trigger here, right?
There appeared to be two bugs that people were discussing on that
particular dm_crypt mail thread. Some people were complaining about
issues with dm_crypt even when ext4 was not involved.
So I think it's fair to say that there was definitely _a_ ext4 bug
which was most easily seen when dm_crypt was in play, but which was
definitely not dm_crypt specific (it was possible to see it on an
hdd-only system, but the workload was much more severe). In any case,
as soon as the problem was found, we disabled the ext4 optimization
in 2.6.37-rc5.
So the fact that we found and fixed an ext4 bug that was triggered by
dm_crypt should not be taken as a statement (one way or the other)
that dm_crypt is Bug-Free(tm). :-)
- Ted
^ permalink raw reply
* Re: [PATCH] cortex-m3: adjusted target cflags
From: Mark Hatle @ 2011-02-07 20:42 UTC (permalink / raw)
To: Khem Raj; +Cc: Enrico Scholz, openembedded-devel
In-Reply-To: <AANLkTikT+xiXg5W39LzE4dHyLjGnO1oQF3=x_k0mXAjN@mail.gmail.com>
On 2/7/11 2:19 PM, Khem Raj wrote:
> On Mon, Feb 7, 2011 at 11:39 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 2/7/11 1:33 PM, Khem Raj wrote:
>>> On Mon, Feb 7, 2011 at 7:53 AM, Enrico Scholz
>>> <enrico.scholz@sigma-chemnitz.de> wrote:
>>>> Explicit '-mthumb' is required because Cortex-M3 does not support ARM
>>>> instructions and actual flags cause gcc to fail with 'error: target CPU
>>>> does not support ARM mode'.
>>>>
>>>> The '-mcpu=cortex-m3' is shorter than '-march=armv7-m -mtune=cortex-m3'
>>>> and enables workarounds like '-mfix-cortex-m3-ldrd'.
>>>
>>> Does -mcpu=cortex-m3 also cause gcc to tune for cortex-m3 ?
>>
>> -mcpu=cortex-m3 is equivalent to -march=cortex-m3 -mtune=cortex-m3
>
> is -march=cortex-m3 valid even ? my question was if we select armv7-m
> using -march
> then gcc knows stuff like oh this arch has a hardware div instruction
> but now if we
> use -mcpu will it still do it.
You would have to look in the source and see if -mcpu=cortex-m3 is an "alias"
for anything or simply uses the default logic of cpu == march && mtune..
(FYI, last time I looked at how this worked was a year or so ago.. so if the way
GCC processes options has changed, then I'm wrong.. but it's worth looking at..
I was scolded many times by GCC developers that -mcpu= is not the same as
specifically setting the arch and tune.)
Usually you use march & mtune when you are trying to make a set of binaries that
is capable of running on multiple cores in the same family. I see it used the
most of IA and Power systems myself.
--Mark
^ permalink raw reply
* Re: [patch 0/3] platform-drivers: x86: Cleanup pmic gpio interrupt
From: Thomas Gleixner @ 2011-02-07 20:41 UTC (permalink / raw)
To: Matthew Garrett; +Cc: LKML, Feng Tang, Alan Cox, Alek Du
In-Reply-To: <20110207201730.GA21520@srcf.ucam.org>
On Mon, 7 Feb 2011, Matthew Garrett wrote:
> Applied, thanks.
Btw, there is no real reason to have this as a chained handler. I
guess I need to find some time for educational documentation :)
See below.
Thanks,
tglx
------->
Subject: platform-drivers: x86: pmic: Use request_irq instead of chained handler
From: Thomas Gleixner <tglx@linutronix.de>
Date: Mon, 07 Feb 2011 21:24:29 +0100
There is no need to install a chained handler for this hardware. This
is a plain x86 IOAPIC interrupt which is handled by the core code
perfectly fine. There is nothing special about demultiplexing these
gpio interrupts which justifies a custom hack. Replace it by a plain
old interrupt handler installed with request_irq. That makes the code
agnostic about the underlying primary interrupt hardware. The overhead
for this is minimal, but it gives us the advantage of accounting,
balancing and to detect interrupt storms. gpio interrupts are not
really that performance critical.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
drivers/platform/x86/intel_pmic_gpio.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
Index: linux-2.6/drivers/platform/x86/intel_pmic_gpio.c
===================================================================
--- linux-2.6.orig/drivers/platform/x86/intel_pmic_gpio.c
+++ linux-2.6/drivers/platform/x86/intel_pmic_gpio.c
@@ -211,9 +211,9 @@ static struct irq_chip pmic_irqchip = {
.irq_set_type = pmic_irq_type,
};
-static void pmic_irq_handler(unsigned irq, struct irq_desc *desc)
+static irqreturn_t pmic_irq_handler(unsigned int irq, void *data)
{
- struct pmic_gpio *pg = (struct pmic_gpio *)get_irq_data(irq);
+ struct pmic_gpio *pg = data;
u8 intsts = *((u8 *)pg->gpiointr + 4);
int gpio;
@@ -223,7 +223,6 @@ static void pmic_irq_handler(unsigned ir
generic_handle_irq(pg->irq_base + gpio);
}
}
- desc->chip->irq_eoi(get_irq_desc_chip_data(desc));
}
static int __devinit platform_pmic_gpio_probe(struct platform_device *pdev)
@@ -280,8 +279,13 @@ static int __devinit platform_pmic_gpio_
printk(KERN_ERR "%s: Can not add pmic gpio chip.\n", __func__);
goto err;
}
- set_irq_data(pg->irq, pg);
- set_irq_chained_handler(pg->irq, pmic_irq_handler);
+
+ retval = request_irq(pg->irq, pmic_irq_handler, 0, "pmic", pg);
+ if (retval) {
+ printk(KERN_WARN "pmic: Interrupt request failed\n");
+ goto err;
+ }
+
for (i = 0; i < 8; i++) {
set_irq_chip_and_handler_name(i + pg->irq_base, &pmic_irqchip,
handle_simple_irq, "demux");
^ permalink raw reply
* Re: hung task in iozone test on nfs client
From: Jim Rees @ 2011-02-07 20:41 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs, peter honeyman
In-Reply-To: <1296865456.2938.63.camel@heimdal.trondhjem.org>
[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]
Trond Myklebust wrote:
On Fri, 2011-02-04 at 16:36 -0500, Jim Rees wrote:
> I have a report here of iozone hanging when run on nfs4 client against an
> EMC server. We have reproduced this problem with a wide range of client
> kernel versions, from 2.6.33.3-85.fc13.x86_64 up to
> 2.6.38-0.rc3.git2.1.pnfs_wave3_20110203.fc15.x86_64, and on both 4.0 and
> 4.1. It seems to happen only with heavy multi-threaded iozone testing with
> big files. The iozone is something like this:
>
> iozone -r 2m -s 256m -w -W -c -t 12 -i 0 -o
>
> The call trace is usually something like this:
>
> [<ffffffff810c1314>] ? sync_page+0x0/0x45
> [<ffffffff814297bc>] io_schedule+0x6e/0xb0
> [<ffffffff810c1355>] sync_page+0x41/0x45
> [<ffffffff81429cf8>] __wait_on_bit+0x43/0x76
> [<ffffffff810c14ae>] wait_on_page_bit+0x6d/0x74
> [<ffffffff8106484b>] ? wake_bit_function+0x0/0x2e
> [<ffffffff810c94c0>] ? pagevec_lookup_tag+0x20/0x29
> [<ffffffff810c1751>] filemap_fdatawait_range+0x9f/0x173
> [<ffffffff810c18ce>] filemap_write_and_wait_range+0x3e/0x51
> [<ffffffff8111fa53>] vfs_fsync_range+0x5a/0xad
> [<ffffffff8111faf9>] generic_write_sync+0x53/0x55
> [<ffffffff810c1d4b>] generic_file_aio_write+0x86/0xa2
> [<ffffffffa0321bf8>] nfs_file_write+0xed/0x169 [nfs]
> [<ffffffff811017c5>] do_sync_write+0xbf/0xfc
> [<ffffffff810f4dc9>] ? __slab_free+0x28/0x22e
> [<ffffffff81204b7d>] ? might_fault+0x1c/0x1e
> [<ffffffff811be22b>] ? security_file_permission+0x11/0x13
> [<ffffffff81101d23>] vfs_write+0xa9/0x106
> [<ffffffff81101e36>] sys_write+0x45/0x69
> [<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
>
> I have a pcap file here but it's 8GB. I am trying to distill it to the
> important parts.
>
> Those of you who are familiar with the page cache, is there any obvious
> deadlock here that jumps out at you?
The above just tells you that something is waiting for the PG_writeback
lock (IOW: it is waiting for a writeback of the page to the server to
complete). It doesn't actually tell you why that page writeback is
failing to complete.
Can you send us the output of 'dmesg' after you do
echo 0 >/proc/sys/sunrpc/rpc_debug
as root? The 'echo' command needs to be done during the hang.
Attached.
[-- Attachment #2: hang-rpcdebug-dmesg.txt --]
[-- Type: text/plain, Size: 9742 bytes --]
r38-13-78: [ 1999.083961] -pid- flgs status -client- --rqstp- -timeout ---ops--
r38-13-78: [ 1999.083987] 34411 0001 0 ffff880247b2e800 ffff8802550e6930 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084004] 34412 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084021] 34413 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084036] 34414 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084050] 34415 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084064] 34416 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084078] 34417 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084092] 34418 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084105] 34419 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084119] 34420 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084137] 34421 0001 0 ffff880247b2e800 ffff8802550e6dc8 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084153] 34422 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084167] 34423 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084181] 34424 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084195] 34425 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084209] 34426 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084223] 34427 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084236] 34428 0001 0 ffff880247b2e800 ffff8802550e7260 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084250] 34429 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084262] 34430 0001 0 ffff880247b2e800 ffff8802550e6498 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084276] 34431 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084288] 34432 0001 0 ffff880247b2e800 ffff8802550e6620 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084301] 34433 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084316] 34434 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084330] 34435 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084344] 34436 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084357] 34437 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084369] 34438 0001 -11 ffff880247b2e800 ffff8802550e6188 60000 ffffffffa03c3810 nfsv4 WRITE a:call_transmit_status q:xprt_pending
r38-13-78: [ 1999.084402] 34439 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084419] 34440 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084433] 34441 0001 0 ffff880247b2e800 ffff8802550e6c40 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084449] 34442 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084465] 34443 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084481] 34444 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084498] 34445 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084514] 34446 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084529] 34447 0001 0 ffff880247b2e800 ffff8802550e73e8 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084545] 34448 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084561] 34449 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084577] 34450 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084592] 34451 0001 0 ffff880247b2e800 ffff8802550e70d8 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084608] 34452 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084625] 34453 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084642] 34454 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084658] 34455 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084674] 34456 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084690] 34457 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084706] 34458 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084722] 34459 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084738] 34460 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084754] 34461 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084770] 34462 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084786] 34463 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084802] 34464 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084817] 34465 0001 -11 ffff880247b2e800 ffff8802550e6f50 0 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_sending
r38-13-78: [ 1999.084833] 34466 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084848] 34467 0001 0 ffff880247b2e800 ffff8802550e7570 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084864] 34468 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084878] 34469 0001 -11 ffff880247b2e800 ffff8802550e6310 0 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_sending
r38-13-78: [ 1999.084894] 34470 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:NFS client
r38-13-78: [ 1999.084910] 34471 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084925] 34472 0001 0 ffff880247b2e800 ffff8802550e76f8 60000 ffffffffa03c3810 nfsv4 WRITE a:call_status q:xprt_pending
r38-13-78: [ 1999.084943] 34473 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084959] 34474 0001 0 ffff880247b2e800 (null) 0 ffffffffa03c3810 nfsv4 WRITE a:rpc_prepare_task q:ForeChannel Slot table
r38-13-78: [ 1999.084974] 18306 0280 0 ffff880253a4a000 ffff8802550e6ab8 60000 ffffffffa03cdb80 nfsv4 SEQUENCE a:call_status q:xprt_pending
^ permalink raw reply
* Re: [PATCH] GRO: fix merging a paged skb after non-paged skbs
From: Ben Hutchings @ 2011-02-07 20:39 UTC (permalink / raw)
To: Michal Schmidt; +Cc: David Miller, netdev, Herbert Xu, linux-net-drivers
In-Reply-To: <1295918675.4105.5.camel@localhost>
On Tue, 2011-01-25 at 11:24 +1000, Ben Hutchings wrote:
> On Mon, 2011-01-24 at 18:47 +0100, Michal Schmidt wrote:
> > Suppose that several linear skbs of the same flow were received by GRO. They
> > were thus merged into one skb with a frag_list. Then a new skb of the same flow
> > arrives, but it is a paged skb with data starting in its frags[].
> >
> > Before adding the skb to the frag_list skb_gro_receive() will of course adjust
> > the skb to throw away the headers. It correctly modifies the page_offset and
> > size of the frag, but it leaves incorrect information in the skb:
> > ->data_len is not decreased at all.
> > ->len is decreased only by headlen, as if no change were done to the frag.
> > Later in a receiving process this causes skb_copy_datagram_iovec() to return
> > -EFAULT and this is seen in userspace as the result of the recv() syscall.
> >
> > In practice the bug can be reproduced with the sfc driver. By default the
> > driver uses an adaptive scheme when it switches between using
> > napi_gro_receive() (with skbs) and napi_gro_frags() (with pages). The bug is
> > reproduced when under rx load with enough successful GRO merging the driver
> > decides to switch from the former to the latter.
> [...]
>
> This is odd because I thought we made sure to flush before making such a
> change. Perhaps that got lost during the conversion from inet_lro to
> GRO?
That is indeed the case; commit da3bc07171dff957906cbe2ad5abb443eccf57c4
made the following deletions:
- /* Both our generic-LRO and SFC-SSR support skb and page based
- * allocation, but neither support switching from one to the
- * other on the fly. If we spot that the allocation mode has
- * changed, then flush the LRO state.
- */
- if (unlikely(channel->rx_alloc_pop_pages != (rx_buf->page != NULL))) {
- efx_flush_lro(channel);
- channel->rx_alloc_pop_pages = (rx_buf->page != NULL);
- }
Ben.
> Anyway, thanks very much for fixing this.
>
> Ben.
>
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [LSF/FS TOPIC] I/O performance isolation for shared storage
From: Vivek Goyal @ 2011-02-07 20:38 UTC (permalink / raw)
To: Chad Talbott; +Cc: lsf-pc, linux-fsdevel
In-Reply-To: <AANLkTi=HPdvU0MpaE-CbDNvOegDROHMXpW9Bh8gewc1r@mail.gmail.com>
On Mon, Feb 07, 2011 at 11:40:26AM -0800, Chad Talbott wrote:
> On Mon, Feb 7, 2011 at 10:06 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Fri, Feb 04, 2011 at 03:07:15PM -0800, Chad Talbott wrote:
> >> I'd like to hear more about this.
> >
> > If a group dispatches some IO and then it is empty, then it will be
> > deleted from service tree and when new IO comes in, it will be put
> > at the end of service tree. That way all the groups become more of
> > round robin and there is no service differentiation.
> >
> > I was thiking that when a group gets backlogged instead of putting
> > him at the end of service tree come up with a new mechanism of
> > where they are put at certain offset from the st->min_vdisktime. This
> > offset is more for high prio group and less for low prio group. That
> > way even if a group gets deleted and comes back again with more IO
> > there is a chance it gets schedled ahead of already queued low prio
> > group and we could see some service differentiation even with idling
> > disabled.
>
> This is interesting. I think Nauman may have come up with a different
> method to address similar concerns. In his method, we remember a
> group's vdisktime even when they are removed from the service tree.
> This would lead fairness over too long of a time window implemented by
> itself. Only when the disk becomes idle, we "forget" everyone's
> vdisktime. We should be sending that patch out Real Soon Now, along
> with the rest.
I have thought about it in the past. I think there are still few
concerns there.
- How to determine which group's vdisktime is still valid and how to
invalidate all the past vdisktimes.
- When idling is disabled, most likely groups will dispatch bunch of
requests and go away. So slice used might be just 1 jiffy or even
less. In that case all the groups then have same vdisktime at
expiry and not service differentiation.
- Even if we reuse the previous disktime, most likely it is past
st->min_vdisktime, which is an monotonically increasing number. How
is that handled.
Thanks
Vivek
^ permalink raw reply
* Re: Profiling a program's runtime
From: Arnaldo Carvalho de Melo @ 2011-02-07 20:38 UTC (permalink / raw)
To: Maucci, Cyrille
Cc: Christoph Bartoschek, linux-perf-users@vger.kernel.org,
Ingo Molnar, Thomas Gleixner
In-Reply-To: <0E02F16954AF394BB163AEE50FDF548568FE033642@GVW1121EXC.americas.hpqcorp.net>
Em Fri, Feb 04, 2011 at 07:57:00PM +0000, Maucci, Cyrille escreveu:
> Yep. I was not promoting caliper here.
> I was just referring to it so that we may get an idea of what he'd like to see in 'perf' reports.
Right, useful pointers, thanks, barring patents, I think we can get that
with perf at some point.
Catering to I/O bound workloads is something that is in the radar, has
been experimented with and should resume development soon, please take a
look at the 'trace' description at:
http://lwn.net/Articles/415728/
The discussion also has lots of useful suggestions and insights.
It is an area that badly needs help to get the perf infrastructure to
the next level, beyong the current state of good (excellent?) CPU bound
profiling.
- Arnaldo
^ permalink raw reply
* [U-Boot] IXP42x patch series version 3
From: Michael Schwingen @ 2011-02-07 20:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110204235233.CEEA91B765DB@gemini.denx.de>
Am 02/05/2011 12:52 AM, schrieb Wolfgang Denk:
> Dear Michael Schwingen,
>
> In message <1296860763-16149-1-git-send-email-michael@schwingen.org> you wrote:
>> here is the third incarnation of the IXP patch series. I hope I addressed
>> all the comments from version 2:
>> - timer system now uses no BSS-based variables
>> - use I/O accessors
>> - remove config.mk from board directories
>> - set -ffunction-sections/--gc-sections globally (for IXP architecture)
> Sorry, but please consider it all NAKed.
>
> See the note at bullet 2 at
> http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
> for the rationale.
Hi,
I just tried, but I can't find a way to insert the changelog so that
git-send-email places it at the required point (ie. after the s.o.b. and
inside the same comment block as the diffstat) - all I could get was the
changelog inside the comment block, with a line with "---" above, like this:
From: Michael Schwingen <michael@schwingen.org>
Date: Fri, 4 Feb 2011 21:34:59 +0100
Subject: [PATCH 01/17] add XScale sub architecture (IXP/PXA) to
maintainer list
---
Changes for V2:
Changes for V3:
- change patch description
- drop wepep250 (should already be deleted)
Changes for V4:
- add changelog
Signed-off-by: Michael Schwingen <michael@schwingen.org>
---
MAINTAINERS | 44 ++++++++++++++++++++++----------------------
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b37ed0c..709c5d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -559,8 +559,8 @@ Stefano Babic <sbabic@denx.de>
which looks quite different from what the wiki suggests.
Do you have a short pointer how to get the right result using git? Or is
this format actually acceptable?
thanks,
Michael
^ permalink raw reply related
* Re: [1.8.0] Provide proper remote ref namespaces
From: Nicolas Pitre @ 2011-02-07 20:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marc Branchaud, Jeff King, Johan Herland, git, Sverre Rabbelier,
Nguyen Thai Ngoc Duy
In-Reply-To: <7v62svvdjo.fsf@alter.siamese.dyndns.org>
On Mon, 7 Feb 2011, Junio C Hamano wrote:
> As I said in my message, it feels awkward to use refs/private-tags for
> tags everybody uses for his or her own purpose, so by swapping the roles
> of namespaces around, we would be able to use refs/tags for private ones,
> and refs/remotes/origin/tags for the ones that came from upstream. But
> then if you fetch/pull from a third party (including the "interim
> maintainer"), it feels wasteful to get full set of tags that you have in
> the origin namespace anyway replicated in refs/remotes/interim/tags.
Why so? At least you get to know if that particular remote has a
particular tag that may also exist elsewhere. And if you decide to drop
one remote source with all its tags from your local repository, then the
remaining one(s) still have relevant tags available.
> And that is what bothers me---not the waste itself, but I have this
> nagging feeling that the wasteful duplication is an indication of
> something else designed wrong.
We do have "wasteful" duplicated references all over the place, such as
when two directories (tree objects) contain the same file content (refer
to the same blob object). But no one feels like this is wasted
duplication as those two directories end up using the same single blob
object even if in the working directory you get twice the content.
Here this is the same thing. You have multiple handles to the same tag
which are distributed across different remote repositoryes you are
tracking. The name on the tag may be found in many places, and even
under different names. But there is still only one actual tag object.
If you have 3 remotes sharing the same tag then you know that the tag
cannot be garbage collected until all three remotes have been removed
from your repository.
Simply storing snapshots of the tag state per remote repository is
simple and allow for smarter processing on top, which is in agreement
with the design philosophy for the rest of Git.
Nicolas
^ permalink raw reply
* Re: [PATCH] voicecall: fix transfer
From: andre matos @ 2011-02-07 20:37 UTC (permalink / raw)
To: ofono
In-Reply-To: <4D504C26.4030504@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]
Hi Denis,
On Mon, Feb 7, 2011 at 8:46 PM, Denis Kenzior <denkenz@gmail.com> wrote:
> Hi Andre,
>
> > @@ -1350,11 +1351,12 @@ static DBusMessage
> *manager_transfer(DBusConnection *conn,
> > * implementing the call transfer operation for a call that is
> > * still dialing/alerting.
> > */
> > - numactive += voicecalls_num_connecting(vc);
> > + numconn = voicecalls_num_connecting(vc);
> >
> > numheld = voicecalls_num_held(vc);
> >
> > - if ((numactive != 1) && (numheld != 1))
>
> I don't get it, isn't the above condition taking care of this already?
> Its been a while but the precondition of ECT is:
>
> Held Call
> Outgoing or an Active call. You cannot have an Outgoing and an Active
> call at the same time. Hence numactive == 1 && numheld == 1 should work
> just fine.
>
What you wrote is correct. transfer works when it supposed to work.
The changes i did takes care of the negative cases.
This means calling transfer should fail if we have:
multiparty call active and one held call
one active call and one held multiparty call
only one active call
only one held call
etc...
>
> > + if ((numactive > 1 || numheld > 1) ||
>
this checks if there is multiparty
> + ((numheld + numactive + numconn) != 2))
>
this makes sure we have the the two call necessary for a transfer.
> return __ofono_error_failed(msg);
> >
> > if (vc->driver->transfer == NULL)
>
> Regards,
> -Denis
>
With my change oFono doesn't send unnecessary queries to the modem.
Best regards,
André
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2645 bytes --]
^ permalink raw reply
* Re: [lm-sensors] Standalone driver for W83677HG-I, NCT6775F,
From: Jean Delvare @ 2011-02-07 20:35 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20110205175852.GA26672@ericsson.com>
On Mon, 7 Feb 2011 09:44:12 -0800, Guenter Roeck wrote:
> Hi Andrew,
>
> On Mon, Feb 07, 2011 at 11:50:48AM -0500, Andrew Lutomirski wrote:
> [ ... ]
> > >
> > > So what you'll have to do is to set a minimum speed, and the problem will go away.
> >
> > I admit I'm a bit confused as to what fan2_min does. I have a minimum
> > (to warn?) fan speed set in BIOS, which seems to have nothing to do
> > with the initial value of fan2_min. Changing fan2_min will cause
> > fan2_alarm to become set or unset, when I decrease min below input,
> > alarm stays set until I read it once.
> >
> Interesting; it means that it works, but the BIOS seems to use another set
> of registers to set the minimum speed.
The BIOS doesn't necessarily use limit registers. It is totally
possible that the speed is simply checked at boot time against the
specified limit, and the hardware monitoring chip isn't even aware of
it.
Motherboard vendors have been under- or even misusing the hardware
monitoring features of the chips they selected for years, and while it
gets slowly better over time, it's still dangerous to assume that they
always know what they are doing and that they always do the right thing.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* [Bug 33967] No image on a VGA screen attached to DVI with a dvi to vga adaptor on NVa3 card..
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-02-07 20:34 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-33967-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33967
--- Comment #5 from Maarten Maathuis <madman2003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2011-02-07 12:34:46 PST ---
Taken from dmesg log:
Found Display Configuration Block version 4.0
Raw DCB entry 0: 02000300 00020030
Raw DCB entry 1: 01011312 00020030
Raw DCB entry 2: 01011310 00000000
Raw DCB entry 3: 02022362 00020010
Raw DCB entry 4: 0000000e 00000000
DCB connector table: VHER 0x40 5 16 4
0: 0x00001030: type 0x30 idx 0 tag 0x07
1: 0x00000100: type 0x00 idx 1 tag 0xff
2: 0x00002261: type 0x61 idx 2 tag 0x08
Conclusion:
It seems that the DCB connector table or DCB output table is wrong. VGA
connector is linked to an digital and analog output, while the DVI is only
linked to an analog. Very small chance it's being misparsed, but more likely
it's a broken DCB connector table.
I'll try to see if can get the attention of Ben Skeggs, maybe you need a quirk
for this broken bios table.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [PATCH] Fix SSB chipcommon HT/ALP avail bits layout and usage
From: George Kashperko @ 2011-02-07 19:42 UTC (permalink / raw)
To: linux-next; +Cc: Michael Buesch
BCM4328 chipcommon have different CLKCTLST register HT and ALP availability
bits' layout comparing to other BCM chips. 4328 HT/ALP availability bits are
16/17 whereas other BCM chips' HT/ALP availability bits are 17/16. Therefore
current pmu pll initialization code forces active low power clock for all
non-4328 chips instead of switching HT clock on.
Patch also fixes typo in ALP avail define description.
Signed-off-by: George Kashperko <george@znau.edu.ua>
---
drivers/ssb/driver_chipcommon_pmu.c | 4 ++--
include/linux/ssb/ssb_driver_chipcommon.h | 6 ++++--
2 files changed, 6 insertions(+), 4 deletions(-)
--- linux-next-20110203.orig/drivers/ssb/driver_chipcommon_pmu.c 2011-02-01 05:05:49.000000000 +0200
+++ linux-next-20110203/drivers/ssb/driver_chipcommon_pmu.c 2011-02-07 19:18:06.000000000 +0200
@@ -132,12 +132,12 @@ static void ssb_pmu0_pllinit_r0(struct s
}
for (i = 1500; i; i--) {
tmp = chipco_read32(cc, SSB_CHIPCO_CLKCTLST);
- if (!(tmp & SSB_CHIPCO_CLKCTLST_HAVEHT))
+ if (!(tmp & SSB_CHIPCO_CLKCTLST_HAVEHT_4328))
break;
udelay(10);
}
tmp = chipco_read32(cc, SSB_CHIPCO_CLKCTLST);
- if (tmp & SSB_CHIPCO_CLKCTLST_HAVEHT)
+ if (tmp & SSB_CHIPCO_CLKCTLST_HAVEHT_4328)
ssb_printk(KERN_EMERG PFX "Failed to turn the PLL off!\n");
/* Set PDIV in PLL control 0. */
--- linux-next-20110203.orig/include/linux/ssb/ssb_driver_chipcommon.h 2011-02-01 05:05:49.000000000 +0200
+++ linux-next-20110203/include/linux/ssb/ssb_driver_chipcommon.h 2011-02-07 19:43:22.000000000 +0200
@@ -189,8 +189,10 @@
#define SSB_CHIPCO_CLKCTLST_HAVEALPREQ 0x00000008 /* ALP available request */
#define SSB_CHIPCO_CLKCTLST_HAVEHTREQ 0x00000010 /* HT available request */
#define SSB_CHIPCO_CLKCTLST_HWCROFF 0x00000020 /* Force HW clock request off */
-#define SSB_CHIPCO_CLKCTLST_HAVEHT 0x00010000 /* HT available */
-#define SSB_CHIPCO_CLKCTLST_HAVEALP 0x00020000 /* APL available */
+#define SSB_CHIPCO_CLKCTLST_HAVEALP 0x00010000 /* ALP available */
+#define SSB_CHIPCO_CLKCTLST_HAVEHT 0x00020000 /* HT available */
+#define SSB_CHIPCO_CLKCTLST_HAVEHT_4328 0x00010000 /* HT available on 4328 */
+#define SSB_CHIPCO_CLKCTLST_HAVEALP_4328 0x00020000/* ALP available on 4328 */
#define SSB_CHIPCO_HW_WORKAROUND 0x01E4 /* Hardware workaround (rev >= 20) */
#define SSB_CHIPCO_UART0_DATA 0x0300
#define SSB_CHIPCO_UART0_IMR 0x0304
^ permalink raw reply
* Re: [lm-sensors] Standalone driver for W83677HG-I, NCT6775F,
From: Andrew Lutomirski @ 2011-02-07 20:32 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20110205175852.GA26672@ericsson.com>
On Mon, Feb 7, 2011 at 3:26 PM, Guenter Roeck
<guenter.roeck@ericsson.com> wrote:
> Hi Andrew,
>
> On Mon, 2011-02-07 at 14:53 -0500, Andrew Lutomirski wrote:
> [ ... ]
>> >
>> > Anyway, please try again. I updated the code to fix the pwmX_enable bug.
>>
>> Mostly works.
>>
>> If I set pwm2_enable to 1, then pwm2 controls the fan.
>>
>> If I try to set pwm2_enable to 5, I get:
>>
>> # echo 5 >pwm2_enable
>> bash: echo: write error: Invalid argument
>>
> For now that is on purpose. Problem is that if SmartFanIV mode was not
> initialized by the BIOS, it probably won't work. There are lots of
> parameters which have to be configured. So one can not just let users
> enable it without forcing them to configure all the other parameters ..
> which is currently not possible with the sysfs ABI.
I guess what you'd want is a "set lots of parameters all at once" interface.
>
> So this is really a one-way street for now.
>
> Nuvoton's position on this matter is that fan control should be left to
> the board vendor to prevent system damage, ie that users should not try
> to configure it at all other than through the BIOS. They might have a
> point.
Fair enough. I actually plan to let BIOS configure everything, since
it seems to work nicely. But as long as there is a driver that offers
fan control, might as well have it work properly. (I care a lot more
about the sensors than the fan control.)
Should there be a "read-only" module option?
--Andy
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH] Fix SSB chipcommon HT/ALP avail bits layout and usage
From: Michael Büsch @ 2011-02-07 19:55 UTC (permalink / raw)
To: George Kashperko; +Cc: linux-next
In-Reply-To: <1297107730.32607.10.camel@dev.znau.edu.ua>
On Mon, 2011-02-07 at 21:42 +0200, George Kashperko wrote:
> BCM4328 chipcommon have different CLKCTLST register HT and ALP availability
> bits' layout comparing to other BCM chips. 4328 HT/ALP availability bits are
> 16/17 whereas other BCM chips' HT/ALP availability bits are 17/16. Therefore
> current pmu pll initialization code forces active low power clock for all
> non-4328 chips instead of switching HT clock on.
> Patch also fixes typo in ALP avail define description.
Where did you get the knowledge that the bits are swapped on 4328 from?
--
Greetings Michael.
^ permalink raw reply
* Re: mkcephfs: clean up temp files, honor $TEMPDIR
From: Colin McCabe @ 2011-02-07 20:31 UTC (permalink / raw)
To: DongJin Lee; +Cc: ceph-devel
In-Reply-To: <AANLkTikESf2F0OGcaxhGUu_vGbVRfP2kyPnGaUqmtvWS@mail.gmail.com>
This is resolved by aa8a25592f442ab640708115e144e6b8d95cb664, give it a try!
C.
On Sun, Feb 6, 2011 at 10:02 PM, Colin McCabe <cmccabe@alumni.cmu.edu> wrote:
> On Sun, Feb 6, 2011 at 5:33 AM, DongJin Lee <dongjin.lee@auckland.ac.nz> wrote:
>> Hi all:
>>
>> commit 09c38e8edadb3a5bf470ff9b0409172e0c61e012
>> About introducing the new tmp directory.
>>
>> TDIR=`mktemp -d -t mkcephfs.XXXXXXXXXX` || exit 1
>> trap "rm -rf ${TDIR}; exit" INT TERM EXIT
>>
>> I think this works if running all on the same nodes.
>> but other nodes don't know this directory name as they don't yet have
>> this newly (and randomly) created directory.
>
> Yes, the scp should be fixed. Good find.
>
>> Also, in the line 193, scp -q $conf $host:$conf
>> I don't think we check whether nodes have config directory, e.g., for
>> -c /etc/ceph/ceph.conf, we don't check /etc/ceph directory?
>> and so the other custom directory would also fail, too I think.
>
> I suppose we should do a mkdir -p before copying over the configuration file.
>
> cheers,
> Colin
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.