* Re: [patch 27/28] posix-timers: Add support for fd based clocks
From: john stultz @ 2011-02-01 21:38 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134420.062860200@linutronix.de>
On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix-timers-add-support-for-fd-based-clocks.patch)
> From: Richard Cochran <richard.cochran@omicron.at>
>
> Extend the negative clockids which are currently used by posix cpu
> timers to encode the PID with a file descriptor based type which
> encodes the fd in the upper bits.
>
> Originally-from: Richard Cochran <richard.cochran@omicron.at>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: John Stultz <john.stultz@linaro.org>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* LVM2/scripts lvmdump.sh
From: wysochanski @ 2011-02-01 21:39 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: wysochanski at sourceware.org 2011-02-01 21:39:15
Modified files:
scripts : lvmdump.sh
Log message:
Add "dmsetup ls --tree" output to lvmdump.
It would be most useful to add "dmsetup ls --tree" to the commands run.
This command helps in answering the question "which devices are actually
underneath a given LV?"
Although the info is available with other existing dmsetup commands,
adding this command gives a much clearer summary of complex setups.
Here's an example of an LVM mirror, with mirror images on partitions
created on top of multipath devices. The multipath devices are on
simple block devices. As you can see, it is easy to see the stacking
from the "dmsetup ls --tree" output:
vgmpathtest-lvmpathmir (253:14)
??????vgmpathtest-lvmpathmir_mimage_1 (253:13)
??? ??????mpath5p1 (253:5)
??? ??????mpath5 (253:2)
??? ?????? (8:16)
??? ?????? (8:0)
??????vgmpathtest-lvmpathmir_mimage_0 (253:12)
??? ??????mpath6p1 (253:6)
??? ??????mpath6 (253:3)
??? ?????? (8:48)
??? ?????? (8:32)
??????vgmpathtest-lvmpathmir_mlog (253:11)
??????mpath7 (253:4)
?????? (8:80)
?????? (8:64)
VolGroup00-LogVol01 (253:1)
?????? (202:2)
vgtest-lvmir (253:10)
??????vgtest-lvmir_mimage_1 (253:9)
??? ?????? (7:1)
??????vgtest-lvmir_mimage_0 (253:8)
??? ?????? (7:0)
??????vgtest-lvmir_mlog (253:7)
?????? (7:3)
VolGroup00-LogVol00 (253:0)
?????? (202:2)
But it is much harder to see the stacking with only the commands today
("dmsetup info", "dmsetup status", and "dmsetup table"). We could
piece together the stacking from "dmsetup table" but it requires
further processing (take output from "dmsetup info to get
map name to major/minor, then parse "dmsetup table", etc).
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/scripts/lvmdump.sh.diff?cvsroot=lvm2&r1=1.15&r2=1.16
--- LVM2/scripts/lvmdump.sh 2010/04/14 20:03:46 1.15
+++ LVM2/scripts/lvmdump.sh 2011/02/01 21:39:15 1.16
@@ -183,6 +183,7 @@
log "\"$DMSETUP\" info -c > \"$dir/dmsetup_info\" 2>> \"$log\""
log "\"$DMSETUP\" table > \"$dir/dmsetup_table\" 2>> \"$log\""
log "\"$DMSETUP\" status > \"$dir/dmsetup_status\" 2>> \"$log\""
+log "\"$DMSETUP\" ls --tree > \"$dir/dmsetup_ls_tree\" 2>> \"$log\""
myecho "Gathering process info..."
log "$PS alx > \"$dir/ps_info\" 2>> \"$log\""
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-01 21:41 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, steved, netdev, kvm, rusty
In-Reply-To: <1296595725.26937.819.camel@localhost.localdomain>
On Tue, Feb 01, 2011 at 01:28:45PM -0800, Shirley Ma wrote:
> On Tue, 2011-02-01 at 23:21 +0200, Michael S. Tsirkin wrote:
> > Confused. We compare capacity to skb frags, no?
> > That's sg I think ...
>
> Current guest kernel use indirect buffers, num_free returns how many
> available descriptors not skb frags. So it's wrong here.
>
> Shirley
I see. Good point. In other words when we complete the buffer
it was indirect, but when we add a new one we
can not allocate indirect so we consume.
And then we start the queue and add will fail.
I guess we need some kind of API to figure out
whether the buf we complete was indirect?
Another failure mode is when skb_xmit_done
wakes the queue: it might be too early, there
might not be space for the next packet in the vq yet.
A solution might be to keep some kind of pool
around for indirect, we wanted to do it for block anyway ...
--
MST
^ permalink raw reply
* [1.8.0] Handle submodule config options consistently in diff plumbing
From: Jens Lehmann @ 2011-02-01 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vwrll57ha.fsf@alter.siamese.dyndns.org>
Proposal:
Handle the submodule options "diff.ignoreSubmodules" and
"submodule.<name>.ignore" consistently in diff plumbing.
I see two basic ways to change the behavior of the plumbing diff
commands:
a) Let them use the "diff.ignoreSubmodules" configuration too.
b) Don't let them use the "submodule.<name>.ignore" entries either.
But if we go that way, we might have to revert the default of
recursing into populated submodules too, as it might cause
unexpected behavior when all configuration options introduced
to control that recursion are just ignored unless explicitly
told otherwise.
History:
When the submodule recursion for the diff commands was introduced,
all diff commands - including plumbing - learned to recurse into
submodules by default. This was done to mark submodules with
uncommitted changes as dirty so no user could accidentally forget
to commit his changes there before pushing in the superproject.
Some time after that "--ignore-submodules" learned some values to
achieve more control over what conditions mark a submodule dirty.
Then the "submodule.<name>.ignore" option was added to .git/config
and the .gitmodules file to to be able to specify these values for
one or more submodules. In a later commit the "diff.ignoreSubmodules"
option was added, but the plumbing diff commands weren't taught to
use that config option.
Risks:
a) Those scripts which depend on the plumbing commands to ignore
the setting from "diff.ignoreSubmodules" will break.
b) All scripts written or changed since 1.7.0 which depend on the
current behavior to recurse into submodules and use the
"submodule.<name>.ignore" entries will be broken.
Me thinks the risks are much smaller when doing a), as people who
learned to use the recursive behavior since 1.7.0 will see that
changed under their feet when we do b) and I expect much more code
to rely on the recursion than on the "diff.ignoreSubmodules"
setting. And doing a) would fix a real life problem too, see [1].
Migration plan:
a) During the 1.7.x series a new "noconfig" value is added for the
"--ignore-submodules" command line option for people who don't
want user configuration to interfere with the recursion, e.g. in
scripts (turning off the recursion is already implemented, just
use the "--ignore-submodules" option). And then starting with
1.8.0 "diff.ignoreSubmodules" will be used by diff plumbing.
b) During the 1.7.x series a new value for "--ignore-submodules"
called "porcelain" is added which enables recursion and also
tells diff plumbing use all configuration settings. Then all
relevant call sites (like git gui, gitk and PS1 from completion
and others) are changed to use this option. Changing the default
behavior to ignore "submodule.<name>.ignore" and to not recurse
anymore will be done in the 1.8.0 release.
Personally I'm in favor of solution a), but lets hear what other
people say.
[1] http://thread.gmane.org/gmane.comp.version-control.git/164166/focus=164172
^ permalink raw reply
* [Buildroot] [PATCH] Makefile.package.in: fix upper case $(PKG)_SITE_METHOD
From: Daniel Nyström @ 2011-02-01 21:41 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTi=hsz2+gsaUihXuYAz8uRuVKa4f0A9q3wHSdJgq@mail.gmail.com>
2011/2/1 Bj?rn Forsman <bjorn.forsman@gmail.com>:
> So the best thing is probably to patch the documentation.
While on it; maybe change YES/NO into yes/no will make all parameters
lower case?
^ permalink raw reply
* LVM2 WHATS_NEW
From: wysochanski @ 2011-02-01 21:41 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: wysochanski at sourceware.org 2011-02-01 21:41:31
Modified files:
. : WHATS_NEW
Log message:
Update WHATS_NEW for lvmdump change.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.1896&r2=1.1897
--- LVM2/WHATS_NEW 2011/01/31 19:52:40 1.1896
+++ LVM2/WHATS_NEW 2011/02/01 21:41:31 1.1897
@@ -1,5 +1,6 @@
Version 2.02.83 -
===================================
+ Add "dmsetup ls --tree" output to lvmdump.
Fix udev synchronization with no-locking --sysinit (2.02.80).
Updating man pages for pvcreate, pvremove, pvresize, pvscan.
Avoid rebuilding of uuid validation table.
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-01 21:42 UTC (permalink / raw)
To: Shirley Ma
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <1296595955.26937.822.camel@localhost.localdomain>
On Tue, Feb 01, 2011 at 01:32:35PM -0800, Shirley Ma wrote:
> On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> > My theory is that the issue is not signalling.
> > Rather, our queue fills up, then host handles
> > one packet and sends an interrupt, and we
> > immediately wake the queue. So the vq
> > once it gets full, stays full.
>
> >From the printk debugging output, it might not be exactly the case. The
> ring gets full, run a bit, then gets full, then run a bit, then full...
Yes, but does it get even half empty in between?
> > If you try my patch with bufs threshold set to e.g.
> > half the vq, what we will do is send interrupt after we have processed
> > half the vq. So host has half the vq to go, and guest has half the vq
> > to fill.
> >
> > See?
>
> I am cleaning up my set up to run your patch ...
>
> Shirley
>
^ permalink raw reply
* Re: Odd "data used" reporting behavior by ceph -w
From: Gregory Farnum @ 2011-02-01 21:44 UTC (permalink / raw)
To: Jim Schutt; +Cc: ceph-devel@vger.kernel.org
In-Reply-To: <1296595866.23762.226.camel@sale659.sandia.gov>
On Tue, Feb 1, 2011 at 1:31 PM, Jim Schutt <jaschut@sandia.gov> wrote:
> I've just lightly tested current stable branch, commit 0f3198e8c63.
>
> For me both problems seem to still exist.
Well that's a bummer.
> I'm running 4 osds per host on 4 hosts, 1 mon, 1 mds, 64 clients.
>
> For me a "ls" on the file system root from one of
> the clients still doesn't complete until the dd commands
> running on each client complete.
>
> Also, it is still true for me if I truncate all the files
> to zero from one of the clients, then write them again,
> one file per client, that second set of writes goes very
> slow.
>
> Am I maybe testing the wrong commit?
Nope, that commit should do it.
What version of the client software are you running? I'll have to look
over the change logs to see if maybe there are changes in there that
would impact this as well. Also my test environment is smaller than
yours; I'll endeavor to look this over again on a larger one with more
clients and see if I can spot any extra interactions causing problems.
-Greg
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-01 21:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Shawn Pearce, Jakub Narebski, Jonathan Nieder, Dmitry S. Kravtsov,
git, Junio C Hamano
In-Reply-To: <AANLkTi=oTL2_ObcyKRb7bf7ZMPZoa1BU7uNH5pJRQtVC@mail.gmail.com>
On Wed, 2 Feb 2011, Nguyen Thai Ngoc Duy wrote:
> - push support for shallow clone (Elijah approach does not base on
> shallow clone, so it's non-issue)
Push support from a shallow clone should be really simple. Either you
can update the remote, or you can't. If your local history does include
the remote branch head you wish to update then there is nothing
currently that would prevent the push from proceeding as implemented
today. If the remote head is outside the history subset you have
locally then the push simply cannot proceed.
Nicolas
^ permalink raw reply
* Re: b44 driver causes panic when using swiotlb
From: Robert Hancock @ 2011-02-01 21:44 UTC (permalink / raw)
To: Andi Kleen; +Cc: Chuck Ebbert, linux-kernel, David Woodhouse
In-Reply-To: <20110201180749.GA19382@tassilo.jf.intel.com>
On Tue, Feb 1, 2011 at 12:07 PM, Andi Kleen <ak@linux.intel.com> wrote:
> On Mon, Jan 31, 2011 at 06:54:21PM -0600, Robert Hancock wrote:
>> On 01/31/2011 10:36 AM, Andi Kleen wrote:
>> >On Mon, Jan 31, 2011 at 10:54:12AM -0500, Chuck Ebbert wrote:
>> >>The b44 driver is triggering this panic in swiotlb_map_page():
>> >>
>> >> if (!dma_capable(dev, dev_addr, size))
>> >> panic("map_single: bounce buffer is not DMA'ble");
>> >>
>> >>The kernel log says the bounce buffers are at 0xdb400000, but b44 can
>> >>only do DMA to the first 1GB of memory:
>> >
>> >b44 needs to use GFP_DMA then and do its own custom bouncing.
>> >The standard pci_map_* bounce buffering is only designed for at least
>> >32bit capable devices.
>>
>> That seems wrong - it's a documented API and that restriction isn'
>
> Please read the documentation. When PCI DMA cannot handle it
> it returns failure. That is what happened here.
Apparently not, given that it hit a panic inside the swiotlb code..
^ permalink raw reply
* RE: Kernel 2.6.32-5-amd64 fails to boot.
From: Leslie Rhorer @ 2011-02-01 21:44 UTC (permalink / raw)
To: 'Rudy Zijlstra'; +Cc: 'Linux RAID'
In-Reply-To: <4D4874D2.601@grumpydevil.homelinux.org>
> -----Original Message-----
> From: Rudy Zijlstra [mailto:rudy@grumpydevil.homelinux.org]
> Sent: Tuesday, February 01, 2011 3:02 PM
> To: lrhorer@satx.rr.com
> Cc: 'Linux RAID'
> Subject: Re: Kernel 2.6.32-5-amd64 fails to boot.
>
> On 02/01/2011 09:52 PM, Leslie Rhorer wrote:
> >> On 02/01/2011 09:23 PM, Leslie Rhorer wrote:
> >>
> >>
> >>> doesn't boot, either. It gives a bit more detail in the output, but
> >>>
> >> nothing
> >>
> >>> illuminating. The old kernel (2.6.32-3-amd64) boots just fine.
> >>>
> >>>
> >> Can you enable serial console and catch the console output that way?
> >>
> > Well, not easily. I don't have a serial terminal. I suppose I
> > could set something up. You're suggesting I poke around to see what md
> is
> > reporting? Also, I'm not sure why - if the keyboard console is failing
> -
> > the serial console would work better.
> >
> >
> >
> Serial console can be captured to a file and then the output analysed.
> So you can read afterwards the messages that are flying past.
>
> What i do in such case, is that i take serial connector from a laptop,
> and run a terminal emulater like minicom. And capture it to a file so i
> can analyse what has been happening.
Yeah, I don't think there is anything pertinent prior to the md
failures, but it might be worth a shot. I don't have a laptop, but I do
have another server sitting right below the one in question. The main
problem is, neither one has a serial port.
^ permalink raw reply
* [PATCHv2 2 of 2]LVM: allow exclusive snapshots in cluster
From: Jonathan Brassow @ 2011-02-01 21:48 UTC (permalink / raw)
To: lvm-devel
Allow snapshots in a cluster as long as they are exclusively
activated.
In order to achieve this, we need to be able to query whether
the origin is active exclusively (a condition of being able to
add an exclusive snapshot).
Index: LVM2/lib/activate/activate.c
===================================================================
--- LVM2.orig/lib/activate/activate.c
+++ LVM2/lib/activate/activate.c
@@ -696,23 +696,43 @@ int lvs_in_vg_opened(const struct volume
}
/*
+ * _lv_is_active
+ * @lv: logical volume being queried
+ * @locally: set if active locally
+ * @exclusive: set if active exclusively
+ *
* Determine whether an LV is active locally or in a cluster.
- * Assumes vg lock held.
- * Returns:
- * 0 - not active locally or on any node in cluster
- * 1 - active either locally or some node in the cluster
+ * In addition to the return code which indicates whether or
+ * not the LV is active somewhere, two other values are set
+ * to yield more information about the status of the activation:
+ * return locally exclusively status
+ * ====== ======= =========== ======
+ * 0 0 0 not active
+ * 0 0 1 N/A (not active)
+ * 0 1 0 N/A (not active)
+ * 0 1 1 N/A (not active)
+ * 1 0 0 active remotely
+ * 1 0 1 exclusive remotely
+ * 1 1 0 active locally and possibly remotely
+ * 1 1 1 exclusive locally (or local && !cluster)
+ * The VG lock must be held to call this function.
+ *
+ * Returns: 0 or 1
*/
-int lv_is_active(struct logical_volume *lv)
+static int _lv_is_active(struct logical_volume *lv,
+ int *locally, int *exclusive)
{
int ret;
if (_lv_active(lv->vg->cmd, lv))
- return 1;
+ *locally = 1;
- if (!vg_is_clustered(lv->vg))
- return 0;
+ if (!vg_is_clustered(lv->vg)) {
+ *exclusive = 1; /* by definition */
+ return *locally;
+ }
- if ((ret = remote_lock_held(lv->lvid.s)) >= 0)
+ if ((ret = remote_lock_held(lv->lvid.s, exclusive)) >= 0)
return ret;
/*
@@ -731,6 +751,34 @@ int lv_is_active(struct logical_volume *
return 1;
}
+int lv_is_active(struct logical_volume *lv)
+{
+ int l, e;
+ return _lv_is_active(lv, &l, &e);
+}
+
+/*
+int lv_is_active_locally(struct logical_volume *lv)
+{
+ int l, e;
+ return _lv_is_active(lv, &l, &e) && l;
+}
+*/
+
+int lv_is_active_exclusive_locally(struct logical_volume *lv)
+{
+ int l, e;
+ return _lv_is_active(lv, &l, &e) && l && e;
+}
+
+/*
+int lv_is_active_exclusive_remotely(struct logical_volume *lv)
+{
+ int l, e;
+ return _lv_is_active(lv, &l, &e) && !l && e;
+}
+*/
+
#ifdef DMEVENTD
static struct dm_event_handler *_create_dm_event_handler(struct cmd_context *cmd, const char *dmuuid, const char *dso,
const int timeout, enum dm_event_mask mask)
Index: LVM2/lib/activate/dev_manager.c
===================================================================
--- LVM2.orig/lib/activate/dev_manager.c
+++ LVM2/lib/activate/dev_manager.c
@@ -1390,10 +1390,6 @@ static int _add_segment_to_dtree(struct
/* If this is a snapshot origin, add real LV */
/* If this is a snapshot origin + merging snapshot, add cow + real LV */
} else if (lv_is_origin(seg->lv) && !layer) {
- if (vg_is_clustered(seg->lv->vg)) {
- log_error("Clustered snapshots are not yet supported");
- return 0;
- }
if (lv_is_merging_origin(seg->lv)) {
if (!_add_new_lv_to_dtree(dm, dtree,
find_merging_cow(seg->lv)->cow, "cow"))
Index: LVM2/lib/locking/locking.c
===================================================================
--- LVM2.orig/lib/locking/locking.c
+++ LVM2/lib/locking/locking.c
@@ -549,7 +549,7 @@ int locking_is_clustered(void)
return (_locking.flags & LCK_CLUSTERED) ? 1 : 0;
}
-int remote_lock_held(const char *vol)
+int remote_lock_held(const char *vol, int *exclusive)
{
int mode = LCK_NULL;
@@ -567,5 +567,8 @@ int remote_lock_held(const char *vol)
return 1;
}
+ if (exclusive)
+ *exclusive = (mode == LCK_EXCL);
+
return mode == LCK_NULL ? 0 : 1;
}
Index: LVM2/lib/locking/locking.h
===================================================================
--- LVM2.orig/lib/locking/locking.h
+++ LVM2/lib/locking/locking.h
@@ -25,7 +25,7 @@ void reset_locking(void);
int vg_write_lock_held(void);
int locking_is_clustered(void);
-int remote_lock_held(const char *vol);
+int remote_lock_held(const char *vol, int *exclusive);
/*
* LCK_VG:
Index: LVM2/lib/metadata/lv_manip.c
===================================================================
--- LVM2.orig/lib/metadata/lv_manip.c
+++ LVM2/lib/metadata/lv_manip.c
@@ -3164,11 +3164,6 @@ int lv_create_single(struct volume_group
"device-mapper kernel driver");
return 0;
}
- /* FIXME Allow exclusive activation. */
- if (vg_is_clustered(vg)) {
- log_error("Clustered snapshots are not yet supported.");
- return 0;
- }
/* Must zero cow */
status |= LVM_WRITE;
@@ -3217,6 +3212,12 @@ int lv_create_single(struct volume_group
return 0;
}
origin_active = info.exists;
+
+ if (!lv_is_active_exclusive_locally(org)) {
+ log_error("%s must be active exclusively to"
+ " create snapshot", org->name);
+ return 0;
+ }
}
}
Index: LVM2/lib/activate/activate.h
===================================================================
--- LVM2.orig/lib/activate/activate.h
+++ LVM2/lib/activate/activate.h
@@ -94,6 +94,7 @@ int lvs_in_vg_activated(struct volume_gr
int lvs_in_vg_opened(const struct volume_group *vg);
int lv_is_active(struct logical_volume *lv);
+int lv_is_active_exclusive_locally(struct logical_volume *lv);
int lv_has_target_type(struct dm_pool *mem, struct logical_volume *lv,
const char *layer, const char *target_type);
^ permalink raw reply
* Wrong version in xen/Makefile
From: M A Young @ 2011-02-01 21:49 UTC (permalink / raw)
To: xen-devel
I noticed a test build of xen-4.1.0-rc3 creates a hypervisor called
xen-4.1.0-rc3-pre.gz . I think xen/Makefile is a bit behind what it should
be.
Michael Young
^ permalink raw reply
* [PATCH v1 0/4] davinci: Add SPI support for da8xx platforms
From: Michael Williamson @ 2011-02-01 21:49 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds the necessary SPI resources and registration
routines for da850/OMAP-L138/AM18x and da830/OMAP-L137/AM17x devices.
It also adds on-board SPI FLASH devices for the da830 evm, the da850
evm, and the MityDSP-L138/MityARM-1808 platforms.
These patches are based on work done during testing of davinci SPI driver
submissions incorporated in version 2.6.38 of the kernel, at [1].
The da850 and da830 EVM portions of this patch need verification / ack.
The MityDSP-L138 platform patch has been tested.
The patch series is against commit 8fb837c158e342413d08d6f211b5b8f67d5adc2f
of kevin's tree.
[1] http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite
---
Changes since v0:
- fixed up issues in device stuctures pointed out by Sergei
- moved spi platform data structures to common array in devices-da8xx.c
- Added sign-off information for Sekhar's patches per comments.
Michael Williamson (2):
davinci: da8xx/omap-l1: add support for SPI
davinci: add spi devices support for MityDSP-L138/MityARM-1808
platform
Sekhar Nori (2):
davinci: add spi devices support for da850/omap-l138/am18x evm
davinci: add spi devices support for da830/omap-l137/am17x evm
arch/arm/mach-davinci/board-da830-evm.c | 78 ++++++++++++++++++++++
arch/arm/mach-davinci/board-da850-evm.c | 84 +++++++++++++++++++++++
arch/arm/mach-davinci/board-mityomapl138.c | 100 ++++++++++++++++++++++++++++
arch/arm/mach-davinci/da850.c | 16 +++++
arch/arm/mach-davinci/devices-da8xx.c | 96 ++++++++++++++++++++++++++
arch/arm/mach-davinci/include/mach/da8xx.h | 3 +
6 files changed, 377 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
From: Michael Williamson @ 2011-02-01 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
Add SPI registration routines, clocks, and driver resources for
DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
---
arch/arm/mach-davinci/da850.c | 16 +++++
arch/arm/mach-davinci/devices-da8xx.c | 96 ++++++++++++++++++++++++++++
arch/arm/mach-davinci/include/mach/da8xx.h | 3 +
3 files changed, 115 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..68fe4c2 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -359,6 +359,20 @@ static struct clk usb20_clk = {
.gpsc = 1,
};
+static struct clk spi0_clk = {
+ .name = "spi0",
+ .parent = &pll0_sysclk2,
+ .lpsc = DA8XX_LPSC0_SPI0,
+};
+
+static struct clk spi1_clk = {
+ .name = "spi1",
+ .parent = &pll0_sysclk2,
+ .lpsc = DA8XX_LPSC1_SPI1,
+ .gpsc = 1,
+ .flags = DA850_CLK_ASYNC3,
+};
+
static struct clk_lookup da850_clks[] = {
CLK(NULL, "ref", &ref_clk),
CLK(NULL, "pll0", &pll0_clk),
@@ -403,6 +417,8 @@ static struct clk_lookup da850_clks[] = {
CLK(NULL, "aemif", &aemif_clk),
CLK(NULL, "usb11", &usb11_clk),
CLK(NULL, "usb20", &usb20_clk),
+ CLK("spi_davinci.0", NULL, &spi0_clk),
+ CLK("spi_davinci.1", NULL, &spi1_clk),
CLK(NULL, NULL, NULL),
};
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..f421f97 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
return platform_device_register(&da8xx_cpuidle_device);
}
+
+static struct resource da8xx_spi0_resources[] = {
+ [0] = {
+ .start = 0x01c41000,
+ .end = 0x01c41fff,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_DA8XX_SPINT0,
+ .end = IRQ_DA8XX_SPINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = EDMA_CTLR_CHAN(0, 14),
+ .end = EDMA_CTLR_CHAN(0, 14),
+ .flags = IORESOURCE_DMA,
+ },
+ [3] = {
+ .start = EDMA_CTLR_CHAN(0, 15),
+ .end = EDMA_CTLR_CHAN(0, 15),
+ .flags = IORESOURCE_DMA,
+ },
+ [4] = {
+ .flags = IORESOURCE_DMA,
+ },
+};
+
+static struct resource da8xx_spi1_resources[] = {
+ [0] = {
+ .start = 0x01f0e000,
+ .end = 0x01f0efff,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_DA8XX_SPINT1,
+ .end = IRQ_DA8XX_SPINT1,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = EDMA_CTLR_CHAN(0, 18),
+ .end = EDMA_CTLR_CHAN(0, 18),
+ .flags = IORESOURCE_DMA,
+ },
+ [3] = {
+ .start = EDMA_CTLR_CHAN(0, 19),
+ .end = EDMA_CTLR_CHAN(0, 19),
+ .flags = IORESOURCE_DMA,
+ },
+ [4] = {
+ .flags = IORESOURCE_DMA,
+ },
+};
+
+struct davinci_spi_platform_data da8xx_spi_pdata[] = {
+ [0] = {
+ .version = SPI_VERSION_2,
+ .intr_line = 1,
+ },
+ [1] = {
+ .version = SPI_VERSION_2,
+ .intr_line = 1,
+ },
+};
+
+static struct platform_device da8xx_spi_device[] = {
+ [0] = {
+ .name = "spi_davinci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(da8xx_spi0_resources),
+ .resource = da8xx_spi0_resources,
+ .dev = {
+ .platform_data = &da8xx_spi_pdata[0],
+ },
+ },
+ [1] = {
+ .name = "spi_davinci",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(da8xx_spi1_resources),
+ .resource = da8xx_spi1_resources,
+ .dev = {
+ .platform_data = &da8xx_spi_pdata[1],
+ },
+ },
+};
+
+int __init da8xx_register_spi(int instance)
+{
+ struct platform_device *pdev;
+
+ if (instance == 0 || instance == 1)
+ pdev = &da8xx_spi_device[instance];
+ else
+ return -EINVAL;
+
+ return platform_device_register(pdev);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..0c5fa01 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -23,6 +23,7 @@
#include <mach/mmc.h>
#include <mach/usb.h>
#include <mach/pm.h>
+#include <mach/spi.h>
extern void __iomem *da8xx_syscfg0_base;
extern void __iomem *da8xx_syscfg1_base;
@@ -77,6 +78,7 @@ void __init da850_init(void);
int da830_register_edma(struct edma_rsv_info *rsv);
int da850_register_edma(struct edma_rsv_info *rsv[2]);
int da8xx_register_i2c(int instance, struct davinci_i2c_platform_data *pdata);
+int da8xx_register_spi(int instance);
int da8xx_register_watchdog(void);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
@@ -95,6 +97,7 @@ extern struct platform_device da8xx_serial_device;
extern struct emac_platform_data da8xx_emac_pdata;
extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
+extern struct davinci_spi_platform_data da8xx_spi_pdata[];
extern struct platform_device da8xx_wdt_device;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v1 2/4] davinci: add spi devices support for MityDSP-L138/MityARM-1808 platform
From: Michael Williamson @ 2011-02-01 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
This patch adds support for accessing the on board SPI NOR FLASH
device for MityDSP-L138 and MityARM-1808 SoMs.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
---
arch/arm/mach-davinci/board-mityomapl138.c | 100 ++++++++++++++++++++++++++++
1 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 0ea5932..dc4c3f1 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -17,6 +17,8 @@
#include <linux/i2c.h>
#include <linux/i2c/at24.h>
#include <linux/etherdevice.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -25,6 +27,7 @@
#include <mach/da8xx.h>
#include <mach/nand.h>
#include <mach/mux.h>
+#include <mach/spi.h>
#define MITYOMAPL138_PHY_ID "0:03"
@@ -294,6 +297,100 @@ static int __init pmic_tps65023_init(void)
}
/*
+ * SPI Devices:
+ * SPI1_CS0: 8M Flash ST-M25P64-VME6G
+ */
+static struct mtd_partition spi_flash_partitions[] = {
+ [0] = {
+ .name = "ubl",
+ .offset = 0,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = "u-boot",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_512K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [2] = {
+ .name = "u-boot-env",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [3] = {
+ .name = "periph-config",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [4] = {
+ .name = "reserved",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K + SZ_64K,
+ },
+ [5] = {
+ .name = "kernel",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M + SZ_1M,
+ },
+ [6] = {
+ .name = "fpga",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ },
+ [7] = {
+ .name = "spare",
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct flash_platform_data mityomapl138_spi_flash_data = {
+ .name = "m25p80",
+ .parts = spi_flash_partitions,
+ .nr_parts = ARRAY_SIZE(spi_flash_partitions),
+ .type = "m24p64",
+};
+
+static struct davinci_spi_config spi_eprom_config = {
+ .io_type = SPI_IO_TYPE_DMA,
+ .c2tdelay = 8,
+ .t2cdelay = 8,
+};
+
+static struct spi_board_info mityomapl138_spi_flash_info[] = {
+ {
+ .modalias = "m25p80",
+ .platform_data = &mityomapl138_spi_flash_data,
+ .controller_data = &spi_eprom_config,
+ .mode = SPI_MODE_0,
+ .max_speed_hz = 30000000,
+ .bus_num = 1,
+ .chip_select = 0,
+ },
+};
+
+static void __init mityomapl138_init_spi1(struct spi_board_info *info,
+ unsigned len)
+{
+ int ret;
+
+ ret = spi_register_board_info(info, len);
+ if (ret)
+ pr_warning("%s: failed to register board info : %d\n",
+ __func__, ret);
+
+ da8xx_spi_pdata[1].num_chipselect = len;
+
+ ret = da8xx_register_spi(1);
+ if (ret)
+ pr_warning("%s: failed to register spi 1 device : %d\n",
+ __func__, ret);
+}
+
+/*
* MityDSP-L138 includes a 256 MByte large-page NAND flash
* (128K blocks).
*/
@@ -448,6 +545,9 @@ static void __init mityomapl138_init(void)
mityomapl138_setup_nand();
+ mityomapl138_init_spi1(mityomapl138_spi_flash_info,
+ ARRAY_SIZE(mityomapl138_spi_flash_info));
+
mityomapl138_config_emac();
ret = da8xx_register_rtc();
--
1.7.0.4
^ permalink raw reply related
* [PATCH v1 3/4] davinci: add spi devices support for da850/omap-l138/am18x evm
From: Michael Williamson @ 2011-02-01 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
From: Sekhar Nori <nsekhar@ti.com>
This patch adds the on-board SPI flash device to the
DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
device to the MTD subsystem.
Based on SPI flash device support for MityDSP-L138F platform.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[michael.williamson at criticallink.com: moved da850_evm_spi1_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 84 +++++++++++++++++++++++++++++++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..487bd3a 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,8 @@
#include <linux/regulator/machine.h>
#include <linux/regulator/tps6507x.h>
#include <linux/input/tps6507x-ts.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -38,6 +40,7 @@
#include <mach/nand.h>
#include <mach/mux.h>
#include <mach/aemif.h>
+#include <mach/spi.h>
#define DA850_EVM_PHY_ID "0:00"
#define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8)
@@ -48,6 +51,85 @@
#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6)
+static struct mtd_partition da850evm_spiflash_part[] = {
+ [0] = {
+ .name = "UBL",
+ .offset = 0,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = "U-Boot",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_512K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [2] = {
+ .name = "U-Boot-Env",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [3] = {
+ .name = "Kernel",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M + SZ_512K,
+ .mask_flags = 0,
+ },
+ [4] = {
+ .name = "Filesystem",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_4M,
+ .mask_flags = 0,
+ },
+ [5] = {
+ .name = "MAC-Address",
+ .offset = SZ_8M - SZ_64K,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+};
+
+static struct flash_platform_data da850evm_spiflash_data = {
+ .name = "m25p80",
+ .parts = da850evm_spiflash_part,
+ .nr_parts = ARRAY_SIZE(da850evm_spiflash_part),
+ .type = "m25p64",
+};
+
+static struct davinci_spi_config da850evm_spiflash_cfg = {
+ .io_type = SPI_IO_TYPE_DMA,
+ .c2tdelay = 8,
+ .t2cdelay = 8,
+};
+
+static struct spi_board_info da850evm_spi_info[] = {
+ {
+ .modalias = "m25p80",
+ .platform_data = &da850evm_spiflash_data,
+ .controller_data = &da850evm_spiflash_cfg,
+ .mode = SPI_MODE_0,
+ .max_speed_hz = 30000000,
+ .bus_num = 1,
+ .chip_select = 0,
+ },
+};
+
+static void __init da850evm_init_spi1(struct spi_board_info *info, unsigned len)
+{
+ int ret;
+
+ ret = spi_register_board_info(info, len);
+ if (ret)
+ pr_warning("failed to register board info : %d\n", ret);
+
+ da8xx_spi_pdata[1].num_chipselect = len;
+
+ ret = da8xx_register_spi(1);
+ if (ret)
+ pr_warning("failed to register spi 1 device : %d\n", ret);
+}
+
static struct mtd_partition da850_evm_norflash_partition[] = {
{
.name = "bootloaders + env",
@@ -1167,6 +1249,8 @@ static __init void da850_evm_init(void)
if (ret)
pr_warning("da850_evm_init: suspend registration failed: %d\n",
ret);
+
+ da850evm_init_spi1(da850evm_spi_info, ARRAY_SIZE(da850evm_spi_info));
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
1.7.0.4
^ permalink raw reply related
* [PATCH v1 4/4] davinci: add spi devices support for da830/omap-l137/am17x evm
From: Michael Williamson @ 2011-02-01 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
From: Sekhar Nori <nsekhar@ti.com>
This patch adds the on-board SPI flash device to the
DA830/OMAP-L137/AM17x EVM. It also registers the SPI flash
device to the MTD subsystem.
Based on SPI flash device support for MityDSP-L138F platform.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[michael.williamson at criticallink.com: moved da830evm_spi0_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 78 +++++++++++++++++++++++++++++++
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index b52a3a1..01319bd 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -20,6 +20,8 @@
#include <linux/i2c/at24.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -30,6 +32,7 @@
#include <mach/da8xx.h>
#include <mach/usb.h>
#include <mach/aemif.h>
+#include <mach/spi.h>
#define DA830_EVM_PHY_ID ""
/*
@@ -534,6 +537,79 @@ static struct edma_rsv_info da830_edma_rsv[] = {
},
};
+static struct mtd_partition da830evm_spiflash_part[] = {
+ [0] = {
+ .name = "DSP-UBL",
+ .offset = 0,
+ .size = SZ_8K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = "ARM-UBL",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_16K + SZ_8K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [2] = {
+ .name = "U-Boot",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K - SZ_32K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [3] = {
+ .name = "U-Boot-Environment",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_16K,
+ .mask_flags = 0,
+ },
+ [4] = {
+ .name = "Kernel",
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0,
+ },
+};
+
+static struct flash_platform_data da830evm_spiflash_data = {
+ .name = "m25p80",
+ .parts = da830evm_spiflash_part,
+ .nr_parts = ARRAY_SIZE(da830evm_spiflash_part),
+ .type = "w25x32",
+};
+
+static struct davinci_spi_config da830evm_spiflash_cfg = {
+ .io_type = SPI_IO_TYPE_DMA,
+ .c2tdelay = 8,
+ .t2cdelay = 8,
+};
+
+static struct spi_board_info da830evm_spi_info[] = {
+ {
+ .modalias = "m25p80",
+ .platform_data = &da830evm_spiflash_data,
+ .controller_data = &da830evm_spiflash_cfg,
+ .mode = SPI_MODE_0,
+ .max_speed_hz = 30000000,
+ .bus_num = 0,
+ .chip_select = 0,
+ },
+};
+
+static void __init da830evm_init_spi0(struct spi_board_info *info, unsigned len)
+{
+ int ret;
+
+ ret = spi_register_board_info(info, len);
+ if (ret)
+ pr_warning("failed to register board info : %d\n", ret);
+
+ da8xx_spi_pdata[0].num_chipselect = len;
+
+ ret = da8xx_register_spi(0);
+ if (ret)
+ pr_warning("failed to register spi 0 device : %d\n", ret);
+}
+
static __init void da830_evm_init(void)
{
struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -590,6 +666,8 @@ static __init void da830_evm_init(void)
ret = da8xx_register_rtc();
if (ret)
pr_warning("da830_evm_init: rtc setup failed: %d\n", ret);
+
+ da830evm_init_spi0(da830evm_spi_info, ARRAY_SIZE(da830evm_spi_info));
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
1.7.0.4
^ permalink raw reply related
* Re: [patch 28/28] posix clocks: Introduce dynamic clocks
From: john stultz @ 2011-02-01 21:49 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134420.164172635@linutronix.de>
On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix-clocks-introduce-dynamic-clocks.patch)
> From: Richard Cochran <richardcochran@gmail.com>
>
> This patch adds support for adding and removing posix clocks. The
> clock lifetime cycle is patterned after usb devices. Each clock is
> represented by a standard character device. In addition, the driver
> may optionally implement custom character device operations.
>
> The posix clock and timer system calls listed below now work with
> dynamic posix clocks, as well as the traditional static clocks.
> The following system calls are affected:
>
> - clock_adjtime (brand new syscall)
> - clock_gettime
> - clock_getres
> - clock_settime
> - timer_create
> - timer_delete
> - timer_gettime
> - timer_settime
>
> [ tglx: Adapted to the posix-timer cleanup. Moved clock_posix_dynamic
> to posix-clock.c and made all referenced functions static ]
I sort of worry about the naming collision with the term posix-clock, as
this is just one type of posix clock (I suspect most folks think of a
posix clock as the clockid passed to the existing posix api).
Could we maybe use posix-dynclock or posix-fdclock or something? I know
its already been changed from clkdev, so sorry for being finicky here
and not catching this earlier.
thanks
-john
^ permalink raw reply
* advice needed on how best to fix kirkwood kexec
From: Eric Cooper @ 2011-02-01 21:50 UTC (permalink / raw)
To: linux-arm-kernel
I found the problem with kexec'ing kirkwood kernels:
During late initialization, the kirkwood_clock_gate function powers
down unused units, including the PCIe. But the early initialization
(kirkwood_timer_init) relies on reading the device ID register, which
is in the PCIe space, so it will hang when started by kexec.
My question is, should I patch the kexec code or the initialization code?
Patching the kexec code is much more useful, because it allows
kexec'ing the existing kirkwood kernels that are already "out there",
in distros, etc. But it requires a kirkwood-specific operation in the
otherwise generic machine_kexec().
Patching just the kirkwood initialization is better from an
"information hiding" perspective, but won't provide any benefit until
it makes its way into the kernels that people might want to kexec.
--
Eric Cooper e c c @ c m u . e d u
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-01 21:51 UTC (permalink / raw)
To: Shawn Pearce
Cc: Nguyen Thai Ngoc Duy, Jakub Narebski, Jonathan Nieder,
Dmitry S. Kravtsov, git
In-Reply-To: <AANLkTi=KUpYJBRMp9ti0h+g6a0iTw4D113rTgfTpR8C4@mail.gmail.com>
On Tue, 1 Feb 2011, Shawn Pearce wrote:
> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > Narrow/Subtree clone is still just an idea, but can pack cache support
> > be made to resumable initial narrow clone too?
>
> This would be very hard to do. We could do cached packs for a popular
> set of path specifications (e.g. Documentation/ if documentation only
> editing is common), but once we start getting random requests for path
> specifications that we cannot predict in advance and pre-pack we'd
> have to fall back to the normal enumerate code path.
Also... people interested in Narrow clones are likely to be shallow
clone users too, right?
Nicolas
^ permalink raw reply
* btrfs bug in 2.6.37
From: Carlos R. Mafra @ 2011-02-01 21:51 UTC (permalink / raw)
To: linux-btrfs
I am running 2.6.37 plus the revert of bf9dc102e284 (which is related to drm).
My /home is on btrfs as well as a 1TB external USB hard-disk.
I was compiling 2.6.38-rc3 from /home/mafra/linux2.6 using
the external hd as the destination of the compiled files:
make -j4 O=/mnt/wd/kernel-compile
So after some time I got this bug and I was dropped out of X
[ 2730.943101] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[ 2730.943159] IP: [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2730.943217] PGD 2248f067 PUD 5adc8067 PMD 0
[ 2730.943256] Oops: 0000 [#1] SMP
[ 2730.943285] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
[ 2730.943331] CPU 0
[ 2730.943346] Modules linked in: ppp_deflate ppp_async ppp_generic slhc snd_seq snd_seq_device vfat fat option usb_wwan usbserial snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec sky2 uvcvideo i2c_i801 snd_hwdep evdev
[ 2730.943526]
[ 2730.943541] Pid: 15437, comm: as Not tainted 2.6.37-xrandr-00001-g1d95a75 #16 VAIO/VGN-FZ240E
[ 2730.943581] RIP: 0010:[<ffffffff811ba3e5>] [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2730.943629] RSP: 0000:ffff88005a771ad8 EFLAGS: 00010287
[ 2730.943661] RAX: 00000000fffffffb RBX: ffff88005b048d90 RCX: ffff880037f49d38
[ 2730.943695] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88004d456000
[ 2730.943729] RBP: ffff88005a771b58 R08: 00000000fffffffb R09: 0000000000000000
[ 2730.943763] R10: 0000000000000001 R11: 00000000ffffffff R12: 0000000000000005
[ 2730.943797] R13: ffff88005a771fd8 R14: 0000000000000000 R15: 0000000000000000
[ 2730.943831] FS: 00002b01b9f88000(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
[ 2730.943872] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2730.943901] CR2: 0000000000000030 CR3: 000000006161c000 CR4: 00000000000006f0
[ 2730.943934] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2730.943968] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2730.944002] Process as (pid: 15437, threadinfo ffff88005a770000, task ffff88002ffea680)
[ 2730.944009] Stack:
[ 2730.944009] 0000001cc7d27000 ffffffff811e4724 ffff88004d456000 0000001cc7784000
[ 2730.944009] ffff88005a771b58 ffff88005b048d90 0000001cc7d27000 00000000005000a8
[ 2730.944009] ffff8800491a0e00 ffff88006c2de6c0 0000000000000005 ffff88005b048d90
[ 2730.944009] Call Trace:
[ 2730.944009] [<ffffffff811e4724>] ? set_extent_dirty+0x24/0x30
[ 2730.944009] [<ffffffff811b30dd>] __btrfs_free_extent+0x61d/0x6e0
[ 2730.944009] [<ffffffff811b635b>] run_clustered_refs+0x1fb/0x810
[ 2730.944009] [<ffffffff811e7bda>] ? set_extent_buffer_dirty+0x4a/0xa0
[ 2730.944009] [<ffffffff811c342f>] ? btrfs_mark_buffer_dirty+0xaf/0x130
[ 2730.944009] [<ffffffff81201100>] ? btrfs_find_ref_cluster+0x60/0x190
[ 2730.944009] [<ffffffff811b6a30>] btrfs_run_delayed_refs+0xc0/0x210
[ 2730.944009] [<ffffffff811c55b8>] __btrfs_end_transaction+0x68/0x240
[ 2730.944009] [<ffffffff811c57d0>] btrfs_end_transaction+0x10/0x20
[ 2730.944009] [<ffffffff811ced57>] btrfs_evict_inode+0x1c7/0x1e0
[ 2730.944009] [<ffffffff810fa8c2>] evict+0x22/0xb0
[ 2730.944009] [<ffffffff810fb141>] iput+0x1b1/0x290
[ 2730.944009] [<ffffffff810f14f5>] do_unlinkat+0x115/0x1c0
[ 2730.944009] [<ffffffff810e94ae>] ? sys_newlstat+0x2e/0x40
[ 2730.944009] [<ffffffff810f2af1>] sys_unlink+0x11/0x20
[ 2730.944009] [<ffffffff81002cfb>] system_call_fastpath+0x16/0x1b
[ 2730.944009] Code: 84 00 00 00 00 00 55 48 89 e5 48 83 c4 80 48 89 5d d8 4c 89 6d e8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 65 4c 8b 2c 25 88 b5 00 00 <48> 8b 46 30 49 81 ed d8 1f 00 00 48 89 f3 41 ff 45 1c 48 ba 00
[ 2730.944009] RIP [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2730.944009] RSP <ffff88005a771ad8>
[ 2730.944009] CR2: 0000000000000030
[ 2730.950886] ---[ end trace 3c2d14569018819f ]---
[ 2731.229129] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[ 2731.230010] IP: [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2731.230010] PGD 22623067 PUD 2278d067 PMD 0
[ 2731.230010] Oops: 0000 [#2] SMP
[ 2731.230010] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
[ 2731.230010] CPU 1
[ 2731.230010] Modules linked in: ppp_deflate ppp_async ppp_generic slhc snd_seq snd_seq_device vfat fat option usb_wwan usbserial snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec sky2 uvcvideo i2c_i801 snd_hwdep evdev
[ 2731.230010]
[ 2731.230010] Pid: 15444, comm: as Tainted: G D 2.6.37-xrandr-00001-g1d95a75 #16 VAIO/VGN-FZ240E
[ 2731.230010] RIP: 0010:[<ffffffff811ba3e5>] [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2731.230010] RSP: 0000:ffff88004d42dad8 EFLAGS: 00010287
[ 2731.230010] RAX: 00000000fffffffb RBX: ffff88005b048b50 RCX: ffff880037f49d38
[ 2731.230010] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88004d456000
[ 2731.230010] RBP: ffff88004d42db58 R08: 00000000fffffffb R09: 0000000000000000
[ 2731.230010] R10: 0000000000000001 R11: 00000000ffffffff R12: 0000000000000005
[ 2731.230010] R13: ffff88004d42dfd8 R14: 0000000000000000 R15: 0000000000000000
[ 2731.230010] FS: 00002aac5cec6000(0000) GS:ffff88007f500000(0000) knlGS:0000000000000000
[ 2731.230010] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2731.230010] CR2: 0000000000000030 CR3: 00000000226af000 CR4: 00000000000006e0
[ 2731.230010] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2731.230010] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2731.230010] Process as (pid: 15444, threadinfo ffff88004d42c000, task ffff88007b69e280)
[ 2731.230010] Stack:
[ 2731.230010] 0000001cc7d2c000 ffffffff811dd7c5 ffff88004d456000 ffff8800218b8898
[ 2731.230010] ffff88004d42dba8 ffff88005b048b50 0000001cc7d2c000 00000000005000a8
[ 2731.230010] ffff88004d42db00 ffff88005a5e5cc0 0000000000000005 ffff88005b048b50
[ 2731.230010] Call Trace:
[ 2731.230010] [<ffffffff811dd7c5>] ? btrfs_key_generation+0xe5/0xf0
[ 2731.230010] [<ffffffff811b30dd>] __btrfs_free_extent+0x61d/0x6e0
[ 2731.230010] [<ffffffff811e7bda>] ? set_extent_buffer_dirty+0x4a/0xa0
[ 2731.230010] [<ffffffff811c342f>] ? btrfs_mark_buffer_dirty+0xaf/0x130
[ 2731.230010] [<ffffffff811b635b>] run_clustered_refs+0x1fb/0x810
[ 2731.230010] [<ffffffff81201100>] ? btrfs_find_ref_cluster+0x60/0x190
[ 2731.230010] [<ffffffff811b6a30>] btrfs_run_delayed_refs+0xc0/0x210
[ 2731.230010] [<ffffffff811c55b8>] __btrfs_end_transaction+0x68/0x240
[ 2731.230010] [<ffffffff811c57d0>] btrfs_end_transaction+0x10/0x20
[ 2731.230010] [<ffffffff811ced1f>] btrfs_evict_inode+0x18f/0x1e0
[ 2731.230010] [<ffffffff810fa8c2>] evict+0x22/0xb0
[ 2731.230010] [<ffffffff810fb141>] iput+0x1b1/0x290
[ 2731.230010] [<ffffffff810f14f5>] do_unlinkat+0x115/0x1c0
[ 2731.230010] [<ffffffff810e94ae>] ? sys_newlstat+0x2e/0x40
[ 2731.230010] [<ffffffff810f2af1>] sys_unlink+0x11/0x20
[ 2731.230010] [<ffffffff81002cfb>] system_call_fastpath+0x16/0x1b
[ 2731.230010] Code: 84 00 00 00 00 00 55 48 89 e5 48 83 c4 80 48 89 5d d8 4c 89 6d e8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 65 4c 8b 2c 25 88 b5 00 00 <48> 8b 46 30 49 81 ed d8 1f 00 00 48 89 f3 41 ff 45 1c 48 ba 00
[ 2731.230010] RIP [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2731.230010] RSP <ffff88004d42dad8>
[ 2731.230010] CR2: 0000000000000030
[ 2731.304076] ---[ end trace 3c2d1456901881a0 ]---
[ 2731.778512] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[ 2731.779007] IP: [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2731.779007] PGD 2ffa8067 PUD 5a93d067 PMD 0
[ 2731.779007] Oops: 0000 [#3] SMP
[ 2731.779007] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
[ 2731.779007] CPU 0
[ 2731.779007] Modules linked in: ppp_deflate ppp_async ppp_generic slhc snd_seq snd_seq_device vfat fat option usb_wwan usbserial snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec sky2 uvcvideo i2c_i801 snd_hwdep evdev
[ 2731.779007]
[ 2731.779007] Pid: 15448, comm: as Tainted: G D 2.6.37-xrandr-00001-g1d95a75 #16 VAIO/VGN-FZ240E
[ 2731.779007] RIP: 0010:[<ffffffff811ba3e5>] [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2731.779007] RSP: 0018:ffff8800227c5ad8 EFLAGS: 00010287
[ 2731.779007] RAX: 00000000fffffffb RBX: ffff88005b048c70 RCX: ffff880021f9fd38
[ 2731.779007] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88004d456000
[ 2731.779007] RBP: ffff8800227c5b58 R08: 00000000fffffffb R09: 0000000000000000
[ 2731.779007] R10: 0000000000000001 R11: 00000000ffffffff R12: 0000000000000005
[ 2731.779007] R13: ffff8800227c5fd8 R14: 0000000000000000 R15: 0000000000000000
[ 2731.779007] FS: 00002b0f18c8e000(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
[ 2731.779007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2731.779007] CR2: 0000000000000030 CR3: 000000006c0b5000 CR4: 00000000000006f0
[ 2731.779007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2731.779007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2731.779007] Process as (pid: 15448, threadinfo ffff8800227c4000, task ffff88003acfc5c0)
[ 2731.779007] Stack:
[ 2731.779007] 0000001cc7d3c000 ffffffff811dd7c5 ffff88004d456000 ffff8800218b21f0
[ 2731.779007] ffff8800227c5ba8 ffff88005b048c70 0000001cc7d3c000 00000000005000a8
[ 2731.779007] ffff8800227c5b00 ffff88007229ea40 0000000000000005 ffff88005b048c70
[ 2731.779007] Call Trace:
[ 2731.779007] [<ffffffff811dd7c5>] ? btrfs_key_generation+0xe5/0xf0
[ 2731.779007] [<ffffffff811b30dd>] __btrfs_free_extent+0x61d/0x6e0
[ 2731.779007] [<ffffffff811dd9b4>] ? btrfs_item_offset+0xe4/0xf0
[ 2731.779007] [<ffffffff811b635b>] run_clustered_refs+0x1fb/0x810
[ 2731.779007] [<ffffffff811e7bda>] ? set_extent_buffer_dirty+0x4a/0xa0
[ 2731.779007] [<ffffffff811c342f>] ? btrfs_mark_buffer_dirty+0xaf/0x130
[ 2731.779007] [<ffffffff81201100>] ? btrfs_find_ref_cluster+0x60/0x190
[ 2731.779007] [<ffffffff811b6a30>] btrfs_run_delayed_refs+0xc0/0x210
[ 2731.779007] [<ffffffff811c55b8>] __btrfs_end_transaction+0x68/0x240
[ 2731.779007] [<ffffffff811c57d0>] btrfs_end_transaction+0x10/0x20
[ 2731.779007] [<ffffffff811ced57>] btrfs_evict_inode+0x1c7/0x1e0
[ 2731.779007] [<ffffffff810fa8c2>] evict+0x22/0xb0
[ 2731.779007] [<ffffffff810fb141>] iput+0x1b1/0x290
[ 2731.779007] [<ffffffff810f14f5>] do_unlinkat+0x115/0x1c0
[ 2731.779007] [<ffffffff810e94ae>] ? sys_newlstat+0x2e/0x40
[ 2731.779007] [<ffffffff810f2af1>] sys_unlink+0x11/0x20
[ 2731.779007] [<ffffffff81002cfb>] system_call_fastpath+0x16/0x1b
[ 2731.779007] Code: 84 00 00 00 00 00 55 48 89 e5 48 83 c4 80 48 89 5d d8 4c 89 6d e8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 65 4c 8b 2c 25 88 b5 00 00 <48> 8b 46 30 49 81 ed d8 1f 00 00 48 89 f3 41 ff 45 1c 48 ba 00
[ 2731.779007] RIP [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
[ 2731.779007] RSP <ffff8800227c5ad8>
[ 2731.779007] CR2: 0000000000000030
[ 2731.855520] ---[ end trace 3c2d1456901881a1 ]---
[ 2732.101887] btrfs csum failed ino 244904 extent 124692799488 csum 4201110721 wanted 126609361 mirror 0
[ 2732.102064] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102084] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102102] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102121] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102139] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102158] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102176] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102195] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102213] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102231] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.102250] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2732.103048] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 0
[ 2732.103086] btrfs csum failed ino 244904 extent 124692799488 csum 2566472073 wanted 126609361 mirror 1
[ 2738.344564] btrfs csum failed ino 244835 extent 124686446592 csum 4201110721 wanted 3023272677 mirror 0
[ 2738.344662] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344683] btrfs csum failed ino 244835 extent 124686446592 csum 4201110721 wanted 3023272677 mirror 1
[ 2738.344702] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344729] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344748] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344752] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344768] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344772] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344792] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344823] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344843] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344862] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
[ 2738.344884] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 0
[ 2738.344932] btrfs csum failed ino 244835 extent 124686446592 csum 2566472073 wanted 3023272677 mirror 1
Is this problem already known?
^ permalink raw reply
* Re: [PATCH 1/2] SPARC32: implement SMP IPIs using the generic functions
From: Julian Calaby @ 2011-02-01 21:52 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <1296059911-22861-1-git-send-email-daniel@gaisler.com>
On Wed, Feb 2, 2011 at 07:34, David Miller <davem@davemloft.net> wrote:
> From: Daniel Hellstrom <daniel@gaisler.com>
> Date: Tue, 01 Feb 2011 08:41:51 +0100
>> This is already true, it can be located on any 256 Mbyte boundary. The
>> Kconfig options are only used to create the u-boot image, they do not
>> change the arch/sparc/boot/image in any way, just a matter of
>> convenience when creating the uImage similar to other architectures
>> which support u-boot.
>
> Ok, this is the part I didn't understand.
U-boot (I know because I'm grappling with it on an embedded ARM system
at the moment) is a boot loader that's essentially OF + GRUB in one
package. Modern versions of it peek into the disk and load Linux into
memory from some pre-determined file(s) then boot it in the normal
way. To do this it needs some more info than just the file names, e.g.
how big it is, where to load it and where to jump to, so it only loads
files that have a particular format, which is essentially the kernel /
initrd with an extra header.
The uImage target (if it's anything like the ARM one) sticks that
header on, nothing else, so the numbers that are being set in KConfig
are only changing variables in that header, not how the kernel is
compiled.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 21:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <20110201214211.GB31105@redhat.com>
On Tue, 2011-02-01 at 23:42 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 01, 2011 at 01:32:35PM -0800, Shirley Ma wrote:
> > On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> > > My theory is that the issue is not signalling.
> > > Rather, our queue fills up, then host handles
> > > one packet and sends an interrupt, and we
> > > immediately wake the queue. So the vq
> > > once it gets full, stays full.
> >
> > >From the printk debugging output, it might not be exactly the case.
> The
> > ring gets full, run a bit, then gets full, then run a bit, then
> full...
>
> Yes, but does it get even half empty in between?
Sometimes, most of them not half of empty in between. But printk slow
down the traffics, so it's not accurate. I think your patch will improve
the performance if it signals guest when half of the ring size is
empty.
But you manage signal by using TX bytes, I would like to change it to
half of the ring size instead for signaling. Is that OK?
Shirley
^ permalink raw reply
* RE: Bootable Raid-1
From: Leslie Rhorer @ 2011-02-01 21:53 UTC (permalink / raw)
To: naira; +Cc: linux-raid
In-Reply-To: <4D487CA4.2030502@faccat.br>
> -----Original Message-----
> From: Naira Kaieski [mailto:naira@faccat.br]
> Sent: Tuesday, February 01, 2011 3:36 PM
> To: lrhorer@satx.rr.com
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Bootable Raid-1
>
> Hi,
>
> My metadata is 0.90...
>
> My Partitions:
> /dev/sda1 1 122 979933+ fd Linux raid
> autodetect
> /dev/sda2 * 123 134 96390 fd Linux raid
> autodetect
> /dev/sda3 135 19457 155211997+ fd Linux raid
> autodetect
I recall reading very recently (it might have even been today) that
Linux RAID Autodetect partitions can cause problems. I have mine set to
simply "Linux":
Disk /dev/sda: 500 GB, 500105249280 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 50 401593 83 Linux
/dev/sda2 51 40000 320890342 83 Linux
/dev/sda3 40001 60801 167076000 83 Linux
> Disk /dev/md1: 1003 MB, 1003356160 bytes
> 2 heads, 4 sectors/track, 244960 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> Disk /dev/md1 doesn't contain a valid partition table
>
> Disk /dev/md2: 98 MB, 98631680 bytes
> 2 heads, 4 sectors/track, 24080 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> Disk /dev/md2 doesn't contain a valid partition table
>
> Disk /dev/md3: 158.9 GB, 158936989696 bytes
> 2 heads, 4 sectors/track, 38802976 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xc4036374
>
> Disk /dev/md3 doesn't contain a valid partition table
>
>
> I created the array with the command:
> mdadm --create --verbose --assume-clean --metadata=0.90 /dev/md3
> --level=1 --raid-devices=2 /dev/sda3 missing
>
> # cat /proc/mdstat
> Personalities : [raid1]
> md3 : active raid1 sda3[0]
> 155211904 blocks [2/1] [U_]
>
> md2 : active raid1 sda2[0]
> 96320 blocks [2/1] [U_]
>
> md1 : active raid1 sda1[0]
> 979840 blocks [2/1] [U_]
>
> # mdadm -D --scan
> ARRAY /dev/md1 metadata=0.90 UUID=e905069f:43e2eaa4:e090bcab:b1d9c206
> ARRAY /dev/md2 metadata=0.90 UUID=d259ec4f:1c63d0b1:e090bcab:b1d9c206
> ARRAY /dev/md3 metadata=0.90 UUID=030d5ded:82314c21:e090bcab:b1d9c206
>
> On dmesg:
> [ 2349.760155] md: bind<sda1>
> [ 2349.762677] md/raid1:md1: active with 1 out of 2 mirrors
> [ 2349.762720] md1: detected capacity change from 0 to 1003356160
> [ 2349.765307] md1: unknown partition table
> [ 2363.059235] md: bind<sda2>
> [ 2363.061089] md/raid1:md2: active with 1 out of 2 mirrors
> [ 2363.061129] md2: detected capacity change from 0 to 98631680
> [ 2363.065812] md2: unknown partition table
> [ 2372.302358] md: bind<sda3>
> [ 2372.304614] md/raid1:md3: active with 1 out of 2 mirrors
> [ 2372.304663] md3: detected capacity change from 0 to 158936989696
> [ 2372.308395] md3: unknown partition table
>
> My kernel config:
> CONFIG_MD=y
> CONFIG_BLK_DEV_MD=y
> CONFIG_MD_AUTODETECT=y
> CONFIG_MD_RAID1=y
>
> # mdadm --examine /dev/sda3
> /dev/sda3:
> Magic : a92b4efc
> Version : 0.90.00
> UUID : 030d5ded:82314c21:e090bcab:b1d9c206 (local to host dns)
> Creation Time : Tue Feb 1 19:03:30 2011
> Raid Level : raid1
> Used Dev Size : 155211904 (148.02 GiB 158.94 GB)
> Array Size : 155211904 (148.02 GiB 158.94 GB)
> Raid Devices : 2
> Total Devices : 1
> Preferred Minor : 3
>
> Update Time : Tue Feb 1 19:18:56 2011
> State : clean
> Active Devices : 1
> Working Devices : 1
> Failed Devices : 1
> Spare Devices : 0
> Checksum : 64a5bec0 - correct
> Events : 7
>
>
> Number Major Minor RaidDevice State
> this 0 8 3 0 active sync /dev/sda3
>
> 0 0 8 3 0 active sync /dev/sda3
> 1 1 0 0 1 faulty removed
>
> I format the md* devices and copy file with rsync, alter the grub and
> fstab to boot md devices but on boot i have fail to boot md3 as rootfs
>
> Atenciosamente,
> Naira Kaieski
>
>
>
> Em 1/2/2011 18:43, Leslie Rhorer escreveu:
> >> I have read several articles on the internet and researched in the
> >> messages list, but I'm still having trouble configuring a raid level 1
> >> array that is bootable.
> >>
> >> I configured a server some time agowith Gentoo Linux, Kernel
> >> 2.6.28-hardened-r9, mdadm - v3.0 and 2 IDE hard drives, this is working
> >> correctly. For this installation iused as a basis for consultation
> >> Article http://en.gentoo-wiki.com/wiki/Migrate_to_RAID
> >>
> >> Now, I want to use two SATA drives in raid level 1,
> >>
> >> Now i have Gentoo Linux with kernel 2.6.36-hardened-r6 and mdadm -
> >> v3.1.4 and the instructions of Article dont work. The kernel was
> >> configured with support for disks raid autodetect and supported the
> raid
> >> level 1. But in the logs of dmesg does not run the auto-detection of
> the
> >> disks to the array, so in the boot when mounting the root device /
> >> dev/md2 the system can not find the device.
> >>
> >> When I run mdadm - auto-detect the array are found somewhere but still
> >> displays message indicating that the raid device is not a valid
> >> partition table.
> >>
> >> How can you configure a raid level 1 with bootable disks / dev / sda
> and
> >> / dev / sdb?
> >> I want three partitions:
> >> /dev/md1 - swap - /dev/sda1, /dev/sdb1
> >> /dev/md2 - boot - /dev/sda2, /dev/sdb2
> >> /dev/md3 - / - /dev/sda3, /dev/sdb3
> >>
> >> I am using grub as bootloader.
> > This is very similar to my boot configuration on my two servers. I
> > suspect your problem is the metadata. What version of superblock are
> you
> > using for /dev/md2? GRUB2 does not recognize a version 1.x superblock.
> > Since the boot images are quite small, and don't require an array of
> many
> > disks, there is nothing wrong with the 0.90 superblock, however. If
> your
> > /dev/md2 array is not a 0.9 version superblock, try converting it. Here
> is
> > my configuration from one of the servers:
> >
> > ARRAY /dev/md0 level=raid6 num-devices=10 metadata=01.2 name=Backup:0
> > UUID=431244d6:45d9635a:e88b3de5:92f30255
> > ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90
> > UUID=4cde286c:0687556a:4d9996dd:dd23e701
> > ARRAY /dev/md2 level=raid1 num-devices=2 metadata=01.2 name=Backup:2
> > UUID=d45ff663:9e53774c:6fcf9968:21692025
> > ARRAY /dev/md3 level=raid1 num-devices=2 metadata=01.2 name=Backup:3
> > UUID=51d22c47:10f58974:0b27ef04:5609d357
> >
> > Where md0 is a large (11T) data array, md1 is boot, md2 is root, and
> > md3 is swap. The partitioning layout of the boot drives is the same as
> > yours.
> >
^ 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.