* Re: [Qemu-devel] [PATCH 3/3] monitor: add ability to dump SLB entries
From: Nishanth Aravamudan @ 2011-10-31 22:53 UTC (permalink / raw)
To: Alexander Graf, qemu-devel, qemu-ppc
In-Reply-To: <20111031041412.GG9698@truffala.fritz.box>
On 31.10.2011 [15:14:12 +1100], David Gibson wrote:
> Good points below. I forgot to CC Nish, the original patch author on
> my post, so I've added him to the list now.
>
> Nish, can you correct these problems and resend the patch please?
Yep, I'll work on this shortly.
> On Mon, Oct 31, 2011 at 04:35:54AM +0100, Alexander Graf wrote:
> >
> > On 31.10.2011, at 04:16, David Gibson wrote:
> >
> > > From: Nishanth Aravamudan <nacc@us.ibm.com>
> > >
> > > When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
> > > qemu monitor reports "dump_mmu: unimplemented". However, during
> > > bringup work, it can be quite handy to have the SLB entries, which are
> > > available in the CPUPPCState. This patch adds an implementation of
> > > info tlb for book3s, which dumps the SLB.
> > >
> > > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > ---
> > > target-ppc/helper.c | 32 +++++++++++++++++++++++++++-----
> > > 1 files changed, 27 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/target-ppc/helper.c b/target-ppc/helper.c
> > > index 137a494..29c7050 100644
> > > --- a/target-ppc/helper.c
> > > +++ b/target-ppc/helper.c
> > > @@ -1545,14 +1545,36 @@ static void mmubooke206_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> > > }
> > > }
> > >
> > > +static void mmubooks_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> > > + CPUState *env)
> > > +{
> > > + int i;
> > > + uint64_t slbe, slbv;
> > > +
> > > + cpu_synchronize_state(env);
> > > +
> > > + cpu_fprintf(f, "SLB\tESID\t\t\tVSID\n");
> > > + for (i = 0; i < env->slb_nr; i++) {
> > > + slbe = env->slb[i].esid;
> > > + slbv = env->slb[i].vsid;
> >
> > From cpu.h:
> >
> > #if defined(TARGET_PPC64)
> > /* Address space register */
> > target_ulong asr;
> > /* PowerPC 64 SLB area */
> > ppc_slb_t slb[64];
> > int slb_nr;
> > #endif
Being unfamiliar with qemu's coding style (and not immediately seeing it
in CODING_STYLE), would the right approach be to wrap this definition in
an #if defined(TARGET_PPC64)?
> > > + if (slbe == 0 && slbv == 0) {
> > > + continue;
> > > + }
> > > + cpu_fprintf(f, "%d\t0x%016" PRIx64 "\t0x%016" PRIx64 "\n",
> > > + i, slbe, slbv);
> > > + }
> > > +}
> > > +
> > > void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
> > > {
> > > - switch (env->mmu_model) {
> > > - case POWERPC_MMU_BOOKE206:
> > > + if (env->mmu_model == POWERPC_MMU_BOOKE206) {
> > > mmubooke206_dump_mmu(f, cpu_fprintf, env);
> > > - break;
> > > - default:
> > > - cpu_fprintf(f, "%s: unimplemented\n", __func__);
> > > + } else {
> > > + if ((env->mmu_model & POWERPC_MMU_64B) != 0) {
> >
> > I would actually prefer to explicitly keep the switch and match on
> > all implementations explicitly. Also, have you verified this works
> > without CONFIG_PPC64 set? In cpu.h I see the following:
> >
> > #if defined(TARGET_PPC64)
> > #define POWERPC_MMU_64 0x00010000
> > #define POWERPC_MMU_1TSEG 0x00020000
> > /* 64 bits PowerPC MMU */
> > POWERPC_MMU_64B = POWERPC_MMU_64 | 0x00000001,
> > /* 620 variant (no segment exceptions) */
> > POWERPC_MMU_620 = POWERPC_MMU_64 | 0x00000002,
> > /* Architecture 2.06 variant */
> > POWERPC_MMU_2_06 = POWERPC_MMU_64 | POWERPC_MMU_1TSEG | 0x00000003,
> > #endif /* defined(TARGET_PPC64) */
> >
> > So POWERPC_MMU_64B shouldn't be defined for qemu-system-ppc.
And similarly here, only have the MMU_2_06 and MMU_64B cases in the
switch be defined #if defined(TARGET_PPC64)?
Basically, asking if #ifdefs in the middle of functions are ok :)
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
From: Tom Warren @ 2011-10-31 22:54 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ1JVw=wMUoFc9Hyf_Q4cUJd5QXUwXtzshhW3QPq7uOGBA@mail.gmail.com>
^ permalink raw reply
* Re: [PATCH 00/17] drop unused Kconfig symbols
From: Paul Bolle @ 2011-10-31 22:55 UTC (permalink / raw)
To: Michal Marek
Cc: linux-kernel, Jesper Nilsson, Mikael Starvik,
Valdis.Kletnieks@vt.edu, Paul Mundt
In-Reply-To: <20111031224248.GB25411@sepie.suse.cz>
On Mon, 2011-10-31 at 23:42 +0100, Michal Marek wrote:
> On Mon, Oct 24, 2011 at 01:37:35PM +0200, Paul Bolle wrote:
> > 1) I've dropped five patches that were taken by the maintainers
> > (blackfin, unicore32, tomoyo, m68k, and staging). cris got a NAK (for an
> > invalid reason, but I guess I'll just try again after the v3.2 merge
> > window closes).
Just today Jesper Nilsson basically dropped that NAK. I assume Jesper
will try to carry the patch in (one of) their tree(s). Is that correct?
> > 4) I'll send these patches only to you and the people that added a tag.
> > Please tell me if you'd like me to also cc lkml and the maintainers. I
> > assumed cc'ing those addresses would not be helpful in this stage.
> >
> > Paul Bolle (17):
> > alpha: drop unused Kconfig symbol
> > sparc: drop unused Kconfig symbol
> > um: drop unused Kconfig symbol
> > sh: drop unused Kconfig symbol
Paul Mundt applied this one a few days ago. But I think git merge will
handle that somewhere down the road.
> > score: drop unused Kconfig symbols
> > m32r: drop unused Kconfig symbol
> > samples: drop unused Kconfig symbol
> > arm: at91: drop unused Kconfig symbol
> > (arm: drop unused Kconfig symbol -- skipped)
> > openrisc: drop unused Kconfig symbols
> > mips: drop unused Kconfig symbols
> > powerpc: 40x: drop unused Kconfig symbol
> > powerpc: drop unused Kconfig symbols
> > x86: drop unused Kconfig symbol
> > stmmac: drop unused Kconfig symbol
> > pci: drop unused Kconfig symbol
> > scsi: drop unused Kconfig symbol
>
> Applied except for the one arm commit.
Paul Bolle
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Jonas Meurer @ 2011-10-31 22:56 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <4EAE60AC.4010001@laposte.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey Quentin,
Am 31.10.2011 09:47, schrieb Quentin Lefebvre:
> Indeed, it seems that improvements can be done for the Debian
> installer to better handle crypto disks and partitions. With the
> little experience I have about using encrypted partitions with
> LUKS/cryptsetup under/over LVM, I would not have tried to attach an
> existing encrypted device through the installer menu, as I know
> pretty well that few scenarios are handled at this point.
> Hopelessly, what you had to do in your case was to switch to a
> console to make changes by hand or, if you could, wait for the
> reboot of your fresh install to edit the system files and mount old
> volumes this way.
>
> I agree on the point you mention, i.e. encryption could be better
> integrated in the installer so that assisted mounting of old
> encrypted partitions becomes possible. [...] I would be happy to
> help Debian developers regarding this kind of install, but I have
> always delayed the moment I contact them. If you are planning to do
> so, I would be interested to be included in the discussion and give
> my feedback too.
I'm pretty sure that help with cryptsetup integration into the Debian
Installer (D-I) is highly appreciated by the current D-I developers.
As a starting point, you might want to check the following resources:
request for support to integrate existing encrypted devices in D-I:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451535
slighly outdated wiki page about cryptsetup integration to D-I:
http://wiki.debian.org/DebianInstaller/PartmanCrypto
git repository with partman-crypto code:
http://anonscm.debian.org/gitweb/?p=d-i/partman-crypto.git
Greetings,
jonas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOryeYAAoJEFJi5/9JEEn+kRQP/0rYn8A/0w0PKJ7bCbkIxyC4
xh6QWG1quFCWiWXSQMqidWrXNv9Ht2TeJ58MMn/jk/rWJV8ZE7SGkkGW5h1Lf09m
bjPqd9GRajzWLtZC7GCx5EigaNdoCtrXA4qmwDVDf8S+0KpxWZVi5tmz9CB9tUp6
V4qK5Iti2v8mH+rNktlv2sQRDfmXr0fe0+LLVTk9VmKzgn3blQ6jd51VI+XtcjK6
Uw/Tr525KlL5iPjZy7DDEJ4P+36774Euc5VmZiDahdrnzwV6oeUzIjLTLwe4KEYQ
SDVu7T8eTaCY34c9KLAr1kCg0b8TzH4GSP2JXRkK6jGpYgzgTSFlHzi+OcTsiZ26
JZKGth6vs9IILpysCqGb53KyrVaKGAG2rVe8FdOtitYm2xOpLdNPHVs9x2XP0lFN
sqo4o6cRIWBsz8RIdU6ma6pPphWBEUZqsHzLqEHqEpZN2iA3RE7Kp/RyEsnSSdz5
ra6t1So9LX+6FaxrHf6u2ZzcZ7SJB5+p54HYxgKCoXXZ/g8X95Z7PlaOBSBkvN2c
uzleQ+2PCf+002CI+UcK9hmWsp6KxzZsTagilVFDFg+66c7IDfo5xK2acquq9a3l
OujoEfOyShjo9CdMMMBlSki4V8Kn9BFfk4m0g594fJ9DkJwVl9PMSESw4CJbWuCl
YaOA82xNdVhHO0ESful+
=GPw5
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC/PATCH 6/7] x86, mm: Prepare zone_sizes_init() for unification
From: David Rientjes @ 2011-10-31 22:56 UTC (permalink / raw)
To: Pekka Enberg; +Cc: x86, linux-kernel, Tejun Heo, Yinghai Lu, H. Peter Anvin
In-Reply-To: <1319811801-1725-6-git-send-email-penberg@kernel.org>
On Fri, 28 Oct 2011, Pekka Enberg wrote:
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index 6101894..12274fb 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -677,10 +677,14 @@ void __init initmem_init(void)
> static void __init zone_sizes_init(void)
> {
> unsigned long max_zone_pfns[MAX_NR_ZONES];
> +
> memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
> #ifdef CONFIG_ZONE_DMA
> max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
> #endif
> +#ifdef CONFIG_ZONE_DMA32
> + max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
> +#endif
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
> #ifdef CONFIG_HIGHMEM
> max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index f6b1f08..06c4360 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -624,6 +624,9 @@ static void __init zone_sizes_init(void)
> max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
> #endif
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
> +#ifdef CONFIG_HIGHMEM
> + max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
> +#endif
>
> free_area_init_nodes(max_zone_pfns);
> }
I'd just fold patch 7 into this, it doesn't make much sense to have add
CONFIG_HIGHMEM code for 64-bit, for example, just to make the next patch
simpler.
^ permalink raw reply
* Re: [PATCH 2/2] ext4: fix a typo in struct ext4_allocation_context
From: Ted Ts'o @ 2011-10-31 22:56 UTC (permalink / raw)
To: Robin Dong; +Cc: linux-ext4, Robin Dong
In-Reply-To: <1314272192-7414-2-git-send-email-hao.bigrat@gmail.com>
On Thu, Aug 25, 2011 at 07:36:32PM +0800, Robin Dong wrote:
> From: Robin Dong <sanbai@taobao.com>
>
> This patch change "bext" to "best".
>
> Signed-off-by: Robin Dong <sanbai@taobao.com>
Thanks, applied.
- Ted
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vvcr4ojvp.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Some cut-and-paste (or piping the e-mail to a command) would be necessary
> evil, though, as you would have GPG keys from more than one trusted person
> in your keyring, and when you are responding to a pull-request from person
> A, finding a valid commit signed by person B should not be a success, but
> at least should raise a warning.
Why?
The signer of the message needs to be printed out *anyway*. I can
match that up with the pull request, the same way I already match up
diffstat information.
So any extra cut-and-paste is (a) stupid, (b) unnecessary and (c) annoying.
It's also "bad user interface". The whole point is that we should make
the user interface *good*. Which means that the pushing side should
only need to add a "-s" to ask for signing, have to type his
passphrase (and even that would go away when using gpg-agent or
something), and perhaps a message (which would not be about the
signing, but about something that could be added to the merge commit.
And the receiving side would just do the "git pull" and automatically
just get notified that "Yes, this push has been signed by key Xyz
Abcdef"
Linus
^ permalink raw reply
* Re: [GIT] pull request for x86 platform drivers tree
From: Matthew Garrett @ 2011-10-31 22:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: platform-driver-x86
In-Reply-To: <CA+55aFwKz+-FeoZQB_Y1Oj1dEBo8LxjgLPUP=Nz0TXSTcdN2Ng@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
On Mon, Oct 31, 2011 at 03:49:19PM -0700, Linus Torvalds wrote:
> On Mon, Oct 31, 2011 at 6:24 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> > are available in the git repository at:
> > git://cavan.codon.org.uk/platform-drivers-x86.git for_linus
>
> So I've never seen this host before, and have no idea whose it is or
> why I should trust it..
>
> Please make me feel better about it.
Is this any help?
--
Matthew Garrett | mjg59@cavan.codon.org.uk
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)
From: jim burns @ 2011-10-31 23:00 UTC (permalink / raw)
To: Ian Campbell, xen-devel, xen-users
In-Reply-To: <1320060379.23193.72.camel@zakaz.uk.xensource.com>
On Mon October 31 2011, 11:26:19 AM, Ian Campbell wrote:
> On Mon, 2011-10-31 at 10:50 +0000, Ian Campbell wrote:
> > On Sat, 2011-10-29 at 06:57 +0100, jim burns wrote:
> > > [...]
> > > New to 4.1.2:
> > >
> > > 1) Starting winxp with xl does not create a vif interface - only a
> > > tap one. More exactly, the vif is created, but does not get an ipv6
> > > address - it shows up in 'ifconfig -a', or 'ifconfig vifn.0' - and
> > > does not get added to the bridge. If you are using James' GPLPV
> > > drivers, you end up with no network connectivity, as they use vif,
> > > not tap. I'd be surprised if other pvhvm solutions don't see this
> > > also.
> >
> > I see this with the tip of xen-4.1-testing too but not with
> > xen-unstable. I'll see if I can figure out which backport is missing...
>
> 23047:4ca13a170482 "libxl: provide full path to vif hotplug script
> script" seems like a very plausible candidate, I bet
> "script=/etc/xen/scripts/vif-bridge" would function as a workaround.
Yep - that works. Should have guessed. You have to supply the full path to the
config file too, or it can't find it (doesn't default to searching /etc/xen).
> > [...]
> >
> > > 2) If your vif= line in your config specifies a bridge, such as
> > > 'bridge=virbr0', the '-net tap' option to qemu-dm remains as
> > > 'bridge=xenbr0', as if it was hard coded. Again, this is an hvm
> > > problem. 'xl create'-ing a pv domu correctly puts the vif on the
> > > requested bridge. (If memory serves, under xen 4.1.1, when the vif
> > > for an hvm domain was being put on a bridge, I believe it was on
> > > the bridge requested, so the problem is just with tap.)>
> > Similarly I can reproduce this too but only on 4.1.
>
> Actually this one is broken in unstable too.
>
> The handling of leading and trailing whitespace in the vif option seems
> to be completely b0rked in xl and e.g. "bridge = virbr1" ends up as key
> "bridge " and key " virbr1". That entire parser (actually, both of them
> -- there's a whole nother one in main_networkattach!) is a mess.
>
> There's probably a bandaid which can be applied but really the whole
> thing need ripping out and making sensible.
>
> As a workaround in the meantime you can probably avoid whitespace around
> the "=" and "," in the vif line.
>
Yep - that works too:
root@insp6400 10/31/11 6:31PM:~
[512] > xl create /etc/xen/winxp; brctl show; ps -A|grep qemu; netstat -tlp|
grep 59; renice -11 `pidof qemu-dm`; ps -A|grep vncv; ifconfig vif3.0 mtu
9000
Parsing config file /etc/xen/winxp
xc: info: VIRTUAL MEMORY ARRANGEMENT:
Loader: 0000000000100000->000000000017b270
TOTAL: 0000000000000000->000000002fc00000
ENTRY ADDRESS: 00000000001015a0
xc: info: PHYSICAL MEMORY ALLOCATION:
4KB PAGES: 0x0000000000009a00
2MB PAGES: 0x0000000000000131
1GB PAGES: 0x0000000000000000
Daemon running with PID 6804
bridge name bridge id STP enabled interfaces
virbr0 8000.feffffffffff yes tap3.0
xenbr0 8000.0015c5047d4f no bond0
6809 pts/1 S+ 0:00 grep --color=auto qemu
6758 ? RLsl 0:00 qemu-dm -d 3 -domain-name winxp -vnc 0.0.0.0:3 -k
en-us -serial pty -videoram 4 -boot cda -usb -usbdevice tablet -soundhw es1370
-acpi -vcpus 2 -vcpu_avail 0x3 -net
nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
tap,vlan=0,ifname=tap3.0,bridge=virbr0,script=no -M xenfv
tcp 0 0 *:5901 *:*
LISTEN 3283/Xvnc
tcp 0 0 *:5903 *:*
LISTEN 6758/qemu-dm
6758 (process ID) old priority 0, new priority -11
6907 pts/1 S+ 0:00 grep --color=auto vncv
root@insp6400 10/31/11 6:32PM:~
[513] > brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.feffffffffff yes tap3.0
vif3.0
xenbr0 8000.0015c5047d4f no bond0
For 4):
On Mon October 31 2011, 10:56:51 AM, Ian Campbell wrote:
> On Sat, 2011-10-29 at 07:17 +0100, jim burns wrote:
> > On Sat October 29 2011, 1:57:12 AM, jim burns wrote:
> > > For the remaining problems, note that 'xl create winxp' creates a
> > > qemu-dm process with the following parameters:
> > >
> > > qemu-dm -d 8 -domain-name winxp -vnc 0.0.0.0:3 -k en-us -serial pty
> > > -videoram 4 -boot cda -usb -usbdevice tablet -soundhw es1370 -acpi
> > > -vcpus 2 -vcpu_avail 0x3 -net
> > > nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
> > > tap,vlan=0,ifname=tap8.0,bridge=xenbr0,script=no -M xenfv>
> > Note, starting the domain with 'xm create' with the same config results
> > in:
> >
> > /usr/lib/xen/bin/qemu-dm -d 11 -domain-name winxp -videoram 4 -k en-us
> > -vnc 0.0.0.0:3 -monitor vc -vcpus 2 -vcpu_avail 0x3 -boot cda -soundhw
> > es1370 - localtime -serial pty -acpi -usbdevice tablet -net
> > nic,vlan=1,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
> > tap,vlan=1,ifname=tap11.0,bridge=xenbr0 -M xenfv
> >
> > Note, 'xl create' does not pass the '-localtime' option,
>
> that's the source of one of the missing features. Fixing it should be a
> case of adding the option to libxl_domain_build_info in the IDL,
> reacting to it in libxl__build_device_model_args_old and
> libxl__build_device_model_args_new and parsing the config file option
> into it in parse_config_data().
Hopefully, the fix for 3) (vncconsole=1) is just as simple.
> > and its '-net tap' specifies 'script=no', unlike 'xm create'.
>
> This is expected, with xl the script for tap devices is run via the
> hotplug mechanism (i.e. the same as vif) whereas xend apparently runs it
> via qemu. Either _should_ work.
>
> > Also, for some reason, the vlan numbers are different between xl and xm.
>
> That's ok, they are effectively arbitrary and just serve to bind the
> "-net nic,..." and "-net tap,..." options to one another (IOW the vlan
> ID needs to be consistent across those two options but is otherwise
> unimportant).
Thanx for the explanations.
On Mon October 31 2011, 10:50:32 AM, Ian Campbell wrote:
> > 5) Anything other than 'videoram=4' in your config will be ignored when
> > starting with xl, but not with xm. You will get an error in your qemu-dm
> > log file of the form:
> >
> >
> > -videoram option does not work with cirrus vga device model. Videoram
> > set to 4M.
>
> I'm not sure what's going on here, since this appears to be a qemu thing
> and that is the same for xend and xl. Perhaps they are choosing
> differing graphics card device models? How do the command lines differ
> if you use this option?
With videoram=8, and 'xm create', you get what you expect:
6026 ? RLl 0:00 /usr/lib/xen/bin/qemu-dm -d 2 -domain-name
winxp -videoram 8 -k en-us -vnc 0.0.0.0:3 -monitor vc -vcpus 2 -vcpu_avail 0x3
-boot cda -soundhw es1370 -localtime -serial pty -acpi -usbdevice tablet -net
nic,vlan=1,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
tap,vlan=1,ifname=tap2.0,bridge=xenbr0 -M xenfv
Thanx for the thorough review.
^ permalink raw reply
* Re: [PATCH] ramoops appears geared to not support ARM
From: Bryan Freed @ 2011-10-31 23:03 UTC (permalink / raw)
To: Marco Stornelli; +Cc: linux-kernel, akpm, msb, seiji.aguchi
In-Reply-To: <4EAE630A.6040309@gmail.com>
On Mon, Oct 31, 2011 at 1:57 AM, Marco Stornelli
<marco.stornelli@gmail.com> wrote:
> Il 31/10/2011 07:03, Bryan Freed ha scritto:
>>
>> On Sun, Oct 30, 2011 at 4:33 AM, Marco Stornelli
>> <marco.stornelli@gmail.com> wrote:
>>>
>>> Il 30/10/2011 03:07, Bryan Freed ha scritto:
>>>>
>>>> Right, and that is what I do to get ARM working. The reserve() function
>>>> calls memblock_reserve() to reserve the memory for RAMOOPS. Keeping it
>>>> part of main memory (by not using memblock_remove()) gets the memory
>>>> properly mapped.
>>>>
>>>
>>> According to Russell, it needs to use memblock_remove to exclude that
>>> piece of memory.
>>>
>>>> The problem I think we need to resolve is that this makes the ramoops
>>>> driver messy.
>>>
>>> I agree. Indeed I think we don't need to do anything in the driver. The
>>> problem is only how to exclude a piece of memory from kernel main memory
>>> view. For x86 it's trivial, for ARM it doesn't, but it's still possible.
>>>
>>> Marco
>>
>> I will give that (using mem_remove()) a shot tomorrow.
>> My recollection on using it in last week's investigation showed the
>> ramoops driver ioremap() giving a mapping that did not correspond with
>> what the /dev/mem expected to see. I vaguely recall /dev/mem was
>> effectively calling __va(0x02000000) which added a base address of
>> 0xc0000000 giving 0xc2000000 as the resulting virtual address. The
>> ramoops ioremap(), however, gave some arbitrary virtual address for
>> this memory.
>> The result was that using /dev/mem to read 0x02000000 caused a panic.
>
> I don't understand this point. We have different virtual addresses and then?
Yes, we get different virtual addresses.
The /dev/mem xlate_dev_mem_ptr() is defined (for ARM) as __va(), so it
gives 0xc2000000.
The ramoops ioremap() gives 0xef90000 because
__arm_ioremap_pfn_caller() makes a fresh get_vm_area_caller() call.
On x86, the /dev/mem xlate_dev_mem_ptr() gives an ioremap_cache()
address rather than a __va() address because it (properly?) detects
the memory is not RAM (because it was reserved by BIOS, so it was not
configured with system memory).
> The linear transformation with a fixed offset is the normal way for the
> kernel to have a virtual address from a physical one when you are using a
> memory address directly mapped. The virtual address returned by ioremap it
> can be an address not directly mapped, I mean it isn't a simple linear
> transformation of the physical address used in input.
Right, that is what I see on the ARM side as well.
__arm_ioremap_pfn_caller() gets a virtual address with
get_vm_area_caller().
> It isn't normal to have a kernel panic, even if there is something wrong,
> you should receive EINVAL or something similar.
Yeah, /dev/mem will give an EFAULT on ARM if (addr + count >
__pa(high_memory)). But we are not beyond the end of our physical
memory. We are somewhere in the middle. So read_mem() gets the
virtual address with xlate_dev_mem_ptr() which on ARM is just __va().
If this memory is memblock_removed, then that virtual address is not mapped.
Now that I look closer, we use copy_to_user(). So we should be
catching this fault.
I will take a closer look at this.
Either way, /dev/mem will not give us proper access to the ARM ramoops buffer.
>
>>
>> Another problem was that removing just 512KiB of memory for ramoops
>> screwed up the system memory initialization. It appeared to me that
>> the ARM memory code expected sections to be 1MiB aligned. I could
>> memblock_reserve anything, but I could only memblock_remove on a 1MiB
>> boundary.
>>
>
> It's an arch problem not related to the driver.
Yes, that is an arch problem. But it is another reason to move away
from memblock_remove() and toward memblock_reserve().
>> And I cannot shake the feeling that we have a fairly simple disconnect
>> here. Ramoops expects to use _device_ memory because it uses
>> ioremap(). But the buffer itself is accessed through /dev/mem which
>> (as we use it with no mmap() calls) expects to give access to _system_
>
> no mmap calls?! I don't understand how you are using /dev/mem.
open(), lseek(), read(). No mmap is required for RAM, right?
dd if=/dev/mem bs=1 count=1000 skip=32M
My point above about the disconnect between system memory and device
memory would be resolved if ramoops provided its own access to the
buffer. What do you think of that idea?
bryan.
> Marco
>
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 23:03 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF2724.8040001@zytor.com>
On Mon, Oct 31, 2011 at 3:54 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 10/31/2011 03:52 PM, Linus Torvalds wrote:
>>
>> Save it in the commit we generate. BAM! Useful, readable, permanent,
>> and independently verifiable.
>>
>
> Note: this means creating a commit even for a fast-forward merge. Not
> that there is any technical problem with that, of course.
Well, only for the signed case, but yes. And for that case it's likely
a good thing.
In fact, even without signing, some projects always use --no-ff,
because they want the merge messages with the nice summary in them.
I've played around with it too, but haven't generally found it to be
worth it, and tend to think that it aggrandizes the merger too much.
It generates nice merge summaries, and it can look nice, but if the
*only* upside is the merge summary I think it's borderline worth it.
But with a signature, it would suddenly actually contain real
information, and I think that changes the equation.
Linus
^ permalink raw reply
* [U-Boot] [PATCH 4/4] PXA: Adapt Voipac PXA270 to OneNAND SPL
From: Scott Wood @ 2011-10-31 23:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320067393-18822-5-git-send-email-marek.vasut@gmail.com>
On 10/31/2011 08:23 AM, Marek Vasut wrote:
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> ---
> board/vpac270/Makefile | 6 ++
> board/vpac270/onenand.c | 136 +++++++++++++++++++++++++++++++++++++++++++++
> board/vpac270/vpac270.c | 2 +
> include/configs/vpac270.h | 25 +++++++--
> 4 files changed, 164 insertions(+), 5 deletions(-)
> create mode 100644 board/vpac270/onenand.c
>
> diff --git a/board/vpac270/Makefile b/board/vpac270/Makefile
> index b5c60fd..f25822f 100644
> --- a/board/vpac270/Makefile
> +++ b/board/vpac270/Makefile
> @@ -23,7 +23,13 @@ include $(TOPDIR)/config.mk
>
> LIB = $(obj)lib$(BOARD).o
>
> +ifndef CONFIG_SPL_BUILD
> COBJS := vpac270.o
> +endif
> +
> +ifdef CONFIG_SPL_BUILD
> +COBJS := onenand.o
> +endif
else?
> SRCS := $(COBJS:.o=.c)
> OBJS := $(addprefix $(obj),$(COBJS))
> diff --git a/board/vpac270/onenand.c b/board/vpac270/onenand.c
> new file mode 100644
> index 0000000..50de2ab
> --- /dev/null
> +++ b/board/vpac270/onenand.c
> @@ -0,0 +1,136 @@
> +/*
> + * Voipac PXA270 OneNAND SPL
> + *
> + * Copyright (C) 2011 Marek Vasut <marek.vasut@gmail.com>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <common.h>
> +#include <config.h>
> +#include <asm/io.h>
> +#include <onenand_uboot.h>
> +
> +extern void pxa_dram_init(void);
> +
> +inline void spl_copy_self(void)
> +{
> + extern uint32_t _end;
> + struct spl_onenand_data data;
> + uint32_t page;
> + uint32_t total_bytes = (uint32_t)&_end - CONFIG_SPL_TEXT_BASE;
> + uint32_t total_pages;
> + uint8_t *addr = (uint8_t *)CONFIG_SPL_TEXT_BASE;
> + int ret;
> +
> + spl_onenand_get_geometry(&data);
> +
> + /* The page can be either 2k or 4k, avoid using DIV_ROUND_UP. */
> + total_pages = total_bytes >> 11;
> + if (data.pagesize == 4096)
> + total_pages >>= 1;
total_bytes / 2048 and total_pages / 2 are more readable and should
generate exactly the same code.
> + for (page = 0; page <= total_pages; page++) {
> + ret = spl_onenand_read_page(0, page, addr, data.pagesize);
> + if (ret)
> + total_pages++;
> + else
> + addr += data.pagesize;
> + }
> +}
You want to skip to the next block if spl_onenand_read_page() fails
(which can occur after you've already read some of the block).
How much of this is board-specific?
> +inline void spl_copy_uboot(void)
> +{
> + uint8_t *addr = (uint8_t *)CONFIG_SYS_TEXT_BASE;
> + struct spl_onenand_data data;
> + uint32_t total_pages;
> + uint32_t block;
> + uint32_t page, rpage;
> + int ret;
> +
> + spl_onenand_get_geometry(&data);
> +
> + /* The page can be either 2k or 4k, avoid using DIV_ROUND_UP. */
> + total_pages = CONFIG_SPL_ONENAND_LOAD_SIZE >> 11;
> + page = CONFIG_SPL_ONENAND_LOAD_ADDR >> 11;
> + if (data.pagesize == 4096) {
> + total_pages >>= 1;
> + page >>= 1;
> + }
> +
> + for (; page <= total_pages; page++) {
> + block = page >> 6;
> + rpage = page & 0xff;
> + ret = spl_onenand_read_page(block, rpage, addr, data.pagesize);
> + if (ret)
> + total_pages++;
> + else
> + addr += data.pagesize;
> + }
> +}
What is so different about this compared to spl_copy_self, that warrants
such duplication? Can't you just pass in offset, length, and
destination as parameters? Or just have the OneNAND SPL driver export
nand_spl_load_image(), as any other NAND SPL driver would?
> +inline void board_init_f(unsigned long unused)
> +{
> + uint32_t tmp;
> +
> + asm volatile("mov %0, pc" : "=r"(tmp));
> + tmp >>= 24;
> +
> + /* The code runs from OneNAND RAM, copy SPL to SRAM and execute it. */
> + if (tmp == 0) {
> + spl_copy_self();
> + asm volatile("mov pc, %0" : : "r"(CONFIG_SPL_TEXT_BASE));
> + }
Is it not possible to use a simple memcpy for spl_copy_self()? If the
CPU can run the code, you'd think it could read it.
> +inline void board_init_r(gd_t *id, ulong dest_addr)
> +{
> + for (;;)
> + ;
> +}
This doesn't seem like a useful board_init_r(). If you don't need it,
maybe make sure it's not called, and save yourself some bytes in the
SPL. Likewise for the other stub functions, where practical.
> +inline int printf(const char *fmt, ...)
> +{
> + return 0;
> +}
> +
> +inline void __coloured_LED_init(void) {}
> +inline void __red_LED_on(void) {}
> +void coloured_LED_init(void)
> + __attribute__((weak, alias("__coloured_LED_init")));
> +void red_LED_on(void)
> + __attribute__((weak, alias("__red_LED_on")));
> +void hang(void) __attribute__ ((noreturn));
> +void hang(void)
> +{
> + for (;;)
> + ;
> +}
> +
> +inline void icache_disable(void) {}
> +inline void dcache_disable(void) {}
Why are you specifying inline on just about everything, even functions
that are not used in this file?
Why are you not specifying static on things that are not needed outside
this file?
> diff --git a/board/vpac270/vpac270.c b/board/vpac270/vpac270.c
> index 43bbdff..f146009 100644
> --- a/board/vpac270/vpac270.c
> +++ b/board/vpac270/vpac270.c
> @@ -56,7 +56,9 @@ struct serial_device *default_serial_console(void)
> extern void pxa_dram_init(void);
> int dram_init(void)
> {
> +#ifndef CONFIG_ONENAND
> pxa_dram_init();
> +#endif
> gd->ram_size = PHYS_SDRAM_1_SIZE;
> return 0;
> }
Should this really be about whether OneNAND support is present, or
should it be based on whether you're using the OneNAND SPL?
-Scott
^ permalink raw reply
* Re: [PATCH 09/11] iptables: upgrade to version 1.4.12.1
From: Richard Purdie @ 2011-10-31 22:57 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <83141bc3f748c34d7f19a03c0517d804fadc6024.1319772853.git.dongxiao.xu@intel.com>
On Fri, 2011-10-28 at 11:35 +0800, Dongxiao Xu wrote:
> Remove the do_configure_prepend() since some m4 files are needed when
> doing configuration.
I think we're going to have to specifically delete the libtool m4 files
here. I know we've had problems with them being present in the past.
Also, there is no mention of the licence change here in the commit
message?
Cheers,
Richard
> Define correct FILE for iptables and iptables-dbg packages.
>
> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> ---
> .../{iptables_1.4.9.bb => iptables_1.4.12.1.bb} | 16 ++++++----------
> 1 files changed, 6 insertions(+), 10 deletions(-)
> rename meta/recipes-extended/iptables/{iptables_1.4.9.bb => iptables_1.4.12.1.bb} (69%)
>
> diff --git a/meta/recipes-extended/iptables/iptables_1.4.9.bb b/meta/recipes-extended/iptables/iptables_1.4.12.1.bb
> similarity index 69%
> rename from meta/recipes-extended/iptables/iptables_1.4.9.bb
> rename to meta/recipes-extended/iptables/iptables_1.4.12.1.bb
> index 7c9fbea..59a1bcb 100644
> --- a/meta/recipes-extended/iptables/iptables_1.4.9.bb
> +++ b/meta/recipes-extended/iptables/iptables_1.4.12.1.bb
> @@ -4,8 +4,8 @@ filtering code in Linux."
> HOMEPAGE = "http://www.netfilter.org/"
> BUGTRACKER = "http://bugzilla.netfilter.org/"
> LICENSE = "GPLv2+"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
> - file://iptables.c;firstline=13;endline=25;md5=f1028f2401da1c120df27594b2be50ef"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263\
> + file://iptables/iptables.c;firstline=13;endline=25;md5=f1028f2401da1c120df27594b2be50ef"
>
> PR = "r0"
>
> @@ -18,19 +18,15 @@ RRECOMMENDS_${PN} = "kernel-module-x-tables \
> kernel-module-nf-conntrack-ipv4 \
> kernel-module-nf-nat \
> kernel-module-ipt-masquerade"
> -FILES_${PN}-dbg =+ "${libexecdir}/xtables/.debug"
> +FILES_${PN} =+ "${libdir}/xtables/"
> +FILES_${PN}-dbg =+ "${libdir}/xtables/.debug"
>
> SRC_URI = "http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.bz2"
>
> -SRC_URI[md5sum] = "db1312f7ce5a4c11dc981a2ac76b26e8"
> -SRC_URI[sha256sum] = "1ac719d6265cf64220c80c0974ed9d35febdac2986bb96eeaa9c8c7959a1d306"
> +SRC_URI[md5sum] = "b08a1195ec2c1ebeaf072db3c55fdf43"
> +SRC_URI[sha256sum] = "77e6581f21f15946a814fa311236e5f3f7c6593180f9d695cea06aa95e464aba"
>
> inherit autotools
>
> EXTRA_OECONF = "--with-kernel=${STAGING_INCDIR} \
> ${@base_contains('DISTRO_FEATURES', 'ipv6', '', '--disable-ipv6', d)}"
> -
> -do_configure_prepend() {
> - # they are all libtool m4 files
> - rm -rf ${S}/m4
> -}
^ permalink raw reply
* [Qemu-devel] [PATCH] MAINTAINERS: Add PReP maintainer
From: Andreas Färber @ 2011-10-31 23:03 UTC (permalink / raw)
To: qemu-devel; +Cc: Andreas Färber, Hervé Poussineau, Alexander Graf
Officially take on maintainership for PReP and upgrade to Odd Fixes.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Cc: Alexander Graf <agraf@suse.de>
Cc: Hervé Poussineau <hpoussin@reactos.org>
---
MAINTAINERS | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4535eeb..bccdd4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -303,9 +303,9 @@ M: Alexander Graf <agraf@suse.de>
S: Maintained
F: hw/ppc_oldworld.c
-Prep
-M: qemu-devel@nongnu.org
-S: Orphan
+PReP
+M: Andreas Färber <andreas.faerber@web.de>
+S: Odd Fixes
F: hw/ppc_prep.c
SH4 Machines
--
1.7.7
^ permalink raw reply related
* Sony DualShock3 - Detected but no events
From: Alon Bar-Lev @ 2011-10-31 23:04 UTC (permalink / raw)
To: linux-input
Hello,
I feel uncomfortable, as people reports that it does work...
Bluetooth pairing is not working and almost no documentation of
bluez-4 success....
So I thought starting in USB will be easier....
I am using linux-3.1.0
When doing cat /dev/input/js0 or cat /dev/input/event15 or usbhid-dump
I get no activity.
Can anyone please help? or acknowledge that it actually work?
Can I provide more information?
Thanks,
Alon.
lsusb
---
Bus 006 Device 002: ID 054c:0268 Sony Corp. Batoh Device / PlayStation
3 Controller
---
When plugged, I get:
---
usb 6-1: new full speed USB device number 2 using uhci_hcd
sony 0003:054C:0268.000A: Fixing up Sony Sixaxis report descriptor
input: Gasia Co.,Ltd PS(R) Gamepad as
/devices/pci0000:00/0000:00:1d.0/usb6/6-1/6-1:1.0/input/input23
sony 0003:054C:0268.000A: input: USB HID v1.11 Joystick [Gasia Co.,Ltd
PS(R) Gamepad] on usb-0000:00:1d.0-1/input0
---
/proc/bus/input/devices
---
I: Bus=0003 Vendor=054c Product=0268 Version=0111
N: Name="Gasia Co.,Ltd PS(R) Gamepad"
P: Phys=usb-0000:00:1d.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb6/6-1/6-1:1.0/input/input23
U: Uniq=
H: Handlers=event15 js0
B: PROP=0
B: EV=1b
B: KEY=70000 0 0 0 0 0 0 ffff00000000 0 0 0 0
B: ABS=7fffff0000000027
B: MSC=10
---
# usbhid-dump -f --entity="both" 6 2
---
000:DESCRIPTOR 1320102071.430309
05 01 09 04 A1 01 A1 02 85 01 75 08 95 01 15 00
26 FF 00 81 03 75 01 95 13 15 00 25 01 35 00 45
01 05 09 19 01 29 13 81 02 75 01 95 0D 06 00 FF
81 03 15 00 26 FF 00 05 01 09 01 A1 00 75 08 95
04 35 00 46 FF 00 09 30 09 31 09 32 09 35 81 02
C0 05 01 75 08 95 27 09 01 81 02 75 08 95 30 09
01 91 02 75 08 95 30 09 01 B1 02 C0 A1 02 85 02
75 08 95 30 09 01 B1 02 C0 A1 02 85 EE 75 08 95
30 09 01 B1 02 C0 A1 02 85 EF 75 08 95 30 09 01
B1 02 C0 C0
---
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 23:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vvcr4ojvp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> ...
> As I already said, I do not think notes is a good match as a tool to do
> this.
>
>> matters is that "git push" and "git pull" would JustWork(tm), and
>> check the signature if one exists, without having to cut-and-paste
>> data that simply shouldn't be visible to the user.
>>
>> I abhor the interface Ingo suggested, for example....
>
> Some cut-and-paste (or piping the e-mail to a command) would be necessary
> evil, though, as you would have GPG keys from more than one trusted person
> in your keyring, and when you are responding to a pull-request from person
> A, finding a valid commit signed by person B should not be a success, but
> at least should raise a warning.
So here is a quick hack that does not involve cut-and-paste (it depends on
the signed-commit topic in 'next').
$ git pull --require-signature
would trigger signature verification and stops you after fetching but
before merging.
git-pull.sh | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 9868a0b..f3b4c93 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -39,7 +39,7 @@ test -z "$(git ls-files -u)" || die_conflict
test -f "$GIT_DIR/MERGE_HEAD" && die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
-log_arg= verbosity= progress= recurse_submodules=
+log_arg= verbosity= progress= recurse_submodules= must_be_signed=
merge_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short="${curr_branch#refs/heads/}"
@@ -60,6 +60,8 @@ do
diffstat=--no-stat ;;
--stat|--summary)
diffstat=--stat ;;
+ --require-signature)
+ must_be_signed=yes ;;
--log|--no-log)
log_arg=$1 ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
@@ -208,6 +210,27 @@ orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
test -z "$dry_run" || exit 0
+if test -n "$must_be_signed"
+then
+ signature=$(git show -s --format='%G?' FETCH_HEAD)
+ case "$signature" in
+ G)
+ case "$verbosity" in
+ *' '-v*)
+ git show -s --show-signature FETCH_HEAD ;;
+ esac
+ ;;
+ B)
+ echo >&2 "Bad signature on the tip commit"
+ exit 1
+ ;;
+ *)
+ echo >&2 "Tip commit must be signed"
+ exit 1
+ ;;
+ fi
+fi
+
curr_head=$(git rev-parse -q --verify HEAD)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
then
^ permalink raw reply related
* Re: [GIT] pull request for x86 platform drivers tree
From: Linus Torvalds @ 2011-10-31 23:09 UTC (permalink / raw)
To: Matthew Garrett; +Cc: platform-driver-x86
In-Reply-To: <20111031225748.GA13356@srcf.ucam.org>
On Mon, Oct 31, 2011 at 3:57 PM, Matthew Garrett
<mjg59@cavan.codon.org.uk> wrote:
>
> Is this any help?
Ok, mutt seems to like that key, and it's signed by at least Jesse
Barnes who is in my keyring, so.. Yes.
Linus
^ permalink raw reply
* Re: Latency writing to an mlocked ext4 mapping
From: Jan Kara @ 2011-10-31 23:10 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jan Kara, Andreas Dilger, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-ext4@vger.kernel.org
In-Reply-To: <CALCETrWoZeFpznU5Nv=+PvL9QRkTnS4atiGXx0jqZP_E3TJPqw@mail.gmail.com>
On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
> >> - Why are we calling file_update_time at all? Presumably we also
> >> update the time when the page is written back (if not, that sounds
> >> like a bug, since the contents may be changed after something saw the
> >> mtime update), and, if so, why bother updating it on the first write?
> >> Anything that relies on this behavior is, I think, unreliable, because
> >> the page could be made writable arbitrarily early by another program
> >> that changes nothing.
> > We don't update timestamp when the page is written back. I believe this
> > is mostly because we don't know whether the data has been changed by a
> > write syscall, which already updated the timestamp, or by mmap. That is
> > also the reason why we update the timestamp at page fault time.
> >
> > The reason why file_update_time() blocks for you is probably that it
> > needs to get access to buffer where inode is stored on disk and because a
> > transaction including this buffer is committing at the moment, your thread
> > has to wait until the transaction commit finishes. This is mostly a problem
> > specific to how ext4 works so e.g. xfs shouldn't have it.
> >
> > Generally I believe the attempts to achieve any RT-like latencies when
> > writing to a filesystem are rather hopeless. How much hopeless depends on
> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
> > can imagine some tweaks could reduce your latencies to an acceptable level
> > but once the disk gets loaded you'll be screwed). So I'd suggest that
> > having RT thread just store log in memory (or write to a pipe) and have
> > another non-RT thread write the data to disk would be a much more robust
> > design.
>
> Windows seems to do pretty well at this, and I think it should be fixable on
> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
> page_mkclean_one. The fallout from that might be unpleasant, though, but
> it would probably speed up a number of workloads.
Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
unlikely to go away in a forseeable future. The reason is that we need to
reliably account the number of dirty pages so that we can throttle
processes that dirty too much of memory and also protect agaist system
going into out-of-memory problems when too many pages would be dirty (and
thus hard to reclaim). Thus we create clean pages as write-protected, when
they are first written to, we account them as dirtied and unprotect them.
When pages are cleaned by writeback, we decrement number of dirty pages
accordingly and write-protect them again.
> Adding a whole separate process just to copy data from memory to disk sounds
> a bit like a hack -- that's what mmap + mlock would do if it worked better.
Well, always only guarantees you cannot hit major fault when accessing
the page. And we keep that promise - we only hit a minor fault. But I agree
that for your usecase this is impractical.
I can see as theoretically feasible for writeback to skip mlocked pages
which would help your case. But practically, I do not see how to implement
that efficiently (just skipping a dirty page when we find it's mlocked
seems like a way to waste CPU needlessly).
> Incidentally, pipes are no good. I haven't root-caused it yet, but both
> reading to and writing from pipes, even if O_NONBLOCK, can block. I
> haven't root-caused it yet.
Interesting. I imagine they could block on memory allocation but I guess
you don't put that much pressure on your system. So it might be interesting
to know where else they block...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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
* Re: Latency writing to an mlocked ext4 mapping
From: Jan Kara @ 2011-10-31 23:10 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jan Kara, Andreas Dilger, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-ext4@vger.kernel.org
In-Reply-To: <CALCETrWoZeFpznU5Nv=+PvL9QRkTnS4atiGXx0jqZP_E3TJPqw@mail.gmail.com>
On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
> >> - Why are we calling file_update_time at all? Presumably we also
> >> update the time when the page is written back (if not, that sounds
> >> like a bug, since the contents may be changed after something saw the
> >> mtime update), and, if so, why bother updating it on the first write?
> >> Anything that relies on this behavior is, I think, unreliable, because
> >> the page could be made writable arbitrarily early by another program
> >> that changes nothing.
> > We don't update timestamp when the page is written back. I believe this
> > is mostly because we don't know whether the data has been changed by a
> > write syscall, which already updated the timestamp, or by mmap. That is
> > also the reason why we update the timestamp at page fault time.
> >
> > The reason why file_update_time() blocks for you is probably that it
> > needs to get access to buffer where inode is stored on disk and because a
> > transaction including this buffer is committing at the moment, your thread
> > has to wait until the transaction commit finishes. This is mostly a problem
> > specific to how ext4 works so e.g. xfs shouldn't have it.
> >
> > Generally I believe the attempts to achieve any RT-like latencies when
> > writing to a filesystem are rather hopeless. How much hopeless depends on
> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
> > can imagine some tweaks could reduce your latencies to an acceptable level
> > but once the disk gets loaded you'll be screwed). So I'd suggest that
> > having RT thread just store log in memory (or write to a pipe) and have
> > another non-RT thread write the data to disk would be a much more robust
> > design.
>
> Windows seems to do pretty well at this, and I think it should be fixable on
> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
> page_mkclean_one. The fallout from that might be unpleasant, though, but
> it would probably speed up a number of workloads.
Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
unlikely to go away in a forseeable future. The reason is that we need to
reliably account the number of dirty pages so that we can throttle
processes that dirty too much of memory and also protect agaist system
going into out-of-memory problems when too many pages would be dirty (and
thus hard to reclaim). Thus we create clean pages as write-protected, when
they are first written to, we account them as dirtied and unprotect them.
When pages are cleaned by writeback, we decrement number of dirty pages
accordingly and write-protect them again.
> Adding a whole separate process just to copy data from memory to disk sounds
> a bit like a hack -- that's what mmap + mlock would do if it worked better.
Well, always only guarantees you cannot hit major fault when accessing
the page. And we keep that promise - we only hit a minor fault. But I agree
that for your usecase this is impractical.
I can see as theoretically feasible for writeback to skip mlocked pages
which would help your case. But practically, I do not see how to implement
that efficiently (just skipping a dirty page when we find it's mlocked
seems like a way to waste CPU needlessly).
> Incidentally, pipes are no good. I haven't root-caused it yet, but both
> reading to and writing from pipes, even if O_NONBLOCK, can block. I
> haven't root-caused it yet.
Interesting. I imagine they could block on memory allocation but I guess
you don't put that much pressure on your system. So it might be interesting
to know where else they block...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* Re: Latency writing to an mlocked ext4 mapping
From: Jan Kara @ 2011-10-31 23:10 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jan Kara, Andreas Dilger, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-ext4@vger.kernel.org
In-Reply-To: <CALCETrWoZeFpznU5Nv=+PvL9QRkTnS4atiGXx0jqZP_E3TJPqw@mail.gmail.com>
On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
> >> - Why are we calling file_update_time at all? Presumably we also
> >> update the time when the page is written back (if not, that sounds
> >> like a bug, since the contents may be changed after something saw the
> >> mtime update), and, if so, why bother updating it on the first write?
> >> Anything that relies on this behavior is, I think, unreliable, because
> >> the page could be made writable arbitrarily early by another program
> >> that changes nothing.
> > We don't update timestamp when the page is written back. I believe this
> > is mostly because we don't know whether the data has been changed by a
> > write syscall, which already updated the timestamp, or by mmap. That is
> > also the reason why we update the timestamp at page fault time.
> >
> > The reason why file_update_time() blocks for you is probably that it
> > needs to get access to buffer where inode is stored on disk and because a
> > transaction including this buffer is committing at the moment, your thread
> > has to wait until the transaction commit finishes. This is mostly a problem
> > specific to how ext4 works so e.g. xfs shouldn't have it.
> >
> > Generally I believe the attempts to achieve any RT-like latencies when
> > writing to a filesystem are rather hopeless. How much hopeless depends on
> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
> > can imagine some tweaks could reduce your latencies to an acceptable level
> > but once the disk gets loaded you'll be screwed). So I'd suggest that
> > having RT thread just store log in memory (or write to a pipe) and have
> > another non-RT thread write the data to disk would be a much more robust
> > design.
>
> Windows seems to do pretty well at this, and I think it should be fixable on
> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
> page_mkclean_one. The fallout from that might be unpleasant, though, but
> it would probably speed up a number of workloads.
Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
unlikely to go away in a forseeable future. The reason is that we need to
reliably account the number of dirty pages so that we can throttle
processes that dirty too much of memory and also protect agaist system
going into out-of-memory problems when too many pages would be dirty (and
thus hard to reclaim). Thus we create clean pages as write-protected, when
they are first written to, we account them as dirtied and unprotect them.
When pages are cleaned by writeback, we decrement number of dirty pages
accordingly and write-protect them again.
> Adding a whole separate process just to copy data from memory to disk sounds
> a bit like a hack -- that's what mmap + mlock would do if it worked better.
Well, always only guarantees you cannot hit major fault when accessing
the page. And we keep that promise - we only hit a minor fault. But I agree
that for your usecase this is impractical.
I can see as theoretically feasible for writeback to skip mlocked pages
which would help your case. But practically, I do not see how to implement
that efficiently (just skipping a dirty page when we find it's mlocked
seems like a way to waste CPU needlessly).
> Incidentally, pipes are no good. I haven't root-caused it yet, but both
> reading to and writing from pipes, even if O_NONBLOCK, can block. I
> haven't root-caused it yet.
Interesting. I imagine they could block on memory allocation but I guess
you don't put that much pressure on your system. So it might be interesting
to know where else they block...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Multiple instances of same characteristics (was: Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications)
From: Claudio Takahasi @ 2011-10-31 23:11 UTC (permalink / raw)
To: Tsai, Mike; +Cc: linux-bluetooth
Hi Mike,
> [MT]How can this handle the multiple instances of same characteristics within a single service? The characteristic UUID will not be unique in that case. Also, how is the profile specific characteristic descriptor handled?
>
> Cheers,
>
> Mike
I am moving your question to another thread. The original thread is
almost impossible to follow.
Do you mean support for client characteristic configuration and other
characteristics per device?
In the Generic Attribute API(client), the represented characteristics
are always per device. The abstraction for per device characteristic
value needs to implemented in the server.
The current attribute server supports CCC only, before implementing
per device characteristics we need to cleanup the code.
BR,
Claudio.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 0/6] DAT: Distributed ARP Table
From: Simon Wunderlich @ 2011-10-31 23:11 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <4EAEEE96.9040808@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
Hey,
seems the Wiki was edited just recently, have a look here:
http://www.open-mesh.org/wiki/batman-adv/GSOC2011_DAT
Cheers,
Simon
On Mon, Oct 31, 2011 at 11:53:10AM -0700, Gus Wirth wrote:
>
> The link to the Wiki page doesn't work.
>
> The actual link:
>
> http://www.open-mesh.org/wiki/batman-adv/DistributedArpTable
>
> Except there is no information there :(
>
> Gus
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* git-p4: problem with commit 97a21ca50ef8
From: Michael Wookey @ 2011-10-31 23:11 UTC (permalink / raw)
To: Git Mailing List, Pete Wyckoff, Luke Diamand
[ please CC me as I am not subscribed to the list ]
Hi,
Commit 97a21ca50ef893a171a50c863fe21a924935fd2a "git-p4: stop ignoring
apple filetype" isn't correct. Without knowing too much about how
git-p4 works, it appears that the "apple" filetype includes the
resource fork, and the "p4 print" that is used to obtain the content
from the perforce server doesn't take this into account, or maybe some
post processing of the file needs to be done to include the data, but
not the resource fork, before inclusion into the git repo.
With the above commit, a binary blob that literally contains the
resource fork and data is included within the git repo. Of course,
without the above commit, the intended file was never included in the
git repo at all. Perhaps the resource fork issue was a known problem
by the original git-p4 author.
A sample file that that demonstrates what the above commit produces is
here (use curl/wget):
http://dl.dropbox.com/u/1006983/sample_image_fail.png
This is literally a binary blob with about 110 KiB of resource fork
plus the PNG data. The same image, minus about 110 KiB of resource
fork is here:
http://dl.dropbox.com/u/1006983/sample_image_correct.png
I'm happy to test patches as we have a perforce repository with files
of the "apple" filetype.
Thanks
^ permalink raw reply
* How to test multiusermount?
From: Stef Bon @ 2011-10-31 23:12 UTC (permalink / raw)
To: linux-cifs
Hi,
I would like to test the multiusermounts?
I know to set:
echo 1 > /proc/fs/cifs/MultiuserMount
and add an option to the mount command, but I can remember/read somewhere
that one have to add some mapping somehwere:
local user : remote user
...
Is this correct?
Stef Bon
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] MAINTAINERS: Add PReP maintainer
From: Alexander Graf @ 2011-10-31 23:12 UTC (permalink / raw)
To: Andreas Färber; +Cc: Hervé Poussineau, qemu-devel@nongnu.org
In-Reply-To: <1320102187-18955-1-git-send-email-andreas.faerber@web.de>
On 31.10.2011, at 16:03, Andreas Färber <andreas.faerber@web.de> wrote:
> Officially take on maintainership for PReP and upgrade to Odd Fixes.
>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Hervé Poussineau <hpoussin@reactos.org>
Acked-by: Alexander Graf <agraf@suse.de>
Anthony, could you please take this in directly?
Alex
> ---
> MAINTAINERS | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4535eeb..bccdd4f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -303,9 +303,9 @@ M: Alexander Graf <agraf@suse.de>
> S: Maintained
> F: hw/ppc_oldworld.c
>
> -Prep
> -M: qemu-devel@nongnu.org
> -S: Orphan
> +PReP
> +M: Andreas Färber <andreas.faerber@web.de>
> +S: Odd Fixes
> F: hw/ppc_prep.c
>
> SH4 Machines
> --
> 1.7.7
>
^ 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.