All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] ipv4: fix ipsec forward performance regression
From: Yan, Zheng @ 2011-10-24  0:41 UTC (permalink / raw)
  To: Julian Anastasov
  Cc: netdev@vger.kernel.org, davem@davemloft.net,
	eric.dumazet@gmail.com, Kim Phillips
In-Reply-To: <alpine.LFD.2.00.1110231533410.1499@ja.ssi.bg>

On 10/23/2011 10:52 PM, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Sun, 23 Oct 2011, Yan, Zheng wrote:
> 
>> There is bug in commit 5e2b61f(ipv4: Remove flowi from struct rtable).
>> It makes xfrm4_fill_dst() modify wrong data structure.
>>
>> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
>> ---
>>  net/ipv4/xfrm4_policy.c |   14 +++++++-------
>>  1 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
>> index fc5368a..a0b4c5d 100644
>> --- a/net/ipv4/xfrm4_policy.c
>> +++ b/net/ipv4/xfrm4_policy.c
>> @@ -79,13 +79,13 @@ static int xfrm4_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
>>  	struct rtable *rt = (struct rtable *)xdst->route;
>>  	const struct flowi4 *fl4 = &fl->u.ip4;
>>  
>> -	rt->rt_key_dst = fl4->daddr;
>> -	rt->rt_key_src = fl4->saddr;
>> -	rt->rt_key_tos = fl4->flowi4_tos;
>> -	rt->rt_route_iif = fl4->flowi4_iif;
>> -	rt->rt_iif = fl4->flowi4_iif;
>> -	rt->rt_oif = fl4->flowi4_oif;
>> -	rt->rt_mark = fl4->flowi4_mark;
>> +	xdst->u.rt.rt_key_dst = fl4->daddr;
>> +	xdst->u.rt.rt_key_src = fl4->saddr;
>> +	xdst->u.rt.rt_key_tos = fl4->flowi4_tos;
>> +	xdst->u.rt.rt_route_iif = fl4->flowi4_iif;
> 
> 	May be I'm missing something but I don't see where
> flowi4_iif is set for the forwarding case. __xfrm_route_forward
> calls xfrm_decode_session which does not appear to set
> flowi4_iif. When providing fl4 for output routes flowi4_iif
> is always set to 0, so it represents rt_route_iif. But
> then there are 2 variants for __ip_route_output_key:
> 
> - ip_route_output_slow sets flowi4_iif to loopback and
> flowi4_oif to outdev during lookup but never restores them
> to original values. It is assumed that caller uses outdev
> from dst, not from flowi4_oif.
> 
> - for cached route we do not update flowi4_iif and flowi4_oif
> in __ip_route_output_key, so the resulting fl4 can not be
> used for these values. I assume, the current rules are that
> only fl4.saddr and daddr are updated while flowi4_iif and
> flowi4_oif are not. It looks wrong flowi code to rely on them.
> 
> 	Currently, we have 3 values for devices:
> 
> rt_iif: indev for input routes, resulting outdev for output routes
> which plays the role as indev for loopback traffic.
> 
> rt_oif: original outdev key, 0 for input routes, can be 0 for
> output routes if socket is not bound to oif
> 
> rt_route_iif: indev for input routes, 0 for output routes
> 
> 	With above rules for flowi4_iif and flowi4_oif
> it is impossible to select value for rt_iif from fl4.
> 
> 	I don't know the xfrm code well, may be after the

Neither do I. My understanding is that xfrm_dst(s) are managed by the
flow cache (net/core/flow.c). We don't put them into the routing cache.

Regards
Yan, Zheng 

> mentioned change we damaged rt_oif and rt_route_iif values
> for cached dst which can lead to using slow path all the time.
> Even if rt_intern_hash() avoids caching similar dsts multiple
> times, if cached entry is damaged we will add more and
> more new entries after every damage.
> 
>> +	xdst->u.rt.rt_iif = fl4->flowi4_iif;
>> +	xdst->u.rt.rt_oif = fl4->flowi4_oif;
>> +	xdst->u.rt.rt_mark = fl4->flowi4_mark;
>>  
>>  	xdst->u.dst.dev = dev;
>>  	dev_hold(dev);
> 
> Regards
> 
> --
> Julian Anastasov <ja@ssi.bg>

^ permalink raw reply

* Re: [PATCH] x86: Fix S4 regression
From: Yinghai Lu @ 2011-10-24  0:29 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: Linus Torvalds, Rafael J.Wysocki, x86, linux-kernel
In-Reply-To: <s5hwrbvv227.wl%tiwai@suse.de>

On 10/23/2011 02:19 PM, Takashi Iwai wrote:

> The commit 4b239f458: [x86-64, mm: Put early page table high] causes
> a S4 regression since 2.6.39, namely the machine reboots occasionally
> at S4 resume.  It doesn't happen always, overall rate is about 1/20.
> But, like other bugs, once when this happens, it continues to happen.
> 
> This patch fixes the problem by essentially reverting the memory
> assignment in the older way.
> 
> Cc: <stable@kernel.org>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> 
> ---
> I resend this as a "fix" patch now before it's forgotten and rotten.
> It's just papering again over the mystery, but IMO better than the
> hard-reset behavior as of now.  Unfortunately, bisection is pretty 
> much difficult because the bug itself is fairly unstable...



Did you try to check several commit that Rafael pointed out:


On Wed, Sep 28, 2011 at 12:30 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday, September 28, 2011, Takashi Iwai wrote:
>>
>> If my previous test -- 2.6.37+Yinghai's patches didn't show the
>> problem -- is correct, it means that some change in 2.6.38 reacted
>> badly with Yinghai's patches, not about 2.6.39.  I'll check tomorrow
>> again whether this observation is really correct.
>
> Yes, that would be good to know, thanks for doing this!
>
> If that turns out to be the case, there are the following commits
> looking like worth checking:
>
> d344e38 x86, nx: Mark the ACPI resume trampoline code as +x
> 884b821 ACPI: Fix acpi_os_read_memory() and acpi_os_write_memory() (v2)
> d551d81 ACPI / PM: Call suspend_nvs_free() earlier during resume
> 2d6d9fd ACPI: Introduce acpi_os_ioremap()

Thanks

Yinghai Lu

^ permalink raw reply

* I am hoping to develop the linux kernel, which version should I modify
From: Jonathan Neuschäfer @ 2011-10-24  0:29 UTC (permalink / raw)
  To: kernelnewbies
In-Reply-To: <20111024002450.GC2590@debian.debian>

On Mon, Oct 24, 2011 at 02:24:50AM +0200, Jonathan Neusch?fer wrote:
> Well, thanks for this polite and informed post. :-)

I mean "easy to answer". :)

^ permalink raw reply

* [U-Boot] [PATCH] arch/arm/lib/board.c: fix build error
From: Simon Glass @ 2011-10-24  0:29 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1319406671-6360-1-git-send-email-wd@denx.de>

Hi Wolfgang,

On Sun, Oct 23, 2011 at 2:51 PM, Wolfgang Denk <wd@denx.de> wrote:
> Commit dc8bbea "arm: Use getenv_ulong() in place of getenv(), strtoul"
> introduced a build error for all ARM boards with network support:
>
> board.c: In function 'board_init_r':
> board.c:569: error: 's' undeclared (first use in this function)
> board.c:569: error: (Each undeclared identifier is reported only once
> board.c:569: error: for each function it appears in.)
>
> Fix it.

