* [PATCH 2/2] crypto: lrw: fix nblocks not being updated in walk loop
From: Jussi Kivilinna @ 2011-10-23 15:23 UTC (permalink / raw)
To: linux-crypto; +Cc: Herbert Xu, David S. Miller
In-Reply-To: <20111023152302.31041.36522.stgit@localhost6.localdomain6>
In lrw_crypt() function, nblocks should be updated after blkcipher_walk_done
call.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
crypto/lrw.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/crypto/lrw.c b/crypto/lrw.c
index 66c4d22..ba42acc 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -284,6 +284,7 @@ first:
if (!nbytes)
break;
+ nblocks = min(nbytes / bsize, max_blks);
src = (be128 *)walk.src.virt.addr;
dst = (be128 *)walk.dst.virt.addr;
}
^ permalink raw reply related
* [PATCH 1/2] crypto: xts: fix nblocks not being updated in walk loop
From: Jussi Kivilinna @ 2011-10-23 15:23 UTC (permalink / raw)
To: linux-crypto; +Cc: Herbert Xu, David S. Miller
In-Reply-To: <20111023152302.31041.36522.stgit@localhost6.localdomain6>
In xts_crypt() function, nblocks should be updated after blkcipher_walk_done
call.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
crypto/xts.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/crypto/xts.c b/crypto/xts.c
index 5681d66..ca1608f 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -229,6 +229,7 @@ first:
if (!nbytes)
break;
+ nblocks = min(nbytes / bsize, max_blks);
src = (be128 *)walk.src.virt.addr;
dst = (be128 *)walk.dst.virt.addr;
}
^ permalink raw reply related
* [PATCH 0/2] Fixes for parallel XTS/LRW patch series
From: Jussi Kivilinna @ 2011-10-23 15:23 UTC (permalink / raw)
To: linux-crypto; +Cc: Herbert Xu, David S. Miller
These patches fix bug in xts_crypt()/lrw_crypt() where nblocks is
not updated in the block walk loop.
This causes nblocks to be left at 0, after blkcipher_walk_done() call.
This leads 'do { ... } while (nblocks > 0)' loop to be run one extra
time with nblocks == 0 and at end of do-while loop nblocks gets updated
correctly.
---
Jussi Kivilinna (2):
crypto: xts: fix nblocks not being updated in walk loop
crypto: lrw: fix nblocks not being updated in walk loop
crypto/lrw.c | 1 +
crypto/xts.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [PATCH 00/36] Staging: cx25821: Clean up patch series
From: Leonid V. Fedorenchik @ 2011-10-23 15:20 UTC (permalink / raw)
To: Palash Bandyopadhyay
Cc: Greg Kroah-Hartman, Mauro Carvalho Chehab, Namhyung Kim,
Joe Perches, Ilia Mirkin, Youquan Song,
devel@linuxdriverproject.org, linux-kernel@vger.kernel.org
In-Reply-To: <34B38BE41EDBA046A4AFBB591FA311320506CF35B4@NBMBX01.bbnet.ad>
On Sat, 22 Oct 2011 05:50:14 -0700
"Palash Bandyopadhyay" <Palash.Bandyopadhyay@conexant.com> wrote:
> Thanks Leonid!
>
> Change in patch #18 is also ok.
Thank you for review.
>
> Regards,
> Palash
>
> ________________________________________
> From: Leonid V. Fedorenchik [leonidsbox@gmail.com]
> Sent: Friday, October 21, 2011 10:43 PM
> To: Greg Kroah-Hartman
> Cc: Mauro Carvalho Chehab; Namhyung Kim; Palash Bandyopadhyay; Joe Perches; Ilia Mirkin; Youquan Song; Leonid V. Fedorenchik; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 00/36] Staging: cx25821: Clean up patch series
>
> This patch series fixes some style issues in drivers/staging/cx25821
> Mostly I was hoping to improve readability and fix some issues found by
> checkpatch.pl script.
>
> There is one question, however, in patch no. 18:
> I deleted part of the comment that contradicts to the code and in this
> case maybe I should edit the code to match the comment instead. I am not
> sure if in this case it makes sense to check if width > 0.
>
> Leonid V. Fedorenchik (36):
> Staging: cx25821: cx25821-alsa.c: Line up comments
> Staging: cx25821: cx25821-alsa.c: Add braces to else clause
> Staging: cx25821: cx25821-alsa.c: Fix indent
> Staging: cx25821: cx25821-alsa.c: Change line endings
> Staging: cx25821: cx25821-audio-upstream.c: Fix indent
> Staging: cx25821: cx25821-audio-upstream.c: Move operators
> Staging: cx25821: cx25821-audio-upstream.c: Change line endings
> Staging: cx25821: cx25821-audio.h: Line up defines
> Staging: cx25821: cx25821-audio.h: Fix multiline defines
> Staging: cx25821: cx25821-cards.c: Fix indent
> Staging: cx25821: cx25821-core.c: Delete empty line
> Staging: cx25821: cx25821-core.c: Fix indent
> Staging: cx25821: cx25821-core.c: Change line endings
> Staging: cx25821: cx25821-i2c.c: Change line endings
> Staging: cx25821: cx25821-medusa-defines.h: Fix typo
> Staging: cx25821: cx25821-medusa-defines.h: Line up defines
> Staging: cx25821: cx25821-medusa-reg.h: Line up defines
> Staging: cx25821: cx25821-medusa-video.c: Fix comment
> Staging: cx25821: cx25821-medusa-video.c: Move operators
> Staging: cx25821: cx25821-medusa-video.c: Change line endings
> Staging: cx25821: cx25821-video-upstream-ch2.c: Line up comments
> Staging: cx25821: cx25821-video-upstream-ch2.c: Fix indent
> Staging: cx25821: cx25821-video-upsstream-ch2.c: Move operators
> Staging: cx25821: cx25821-video-upstream-ch2.c: Remove braces
> Staging: cx25821: cx25821-video-upstream-ch2.c: Change line endings
> Staging: cx25821: cx25821-video-upstream.c: Remove braces
> Staging: cx25821: cx25821-video-upstream.c: Fix indent
> Staging: cx25821: cx25821-video-upstream.c: Change line endings
> Staging: cx25821: cx25821-video.c: Delete empty line
> Staging: cx25821: cx25821-video.c: Change spaces
> Staging: cx25821: cx25821-video.c: Fix assignment
> Staging: cx25821: cx25821-video.c: Fix definitions
> Staging: cx25821: cx25821-video.c: Move operators
> Staging: cx25821: cx25821-video.c: Fix indent
> Staging: cx25821: cx25821-video.c: Change line endings
> Staging: cx25821: cx25821.h: Line up defines
>
> drivers/staging/cx25821/cx25821-alsa.c | 73 ++--
> drivers/staging/cx25821/cx25821-audio-upstream.c | 102 ++--
> drivers/staging/cx25821/cx25821-audio.h | 39 +-
> drivers/staging/cx25821/cx25821-cards.c | 2 +-
> drivers/staging/cx25821/cx25821-core.c | 57 +--
> drivers/staging/cx25821/cx25821-i2c.c | 10 +-
> drivers/staging/cx25821/cx25821-medusa-defines.h | 6 +-
> drivers/staging/cx25821/cx25821-medusa-reg.h | 518 ++++++++++----------
> drivers/staging/cx25821/cx25821-medusa-video.c | 410 ++++++----------
> .../staging/cx25821/cx25821-video-upstream-ch2.c | 126 ++---
> drivers/staging/cx25821/cx25821-video-upstream.c | 146 +++----
> drivers/staging/cx25821/cx25821-video.c | 145 +++---
> drivers/staging/cx25821/cx25821.h | 4 +-
> 13 files changed, 745 insertions(+), 893 deletions(-)
> Conexant E-mail Firewall (Conexant.Com) made the following annotations
> ---------------------------------------------------------------------
> ********************** Legal Disclaimer ****************************
>
> "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
>
> **********************************************************************
>
> ---------------------------------------------------------------------
>
Leonid V. Fedorenchik
^ permalink raw reply
* Re: how stable are snapshots at the block level?
From: Mathijs Kwik @ 2011-10-23 15:19 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: linux-btrfs
In-Reply-To: <000101cc918d$3ffb45b0$bff1d110$@nedharvey.com>
On Sun, Oct 23, 2011 at 4:08 PM, Edward Ned Harvey <kernel@nedharvey.co=
m> wrote:
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Mathijs Kwik
>>
>> I'm currently doing backups by doing a btrfs snapshot, then rsync th=
e
>> snapshot to my backup location.
>> As I have a lot of small files and quite some changes between
>> snapshots, this process is taking more and more time.
>> I looked at "btrfs find-new", which is promissing, but I need
>> something to track deletes and modifications too.
>> Also, while this will help the initial comparison phase, most time i=
s
>> still spent on the syncing itself, as a lot of overhead is caused by
>> the tiny files.
>
> No word on when this will be available, but "btrfs send" or whatever =
it's going to be called, is currently in the works. =C2=A0This is reall=
y what you want.
>
>
>> After finding some discussion about it here:
>> http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-
>> mailing-lists-3/backuppc-21/using-rsync-for-blockdevice-level-
>> synchronisation-of-backupp-100438
>
> When you rsync at the file level, it needs to walk the directory stru=
cture, which is essentially a bunch of random IO. =C2=A0When you rsync =
at the block level, it needs to read the entire storage device sequenti=
ally. =C2=A0The latter is only a possible benefit, when the amount of t=
ime to walk the tree is significantly greater than the time to read the=
entire block device.
My test was just a 10G block device filled with random files between 51=
2b and 8k
While this is a contrived example, in this case a block level rsync is
way way way faster. It's not just the tree-walking that's slow, I
guess there's some per-file overhead too.When not using rsync but
plain dd, it's even faster (at the expense of more writes, even when
unneeded), since it can almost transfer data at the maximum write
speed for the receiver.
>
> Even if you rsync the blocklevel device, the local rsync will have to=
read the entire block device to search for binary differences before s=
ending. =C2=A0This will probably have the opposite effect from what you=
want - Because every time you created and deleted a file, every time y=
ou overwrote an existing block (copy on write) it still represents bina=
ry differences on disk, so even though that file was deleted, or severa=
l modifications all yielded a single modification in the end, all the b=
ytes of all the deleted files and all the file deltas that were formerl=
y occupied will be sent anyway. =C2=A0Unless you always zero them out, =
or something.
I understand. A block copy is not advantageous in every situation. I'm
just trying to find out if it's possible for the situations where it
is beneficial.
>
> Given that you're talking about rsync'ing a block level device that c=
ontains btrfs, I'm assuming you have no raid/redundancy. =C2=A0And the =
receiving end is the same.
Yup, in my example I synced my laptop ssd to an external disk (usb3).
>
> Also if you're rsyncing the block level device, you're running undern=
eath btrfs and losing any checksumming benefit that btrfs was giving yo=
u, so you're possibly introducing risk for silent data corruption. =C2=A0=
(Or more accurately, failing to allow btrfs to detect/correct it.)
Not sure... I'm sure that's the case for in-use subvolumes, but
shouldn't snapshots (and their metadata/checksums) just be safe?
>
>
>> I found that the official rsync-patches tarball includes the patch
>> that allows syncing full block devices.
>> After the initial backup, I found that this indeed speeds up my back=
ups a lot.
>> Ofcourse this is meant for syncing unmounted filesystems (or other
>> things that are "stable" at the block level, like LVM snapshot
>> volumes).
>
> Just guessing you did a minimal test. =C2=A0Send initial image, then =
make some changes, then send again. =C2=A0I don't expect this to be typ=
ical after a day or a week of usage, for the reasons previously describ=
ed.
>
>
>> I tested backing up a live btrfs filesystem by making a btrfs
>> snapshot, and this (very simple, non-thorough) turned out to work ok=
=2E
>> My root subvolume contains the "current" subvolume (which I mount) a=
nd
>> several backup subvolumes.
>> Ofcourse I understand that the "current" subvolume on the backup
>> destination is broken/inconsistent, as I change it during the rsync
>> run. But when I mounted the backup disk and compared the subvolumes
>> using normal file-by-file rsync, they were identical.
>
> I may be wrong, but this sounds dangerous to me. =C2=A0As you've demo=
nstrated, it will probably work a lot of the time - because the subvols=
and everything necessary to reference them are static on disk most of =
the time. =C2=A0But as soon as you write to any of the subvols - and th=
at includes a scan, fsck, rebalance, defrag, etc. =C2=A0Anything that w=
rites transparently behind the scenes as far as user processes are conc=
erned... =C2=A0Those could break things.
I understand there are harmful operations, that's why I'm asking if it
is known exactly what those actions are. I'm not writing to the
snapshots (only to my "current" subvol) during rsync/dd and I make
sure not to rebalance or defrag (basically don't use any btrfs progs).
I understand that "current" will be corrupt on the backup destination,
but it would be great to know that all other subvolumes should be
safe.
=46or this case (my laptop) I can stick to file-based rsync, but I thin=
k
some guarantees should exist at the block level. Many virtual machines
and cloud hosting services (like ec2) provide block-level snapshots.
With xfs, I can freeze the filesystem for a short amount of time
(<100ms), snapshot, unfreeze. I don't think such a lock/freeze feature
exists for btrfs, but if btrfs guarantees all snapshots are stable as
long as you don't use any btrfs tools while snapping, it's not needed
either. Ofcourse I understand there's a difference between an instant
block snapshot and a dd/rsync session that takes a few minutes, but if
the dont-use-dangerous-operations conditions are met, it shouldn't
matter for snapshots that aren't used.
Also, I can see how future applications might want to use btrfs for
providing history, or other special purposes that they now write their
own b-tree code for. If the above holds true, block backups would have
no issues backing up this data, while file backups might lead to
enormous redundancy as files/blocks shared between multiple subvolumes
get unCOWed on the destination.
>
>
>> Thanks for any comments on this.
>
> I suggest one of a few options:
> (a) Stick with rsync at the file level. =C2=A0It's stable.
> (b) Wait for btrfs send (or whatever) to become available
> (c) Use ZFS. =C2=A0Both ZFS and BTRFS have advantages over one anothe=
r. =C2=A0This an area where zfs has the advantage for now.
Thanks for your advice,
Like I said, for me, right now, sticking to tried-and-tested
file-based rsync is just ok. But I hope to get some insights into
other possibilities. btrfs send sounds cool, but I sure hope this is
not the only solution, as I described a few scenarios where
block-level copies have advantages.
Mathijs
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
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: Mapping of Shared Page in e500 Powerpc kvm
From: Alexander Graf @ 2011-10-23 15:14 UTC (permalink / raw)
To: kvm-ppc
In-Reply-To: <loom.20111023T153549-514@post.gmane.org>
Am 23.10.2011 um 15:45 schrieb Aashish Mittal <aashish.mittal4u@gmail.com>:
> Hi
>
> I'm working on powerpc e500 machine (Freescale P2020RDB machine) and
> using the paravirtualization guest support available inside kvm and wanted
> to some bookkeeping of my own on the shared page and from what i
> understood is that a single tlb entry is reserved for the shared page
> (magic page) when running the guest which is never preempted or flushed
> but when i tried printing out the dtlb misses on this shared page it show
> me a large number of dtlb misses on this shared page which means that
> this page is being preempted or flushed out in some way . Can someone pleas
> e clarify this situation if i'm understanding something wrong or is it a bug ?
We have seen similar effects and concluded it to be a bug, but didn't track down what exactly was causing it yet.
Alex
>
^ permalink raw reply
* [PATCH 3/3] e2fsprogs: move mke2fs.conf to e2fsprogs-mke2fs package
From: Paul Eggleton @ 2011-10-23 15:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1319382376.git.paul.eggleton@linux.intel.com>
mke2fs.conf, which contains defaults for filesystem formatting options,
ought to be shipped along with mke2fs itself.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
.../e2fsprogs/e2fsprogs_1.41.14.bb | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb
index 1fca7b9..c6c1f0d 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb
@@ -1,6 +1,6 @@
require e2fsprogs.inc
-PR = "r2"
+PR = "r3"
SRC_URI += "file://quotefix.patch \
file://acinclude.m4"
@@ -44,7 +44,7 @@ PACKAGES =+ "libcomerr libss libe2p libext2fs"
FILES_e2fsprogs-blkid = "${base_sbindir}/blkid"
FILES_e2fsprogs-fsck = "${base_sbindir}/fsck"
FILES_e2fsprogs-e2fsck = "${base_sbindir}/e2fsck ${base_sbindir}/fsck.ext*"
-FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs ${base_sbindir}/mkfs.ext*"
+FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs ${base_sbindir}/mkfs.ext* ${sysconfdir}/mke2fs.conf"
FILES_e2fsprogs-tune2fs = "${base_sbindir}/tune2fs ${base_sbindir}/e2label ${base_sbindir}/findfs"
FILES_e2fsprogs-badblocks = "${base_sbindir}/badblocks"
FILES_libcomerr = "${libdir}/libcom_err.so.*"
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/3] util-linux: split out mkfs into its own package
From: Paul Eggleton @ 2011-10-23 15:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1319382376.git.paul.eggleton@linux.intel.com>
For those external tools such as Webmin that call mkfs to do formatting
operations, it is useful to have it in its own package to avoid dragging
in the rest of util-linux.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/recipes-core/util-linux/util-linux.inc | 6 ++++--
meta/recipes-core/util-linux/util-linux_2.19.1.bb | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index 67d81b9..d10bafb 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -29,7 +29,8 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk util-linux-cfdisk util-linux-sfd
util-linux-swaponoff util-linux-losetup util-linux-umount \
util-linux-mount util-linux-readprofile util-linux-libblkid \
util-linux-libblkid-dev util-linux-libuuid util-linux-libuuid-dev \
- util-linux-uuidgen util-linux-lscpu util-linux-fsck util-linux-blkid"
+ util-linux-uuidgen util-linux-lscpu util-linux-fsck util-linux-blkid \
+ util-linux-mkfs"
EXTRA_OECONF = "--disable-use-tty-group --disable-makeinstall-chown --enable-elvtune --enable-init --enable-kill --enable-last \
--enable-mesg --enable-partx --enable-raw --enable-rdev --enable-reset \
@@ -55,13 +56,14 @@ FILES_util-linux-libuuid-dev = "${libdir}/libuuid.so ${libdir}/libuuid.a ${libdi
FILES_util-linux-lscpu = "${bindir}/lscpu"
FILES_util-linux-fsck = "${base_sbindir}/fsck*"
+FILES_util-linux-mkfs = "${sbindir}/mkfs"
# Util-linux' blkid replaces the e2fsprogs one
FILES_util-linux-blkid = "${base_sbindir}/blkid*"
RCONFLICTS_util-linux-blkid = "e2fsprogs-blkid"
RREPLACES_util-linux-blkid = "e2fsprogs-blkid"
-RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile "
+RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile util-linux-mkfs "
RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup perl"
RRECOMMENDS_${PN}_virtclass-native = ""
diff --git a/meta/recipes-core/util-linux/util-linux_2.19.1.bb b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
index 04f4457..fb5637e 100644
--- a/meta/recipes-core/util-linux/util-linux_2.19.1.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
@@ -1,5 +1,5 @@
MAJOR_VERSION = "2.19"
-PR = "r8"
+PR = "r9"
require util-linux.inc
# note that `lscpu' is under GPLv3+
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/3] dbus: remove unused initscript
From: Paul Eggleton @ 2011-10-23 15:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1319382376.git.paul.eggleton@linux.intel.com>
We already install an appropriate init script to /etc/init.d, we do not
need an additional one in /etc/init.d/rc.d as well.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/recipes-core/dbus/dbus.inc | 3 +++
meta/recipes-core/dbus/dbus_1.4.12.bb | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index a8ecda8..339bedf 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -92,6 +92,9 @@ do_install() {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/dbus-1.init ${D}${sysconfdir}/init.d/dbus-1
+ # Remove Red Hat initscript
+ rm -rf ${D}${sysconfdir}/rc.d
+
# disable dbus-1 sysv script on systemd installs
# nearly all distros call the initscript plain 'dbus', but OE-core is different
ln -sf /dev/null ${D}/${base_libdir}/systemd/system/dbus-1.service
diff --git a/meta/recipes-core/dbus/dbus_1.4.12.bb b/meta/recipes-core/dbus/dbus_1.4.12.bb
index ada53c9..9324af7 100644
--- a/meta/recipes-core/dbus/dbus_1.4.12.bb
+++ b/meta/recipes-core/dbus/dbus_1.4.12.bb
@@ -1,4 +1,7 @@
include dbus.inc
+
+PR = "r1"
+
SRC_URI[md5sum] = "104f2ea94c10a896dfb1edecb5714cb1"
SRC_URI[sha256sum] = "da3c97fd546610558d588799e27c4fa81101e754acbcd34747a42c131f30dbe7"
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/3] Misc metadata fixes
From: Paul Eggleton @ 2011-10-23 15:07 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 99da9a4e65f9dffb04efc3ad60125194c476d6b3:
distro-tracking-fields: update fields for tzdata and gst-plugins-good (2011-10-20 13:07:16 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/fixes7
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/fixes7
Paul Eggleton (3):
dbus: remove unused initscript
util-linux: split out mkfs into its own package
e2fsprogs: move mke2fs.conf to e2fsprogs-mke2fs package
meta/recipes-core/dbus/dbus.inc | 3 +++
meta/recipes-core/dbus/dbus_1.4.12.bb | 3 +++
meta/recipes-core/util-linux/util-linux.inc | 6 ++++--
meta/recipes-core/util-linux/util-linux_2.19.1.bb | 2 +-
.../e2fsprogs/e2fsprogs_1.41.14.bb | 4 ++--
5 files changed, 13 insertions(+), 5 deletions(-)
--
1.7.4.1
^ permalink raw reply
* Re: lockdep in mac80211
From: Arik Nemtsov @ 2011-10-23 15:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <CA+XVXffT6pq0bKZrVmrYDqustkTFt_ot99BPK_Q5JmXU3wE0iQ@mail.gmail.com>
On Wed, Oct 19, 2011 at 00:12, Arik Nemtsov <arik@wizery.com> wrote:
> http://pastebin.com/qX3SLy2H
>
> This appears to be a legitimate lockdep (when trying to re-connect to
> an AP whose password I just changed).
> These take the locks in reverse order:
>
> ieee80211_work_work() -> ieee80211_authenticate() (Inlined in the
> lockdep print).
> ieee80211_sta_rx_queued_mgmt() -> ieee80211_rx_mgmt_disassoc()
>
Please disregard this one. The problem was with an internal patch I
was using for testing (as can be seen in the stack trace as well).
Arik
^ permalink raw reply
* [PATCH] init:enable usermodehelper as soon as we have a root filesystem
From: wangyanqing @ 2011-10-23 15:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
before we have a filesystem , it is useless to enable usermodehelper,
and it may cause bug if we enable usermodehelper too early (see commit
d5767c53535ac79758084773418e0ad186aba4a2 for the reason why linus mv
'usermodehelper_enable()' to the end of do_basic_setup, and commit
b0f84374b6ab0dc9c47975df0b02d46165d558d4).This patch
enable usermodehelper as soon as we have a filesystem.
Signed-off-by: wang yanqing <udknight@gmail.com>
---
init/do_mounts.c | 3 +++
init/initramfs.c | 2 ++
init/main.c | 1 -
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index c0851a8..9575bdd 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -490,4 +490,7 @@ out:
devtmpfs_mount("dev");
sys_mount(".", "/", NULL, MS_MOVE, NULL);
sys_chroot((const char __user __force *)".");
+#ifndef CONFIG_BLK_DEV_INITRD
+ usermodehelper_enable();
+#endif
}
diff --git a/init/initramfs.c b/init/initramfs.c
index 2531811..881fc4b 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -581,6 +581,7 @@ static int __init populate_rootfs(void)
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
if (!err) {
+ usermodehelper_enable();
free_initrd();
return 0;
} else {
@@ -603,6 +604,7 @@ static int __init populate_rootfs(void)
initrd_end - initrd_start);
if (err)
printk(KERN_EMERG "Initramfs unpacking failed: %s\n", err);
+ usermodehelper_enable();
free_initrd();
#endif
}
diff --git a/init/main.c b/init/main.c
index 03b408d..2e232cb 100644
--- a/init/main.c
+++ b/init/main.c
@@ -730,7 +730,6 @@ static void __init do_basic_setup(void)
driver_init();
init_irq_proc();
do_ctors();
- usermodehelper_enable();
do_initcalls();
}
--
1.7.3.4
^ permalink raw reply related
* [Qemu-devel] [PATCH] qxl: reset update_surface
From: Alon Levy @ 2011-10-23 15:03 UTC (permalink / raw)
To: kraxel; +Cc: qemu-devel
update init_qxl_ram to reset update_surface to 0. This fixes one case
of breakage when installing an old driver in a vm that had a new driver
installed. The newer driver would know about surface creation and would
change update_surface to !=0, then a reset would happen, all surfaces
are destroyed, then the old driver is initialized and issues an
UPDATE_AREA, and spice server aborts on invalid surface.
RHBZ: 690427
Signed-off-by: Alon Levy <alevy@redhat.com>
---
hw/qxl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 03848ed..632658d 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -330,6 +330,7 @@ static void init_qxl_ram(PCIQXLDevice *d)
d->ram->magic = cpu_to_le32(QXL_RAM_MAGIC);
d->ram->int_pending = cpu_to_le32(0);
d->ram->int_mask = cpu_to_le32(0);
+ d->ram->update_surface = 0;
SPICE_RING_INIT(&d->ram->cmd_ring);
SPICE_RING_INIT(&d->ram->cursor_ring);
SPICE_RING_INIT(&d->ram->release_ring);
--
1.7.6.4
^ permalink raw reply related
* [U-Boot] [PATCH] MPC85xx: remove broken "mpq101" board
From: Wolfgang Denk @ 2011-10-23 15:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318777047.27157.YahooMailNeo@web121011.mail.ne1.yahoo.com>
The board stopped building some time ago, and the board maintainer
agrtees to drop it - see
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/112674
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Alex Dubov <oakad@yahoo.com>
Cc: Andy Fleming <afleming@gmail.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
---
MAINTAINERS | 4 -
board/mercury/mpq101/Makefile | 47 --------------
board/mercury/mpq101/law.c | 52 ---------------
board/mercury/mpq101/mpq101.c | 129 --------------------------------------
board/mercury/mpq101/tlb.c | 82 ------------------------
board/mercury/mpq101/u-boot.lds | 132 ---------------------------------------
boards.cfg | 1 -
doc/README.scrapyard | 1 +
8 files changed, 1 insertions(+), 447 deletions(-)
delete mode 100644 board/mercury/mpq101/Makefile
delete mode 100644 board/mercury/mpq101/law.c
delete mode 100644 board/mercury/mpq101/mpq101.c
delete mode 100644 board/mercury/mpq101/tlb.c
delete mode 100644 board/mercury/mpq101/u-boot.lds
diff --git a/MAINTAINERS b/MAINTAINERS
index e648ccf..f5168b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -134,10 +134,6 @@ Wolfgang Denk <wd@denx.de>
PCIPPC2 MPC750
PCIPPC6 MPC750
-Alex Dubov <oakad@yahoo.com>
-
- mpq101 MPC8548
-
Phil Edworthy <phil.edworthy@renesas.com>
rsk7264 SH7264
diff --git a/board/mercury/mpq101/Makefile b/board/mercury/mpq101/Makefile
deleted file mode 100644
index f9a07cc..0000000
--- a/board/mercury/mpq101/Makefile
+++ /dev/null
@@ -1,47 +0,0 @@
-#
-# Copyright 2007 Freescale Semiconductor, Inc.
-# (C) Copyright 2001-2006
-# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
-#
-# 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 $(TOPDIR)/config.mk
-
-LIB = $(obj)lib$(BOARD).o
-
-COBJS-y += $(BOARD).o
-COBJS-y += law.o
-COBJS-y += tlb.o
-
-SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
-OBJS := $(addprefix $(obj),$(COBJS-y))
-SOBJS := $(addprefix $(obj),$(SOBJS))
-
-$(LIB): $(obj).depend $(OBJS) $(SOBJS)
- $(call cmd_link_o_target, $(OBJS))
-
-#########################################################################
-
-# defines $(obj).depend target
-include $(SRCTREE)/rules.mk
-
-sinclude $(obj).depend
-
-#########################################################################
diff --git a/board/mercury/mpq101/law.c b/board/mercury/mpq101/law.c
deleted file mode 100644
index 0e23a6a..0000000
--- a/board/mercury/mpq101/law.c
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * Copyright 2008 Freescale Semiconductor, Inc.
- *
- * (C) Copyright 2000
- * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
- *
- * 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 <asm/fsl_law.h>
-#include <asm/mmu.h>
-
-/*
- * LAW(Local Access Window) configuration:
- *
- * 0x0000_0000 0x1fff_ffff DDR SYS_SDRAM_SIZE
- * 0xc000_0000 0xdfff_ffff RapidIO (set elsewhere) 512M
- * 0xe000_0000 0xe000_ffff CCSR (set elsewhere) 1M
- * 0xf000_0000 0xffff_ffff LBC options + FLASH 256M
- *
- * Notes:
- * CCSRBAR and L2-as-SRAM don't need a configured Local Access Window.
- * If flash is 8M at default position (last 8M), no LAW needed.
- *
- * LAW 0 is reserved for boot mapping
- */
-
-struct law_entry law_table[] = {
- SET_LAW(CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_SDRAM_SIZE_LOG - 1,
- LAW_TRGT_IF_DDR_1),
- SET_LAW(CONFIG_SYS_LBC_OPTION_BASE_PHYS, LAW_SIZE_256M,
- LAW_TRGT_IF_LBC)
-};
-
-int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/mercury/mpq101/mpq101.c b/board/mercury/mpq101/mpq101.c
deleted file mode 100644
index e02e87f..0000000
--- a/board/mercury/mpq101/mpq101.c
+++ /dev/null
@@ -1,129 +0,0 @@
-/*
- * (C) Copyright 2011 Alex Dubov <oakad@yahoo.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 <asm/processor.h>
-#include <asm/mmu.h>
-#include <asm/immap_85xx.h>
-#include <asm/fsl_law.h>
-#include <asm/io.h>
-#include <miiphy.h>
-#include <libfdt.h>
-#include <fdt_support.h>
-
-/*
- * Initialize Local Bus
- */
-void local_bus_init(void)
-{
- fsl_lbc_t *lbc = LBC_BASE_ADDR;
-
- out_be32(&lbc->ltesr, 0xffffffff); /* Clear LBC error interrupts */
- out_be32(&lbc->lteir, 0xffffffff); /* Enable LBC error interrupts */
-}
-
-int checkboard(void)
-{
- ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
- ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR);
-
- puts("Board: Mercury Computer Systems, Inc. MPQ-101 ");
-#ifdef CONFIG_PHYS_64BIT
- puts("(36-bit addrmap) ");
-#endif
- putc('\n');
-
- /*
- * Initialize local bus.
- */
- local_bus_init();
-
- /*
- * Hack TSEC 3 and 4 IO voltages.
- */
- out_be32(&gur->tsec34ioovcr, 0xe7e0); /* 1110 0111 1110 0xxx */
-
- out_be32(&ecm->eedr, 0xffffffff); /* clear ecm errors */
- out_be32(&ecm->eeer, 0xffffffff); /* enable ecm errors */
- return 0;
-}
-
-phys_size_t fixed_sdram(void)
-{
- ccsr_ddr_t *ddr = (void *)(CONFIG_SYS_MPC85xx_DDR_ADDR);
- const char *p_mode = getenv("perf_mode");
-
- puts("Initializing....");
-
- out_be32(&ddr->cs0_bnds, CONFIG_SYS_DDR_CS0_BNDS);
- out_be32(&ddr->cs0_config, CONFIG_SYS_DDR_CS0_CONFIG);
-
- out_be32(&ddr->timing_cfg_3, CONFIG_SYS_DDR_TIMING_3);
- out_be32(&ddr->timing_cfg_0, CONFIG_SYS_DDR_TIMING_0);
-
- if (p_mode && !strcmp("performance", p_mode)) {
- out_be32(&ddr->timing_cfg_1, CONFIG_SYS_DDR_TIMING_1_PERF);
- out_be32(&ddr->timing_cfg_2, CONFIG_SYS_DDR_TIMING_2_PERF);
- out_be32(&ddr->sdram_mode, CONFIG_SYS_DDR_MODE_1_PERF);
- out_be32(&ddr->sdram_mode_2, CONFIG_SYS_DDR_MODE_2_PERF);
- out_be32(&ddr->sdram_interval, CONFIG_SYS_DDR_INTERVAL_PERF);
- } else {
- out_be32(&ddr->timing_cfg_1, CONFIG_SYS_DDR_TIMING_1);
- out_be32(&ddr->timing_cfg_2, CONFIG_SYS_DDR_TIMING_2);
- out_be32(&ddr->sdram_mode, CONFIG_SYS_DDR_MODE_1);
- out_be32(&ddr->sdram_mode_2, CONFIG_SYS_DDR_MODE_2);
- out_be32(&ddr->sdram_interval, CONFIG_SYS_DDR_INTERVAL);
- }
-
- out_be32(&ddr->sdram_clk_cntl, CONFIG_SYS_DDR_CLK_CTRL);
- out_be32(&ddr->sdram_cfg_2, CONFIG_SYS_DDR_CONTROL2);
-
- asm("sync;isync");
- udelay(500);
-
- out_be32(&ddr->sdram_cfg, CONFIG_SYS_DDR_CONTROL);
- asm("sync; isync");
- udelay(500);
-
- return ((phys_size_t)1) << CONFIG_SYS_SDRAM_SIZE_LOG;
-}
-
-void pci_init_board(void)
-{
- ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
-
- /* PCI is disabled */
- out_be32(&gur->devdisr, in_be32(&gur->devdisr)
- | MPC85xx_DEVDISR_PCI1
- | MPC85xx_DEVDISR_PCI2
- | MPC85xx_DEVDISR_PCIE);
-}
-
-
-#if defined(CONFIG_OF_BOARD_SETUP)
-
-void ft_board_setup(void *blob, bd_t *bd)
-{
- ft_cpu_setup(blob, bd);
-}
-
-#endif
diff --git a/board/mercury/mpq101/tlb.c b/board/mercury/mpq101/tlb.c
deleted file mode 100644
index fd2eaec..0000000
--- a/board/mercury/mpq101/tlb.c
+++ /dev/null
@@ -1,82 +0,0 @@
-/*
- * (C) Copyright 2000
- * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
- *
- * 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 <asm/mmu.h>
-
-struct fsl_e_tlb_entry tlb_table[] = {
- /* TLB 0 - for temp stack in cache */
- SET_TLB_ENTRY(0, CONFIG_SYS_INIT_RAM_ADDR, CONFIG_SYS_INIT_RAM_ADDR,
- MAS3_SX|MAS3_SW|MAS3_SR, 0,
- 0, 0, BOOKE_PAGESZ_4K, 0),
- SET_TLB_ENTRY(0, CONFIG_SYS_INIT_RAM_ADDR + 4 * 1024,
- CONFIG_SYS_INIT_RAM_ADDR + 4 * 1024,
- MAS3_SX|MAS3_SW|MAS3_SR, 0,
- 0, 0, BOOKE_PAGESZ_4K, 0),
- SET_TLB_ENTRY(0, CONFIG_SYS_INIT_RAM_ADDR + 8 * 1024,
- CONFIG_SYS_INIT_RAM_ADDR + 8 * 1024,
- MAS3_SX|MAS3_SW|MAS3_SR, 0,
- 0, 0, BOOKE_PAGESZ_4K, 0),
- SET_TLB_ENTRY(0, CONFIG_SYS_INIT_RAM_ADDR + 12 * 1024,
- CONFIG_SYS_INIT_RAM_ADDR + 12 * 1024,
- MAS3_SX|MAS3_SW|MAS3_SR, 0,
- 0, 0, BOOKE_PAGESZ_4K, 0),
-
- /*
- * TLB 0: 256M Non-cacheable, guarded
- * 0xf0000000 256M LBC (FLASH included)
- * Out of reset this entry is only 4K.
- */
- SET_TLB_ENTRY(1, CONFIG_SYS_LBC_OPTION_BASE,
- CONFIG_SYS_LBC_OPTION_BASE_PHYS,
- MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
- 0, 0, BOOKE_PAGESZ_256M, 1),
-
- /*
- * TLB 1: 1M Non-cacheable, guarded
- * 0xe000_0000 1M CCSRBAR
- */
- SET_TLB_ENTRY(1, CONFIG_SYS_CCSRBAR, CONFIG_SYS_CCSRBAR_PHYS,
- MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
- 0, 1, BOOKE_PAGESZ_1M, 1),
-
-#ifdef CONFIG_SYS_SRIO1_MEM_PHYS
- /*
- * TLB 2: 256M Non-cacheable, guarded
- */
- SET_TLB_ENTRY(1, CONFIG_SYS_SRIO1_MEM_VIRT, CONFIG_SYS_SRIO1_MEM_PHYS,
- MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
- 0, 2, BOOKE_PAGESZ_256M, 1),
-
- /*
- * TLB 3: 256M Non-cacheable, guarded
- */
- SET_TLB_ENTRY(1, CONFIG_SYS_SRIO1_MEM_VIRT + 0x10000000,
- CONFIG_SYS_SRIO1_MEM_PHYS + 0x10000000,
- MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
- 0, 3, BOOKE_PAGESZ_256M, 1),
-
-#endif
-};
-
-int num_tlb_entries = ARRAY_SIZE(tlb_table);
diff --git a/board/mercury/mpq101/u-boot.lds b/board/mercury/mpq101/u-boot.lds
deleted file mode 100644
index f497a63..0000000
--- a/board/mercury/mpq101/u-boot.lds
+++ /dev/null
@@ -1,132 +0,0 @@
-/*
- * Copyright 2007-2009 Freescale Semiconductor, Inc.
- *
- * 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
- */
-
-#ifndef RESET_VECTOR_ADDRESS
-#define RESET_VECTOR_ADDRESS 0xfffffffc
-#endif
-
-#include <config.h>
-
-OUTPUT_ARCH(powerpc)
-
-PHDRS
-{
- text PT_LOAD;
- bss PT_LOAD;
-}
-
-SECTIONS
-{
- /* Read-only sections, merged into text segment: */
- . = + SIZEOF_HEADERS;
- .interp : { *(.interp) }
- /* To simplify mass deployment, environment precedes the monitor text in the
- * same flash sector.
- */
- .ppcenv CONFIG_ENV_ADDR : { common/env_embedded.o (.ppcenv) }
- .text :
- {
- *(.text*)
- } :text
- _etext = .;
- PROVIDE (etext = .);
- .rodata :
- {
- *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
- } :text
-
- /* Read-write section, merged into data segment: */
- . = (. + 0x00FF) & 0xFFFFFF00;
- _erotext = .;
- PROVIDE (erotext = .);
- .reloc :
- {
- _GOT2_TABLE_ = .;
- KEEP(*(.got2))
- KEEP(*(.got))
- PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
- _FIXUP_TABLE_ = .;
- KEEP(*(.fixup))
- }
- __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1;
- __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
-
- .data :
- {
- *(.data*)
- *(.sdata*)
- }
- _edata = .;
- PROVIDE (edata = .);
-
- . = .;
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
-
- . = .;
- __start___ex_table = .;
- __ex_table : { *(__ex_table) }
- __stop___ex_table = .;
-
- . = ALIGN(256);
- __init_begin = .;
- .text.init : { *(.text.init) }
- .data.init : { *(.data.init) }
- . = ALIGN(256);
- __init_end = .;
-
- .bootpg RESET_VECTOR_ADDRESS - 0xffc :
- {
- arch/powerpc/cpu/mpc85xx/start.o (.bootpg)
- } :text = 0xffff
-
- .resetvec RESET_VECTOR_ADDRESS :
- {
- KEEP(*(.resetvec))
- } :text = 0xffff
-
- . = RESET_VECTOR_ADDRESS + 0x4;
-
- /*
- * Make sure that the bss segment isn't linked at 0x0, otherwise its
- * address won't be updated during relocation fixups. Note that
- * this is a temporary fix. Code to dynamically the fixup the bss
- * location will be added in the future. When the bss relocation
- * fixup code is present this workaround should be removed.
- */
-#if (RESET_VECTOR_ADDRESS == 0xfffffffc)
- . |= 0x10;
-#endif
-
- __bss_start = .;
- .bss (NOLOAD) :
- {
- *(.sbss*)
- *(.bss*)
- *(COMMON)
- } :bss
-
- . = ALIGN(4);
- __bss_end__ = . ;
- PROVIDE (end = .);
-}
diff --git a/boards.cfg b/boards.cfg
index 738c186..bccb832 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -706,7 +706,6 @@ P5020DS_NAND powerpc mpc85xx corenet_ds freescale -
P5020DS_SDCARD powerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000
P5020DS_SECURE_BOOT powerpc mpc85xx corenet_ds freescale - P5020DS:SECURE_BOOT
P5020DS_SPIFLASH powerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-mpq101 powerpc mpc85xx mpq101 mercury - mpq101
stxgp3 powerpc mpc85xx stxgp3 stx
stxssa powerpc mpc85xx stxssa stx - stxssa
stxssa_4M powerpc mpc85xx stxssa stx - stxssa:STXSSA_4M
diff --git a/doc/README.scrapyard b/doc/README.scrapyard
index c5dffbb..cb5e4bc 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -11,6 +11,7 @@ easily if here is something they might want to dig for...
Board Arch CPU removed Commit last known maintainer/contact
=============================================================================
+mpq101 powerpc mpc85xx - 2011-10-23 Alex Dubov <oakad@yahoo.com>
ixdpg425 arm ixp 0ca8eb7 2011-09-22 Stefan Roese <sr@denx.de>
ixdp425 arm ixp 0ca8eb7 2011-09-22 Kyle Harris <kharris@nexus-tech.net>
zylonite arm pxa b66521a 2011-09-05
--
1.7.6.2
^ permalink raw reply related
* [ath9k-devel] Can't associate with a particular AP
From: kang haiyang @ 2011-10-23 15:05 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <20111023142536.GA4633@kirya.net>
from the failed wireshark log, i saw there is inconsistent information
in reassociation response:
in capability tag: ap tells client that it supports 40Mhz, but in the HT
info tags it tells client that it only support 20Mhz.
i don't know if this maybe bother some particular clients.
Best Regards,
kang haiyang
On 10/23/2011 10:25 PM, Julien Valroff wrote:
> Hi,
>
> Le dimanche 16 oct. 2011 ? 17:31:44 (+0200 CEST), Adrian Chadd a ?crit :
>> Can you please grab a third device and grab a dump of the actual
>> probe/association frames?
>>
>> I think it'd be helpful to see what's changed.
> I have tried and captured the association process from my 2 other laptops
> using wireshark, but unfortunately, I am unable to capture packets in
> monitoring mode: in Wireshark, the box is not greyed out, but I cannot tick
> it.
>
> I've tried reading the Wireshark documentation on this point, but I could
> not see anything about this problem.
>
> I have followed Peter's instructions and the ones described in [0] both
> with the same results.
>
> But still, I have been able to capture something from the problematic
> laptop, you will find the wireshark logs attached.
>
> When failing to associate, I can see a lot of lines as follows:
> 50 11.081661 ba:f4:8a:c6:c8:44 (TA) 74:2f:68:57:2c:dc (RA) 802.11 46 Request-to-send, Flags=........C
>
> followed by:
> 166 23.082827 ba:f4:8a:c6:c8:44 74:2f:68:57:2c:dc 802.11 56 Deauthentication, SN=1142, FN=0, Flags=........C
>
> where:
> ba:f4:8a:c6:c8:44 is my AP
> 74:2f:68:57:2c:dc is my Atheros wlan NIC
>
> When the association succeeds, I notice the MAC address of the AP changes:
> 99 5.752088 c6:6e:27:a6:be:a4 74:2f:68:57:2c:dc 802.11 272 Probe Response, SN=269, FN=0, Flags=........C, BI=100, SSID=Kirya
> ^^^^
>
> Which is confirmed by iwlist scan.
> Before the association:
> Cell 01 - Address: BA:F4:8A:C6:C8:44
> Channel:3
> Frequency:2.422 GHz (Channel 3)
> Quality=26/70 Signal level=-84 dBm
> Encryption key:on
> ESSID:"Kirya"
>
> After the succeeded association:
> Cell 04 - Address: C6:6E:27:A6:BE:A4
> Channel:3
> Frequency:2.422 GHz (Channel 3)
> Quality=70/70 Signal level=-35 dBm
> Encryption key:on
> ESSID:"Kirya"
>
> How is this possible?
>
> Please continue and CC me as I am not subscribed to the list.
>
> Cheers,
> Julien
>
> [0] http://wiki.wireshark.org/CaptureSetup/WLAN#Linux
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20111023/942575eb/attachment.htm
^ permalink raw reply
* Re: [PATCH net-next] bonding: fix wrong port enabling in 802.3ad
From: Kartik Chandran @ 2011-10-23 15:04 UTC (permalink / raw)
To: netdev; +Cc: Sriram Chidambaram, Hugh Holbrook
In-Reply-To: <CAGMsbm4DMPfT6zSZp+fH2XB_gRUHR9FSRDxcwBJVCOhUi4j9AA@mail.gmail.com>
By a strange coincidence, we ran into this exact issue last week while
experimenting with the "standby" state, where we discovered that the
current implementation in bond_3ad does not pay attention to the Mux
SM state when deciding to enable a slave port for transmission, which
causes misbehavior in forwarding on the partner side.
Since the question was raised on the thread about what the 802.3ad
spec says in this respect, we can confidently answer that the spec
clearly mandates that the aggregator should include a port for
transmission only when it goes to DISTRIBUTING ( in independent
control mode) and COLLECTING+DISTRIBUTING (in coupled mode).
We are testing this extensively right now, so I'm happy to try out
this patch and report back with findings.
-Kartik
^ permalink raw reply
* [ath9k-devel] Can't associate with a particular AP
From: Peter Stuge @ 2011-10-23 15:02 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <20111023142536.GA4633@kirya.net>
Julien Valroff wrote:
> I have tried and captured the association process from my 2 other laptops
> using wireshark, but unfortunately, I am unable to capture packets in
> monitoring mode: in Wireshark, the box is not greyed out, but I cannot tick
> it.
I think it is important to iwconfig eth1 mode monitor before you run
ip link set dev eth1 up, and once you have done that it does not
matter what settings wireshark does or does not do, the mode can't be
changed when the interface is up, so just starting the capture should
work.
> When the association succeeds, I notice the MAC address of the AP
> changes:
..
> Before the association:
> Cell 01 - Address: BA:F4:8A:C6:C8:44
..
> After the succeeded association:
> Cell 04 - Address: C6:6E:27:A6:BE:A4
Which is the actual correct address of your AP? I would expect
c6-6e-27, but the IEEE OUI listing does not have a match for it!
http://standards.ieee.org/cgi-bin/ouisearch?c6-6e-27
> How is this possible?
I guess some fundamental data corruption problem in ath9k. I'm not
surprised at all, although developers claim that by now the code
quality is good. This is a total BS error. I could rant for forever.
> Please continue and CC me as I am not subscribed to the list.
I would try FreeBSD on that machine. I believe the driver there is
more reliable, and using it can allow you to get more concrete help
from Adrian in case the problem is seen also there.
//Peter
^ permalink raw reply
* [Qemu-devel] [PATCH 1/2] libcacard/cac: fix typo in cac_delete_pki_applet_private
From: Alon Levy @ 2011-10-23 14:58 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <1319381932-22901-1-git-send-email-alevy@redhat.com>
Signed-off-by: Alon Levy <alevy@redhat.com>
---
libcacard/cac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libcacard/cac.c b/libcacard/cac.c
index f4b0b1b..927a4ca 100644
--- a/libcacard/cac.c
+++ b/libcacard/cac.c
@@ -266,7 +266,8 @@ static void
cac_delete_pki_applet_private(VCardAppletPrivate *applet_private)
{
CACPKIAppletData *pki_applet_data = NULL;
- if (pki_applet_data == NULL) {
+
+ if (applet_private == NULL) {
return;
}
pki_applet_data = &(applet_private->u.pki_data);
--
1.7.6.4
^ permalink raw reply related
* [Qemu-devel] [PATCH 0/2] libcacard coverity found fixes
From: Alon Levy @ 2011-10-23 14:58 UTC (permalink / raw)
To: qemu-devel
Two fixes, the first means memory for a vcard applet was never freed,
the second fixes vscclient handling of errors when opening it's socket.
Alon Levy (2):
libcacard/cac: fix typo in cac_delete_pki_applet_private
libcacard/vscclient: fix error paths for socket creation
libcacard/cac.c | 3 ++-
libcacard/vscclient.c | 9 +++++++--
2 files changed, 9 insertions(+), 3 deletions(-)
--
1.7.6.4
^ permalink raw reply
* [Qemu-devel] [PATCH 2/2] libcacard/vscclient: fix error paths for socket creation
From: Alon Levy @ 2011-10-23 14:58 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <1319381932-22901-1-git-send-email-alevy@redhat.com>
Signed-off-by: Alon Levy <alevy@redhat.com>
---
libcacard/vscclient.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c
index 2191f60..e317a25 100644
--- a/libcacard/vscclient.c
+++ b/libcacard/vscclient.c
@@ -357,6 +357,7 @@ connect_to_qemu(
if (sock < 0) {
/* Error */
fprintf(stderr, "Error opening socket!\n");
+ return -1;
}
memset(&hints, 0, sizeof(struct addrinfo));
@@ -370,13 +371,13 @@ connect_to_qemu(
if (ret != 0) {
/* Error */
fprintf(stderr, "getaddrinfo failed\n");
- return 5;
+ return -1;
}
if (connect(sock, server->ai_addr, server->ai_addrlen) < 0) {
/* Error */
fprintf(stderr, "Could not connect\n");
- return 5;
+ return -1;
}
if (verbose) {
printf("Connected (sizeof Header=%zd)!\n", sizeof(VSCMsgHeader));
@@ -505,6 +506,10 @@ main(
qemu_host = strdup(argv[argc - 2]);
qemu_port = strdup(argv[argc - 1]);
sock = connect_to_qemu(qemu_host, qemu_port);
+ if (sock == -1) {
+ fprintf(stderr, "error opening socket, exiting.\n");
+ exit(5);
+ }
qemu_mutex_init(&write_lock);
qemu_mutex_init(&pending_reader_lock);
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
From: Andreas Schwab @ 2011-10-23 14:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Linux/m68k, Greg Ungerer, Linux Kernel Development,
uClinux list
In-Reply-To: <CAMuHMdVWAcNFeWauj-DoB3btWY9UTOBDNMzRyTvYmYaYb15N4A@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> All others seem to be old, obsolete, or i386-only.
Those are not referenced by glibc anyway.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
From: Andreas Schwab @ 2011-10-23 14:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Linux/m68k, Greg Ungerer, Linux Kernel Development,
uClinux list
In-Reply-To: <CAMuHMdVWAcNFeWauj-DoB3btWY9UTOBDNMzRyTvYmYaYb15N4A@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> All others seem to be old, obsolete, or i386-only.
Those are not referenced by glibc anyway.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [lm-sensors]
From: Malika et Christophe CHARBONNIER @ 2011-10-23 14:53 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <87ekb9s3tn.wl%info@wore.ma.cx>
[-- Attachment #1.1: Type: text/plain, Size: 209 bytes --]
Veuillez retirer définitivement les adresses suivantes de vos fichiers.
malikacha@laposte.net
charbonnierc@laposte.net
gaiacha@live.fr
gaiacha@bbox.fr
Cei dans les plus brefs délais.
Merci par avance
[-- Attachment #1.2: Type: text/html, Size: 638 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Race condition in switch_to() / set_fs()
From: Alexander Korolkov @ 2011-10-23 14:53 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Seems like I've found a race condition in the ARM implementation of
functions switch_to() and set_fs(). These functions modify the domain
access control (DAC) register and current_thread_info()->cpu_domain
without proper locking.
I have a device based on LPC3250 microcontroller. Recently I've noticed
that epoll_wait() system call sometimes returns -EFAULT. After an
investigation I've found that sometimes __put_user() macro fails, but in
the next system call with exactly the same arguments it works correctly!
Then I've found that when __put_user() fails, DAC register contains a
different value, and it isn't equal to cpu_domain.
My test system:
- one process sending a lot of messages to another process via UNIX
socket (i.e. a lot of context switches)
- ethernet driver which sometimes reads unaligned u32 words
What I observe:
__switch_to():
DAC = next_thread->cpu_domain
ethernet controller interrupt
access to unaligned u32
alignment fixup: do_alignment()
fs = get_fs();
set_fs(KERNEL_DS);
...
set_fs(fs);
DAC = current_thread->cpu_domain
return from ISR
context switch to next_thread
return from __switch_to()
__put_user() returns -EFAULT
system call returns -EFAULT
My conclusion: all interrupts must be disabled in __switch_to() and
set_fs(), see attachment.
This test is really hard to set up, so I'll try to make a simpler test.
Meanwhile, please write me what do you think about this: is this a real
problem, is my solution correct, is it possible that there are other
similar problems?
A lot of kernel versions is affected, at least from 2.6.22 to 3.0.
With best regards,
Alexander Korolkov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-race-condition-fixup.patch
Type: text/x-patch
Size: 1472 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111023/a341cea8/attachment.bin>
^ permalink raw reply
* [PATCH] TTY: pty, fix pty counting
From: Ilya Zykov @ 2011-10-23 14:42 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Jiri Slaby, Alan Cox, linux-kernel
New version for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
diff -uprN a/drivers/tty/pty.c b/drivers/tty/pty.c
--- a/drivers/tty/pty.c 2011-05-19 08:06:34.000000000 +0400
+++ b/drivers/tty/pty.c 2011-10-23 18:01:20.000000000 +0400
@@ -36,13 +36,15 @@
static struct tty_driver *ptm_driver;
static struct tty_driver *pts_driver;
#endif
+static int pty_count;
static void pty_close(struct tty_struct *tty, struct file *filp)
{
BUG_ON(!tty);
- if (tty->driver->subtype == PTY_TYPE_MASTER)
+ if (tty->driver->subtype == PTY_TYPE_MASTER) {
WARN_ON(tty->count > 1);
- else {
+ pty_count--;
+ } else {
if (tty->count > 2)
return;
}
@@ -446,7 +448,6 @@ static inline void legacy_pty_init(void)
int pty_limit = NR_UNIX98_PTY_DEFAULT;
static int pty_limit_min;
static int pty_limit_max = NR_UNIX98_PTY_MAX;
-static int pty_count;
static struct cdev ptmx_cdev;
@@ -599,15 +600,9 @@ free_mem_out:
return -ENOMEM;
}
-static void pty_unix98_remove(struct tty_driver *driver, struct
tty_struct *tty)
-{
- pty_count--;
-}
-
static const struct tty_operations ptm_unix98_ops = {
.lookup = ptm_unix98_lookup,
.install = pty_unix98_install,
- .remove = pty_unix98_remove,
.open = pty_open,
.close = pty_close,
.write = pty_write,
@@ -624,7 +619,6 @@ static const struct tty_operations ptm_u
static const struct tty_operations pty_unix98_ops = {
.lookup = pts_unix98_lookup,
.install = pty_unix98_install,
- .remove = pty_unix98_remove,
.open = pty_open,
.close = pty_close,
.write = pty_write,
^ 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.