headers
Samuel Ortiz | 1 Dec 2008 01:08

Re: [PATCH 1/2] power_supply: Add cold to the POWER_SUPPLY_HEALTH report values

On Tue, Nov 25, 2008 at 02:25:12PM +0300, Anton Vorontsov wrote:
> On Thu, Nov 20, 2008 at 03:23:40PM +0000, Mark Brown wrote:
> > Some systems are able to report problems with batteries being under
> > temperature.
> > 
> > Signed-off-by: Mark Brown <broonie <at> opensource.wolfsonmicro.com>
> 
> Looks good to me.
> 
> Acked-by: Anton Vorontsov <cbouatmailru <at> gmail.com>
Thanks guys, both patches applied.

Cheers,
Samuel.

> > ---
> >  drivers/power/power_supply_sysfs.c |    2 +-
> >  include/linux/power_supply.h       |    1 +
> >  2 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/power/power_supply_sysfs.c b/drivers/power/power_supply_sysfs.c
> > index 23ae846..ac01e06 100644
> > --- a/drivers/power/power_supply_sysfs.c
> > +++ b/drivers/power/power_supply_sysfs.c
> >  <at>  <at>  -45,7 +45,7  <at>  <at>  static ssize_t power_supply_show_property(struct device *dev,
> >  	};
> >  	static char *health_text[] = {
> >  		"Unknown", "Good", "Overheat", "Dead", "Over voltage",
> > -		"Unspecified failure"
> > +		"Unspecified failure", "Cold",
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuel Ortiz | 1 Dec 2008 01:10

Re: [patch 2.6.28-rc6 1/3] mfd: twl4030: simplified child creation code

Hi David,

On Wed, Nov 26, 2008 at 10:53:18AM -0800, David Brownell wrote:
> From: David Brownell <dbrownell <at> users.sourceforge.net>
> 
> Minor cleanup to twl4030-core: define a helper function to populate
> a single child node, and use it to replace six inconsistent versions
> of the same logic.  Both object and source code shrink.
> 
> As part of this, some devices now have more IRQ resources:  battery
> charger, keypad, ADC, and USB transceiver.  That helps to remove some
> irq #defines that block the children's drivers code from compiling on
> non-OMAP platforms.
> 
> Signed-off-by: David Brownell <dbrownell <at> users.sourceforge.net>
> Signed-off-by: Tony Lindgren <tony <at> atomide.com>
> ---
> These three patches are not essential for 2.6.28-final, although
> having the first two merge would be appreciated by ASoc folk so
> they can test-build the twl4030 codec support on non-OMAP hw.
All 3 patches pushed to my for-next branch, thanks.

Cheers,
Samuel.

> The diff on this first one is particularly deceptive; ugh.
> 
>  drivers/mfd/twl4030-core.c |  298 +++++++++++--------------------------------
>  1 file changed, 83 insertions(+), 215 deletions(-)
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Milan Broz | 1 Dec 2008 01:16
Picon
Favicon

Re: Re: next-20081125: crypto hard disk gets unaccessable

Andrew Morton wrote:
> (cc's added)
> 
>> After about four suspend & resume operations in the midst of editing
>> a file, the system beeped twice and issued this error:

Did this work before? If so, please can you provide version where
it works?

It is suspend to encrypted swap?

There should not be any recent change in dm-crypt related to this path,
so I expect it is some bug related to suspend/resume in combination with
running crypto - like corruption of some memory caused during suspend...

> [lots of snippage]
>> [69186.618357] RIP: 0010:[<ffffffff8031f246>]  [<ffffffff8031f246>] crypto_xor+0x7/0x48

> [69186.618468]  [<ffffffffa027226a>] ? crypto_cbc_encrypt+0xfa/0x15a [cbc]
> [69186.618481]  [<ffffffffa0285705>] ? aes_encrypt+0x0/0x7 [aes_x86_64]
> [69186.618494]  [<ffffffffa020667d>] ? async_encrypt+0x35/0x3a [crypto_blkcipher]
> [69186.618509]  [<ffffffffa0269a6f>] ? crypt_convert+0x1d2/0x253 [dm_crypt]
> [69186.618522]  [<ffffffffa0269ed6>] ? kcryptd_crypt+0x3e6/0x407 [dm_crypt]
> [69186.618533]  [<ffffffffa0269af0>] ? kcryptd_crypt+0x0/0x407 [dm_crypt]

I assume that crypto run here synchronously (not through asynchronous completion callback).

Herbert - is my guess ok? (The asynchronous handling in dm-crypt was the only part changed recently.)
(And I think that except crypto hw nobody uses asynchronous mode yet by default.)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Trond Myklebust | 1 Dec 2008 01:17
Picon
Picon

Re: [PATCH 0/3] NFS regression in 2.6.26?, "task blocked for more than 120 seconds"

Can you see if the following 3 patches help? They're against 2.6.28-rc6,
but afaics the problems are pretty much the same on 2.6.26.

Cheers
  Trond

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 59 comments |
headers
Trond Myklebust | 1 Dec 2008 01:18
Picon

Re: [PATCH 1/3] SUNRPC: Ensure the server closes sockets in a timely fashion

We want to ensure that connected sockets close down the connection when we
set XPT_CLOSE, so that we don't keep it hanging while cleaning up all the
stuff that is keeping a reference to the socket.

Signed-off-by: Trond Myklebust <Trond.Myklebust@...>
---

 net/sunrpc/svcsock.c |   21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 95293f5..a1b048d 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
 <at>  <at>  -59,6 +59,7  <at>  <at>  static void		svc_udp_data_ready(struct sock *, int);
 static int		svc_udp_recvfrom(struct svc_rqst *);
 static int		svc_udp_sendto(struct svc_rqst *);
 static void		svc_sock_detach(struct svc_xprt *);
+static void		svc_tcp_sock_detach(struct svc_xprt *);
 static void		svc_sock_free(struct svc_xprt *);

 static struct svc_xprt *svc_create_socket(struct svc_serv *, int,
 <at>  <at>  -1017,7 +1018,7  <at>  <at>  static struct svc_xprt_ops svc_tcp_ops = {
 	.xpo_recvfrom = svc_tcp_recvfrom,
 	.xpo_sendto = svc_tcp_sendto,
 	.xpo_release_rqst = svc_release_skb,
-	.xpo_detach = svc_sock_detach,
+	.xpo_detach = svc_tcp_sock_detach,
 	.xpo_free = svc_sock_free,
 	.xpo_prep_reply_hdr = svc_tcp_prep_reply_hdr,
(Continue reading)

Permalink | Reply | 6 comments |
headers
Marcin Slusarz | 1 Dec 2008 01:18
Picon

Re: next-2008-11-28 : can't mount UDF DVD

On Mon, Dec 01, 2008 at 12:44:05AM +0100, Laurent Riffard wrote:
> Hi,
> 
> With next-2008-11-28, I was unable to mount an UDF-formatted DVD-RW:
> 
> ~$ mount -oro -t udf /dev/sr0 /media/cdrom/
> mount: Not a directory
> 
> There was no problem with 2.6.28-rc6.
> 
> I made a bisection:
> 
> 33284bdf40f88160a154202510b27d983138c805 is first bad commit
> commit 33284bdf40f88160a154202510b27d983138c805
> Author: Marcin Slusarz <marcin.slusarz <at> gmail.com>
> Date:   Sun Nov 16 20:52:19 2008 +0100
> 
>     udf: implement mode and dmode mounting options
> 
>     "dmode" allows overriding permissions of directories and
>     "mode" allows overriding permissions of files.
> 
>     Signed-off-by: Marcin Slusarz <marcin.slusarz <at> gmail.com>
>     Cc: Jan Kara <jack <at> suse.cz>
>     Signed-off-by: Jan Kara <jack <at> suse.cz>
> 
> 
> Indeed, with this commit, I *must* use the dmode option to mount my DVD:

That's not intended behaviour... ;)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Trond Myklebust | 1 Dec 2008 01:19
Picon

Re: [PATCH 2/3] SUNRPC: We only need to call svc_delete_xprt() once...

Use XPT_DEAD to ensure that we only call xpo_detach & friends once.

Signed-off-by: Trond Myklebust <Trond.Myklebust <at> netapp.com>
---

 net/sunrpc/svc_xprt.c |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index bf5b5cd..a417064 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
 <at>  <at>  -838,6 +838,10  <at>  <at>  void svc_delete_xprt(struct svc_xprt *xprt)
 {
 	struct svc_serv	*serv = xprt->xpt_server;

+	/* Only do this once */
+	if (test_and_set_bit(XPT_DEAD, &xprt->xpt_flags) != 0)
+		return;
+
 	dprintk("svc: svc_delete_xprt(%p)\n", xprt);
 	xprt->xpt_ops->xpo_detach(xprt);

 <at>  <at>  -851,13 +855,14  <at>  <at>  void svc_delete_xprt(struct svc_xprt *xprt)
 	 * while still attached to a queue, the queue itself
 	 * is about to be destroyed (in svc_destroy).
 	 */
-	if (!test_and_set_bit(XPT_DEAD, &xprt->xpt_flags)) {
-		BUG_ON(atomic_read(&xprt->xpt_ref.refcount) < 2);
-		if (test_bit(XPT_TEMP, &xprt->xpt_flags))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Trond Myklebust | 1 Dec 2008 01:20
Picon

Re: [PATCH 3/3] SUNRPC: svc_xprt_enqueue should not refuse to enqueue 'XPT_DEAD' transports

Aside from being racy (there is nothing preventing someone setting XPT_DEAD
after the test in svc_xprt_enqueue, and before XPT_BUSY is set), it is
wrong to assume that transports which have called svc_delete_xprt() might
not need to be re-enqueued.

See the list of deferred requests, which is currently never going to
be cleared if the revisit call happens after svc_delete_xprt(). In this
case, the deferred request will currently keep a reference to the transport
forever.

The fix should be to allow dead transports to be enqueued in order to clear
the deferred requests, then change the order of processing in svc_recv() so
that we pick up deferred requests before we do the XPT_CLOSE processing.

Signed-off-by: Trond Myklebust <Trond.Myklebust@...>
---

 net/sunrpc/svc_xprt.c |  124 +++++++++++++++++++++++++++----------------------
 1 files changed, 69 insertions(+), 55 deletions(-)

diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index a417064..b54cf84 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
 <at>  <at>  -297,10 +297,15  <at>  <at>  void svc_xprt_enqueue(struct svc_xprt *xprt)
 	struct svc_serv	*serv = xprt->xpt_server;
 	struct svc_pool *pool;
 	struct svc_rqst	*rqstp;
+	unsigned long flags;
 	int cpu;
(Continue reading)

Permalink | Reply | 12 comments |
headers
Enrico Weigelt | 1 Dec 2008 01:19
Picon

Re: Developing non-commercial drivers ?

* Fredrik Markström <fredrik.markstrom <at> avalonenterprise.com> wrote:

Hi,

> I'm working for as a consultant for a large hardware company porting
> Linux to their new cpu-architecture and everything is pretty much
> up and running. Now they want us to develop a closed-source (to
> protect their IP) ethernet driver for their proprietary Ethernet MAC.

Much of this already had been answered, but just to summarize:

* technically, binary drivers are a very bad idea - just look at 
  the utterly broken nv crap. 
* IMHO, as soon as you include some kernel-internal headers, you've
  got an derived work, thus violating GPL (IANAL!)
* binary-only drivers DON NOT protect IP, just delay the process 
  of revealing a little bit.
* try to find out whether the customer *really* has some valueble 
  IP to protect or if it's just it's default oppionion
* *if* the customer still wants an binary-only driver, you check 
  whether the logic to hide can be moved to userland (let the userland
  part talk to the in-kernel driver via 9P)
* let your customer know that binary-only drivers tend to heavily 
  damage a company's reputation in the OSS world, *BAD* for marketing.

just my 0.02,-

cu
--

-- 
---------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Trond Myklebust | 1 Dec 2008 01:29
Picon

Re: [PATCH 0/3] NFS regression in 2.6.26?, "task blocked for more than 120 seconds"

On Sun, 2008-11-30 at 19:17 -0500, Trond Myklebust wrote:
> Can you see if the following 3 patches help? They're against 2.6.28-rc6,
> but afaics the problems are pretty much the same on 2.6.26.
> 
> Cheers
>   Trond

Sorry... I forgot to add that these 3 patches need to be applied to the
nfs server, not the client.

Cheers
  Trond
--

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 9 comments |

Gmane