This might fix all boards if they have both net and flash, or neither.
But I sent a patch which tries to handle the case where we have one
but not the other.

(I suspect the PPC warning might be similar, but will wait until I
have done a MAKEALL before commenting on that)

Regards,
Simon

>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> ---
> ?arch/arm/lib/board.c | ? ?3 +++
> ?1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index c764844..367cf6b 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -441,6 +441,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
> ?#if !defined(CONFIG_SYS_NO_FLASH)
> ? ? ? ?ulong flash_size;
> ?#endif
> +#if defined(CONFIG_CMD_NET)
> + ? ? ? char *s;
> +#endif
>
> ? ? ? ?gd = id;
>
> --
> 1.7.6.2
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

^ permalink raw reply

* I am hoping to develop the linux kernel, which version should I modify
From: Jonathan Neuschäfer @ 2011-10-24  0:24 UTC (permalink / raw)
  To: kernelnewbies
In-Reply-To: <CAAgJb5vWfnQ9ZU-D6g5oqwv=OKMi4qbfNBTzAgT8C5pVtAcv4Q@mail.gmail.com>

On Mon, Oct 24, 2011 at 08:08:31AM +0800, Jimmy Pan wrote:
> There is a 3.0 in my hard disk, which I downloaded around Aug 10. There is
> 3.0.4 and 3.1-rc4 code. Which version should I use. Since I am a newbie, I
> think I don't need to use the newest version. Can I use my 3.0 version, or
> should I download a new one?

A lot of people use Git[0] to download and manage their kernel source
code, but you can also use the latest mainline (2.6.39, 3.0, ...) or
-rc release, if you like.

To get the kernel source via git, run this (it'll take a while, because
it downloads around 200 megabytes):

  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

> Maybe I can read the kernel source on the web, is there a way to use the
> source on web to make patches?

You can read the linux source code on the web[1,2], but you sure need
it on your own computer, if you're going to change things.

> Thanks in advance.

Well, thanks for this polite and informed post. :-)

[0] http://git-scm.com/
[1] http://lxr.linux.no/linux
[2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree


Greetings,
	Jonathan Neusch?fer

^ permalink raw reply

* [U-Boot] [PATCH 02/10] arm: Use getenv_ulong() in place of getenv(), strtoul
From: Simon Glass @ 2011-10-24  0:19 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20111023214901.3E4961408771@gemini.denx.de>

Hi Wolfgang,

On Sun, Oct 23, 2011 at 2:49 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1318552994-6653-3-git-send-email-sjg@chromium.org> you wrote:
>> This changes the board code to use the new getenv_ulong() function.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>> ?arch/arm/lib/board.c | ? 36 +++++++++++-------------------------
>> ?1 files changed, 11 insertions(+), 25 deletions(-)
>
> Urgh...
>
> This breaks almost all ARM boards like this:
>
> Configuring for a320evb board...
> board.c: In function 'board_init_r':
> board.c:569: error: 's' undeclared (first use in this function)
> board.c:569: error: (Each undeclared identifier is reported only once
> board.c:569: error: for each function it appears in.)
> make[1]: *** [/work/wd/tmp-arm/arch/arm/lib/board.o] Error 1
> make: *** [/work/wd/tmp-arm/arch/arm/lib/libarm.o] Error 2

Sorry, I have sent a patch for this.

>
>
> Didn't you run MAKELL?

No these pre-date my getting that running (with Mike's help) and I
didn't think to go back to this series.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> ADVISORY: ?There is ?an ?Extremely Small ?but ?Nonzero ?Chance ?That,
> Through a Process Know as "Tunneling," This Product May Spontaneously
> Disappear ?from Its Present Location and Reappear at Any Random Place
> in the Universe, Including Your Neighbor's Domicile. The Manufacturer
> Will Not Be Responsible for Any Damages ?or ?Inconvenience ?That ?May
> Result.
>

^ permalink raw reply

* [U-Boot] [PATCH] arm: Correct build error introduced by getenv_ulong() patch
From: Simon Glass @ 2011-10-24  0:14 UTC (permalink / raw)
  To: u-boot

Commit dc8bbea removed a local variable that is used in most ARM boards.

Since we want to avoid an 'unused variable' warning with later compilers,
and the #ifdef logic of whether this variable is required is bit painful,
this declares the variable local to the block of code that needs it.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/arm/lib/board.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index c764844..3c147d1 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -477,6 +477,8 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	flash_size = flash_init();
 	if (flash_size > 0) {
 # ifdef CONFIG_SYS_FLASH_CHECKSUM
+		char *s;
+
 		print_size(flash_size, "");
 		/*
 		 * Compute and print flash CRC if flashchecksum is set to 'y'
@@ -566,9 +568,13 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	/* Initialize from environment */
 	load_addr = getenv_ulong("loadaddr", 16, load_addr);
 #if defined(CONFIG_CMD_NET)
-	s = getenv("bootfile");
-	if (s != NULL)
-		copy_filename(BootFile, s, sizeof(BootFile));
+	{
+		char *s;
+
+		s = getenv("bootfile");
+		if (s != NULL)
+			copy_filename(BootFile, s, sizeof(BootFile));
+	}
 #endif
 
 #ifdef BOARD_LATE_INIT
-- 
1.7.3.1

^ permalink raw reply related

* Re: [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Kamble, Nitin A @ 2011-10-24  0:07 UTC (permalink / raw)
  To: Martin Jansa; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <20111023062813.GC3497@jama.jama.net>

Hi Martin,
  I tested python inside qemux86-64 and it was working fine. I could test small python scripts working as expected.
Thanks,
Nitin


> -----Original Message-----
> From: Martin Jansa [mailto:martin.jansa@gmail.com]
> Sent: Saturday, October 22, 2011 11:28 PM
> To: Kamble, Nitin A
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> from 2.6.6 to 2.7.2
> 
> On Sat, Oct 22, 2011 at 04:54:00PM -0700, Kamble, Nitin A wrote:
> > Hi Martin,
> >   I have kept my python work at nitin/python branch on poky contrib.
> the 2.7.2 python is working for all arches except arm. And I am going
> on vacation for few days, and I could not finish the python arm issue
> arm, so if you get a chance you can look into the arm issue, if you
> have not resolved it already then I will look into it again once I am
> back from my vacation on 13th Nov.
> 
> Hi Nitin,
> 
> I've tried already and failed, but I'll try again and I guess qemux86-
> 64 (linking to host libc and failing if it's not same version as the
> one in
> sysroot) is also still broken and should be taken care of too, right?
> 
> Regards,
> 
> > > -----Original Message-----
> > > From: openembedded-core-bounces@lists.openembedded.org
> > > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> > > Of Martin Jansa
> > > Sent: Friday, October 14, 2011 2:12 AM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [review/test 3/5] python, python-native:
> > > upgrade from 2.6.6 to 2.7.2
> > >
> > > On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> > > > On Thu, Oct 13, 2011 at 04:06:13PM -0700,
> nitin.a.kamble@intel.com
> > > wrote:
> > > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > > >
> > > >
> > > > This patch does not apply after
> > > > 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
> > > >
> > > > can you rebase on top of oe-core?
> > > >
> > > > Also please drop
> > > > DEFAULT_PREFERENCE = "-27"
> > > >
> > > > we have only one python version so I guess it's not usefull at
> all
> > > > anymore
> > > >
> > > > I'll apply it manually, test it here.. and report if those
> modules
> > > are
> > > > build later..
> > >
> > > seems the same as with previous version..
> > >
> > > log.do_compile full of
> > > /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so:
> file
> > > not recognized: File format not recognized
> > > collect2: ld returned 1 exit status
> > >
> > > and only built module is sqlite
> > > OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0
> $
> > > ls Python-2.7.2/build/lib.linux-x86_64-2.7/
> > > _sqlite3.so
> > >
> > > while with 2.6 we had a lot of modules $ ls
> > > Python-2.6.6/build/lib.linux-x86_64-2.6/
> > > _bisect.so          _codecs_jp.so    _ctypes.so        _fileio.so
> > > _json.so             _random.so   _testcapi.so  bz2.so
> > > datetime.so         itertools.so  parser.so    spwd.so
> > > unicodedata.so
> > > _bytesio.so         _codecs_kr.so    _ctypes_test.so
> _functools.so
> > > _locale.so           _socket.so   _weakref.so   cPickle.so
> fcntl.so
> > > math.so       pyexpat.so   strop.so    zlib.so
> > > _codecs_cn.so       _codecs_tw.so    _curses.so        _hashlib.so
> > > _lsprof.so           _sqlite3.so  array.so      cStringIO.so
> > > future_builtins.so  mmap.so       readline.so  syslog.so
> > > _codecs_hk.so       _collections.so  _curses_panel.so  _heapq.so
> > > _multibytecodec.so   _ssl.so      audioop.so    cmath.so
> gdbm.so
> > > nis.so        resource.so  termios.so
> > > _codecs_iso2022.so  _csv.so          _elementtree.so   _hotshot.so
> > > _multiprocessing.so  _struct.so   binascii.so   crypt.so
> grp.so
> > > operator.so   select.so    time.so
> > >
> > > Can you please test that you have non-empty python-syslog python-
> > > resource python-elementtree python-fcntl python-zlib?
> > > And test build for qemuarm, because I guess that it links to -
> native
> > > libpython2.7 when you're building qemux86 on x86 host.
> > >
> > > But it seems that python runtime works now, thanks!
> > >
> > > Regards,
> > > --
> > > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> 
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com



^ permalink raw reply

* Re: --root option in upstream shadow
From: Julian Pidancet @ 2011-10-24  0:06 UTC (permalink / raw)
  To: openembedded-core, Scott Garman, Julian Pidancet,
	pkg-shadow-devel
In-Reply-To: <20111022115412.GM16703@nekral.nekral.homelinux.net>

On Sat, Oct 22, 2011 at 12:54 PM, Nicolas François
<nicolas.francois@centraliens.net> wrote:
> Hello,
>
> I'm the upstream maintainer of the shadow utilities.
>
> I was informed of the OpenEmbedded's add_root_cmd_options patch and would
> like to integrate it upstream.
>
> First of all, thanks a lot for implementing this feature. I was asked
> multiple times for it or something similar, but never found time to work
> on it.
>
> I did not review it completely yet, but would have a question.
> What is the expected behavior when the utility authenticates the caller?
>  1] authenticate the caller in the caller's chroot
>  2] authenticate the caller in the target's chroot
>  3] both
>
> I currently think that 3] would be the right behavior: the caller needs to
> be authenticated to make sure it is allowed to use the tool, then it
> should be authenticated on the target to make sure the operation is
> allowed.
> ...But this is much more complex.
>
> If this is fine for you, I would prefer to disable this feature when the
> utility is setuid and not executed by root.
>
> Best Regards,

Hi Nicolas,

I'm affraid this patch does not do what you think it does. The --root
option does not apply to login, but only to the various administrative
tools that comes with it (gpasswd, groupadd, groupdel, groupmod,
grpconv, grpunconv, passwd, pwconv, pwunconv, useradd, userdel).

It allows OE to manipulate passwd and group files that are located in
a sysroot by chrooting into it, because all these programs have their
path to /etc/passwd and friends hardcoded.

This way, when OE builds a package which needs a special user to be
present at run-time, it can create the user off-line at build-time
instead of beeing required to create post-install scripts which does
the same job but has to be executed at run-time.

-- 
Julian



^ permalink raw reply

* I am hoping to develop the linux kernel, which version should I modify
From: Jimmy Pan @ 2011-10-24  0:08 UTC (permalink / raw)
  To: kernelnewbies

There is a 3.0 in my hard disk, which I downloaded around Aug 10. There is
3.0.4 and 3.1-rc4 code. Which version should I use. Since I am a newbie, I
think I don't need to use the newest version. Can I use my 3.0 version, or
should I download a new one?
Maybe I can read the kernel source on the web, is there a way to use the
source on web to make patches?
Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111024/d5bc7f7b/attachment.html 

^ permalink raw reply

* Re: Request for DIscussion: Cpufreq logging, and frequency floors
From: Dave Jones @ 2011-10-24  0:01 UTC (permalink / raw)
  To: Mark Brown; +Cc: Steven Finney (Palm GBU), cpufreq@vger.kernel.org
In-Reply-To: <20111023114802.GA15272@sirena.org.uk>

On Sun, Oct 23, 2011 at 12:48:03PM +0100, Mark Brown wrote:
 > On Fri, Oct 21, 2011 at 02:31:57PM -0700, Steven Finney (Palm GBU) wrote:
 > 
 > >  2) The ability to keep a diagnostic log of all the frequency changes so, 
 > > e.g., it's possible to determine if bad behavior (e.g. dropouts) is
 > > correlated with a low frequency.
 > 
 > This is a really good and useful idea but it seems to me like it would
 > be better done with the standard trace subsystem - that provides good
 > facilities for enabling and disabling the trace as needed and would make
 > it easy to tie in with the other subsystems that are in play.
 
Indeed. This sounds like the direction to go towards. Having played a little
with Steven Rostedt's kernelshark tool, I could see interesting things coming
from being able to correlate transitions with other system events graphically.

	Dave


^ permalink raw reply

* [dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules
From: Jonas Meurer @ 2011-10-23 23:30 UTC (permalink / raw)
  To: dm-crypt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

In the Debian bugreport #639832 [1], Simon Mackinlay pointed out, that
hardware-optimized crypto driver modules aren't loaded automatically
at cryptsetup invokation in the boot process (initramfs) in Debian.

I verified this. At least for setups with aes support compiled into
the kernel, and hardware-optimized aes drivers (aes-x86_64,
aesni-intel) built as modules (which is the default for Debian and
Ubuntu kernels), the hardware-optimized aes modules aren't loaded at
cryptsetup invokation. (Sure, this is tested with aes-encrypted
volumes.) I didn't have time to check other setups (e.g. everything
built as modules) yet.

Is this behaviour intended, or should the kernel select
hardware-optimized drivers by default in case they're available (even
as modules) and supported by hardware?

I'm happy to extend the initramfs scripts to load hardware-optimized
modules in case they're available before cryptsetup is invoked. But
that an implementation would be ugly and hard to maintain as it needs
to be updated for possible kernel crypto driver changes. I would
prefer a solution where the kernel crypto api took responsibility for
this task.

Greetings,
 jonas

[1] http://bugs.debian.org/639832
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOpKOwAAoJEFJi5/9JEEn+NEMP/RYIryt4pw/4ROxHUIZVJEi7
gsPNzLbqCjwQ89uRsbN6BHrwrLeR7/s8xNUU2e4ppFj34069PI//0/KkY5BwnrQt
LTxg9yiyWeQc0ajVfxTClq2ZtgL3pcN6FclXKTE+ffjYMxbfBbM5AT1ATAkI4AOy
A3KhiT3KzG0sXs0P1o+sP+/JB//QBj6uJcIfMy2lbI0yqhl39rs5U97eueSImwEw
6ZuRVm4MD4zXQVfufAeEAHrXcPJAUd4DQyINQcFv+Ar75bSVtqsyzxsfaJXABOjZ
E+o06Zfs0i4rCfH5S08Wsqdcywua69NSnsmYJZlaOgA16uxVqcLvjw9M8DYFnBWT
clUuEXIquqQInX/bEgtq6eLgJR/BHSxv4GRJ07fVeQMae5xYPNelnEaiov6ikRs2
jNODQ2EHr3vgXsR4k6VDN/ffXybtUkndulk42vEi+a5u9eNBXYLNe1tYwmX/Ylyx
qQmAbKZ0KS3jbBFKU8rUJxlL4BetYpH1+EUDmRAIX99y4SjxdV2/SG5WZHK+scOF
cf/durQK13jGu5SGT7cSodmnFo6lgdvFUm1F+fTz4Kou0Jlgl031byG0aX6cETQD
oTMyr1z2ToUKD0hI6HMdOXYQLydlnE3U94OwV7ph+CQsvcv02qCrKBTX6zUuZNeL
cqYw/o7Yao9lVKmeCNkk
=86Vz
-----END PGP SIGNATURE-----

^ permalink raw reply

* 3.1-rcX (8,9,10): kernel does not validate swapfile on disk(?) - WAS: vnc4server 4.1.1+X4.3.0-3 crashing under normal use
From: Justin Piszcz @ 2011-10-24  0:00 UTC (permalink / raw)
  To: submit; +Cc: linux-kernel
In-Reply-To: <alpine.DEB.2.02.1110221939380.26496@p34.internal.lan>

Package: vnc4server
Version: 4.1.1+X4.3.0-3
Architecture: amd64 (x86-64)
Kernel: 3.0-rc9

Current theory--

(Debian, ) You can close the bug report, my .swapfile was corrupted it 
appears! When I ran swapoff -a and re-launched VNC it did not crash 
anymore, unbelievable, I am also cc'ing the kernel mailing list on this one,
how come the kernel does not ALARM or WARN or BUG() when there is a problem 
with the swapfile, is there no validation?

I was testing many 3.1.0-rcX kernels (some of them crashed my machine) and 
it must have corrupted that file.  The weird part is it only seemed to 
(mainly) affect VNC, I also saw a coredump with xfs_db (randomly) and a 
memtest86+ showed ok after 1-2 passes.

Of course it was the last thing I decided to rule out and that was it-- it 
appears, so far it has not crashed in over an hour, whereas it would crash 
immediately in the past, over and over for several days so I stopped using 
VNC until I had time to look into this problem further.

Very interesting and putting this out there incase anyone else sees this 
problem in the future, maybe it will help someone else.  But I wish the 
kernel would alarm if there were some problem with the swapfile..  Even 
when swap was not in use, the presence of the [bad] file would cause vnc 
to coredump quickly (after launching chrome/thunderbird/etc)  After a 
swapoff -a -- all problems, gone. All is back to normal now.

I waited a few hours before sending this, still no problems/errors, very 
interesting, will update if any future coredumps, but none yet..

Justin.


>
> Problem: About 1-2 weeks ago (I apt-get dist-upgrade regularly), VNC server
> began crashing, e.g. if you launch thunderbird/google chrome or other 
> windows, the VNC server crashes.
>
> May be related to:
> http://old.nabble.com/Bug-424860%3A-eclipse-randomly-crashes-(VNC)-X-server-p11945956.html
> http://forums.fedoraforum.org/showthread.php?t=246145
>
> Example:
>
> $ strace -o /tmp/out -f Xvnc -geometry 1920x1200 -depth 24 -rfbauth 
> ~/.vnc/passwd :1
>
> Xvnc Free Edition 4.1.1 - built Mar 10 2010 22:35:30
> Copyright (C) 2002-2005 RealVNC Ltd.
> See http://www.realvnc.com for information on VNC.
> Underlying X server release 40300000, The XFree86 Project, Inc
>
>
> Sat Oct 22 19:38:49 2011
> vncext:      VNC extension running!
> vncext:      Listening for VNC connections on port 5901
> vncext:      created VNC server for screen 0
> error opening security policy file /etc/X11/xserver/SecurityPolicy
> Could not init font path element /usr/share/fonts/X11/Speedo/, removing from 
> list!
> Could not init font path element /usr/share/fonts/X11/CID/, removing from 
> list!
>
> Sat Oct 22 19:38:51 2011
> Connections: accepted: 0.0.0.0::53214
> SConnection: Client needs protocol version 3.8
> SConnection: Client requests security type VncAuth(2)
>
> Sat Oct 22 19:38:53 2011
> VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian 
> bgr888
> VNCSConnST:  Client pixel format depth 8 (8bpp) rgb max 3,3,3 shift 4,2,0
> VNCSConnST:  Client pixel format depth 24 (32bpp) little-endian rgb888
> Segmentation fault (core dumped)
>
> --
>
> Core backtrace:
>
> $ gdb /usr/bin/Xvnc ./core.Xvnc.26042
> GNU gdb (GDB) 7.3-debian
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/Xvnc...(no debugging symbols found)...done.
> [New LWP 26042]
>
> warning: Can't read pathname for load map: Input/output error.
> Core was generated by `Xvnc -geometry 1920x1200 -depth 24 -rfbauth 
> /home/user/.vnc/passwd :1'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00000000004cbed4 in ?? ()
> (gdb) bt
> #0  0x00000000004cbed4 in ?? ()
> #1  0x00000000004dd577 in ?? ()
> #2  0x00000000005832a2 in ?? ()
> #3  0x00000000005834ff in ?? ()
> #4  0x0000000000426d90 in ?? ()
> #5  0x000000000040be86 in ?? ()
> #6  0x00007f070be96ead in __libc_start_main ()
>   from /lib/x86_64-linux-gnu/libc.so.6
> #7  0x0000000000409259 in ?? ()
> #8  0x00007fff22a53788 in ?? ()
> #9  0x000000000000001c in ?? ()
> #10 0x0000000000000008 in ?? ()
> #11 0x00007fff22a54b2e in ?? ()
> #12 0x00007fff22a54b33 in ?? ()
> #13 0x00007fff22a54b3d in ?? ()
> #14 0x00007fff22a54b47 in ?? ()
> #15 0x00007fff22a54b4e in ?? ()
> #16 0x00007fff22a54b51 in ?? ()
> #17 0x00007fff22a54b5a in ?? ()
> #18 0x00007fff22a54b70 in ?? ()
> #19 0x0000000000000000 in ?? ()
> (gdb)
>
> --
>
>
> Strace output: (4M)
> http://home.comcast.net/~jpiszcz/20111022/vnc-strace.out
>
> From the $HOME/.vnc/*log file:
>
> (xfdesktop:5201): Wnck-CRITICAL **: wnck_workspace_get_number: assertion 
> `WNCK_IS_WORKSPACE (space)' failed
> libpager-Message: Setting the pager rows returned false. Maybe the setting is 
> not applied.
>
> Sat Oct 22 14:26:14 2011
> Connections: accepted: 0.0.0.0::49493
> SConnection: Client needs protocol version 3.8
> SConnection: Client requests security type VncAuth(2)
>
> Sat Oct 22 14:26:15 2011
> VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian 
> bgr888
> VNCSConnST:  Client pixel format depth 8 (8bpp) rgb max 3,3,3 shift 4,2,0
>
> Sat Oct 22 14:26:16 2011
> VNCSConnST:  Client pixel format depth 24 (32bpp) little-endian rgb888
> Gkr-Message: secret service operation failed: The name 
> org.freedesktop.secrets was not provided by any .service files
> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
>      after 143 requests (143 known processed) with 0 events remaining.
> xfce4-panel: Fatal IO error 11 (Resource temporarily unavailable) on X server 
> :1.0.
> xfdesktop: Fatal IO error 11 (Resource temporarily unavailable) on X server 
> :1.0.
> [31476:31476:297527619035:ERROR:chrome_browser_main_x11.cc(57)] X IO Error 
> detected
> xfwm4: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.0.
> xfce4-session: Fatal IO error 11 (Resource temporarily unavailable) on X 
> server :1.
> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
>      after 64951 requests (64951 known processed) with 0 events remaining.
> Thunar: Fatal IO error 11 (Resource temporarily unavailable) on X server 
> :1.0.
> wrapper: Fatal IO error 11 (Resource temporarily unavailable) on X server 
> :1.0.
> running 'ssh-agent -s -k'
> xfsettingsd: Fatal IO error 11 (Resource temporarily unavailable) on X server 
> :1.
> unset SSH_AUTH_SOCK;
> unset SSH_AGENT_PID;
> echo Agent pid 5181 killed;
>
>
> --
>
> Thoughts?
>
> Justin.
>

^ permalink raw reply

* [GIT PULL] ivtv, cx18: FM radio fixes
From: Andy Walls @ 2011-10-24  0:01 UTC (permalink / raw)
  To: linux-media; +Cc: Mauro Carvalho Chehab, Ian Armstrong, Sven Verdoolaege

Mauro,

Please pull two changes that fix FM radio in ivtv and cx18.  Thanks go
to Ian Armstrong for finding and fixing the ivtv problem.

Regards,
Andy


The following changes since commit 35a912455ff5640dc410e91279b03e04045265b2:

  Merge branch 'v4l_for_linus' into staging/for_v3.2 (2011-10-19 12:41:18 -0200)

are available in the git repository at:

  ssh://linuxtv.org/git/awalls/media_tree.git fm_radio

Andy Walls (1):
      cx18: Fix FM radio

Ian Armstrong (1):
      ivtv: Fix radio support

 drivers/media/video/cx18/cx18-driver.c |    2 ++
 drivers/media/video/ivtv/ivtv-driver.c |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)



^ permalink raw reply

* [RFC] libsas: the trouble with ata resets
From: Dan Williams @ 2011-10-23 23:48 UTC (permalink / raw)
  To: linux-scsi, IDE/ATA development list
  Cc: Skirvin, Jeffrey D, Jacek Danecki, edmund.nadolski, Luben Tuikov,
	Mark Salyzyn, Jack Wang, Hannes Reinecke, David Milburn

Currently libsas has a problem with prematurely dropping sata devices
during recovery.  Libata knows that some devices can take quite a
while to recover from a reset and re-establish the link.  The fact
that sas_ata_hard_reset() ignores its 'deadline'  parameter is
evidence that it ignores the link management aspects of what libata
wants from a ->hardreset() handler.

item1: teach sas_ata_hard_reset() to check that the link came back up.
 For direct attached devices the lldd will need the deadline
parameter, and for expander attached perform smp polling to wait for
the link to come back.

Now, during this time that libata is trying to recover the connection
in the host-eh context libsas will start receiving BCNs in the
host-workqueue context.  In the unfortunate cases libsas may take
removal action on a device that will come back with a bit more time.
While libata-eh is in progress libsas should not take any action on
the ata phys in question..

item2:  flush eh before trying to determine what action to take on a phy.

In the case of libsas not all resets are initiated by the eh process
(the sas transport class can reset a phy directly).  It seems libata
takes care to arrange for user requested resets to occur under the
control of eh, and libsas should do the same.

item3: teach all reset entry points to kick and flush eh for ata devices

A corollary for items 1 and 3 is that there is a difference between
scheduling the reset and performing the reset.
->lldd_I_T_nexus_reset() is currently called twice, once by sas-eh to
manage sas_tasks and again by ata-eh to recover the device.  Likely we
need a new ->lldd_ata_hard_reset() handler that is called by ata-eh,
while ->lldd_I_T_nexus_reset() cleans up the sas_tasks and just
schedules reset on the ata_port.

item4: allow for lldd's to provide a direct ->lldd_ata_hard_reset()
which can be assumed to only be called from ata-eh context.

Any other pain points in reset handling?

--
Dan

^ permalink raw reply

* [PATCH] sata_sis.c: trivial spelling fix
From: Chris Dunlop @ 2011-10-23 23:38 UTC (permalink / raw)
  To: linux-ide

Trivial spelling fix.

Signed-off-by: Chris Dunlop <chris@onthe.net.au>

diff --git a/drivers/ata/sata_sis.c b/drivers/ata/sata_sis.c
index 447d9c0..95ec435 100644
--- a/drivers/ata/sata_sis.c
+++ b/drivers/ata/sata_sis.c
@@ -104,7 +104,7 @@ static const struct ata_port_info sis_port_info = {
 };
 
 MODULE_AUTHOR("Uwe Koziolek");
-MODULE_DESCRIPTION("low-level driver for Silicon Integratad Systems SATA controller");
+MODULE_DESCRIPTION("low-level driver for Silicon Integrated Systems SATA controller");
 MODULE_LICENSE("GPL");
 MODULE_DEVICE_TABLE(pci, sis_pci_tbl);
 MODULE_VERSION(DRV_VERSION);

^ permalink raw reply related

* Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
From: NeilBrown @ 2011-10-23 23:44 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux PM list, mark gross, LKML, John Stultz, Alan Stern
In-Reply-To: <201110231516.36787.rjw@sisk.pl>

[-- Attachment #1: Type: text/plain, Size: 9478 bytes --]

On Sun, 23 Oct 2011 15:16:36 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Sunday, October 23, 2011, NeilBrown wrote:
> > On Sun, 23 Oct 2011 00:07:33 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > On Tuesday, October 18, 2011, NeilBrown wrote:

> > > > > 
> > > > > > With that problem solved, experimenting is much easier in user-space than in
> > > > > > the kernel.
> > > > > 
> > > > > Somehow, I'm not exactly sure if we should throw all kernel-based solutions away
> > > > > just yet.
> > > > 
> > > > My rule-of-thumb is that we should reserve kernel space for when
> > > >   a/ it cannot be done in user space
> > > >   b/ it cannot be done efficient in user space
> > > >   c/ it cannot be done securely in user space
> > > > 
> > > > I don't think any of those have been demonstrated yet.  If/when they are it
> > > > would be good to get those kernel-based solutions out of the draw (so yes:
> > > > keep them out of the rubbish bin).
> > > 
> > > I have one more rule.  If my would-be user space solution has the following
> > > properties:
> > > 
> > > * It is supposed to be used by all of the existing variants of user space
> > >   (i.e. all existing variants of user space are expected to use the very same
> > >   thing).
> > > 
> > > * It requires all of those user space variants to be modified to work with it
> > >   correctly.
> > > 
> > > * It includes a daemon process having to be started on boot and run permanently.
> > > 
> > > then it likely is better to handle the problem in the kernel.
> > 
> > By that set or rules, upowerd, dbus, pulse audio, bluez, and probably systemd
> > all need to go in the kernel.  My guess is that you might not find wide
> > acceptance for these rules.
> 
> Well, that's not what I thought.  Perhaps I didn't express that precisely
> enough.  Take systemd, for example.  You still can design and use a Linux-based
> system without systemd, so there's no requirement that _all_ variants of user
> space use the given approach.  The choice of whether or not to use systemd
> is not a choice between a working and non-working system.
> 
> However, this is not the case with the system daemon, becuase it's supposed
> to handle problems that aren't possible to address without it.  So either you
> use it, or you end up with a (slightly) broken system.

I think you are seeing a distinction that isn't there.

Every system needs a process to run as 'init' - as PID == 1.
It might be systemd, it might be sysv-init, it might be /bin/sh, but there
are tasks that process much perform and there must be exactly one process
performing those tasks and the test of the systems need to be able to work
with that task (or ignore if it it is wholely independent).

Similarly every system need one process to manage suspend.  It can be my
daemon or your daemon or Alan's daemon but it cannot be 2 or more of them
running at the same time as that doesn't make any more sense than having
systemd and init running at the same time.


>  
> > > > So I'd respond with "I'm not at all sure that we should throw away an
> > > > all-userspace solution just yet".  Particularly because many of us seem to
> > > > still be working to understand what all the issues really are.
> > > 
> > > OK, so perhaps we should try to implement two concurrent solutions, one
> > > kernel-based and one purely in user space and decide which one is better
> > > afterwards?
> > 
> > Absolutely.
> > 
> > My primary reason for entering this discussion is eloquently presented in
> >        http://xkcd.com/386/
> > 
> > Someone said "We need to change the kernel to get race-free suspend" and this
> > simply is not true.  I wanted to present a way to use the existing
> > functionality to provide race-free suspend - and now even have code to do it.
> > 
> > If someone else wants to write a different implementation, either in
> > userspace or kernel that is fine.
> > 
> > They can then present it as "I know this can be implemented in userspace, but
> > I don't like that solution for reasons X, Y, Z and so here is my better
> > kernel-space implementation" then that is cool.  We can examine X, Y, Z and
> > the code and see if the argument holds up.  Maybe it will, maybe not.
> > 
> > So far the only arguments I've seen for putting the code in the kernel are:
> > 
> >  1/ it cannot be done in userspace - demonstrably wrong
> 
> I'm not sure if that's correct.  If you meant "it can be done in user space
> without _any_ kernel modifications", I probably wouldn't agree.

I have code to do it correctly today with no kernel modifications.  It is
called "lsusd".   Proof by example.  Or can you show that lsusd doesn't work
correctly?


> 
> >  2/ it is more efficient in the kernel - not demonstrated or even
> >     convincingly argued
> 
> I don't agree with that, but let's see.

If you don't agree, then you presumably have a demonstration or a convincing
argument.  Can you share it?

> 
> >  3/ doing it in user-space is too confusing - we would need a clear
> >     demonstration that a kernel interface is less confusing - and still
> >     correct.  Also the best way to remove confusion is with clear
> >     documentation and sample code, not by making up new interfaces.
> 
> The user space solution makes up new interfaces too, although they are
> confined to user space.
> 
> To me, it all boils down to two factors: (1) the complexity and efficiency
> of the code needed to implement the feature and (2) the complexity of the
> resulting framework (be it in the kernel or in user space).
> 
> >  4/ doing it in the kernel makes it more accessible to multiple desktops.
> >     The success of freedesktop.org seems to contradict that.
> 
> I don't agree here too.  Is Android a member of freedesktop.org?
>

This is completely irrelevant.

The "multiple desktops" issue that you brought up is (as I understand it)
multiple desktops running on the same computer, whether concurrently or
sequentially.
Android simply does not face that issue - it is the only "desktop" and is in
complete control of the machine it runs on.
So it doesn't need to solve the issue, so it doesn't need to be a member of
freedesktop.org.


> > So if you can do it a "better" way, please do.  But also please make sure
> > you can quantify "better".   I claim that user-space solutions are "better"
> > because they are more flexible and easier to experiment with.  The "no
> > regressions" rule actively discourages experimentation in the kernel so
> > people should only do it if there is a clear benefit.
> 
> You seem to suppose that every kernel modification necessarily has a potential
> to lead to some regressions.  I'm not exactly use if that's correct
> (e.g. adding a new driver usually doesn't affect people who don't need it).

I think that experimenting in the kernel (or at least in the upstream kernel)
is likely to result in creating functionality that ultimately will
not get used - the whole point of experimenting is that you probably get it
wrong the first time.
If this happens we either:
  - remove the unwanted functionality, which could be considered a regression
    and so must be done very carefully
  - leave the unwanted functionality there thus creating clutter and a
    maintenance burden.

i.e. the point of the "no-regressions" reference is that it tends to make it
harder to remove mistakes.  Not impossible of course, but it requires a lot
more care and time.

So I am against adding code to the kernel until the problem is really well
understood.  From the sorts of discussion that has been going on both in
this thread and elsewhere I'm not convinced the problem really is well
understood at all.
I think we are very much at the stage where people should be experimenting
with solutions, sharing the results, and learning.

So please feel free to publish sample code - whether for the kernel or for
user-space.  But it will only be credible if it is a fairly complete
proposal - e.g. with sample code demonstrating how the kernel features are
used.

(my lsusd really needs a 'plugin' for pm_utils to get it to communicate with
lsusd rather than writing to /sys/power/state ... I should probably add
that.  Then it would be complete and usable on current desktops).



> 
> > User-space solutions are much easier to introduce and then deprecate.
> 
> That's demonstrably incorrect and the counter example is the hibernation user
> space interface.  The sheer amount of work needed to implement user
> space-driven hibernation and maintain that code shows that it's not exactly
> easy and it would be more difficult to deprecate than many existing kernel
> interfaces at this point.
> 
> So, even if you have implemented something in user space, the "no regressions"
> rule and deprecation difficulties will apply to it as well as to the kernel as
> soon as you make a sufficient number of people use it.

Can we agree then that we shouldn't impose any part of a possible solution on
anyone until it has been sensibly tested and reviewed in a variety of
different use cases and found to be reliable and usable?

I think that addresses my main concern with kernel-space additions - I fear
that parts of them will end up unnecessary and unused but we will be stuck
with them.

Thanks,
NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: linux-ti33x-psp_3.0+3.1rc SRCREV
From: Fernandes, Joel A @ 2011-10-23 23:41 UTC (permalink / raw)
  To: meta-ti@yoctoproject.org

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

Hi,

Just to avoid any merge conflicts, I'd like to inform that I am updating SRCREV to the latest in my next pull request which fixes this.

Thanks,
Joel

From: Fernandes, Joel A
Sent: Sunday, October 23, 2011 4:28 PM
To: 'meta-ti@yoctoproject.org'
Subject: linux-ti33x-psp_3.0+3.1rc SRCREV

Dear Koen,

In the last update to SRCREV,
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/commit/?id=ab07a0ea4be961a7e8c7b8b64a56ce6c730cd6e0

The Commit: c7fc664a6a36a4721b43dc287e410a2453f0b782 doesn't exist anymore in arago. Due to this the fetch breaks.

joel@minted ~/repo/linux-omap-2.6 $ git show c7fc664a6a36a4721b43dc287e410a2453f0b782
fatal: bad object c7fc664a6a36a4721b43dc287e410a2453f0b782

Either the Arago tree was rebased or the commit ID is not valid.

Thanks,
Joel

[-- Attachment #2: Type: text/html, Size: 4210 bytes --]

^ permalink raw reply

* [RFD] Network configuration data in sysfs
From: Kirill A. Shutemov @ 2011-10-23 23:35 UTC (permalink / raw)
  To: netdev
  Cc: David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, Greg Kroah-Hartman,
	Kay Sievers, Alexey Gladkov

Hi,

Currently there's no way to set or inspect network configuration (protocol
addresses, routes, etc.) through sysfs. Yes, we have netlink interface for
this, but sysfs has advantage:

- change or inspect network configuration using standard unix utilities
  (echo, cat, etc.). It's useful at least in restricted environment where
  no special utilities available -- initrd or stripped down busybox.

- transparent udev support. It would be nice to get this information to
  udev.

Is there something fundamental preventing us to have sysfs interface for
network configuration?

-- 
 Kirill A. Shutemov

^ permalink raw reply

* [U-Boot] [PATCH v2] NS16550: buffer reads
From: Graeme Russ @ 2011-10-23 23:30 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20111023221848.535F81408E9B@gemini.denx.de>

Hi Wolfgang,

On Monday, October 24, 2011, Wolfgang Denk <wd@denx.de> wrote:
> Dear Graeme Russ,
>
> In message <
CALButCJH8BVzfVh14D83WR2JOV89O9jvJO9VzzB7r_ZgKzZqeg@mail.gmail.com> you
wrote:
>>
>> > Problems happen only with multi-line input, so it is perfectly fine
>> > to handle just that - at the root cause, i. e. when input turns into
>> > multi-line input.
>>
>> Can the U-Boot command line handle multiple commands per line (delimited
by
>> ; for example)
>
> Yes, it can.
>
>> If so, could it not be possible that a Kermit/ymodem command followed by
a
>> time consuming command on the same line cause lost input?
>
> I don't think so.  All serial transfers use a protocol - and when the
> transfer is complete, it does not matter any more, because no more
> data are flowing.

My point is that the transfer turns off flow control - When the transfer
completes, flow control will be off when the next command begins to run.
If the next command is one which takes a long time to execute and it is on
the same line as the transfer command (i.e. no \r to send XOFF) and the
user types something then that input can be lost.

I think the solution is fairly trivial though - During the processing of
commands entered via readline(), cause an XOFF to be sent each time (i.e.
immediately before) the command string is dispatched a to the command
processor just in case the previous command called getc() (and thus caused
an XON to be sent)

Regards,

Graeme

^ permalink raw reply

* [U-Boot] (no subject)
From: E-Loan & Credit Home @ 2011-10-23 23:12 UTC (permalink / raw)
  To: u-boot



ELOAN FINANCE is a consulting group for international debt and equity project finance in addition to commercial mortgage finance in the WORLDWIDE market. We are certified loan lender and offer secured loans to individuals and companies at 2% low interest.We are focused on attempting to fill the void that exists where there are limited options for suitable funding of major corporate and real estate projects, and especially where the request is large. If you are interested in our offer please state briefly the following information to the management 

FIRST INFORMATION NEEDED ARE: 

Full Name:............................... 

Location(Address):................................. 

Marital status:........................... 

Contact Phone numbers:.................... 

Amount Needed:............................. 

Contact E-mail:......................... 

Occupation:.............................. 

Loan Duration ........................ 

Annual Income ...................... 

Brief Self Description........... 

Loan Purpose................ 

Contact us with this Email:eloan_agency141 at live.co.uk

Best Regards 

Mr.Benson Smith 

General Consultant 

Email: eloan_agency141 at live.co.uk

^ permalink raw reply

* [U-Boot] [PATCH v3] arm926ejs: add NXP LPC32x0 cpu series support
From: Vladimir Zapolskiy @ 2011-10-23 23:04 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <4EA200D9.9050206@aribaud.net>

Hi Albert,

On 22.10.2011 02:31, Albert ARIBAUD wrote:
> Hi Vladimir,
>
> Le 18/10/2011 17:55, Vladimir Zapolskiy a ?crit :
>> This change adds initial support for NXP LPC32x0 SoC series.
>>
>> Signed-off-by: Vladimir Zapolskiy<vz@mleia.com>
>> ---
>> Changes from v2 to v3:
>> * checkpatch.pl reports zero errors and warnings
>>
>> Changes from v1 to v2:
>> * BIT(n) and SBF(s, v) macro are not used anymore
>> * removed NS16550 and 14-clock UART definitions from uart.h
>> * added devices.c file, which contains standard UART preinitialization
>> routine
>> * added get_serial_clock() function, it returns actual frequency of
>> UART clock
>> * __udelay() realization is simplified, no need of interrupt handling
>
> As it stands, this is dead code until some board uses it; I imagine you
> have board waiting for this support. Can you submit the SoC and board
> code as a patch set? This way, it will be obvious for all that the SoC
> code in this patch has actual use.

you're right, I have a board to make support for. However I presume that 
U-boot maintainers won't be happy to include a board with 
CONFIG_ENV_IS_NOWHERE, and unfortunately flash driver isn't yet ready 
for publishing.

I'd like to get an advice, if you think that weakly supported but 
working U-boot on the board has chances to be included to arm-next I can 
send the patchset right now for review, otherwise I'll spend some time 
(one week approximately) to finish NAND driver.

-- 
With best wishes,
Vladimir

^ permalink raw reply

* Re: lsusd - The Linux SUSpend Daemon
From: NeilBrown @ 2011-10-23 23:04 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Alan Stern, John Stultz, mark gross, Linux PM list, LKML
In-Reply-To: <201110231448.23069.rjw@sisk.pl>

[-- Attachment #1: Type: text/plain, Size: 5777 bytes --]

On Sun, 23 Oct 2011 14:48:22 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Sunday, October 23, 2011, NeilBrown wrote:
> > On Fri, 21 Oct 2011 22:00:13 -0400 (EDT) Alan Stern
> > <stern@rowland.harvard.edu> wrote:
> > 
> > > On Sat, 22 Oct 2011, NeilBrown wrote:
> > > 
> > > > > >     It uses files in /var/run/suspend for all communication.
> > > > > 
> > > > > I'm not so keen on using files for communication.  At best, they are
> > > > > rather awkward for two-way messaging.  If you really want to use them,
> > > > > then at least put them on a non-backed filesystem, like something under
> > > > > /dev.
> > > > 
> > > > Isn't /var/run a tmpfs filesystem?  It should be.
> > > > Surely /run is, so in the new world order the files should probably go
> > > > there.   But that is just a detail.
> > > 
> > > On my Fedora-14 systems there is no /run, and /var/run is a regular 
> > > directory in a regular filesystem.
> > > 
> > > > I like files...  I particularly like 'flock' to block suspend.   The
> > > > rest.... whatever..
> > > > With files, you only need a context switch when there is real communication.
> > > > With sockets, every message sent must be read so there will be a context
> > > > switch.
> > > > 
> > > > Maybe we could do something with futexes...
> > > 
> > > Not easily -- as far as I can tell, futexes enjoy relatively little 
> > > support.  In any case, they provide the same service as a mutex, which 
> > > means you'd have to build a shared lock on top of them.
> > > 
> > > > > >     lsusd does not try to be event-loop based because:
> > > > > >       - /sys/power/wakeup_count is not pollable.  This could probably be
> > > > > >         'fixed' but I want code to work with today's kernel.  It will probably
> > > > > 
> > > > > Why does this matter?
> > > > 
> > > > In my mind an event based program should never block.  Every action should be
> > > > non-blocking and only taken when 'poll' says it can.
> > > > Reading /sys/power/wakeup_count can be read non-blocking, but you cannot find
> > > > out when it is sensible to try to read it again.  So it doesn't fit.
> > > 
> > > There shouldn't be any trouble about making wakeup_count pollable.  It
> > > also would need to respect nonblocking reads, which it currently does 
> > > not do.
> > 
> > Hmm.. you are correct.  I wonder why I thought it did support non-blocking
> > reads...
> > I guess it was the code for handling an interrupted system call.
> > 
> > I feel a bit uncomfortable with the idea of sysfs files that block but I
> > don't think I can convincingly argue against it.
> > A non-blocking flag could be passed in, but it would be a very messy change -
> > lots of function call signatures changing needlessly:  we would need a flag
> > to the 'show' method ... or add a 'show_nonblock' method which would also be
> > ugly.
> > 
> > 
> > But I think there is a need to block - if there is an in-progress event then
> > it must be possible to wait for it to complete as it may not be visible to
> > userspace until then.
> > We could easily enable 'poll' for wakeup_count and then make it always
> > non-blocking, but I'm not really sure I want to require programs to use poll,
> > only to allow them.  And without using poll there is no way to wait.
> > 
> > As wakeup_count really has to be single-access we could possibly fudge
> > something by remembering the last value read (like we remember the last value
> > written).
> > 
> > - if the current count is different from the last value read, then return
> >   it even if there are in-progress events.
> > - if the current count is the same as the last value read, then block until
> >   there are no in-progress events and return the new value.
> > - enable sysfs_poll on wakeup_count by calling sysfs_notify_dirent at the
> >   end of wakeup_source_deactivated .... or calling something in
> >   kernel/power/main.c which calls that.  However we would need to make
> >   sysfs_notify_dirent a lot lighter weight first.  Maybe I should do that.
> > 
> > Then a process that uses 'poll' could avoid reading wakeup_count except when
> > it has changed, and then it won't block.  And a process that doesn't use poll
> > can block by simply reading twice - either explicitly or by going around a 
> >    read then write and it fails
> > loop a second time.
> > 
> > I'm not sure I'm completely comfortable with that, but it is the best I could
> > come up with.
> 
> Well, you're now considering doing more and more changes to the kernel
> just to be able to implement something in user space to avoid making
> some _other_ changes to the kernel.  That doesn't sound right to me.

:-)   I thought I might get challenged on something like that.

I think the cases are different though.

I'm not presenting this code as a new feature.  I don't need new features -
I have user-space code which works correctly with the current kernel features.

However the precise usage of wakeup_count is a little unusual in that it
blocks when you read.  That doesn't mean that it cannot be used correctly,
but it might limit the options available to a user-space program which wants
to use it.   I was just looking at ways to generalise the existing interface
so that it matches the rest of the kernel better.  I see it much more as a
bug fix than as a new feature.

I'm not saying we need this patch, and I'm not even sure I like it.  I just
presented it as part of exploring exactly how the wakeup_count interface
really works.  It is an interface that I like and that does allow the
original suspend-race problem to be solved, but that does not mean it is
necessarily perfect.

Thanks,
NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active'
From: NeilBrown @ 2011-10-23 22:55 UTC (permalink / raw)
  To: Alexander Lyakas; +Cc: linux-raid
In-Reply-To: <CAGRgLy5mJ=WcnMiApw8+0AZ+AR=Hb72RdgEMCoVsN+5Vp=_CTg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Sun, 23 Oct 2011 11:03:14 +0200 Alexander Lyakas <alex.bolshoy@gmail.com>
wrote:

> Thanks, Neil.
> To end this long email thread: what is "more important": update time
> or event count? Or perhaps they are updated simultaneously?
> 

They are updated simultaneously.

There is no sense that one is more important than the other, but if you know
something about the recent history of the array, then combining that
knowledge with these details might provide you with more precise information
of some sort.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: [CONSOLIDATED PULL 24/27] texi2html: Added recipe from OE
From: Khem Raj @ 2011-10-23 22:35 UTC (permalink / raw)
  To: Saul Wold; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4EA4757A.5010106@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

On Sunday, October 23, 2011, Saul Wold <saul.wold@intel.com> wrote:
> On 10/23/2011 01:06 PM, Khem Raj wrote:
>>
>>
>> On Sunday, October 23, 2011, Saul Wold <sgw@linux.intel.com
>> <mailto:sgw@linux.intel.com>> wrote:
>>  > Needed to build oe-core with oe-core
>>
> Nope, this is needed on the target image to build OE-core with an OE-Core
image.

Ok
>
> Sau!
>>
>> Oe-Core with oe-core did u mean meta-oe in one place ?
>>  >
>>  > Signed-off-by: Saul Wold <sgw@linux.intel.com
>> <mailto:sgw@linux.intel.com>>
>>  > ---
>>  >  meta/recipes-extended/texi2html/texi2html_1.82.bb
>> <http://texi2html_1.82.bb> |   14 ++++++++++++++
>>  >  1 files changed, 14 insertions(+), 0 deletions(-)
>>  >  create mode 100644 meta/recipes-extended/texi2html/texi2html_1.82.bb
>> <http://texi2html_1.82.bb>
>>  >
>>  > diff --git a/meta/recipes-extended/texi2html/texi2html_1.82.bb
>> <http://texi2html_1.82.bb>
>> b/meta/recipes-extended/texi2html/texi2html_1.82.bb
>> <http://texi2html_1.82.bb>
>>  > new file mode 100644
>>  > index 0000000..f19b576
>>  > --- /dev/null
>>  > +++ b/meta/recipes-extended/texi2html/texi2html_1.82.bb
>> <http://texi2html_1.82.bb>
>>  > @@ -0,0 +1,14 @@
>>  > +DESCRIPTION = "Perl script that converts Texinfo to HTML"
>>  > +HOMEPAGE    = "http://www.nongnu.org/texi2html/"
>>  > +SECTION     = "console/utils"
>>  > +LICENSE     = "GPLv2"
>>  > +LIC_FILES_CHKSUM =
"file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
>>  > +
>>  > +PR = "r0"
>>  > +
>>  > +SRC_URI     =
>> "http://download.savannah.gnu.org/releases/texi2html/${P}.tar.bz2"
>>  > +
>>  > +SRC_URI[md5sum] = "a8a9193c0ac1bec2f3ca7be40a5a82eb"
>>  > +SRC_URI[sha256sum] =
>> "d69c1effc416896409003ea64fdb21152cc0a9a7c665d437a0a3bef9b588b4f1"
>>  > +
>>  > +inherit autotools
>>  > --
>>  > 1.7.6.4
>>  >
>>  >
>>  > _______________________________________________
>>  > Openembedded-core mailing list
>>  > Openembedded-core@lists.openembedded.org
>> <mailto:Openembedded-core@lists.openembedded.org>
>>  > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>  >
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>

[-- Attachment #2: Type: text/html, Size: 4301 bytes --]

^ permalink raw reply


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.