* [PATCH 0/2] Regression fixes for rfcomm/tty.c
From: Gianluca Anzolin @ 2014-01-04 16:30 UTC (permalink / raw)
To: gustavo
Cc: peter, marcel, linux-bluetooth, gregkh, jslaby, stable,
Gianluca Anzolin
The following two patches fix a couple of regressions introduced with
the rfcomm tty_port conversion.
The first patch restores the expected behaviour of the rfcomm port when
it's created with the flag RFCOMM_RELEASE_ONHUP.
The second patch fixes a bug that affect userspace (ModemManager) when
the port is created with the flag RFCOMM_REUSE_DLC.
Gianluca Anzolin (2):
rfcomm: release the port when the last user closes the tty
rfcomm: move the device under its parent if already connected
net/bluetooth/rfcomm/tty.c | 68 ++++++++++++++++++++++++++--------------------
1 file changed, 39 insertions(+), 29 deletions(-)
--
1.8.5.2
^ permalink raw reply
* Re: [RFC 2/2] dual scan thread bug fix
From: Alan Stern @ 2014-01-04 16:27 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi, USB list
In-Reply-To: <1388814065.6687.0.camel@dabdike.int.hansenpartnership.com>
On Fri, 3 Jan 2014, James Bottomley wrote:
> > I'm still concerned about one thing. The previous patch does this in
> > scsi_alloc_target():
> >
> > > found:
> > > - found_target->reap_ref++;
> > > + if (!kref_get_unless_zero(&found_target->reap_ref))
> > > + /*
> > > + * release routine already fired. Target is dead, but
> > > + * STARGET_DEL may not yet be set (set in the release
> > > + * routine), so set here as well, just in case
> > > + */
> > > + found_target->state = STARGET_DEL;
> > > spin_unlock_irqrestore(shost->host_lock, flags);
> >
> > As a result, the two comments in this patch aren't right:
> >
> > > @@ -384,9 +385,15 @@ static void scsi_target_reap_ref_release(struct kref *kref)
> > > struct scsi_target *starget
> > > = container_of(kref, struct scsi_target, reap_ref);
> > >
> > > - transport_remove_device(&starget->dev);
> > > - device_del(&starget->dev);
> > > - starget->state = STARGET_DEL;
> > > + /*
> > > + * if we get here and the target is still in the CREATED state that
> > > + * means it was allocated but never made visible (because a scan
> > > + * turned up no LUNs), so don't call device_del() on it.
> > > + */
> > > + if (starget->state == STARGET_RUNNING) {
> > > + transport_remove_device(&starget->dev);
> > > + device_del(&starget->dev);
> > > + }
> >
> > Here the state could already be STARGET_DEL, even though the target is
> > still visible.
>
> Well, I agree with the theory. In practise, there are only a few
> machine instructions between the kref going to zero and us reaching that
> point, because kref_release will jump into this routine next, so the
> condition would be very hard to see.
It's true that the window is very small and not at all likely to be
hit. Still, I prefer eliminating such things entirely.
> However, I suppose it's easy to
> close by checking for != STARGET_CREATED and there's no reason not to do
> that, so I'll change it.
Checking for != STARGET_CREATED is also wrong in principle. The state
could already be STARGET_DEL even though the target was never made
visible.
The basic problem is that you are relying on the state to be an
accurate description of the target's visibility, but
scsi_alloc_target() changes the state without changing the visibility.
I really think you should get rid of that extra assignment in
scsi_alloc_target().
> How does the attached diff look?
Better but still not right.
Alan Stern
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Christoffer Dall @ 2014-01-04 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388816085-21417-1-git-send-email-christoffer.dall@linaro.org>
The stage-2 memory attributes are distinct from the Hyp memory
attributes and the Stage-1 memory attributes. We were using the stage-1
memory attributes for stage-2 mappings causing device mappings to be
mapped as normal memory. Add the S2 equivalent defines for memory
attributes and fix the comments explaining the defines while at it.
Add a prot_pte_s2 field to the mem_type struct and fill out the field
for device mappings accordingly.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
Changelog[v2]:
- Guard the use of L_PTE_S2 defines with s2_policy to allow non-LPAE compiles.
arch/arm/include/asm/pgtable-3level.h | 20 +++++++++++++-------
arch/arm/mm/mm.h | 1 +
arch/arm/mm/mmu.c | 15 ++++++++++++++-
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 4f95039..d5e04d6 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -120,13 +120,19 @@
/*
* 2nd stage PTE definitions for LPAE.
*/
-#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
-#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
-#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
-#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
-#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
-
-#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
+#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
+#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
+#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
+#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
+#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
+#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
+#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
+#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
+
+#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
+#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
+
+#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
/*
* Hyp-mode PL2 PTE definitions for LPAE.
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index d5a982d..7ea641b 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -38,6 +38,7 @@ static inline pmd_t *pmd_off_k(unsigned long virt)
struct mem_type {
pteval_t prot_pte;
+ pteval_t prot_pte_s2;
pmdval_t prot_l1;
pmdval_t prot_sect;
unsigned int domain;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 580ef2d..44d571f 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -231,36 +231,48 @@ __setup("noalign", noalign_setup);
#endif /* ifdef CONFIG_CPU_CP15 / else */
#define PROT_PTE_DEVICE L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN
+#define PROT_PTE_S2_DEVICE PROT_PTE_DEVICE
#define PROT_SECT_DEVICE PMD_TYPE_SECT|PMD_SECT_AP_WRITE
static struct mem_type mem_types[] = {
[MT_DEVICE] = { /* Strongly ordered / ARMv6 shared device */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |
L_PTE_SHARED,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_DEV_SHARED) |
+ L_PTE_SHARED,
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_S,
.domain = DOMAIN_IO,
},
[MT_DEVICE_NONSHARED] = { /* ARMv6 non-shared device */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_NONSHARED,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_DEV_NONSHARED),
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE,
.domain = DOMAIN_IO,
},
[MT_DEVICE_CACHED] = { /* ioremap_cached */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_CACHED,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_DEV_CACHED),
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_WB,
.domain = DOMAIN_IO,
},
[MT_DEVICE_WC] = { /* ioremap_wc */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_WC,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_DEV_WC),
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE,
.domain = DOMAIN_IO,
},
[MT_UNCACHED] = {
.prot_pte = PROT_PTE_DEVICE,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_UNCACHED),
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PMD_TYPE_SECT | PMD_SECT_XN,
.domain = DOMAIN_IO,
@@ -458,7 +470,8 @@ static void __init build_mem_type_table(void)
cp = &cache_policies[cachepolicy];
vecs_pgprot = kern_pgprot = user_pgprot = cp->pte;
s2_pgprot = cp->pte_s2;
- hyp_device_pgprot = s2_device_pgprot = mem_types[MT_DEVICE].prot_pte;
+ hyp_device_pgprot = mem_types[MT_DEVICE].prot_pte;
+ s2_device_pgprot = mem_types[MT_DEVICE].prot_pte_s2;
/*
* ARMv6 and above have extended page tables.
--
1.8.5
^ permalink raw reply related
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Christoffer Dall @ 2014-01-04 16:27 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm; +Cc: kvm, linaro-kernel, patches, Christoffer Dall
In-Reply-To: <1388816085-21417-1-git-send-email-christoffer.dall@linaro.org>
The stage-2 memory attributes are distinct from the Hyp memory
attributes and the Stage-1 memory attributes. We were using the stage-1
memory attributes for stage-2 mappings causing device mappings to be
mapped as normal memory. Add the S2 equivalent defines for memory
attributes and fix the comments explaining the defines while at it.
Add a prot_pte_s2 field to the mem_type struct and fill out the field
for device mappings accordingly.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
Changelog[v2]:
- Guard the use of L_PTE_S2 defines with s2_policy to allow non-LPAE compiles.
arch/arm/include/asm/pgtable-3level.h | 20 +++++++++++++-------
arch/arm/mm/mm.h | 1 +
arch/arm/mm/mmu.c | 15 ++++++++++++++-
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 4f95039..d5e04d6 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -120,13 +120,19 @@
/*
* 2nd stage PTE definitions for LPAE.
*/
-#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
-#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
-#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
-#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
-#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
-
-#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
+#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
+#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
+#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
+#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
+#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
+#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
+#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
+#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
+
+#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
+#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
+
+#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
/*
* Hyp-mode PL2 PTE definitions for LPAE.
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index d5a982d..7ea641b 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -38,6 +38,7 @@ static inline pmd_t *pmd_off_k(unsigned long virt)
struct mem_type {
pteval_t prot_pte;
+ pteval_t prot_pte_s2;
pmdval_t prot_l1;
pmdval_t prot_sect;
unsigned int domain;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 580ef2d..44d571f 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -231,36 +231,48 @@ __setup("noalign", noalign_setup);
#endif /* ifdef CONFIG_CPU_CP15 / else */
#define PROT_PTE_DEVICE L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN
+#define PROT_PTE_S2_DEVICE PROT_PTE_DEVICE
#define PROT_SECT_DEVICE PMD_TYPE_SECT|PMD_SECT_AP_WRITE
static struct mem_type mem_types[] = {
[MT_DEVICE] = { /* Strongly ordered / ARMv6 shared device */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |
L_PTE_SHARED,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_DEV_SHARED) |
+ L_PTE_SHARED,
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_S,
.domain = DOMAIN_IO,
},
[MT_DEVICE_NONSHARED] = { /* ARMv6 non-shared device */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_NONSHARED,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_DEV_NONSHARED),
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE,
.domain = DOMAIN_IO,
},
[MT_DEVICE_CACHED] = { /* ioremap_cached */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_CACHED,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_DEV_CACHED),
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_WB,
.domain = DOMAIN_IO,
},
[MT_DEVICE_WC] = { /* ioremap_wc */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_WC,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_DEV_WC),
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE,
.domain = DOMAIN_IO,
},
[MT_UNCACHED] = {
.prot_pte = PROT_PTE_DEVICE,
+ .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
+ s2_policy(L_PTE_S2_MT_UNCACHED),
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PMD_TYPE_SECT | PMD_SECT_XN,
.domain = DOMAIN_IO,
@@ -458,7 +470,8 @@ static void __init build_mem_type_table(void)
cp = &cache_policies[cachepolicy];
vecs_pgprot = kern_pgprot = user_pgprot = cp->pte;
s2_pgprot = cp->pte_s2;
- hyp_device_pgprot = s2_device_pgprot = mem_types[MT_DEVICE].prot_pte;
+ hyp_device_pgprot = mem_types[MT_DEVICE].prot_pte;
+ s2_device_pgprot = mem_types[MT_DEVICE].prot_pte_s2;
/*
* ARMv6 and above have extended page tables.
--
1.8.5
^ permalink raw reply related
* [Buildroot] [PATCH] manual: use current date/time for 'generated on'
From: Yann E. MORIN @ 2014-01-04 16:25 UTC (permalink / raw)
To: buildroot
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
Currently, the manual uses the last modification date and time of
manual.txt in the generated manual.
This is confusing, especially for long-checked-out repositories where
the top-level manual.txt has not changed since the check out. Moreover,
the manual explicitly states 'generated on', which is confusing at best.
Use the current date and time instead.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Samuel Martin <s.martin49@gmail.com>
---
docs/manual/manual.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/manual/manual.txt b/docs/manual/manual.txt
index 9ae658e..958afae 100644
--- a/docs/manual/manual.txt
+++ b/docs/manual/manual.txt
@@ -8,8 +8,8 @@ The Buildroot user manual
Buildroot usage and documentation by Thomas Petazzoni. Contributions
from Karsten Kruse, Ned Ludd, Martin Herren and others.
-Buildroot {sys:echo $\{BR2_VERSION%%-git*\}} manual generated on {docdate}
-{doctime} from git revision {sys:git rev-parse --short HEAD}
+Buildroot {sys:echo $\{BR2_VERSION%%-git*\}} manual generated on {localdate}
+{localtime} from git revision {sys:git rev-parse --short HEAD}
image::logo.png[]
--
1.8.1.2
^ permalink raw reply related
* Re: Recovering an Array with inconsistent Superblocks
From: Phil Turmel @ 2014-01-04 16:24 UTC (permalink / raw)
To: Fabian Knorr, linux-raid
In-Reply-To: <1388829881.16265.20.camel@vessel>
Good morning Fabian,
We might be able to save you here, but it isn't certain.
On 01/04/2014 05:04 AM, Fabian Knorr wrote:
> Good morning folks,
>
> I have a MD-RAID5 with 8 disks, 7 of them active, 1 spare. They are
> connected to two SATA controllers, 4 disks each.
Side note: If you have a live spare available for a raid5, there's no
good reason not to reshape to a raid6, and very good reasons to do so.
> A few days ago, the disks connected to one of the controllers stopped
> operating (some sort of controller hiccup, I guess). Now those disks are
> marked as "possibly outdated" and the array refuses to assemble or
> start, telling me there are only 4 out of 7 devices operational (See
> attachment "assemble.status")
>
> On boot, "/proc/mdstat" reports an inactive array with 7 spares, trying
> to "mdadm --run" the array fails with the message mentioned above,
> changing "/proc/mdstat" to now show an array of 4 disks.
"mdadm --assemble --force" would have fixed you up if you'd done it
right at this point. That's what "--force" is intended for.
> I tried "--add" with a missing device, getting the message "re-added
> device /dev/sd...", but failing for subsequent devices with the message
> "/dev/md0 failed to start, not adding device ..., You should stop and
> re-assemble the array".
Using "--add" changed those devices' superblocks, losing their original
identity in the array. Which is why ...
> Then I tried "--assemble --scan --force", which yielded the same result
> as above.
... this didn't work.
> The next thing I would try is recreating the array with the layout
> stored in the superblocks, but I was surprised to find it to be
> inconsistent between the disks. I attached the output of "--examine
> --verbose" as "raid.status".
Device names are not guaranteed to remain identical from one boot to
another. And often won't be if a removable device is plugged in at that
time. The linux MD driver keeps identity data in the superblock that
makes the actual device names immaterial.
It is really important that we get a "map" of device names to drive
serial numbers, and adjust all future operations to ensure we are
working with the correct names. An excerpt from "ls -l
/dev/disk/by-id/" would do. And you need to verify it after every boot
until this crisis is resolved.
> Could "--add"ing have changed one superblock, and can I safely try to
> re-create the array with the layout given by /dev/sda and /dev/sdc?
> Also, what parameters would I need to keep the layout (As mentioned in
> the wiki at https://raid.wiki.kernel.org/index.php/RAID_Recovery)
> consistent with the one I have now?
Some additional questions/notes before proceeding:
1) raid.status appears to be from *after* your --add attempts. That
means anything in those reports from those devices is useless. So we
will have to figure out what that data was.
2) You attempted to recreate the array. If you left out
"--assume-clean", your data is toast. Please show the precise command
line you used in your re-create attempt. Also generate a fresh
"raid.status" for the current situation.
3) The array seems to think it's member devices were /dev/sda through
/dev/sdh (not in that order). Your "raid.status" has /dev/sd[abcefghi],
suggesting a rescue usb or some such is /dev/sdd. So device names have
to be re-interpreted between old metadata and recovery attempts.
4) Please describe the structure of the *content* of the array, so we
can suggest strategies to *safely* recognize when our future attempts to
--create --assume-clean have succeeded. LVM? Partitioned? One big
filesystem?
Phil
^ permalink raw reply
* [Buildroot] [RFC PATCH 0/2] gitorious helper
From: Thomas De Schampheleire @ 2014-01-04 16:20 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1387988339-17460-1-git-send-email-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On Wed, Dec 25, 2013 at 5:18 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> The following patches introduce a gitroious helper to download tarballs for
> gitorious. I currently see two shortcomings:
> - the tarball URL is https://gitorious.org/<project>/<repo>/archive/<version>.tar.gz
> so the downloaded tarball doesn't have any name appart from <version>.tar.gz
> - It needs two separate functions for target and host packages.
>
> Alexandre Belloni (2):
> infra: introduce gitorious helper function
> packages: use gitorious helper when applicable
Just a quick note: I'm going to review this (hopefully soon)...
Best regards,
Thomas
^ permalink raw reply
* Re: How to get pid of packet sender from NFQUEUE?
From: Mehran Kholdi @ 2014-01-04 16:17 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <CAKiFbu9h1an38XXeNDy1ivcEz1vZHaqK+ekmQVXZLUChpJ3pBQ@mail.gmail.com>
Anybody having a clue on that?
^ permalink raw reply
* Re: [PATCH 0/6] phylib: cleanups
From: Sergei Shtylyov @ 2014-01-04 17:14 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev
In-Reply-To: <20140104155338.GG4925@netboy>
Hello.
On 01/04/2014 06:53 PM, Richard Cochran wrote:
>> This patchset mainly cleans up the phylib's coding style but then also
>> removes some historically unused stuff.
> Why not put the author of the code onto CC?
Because get_maintainer.pl doesn't suggest it and because Andy Fleming
seems no longer interested in maintaining his code written back in 2004.
> Thanks,
> Richard
WBR, Sergei
^ permalink raw reply
* [PATCH] extensions: libxt_set: Add missing hyphen to --bytes-eq synopsis in manpage
From: Mart Frauenlob @ 2014-01-04 15:57 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 79 bytes --]
Hello,
small fix which adds a missing hyphen in the manpage.
Good day!
Mart
[-- Attachment #2: extensions-libxt_set-Add-missing-hyphen-to-bytes-eq-syno.patch --]
[-- Type: text/plain, Size: 1004 bytes --]
>From fb7aa04245e1c709d5f9c1811780eb90a71f50cc Mon Sep 17 00:00:00 2001
From: Mart Frauenlob <mart.frauenlob@chello.at>
Date: Sat, 4 Jan 2014 16:41:49 +0100
Subject: [PATCH] extensions: libxt_set: Add missing hyphen to --bytes-eq synopsis.
Signed-off-by: Mart Frauenlob <mart.frauenlob@chello.at>
---
extensions/libxt_set.man | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/extensions/libxt_set.man b/extensions/libxt_set.man
index 7012ef2..dbc1586 100644
--- a/extensions/libxt_set.man
+++ b/extensions/libxt_set.man
@@ -43,7 +43,7 @@ packet counter of the element is less than the given value as well.
If the packet is matched an element in the set, match only if the
packet counter of the element is greater than the given value as well.
.TP
-[\fB!\fP] \fB\-bytes\-eq\fP \fIvalue\fP
+[\fB!\fP] \fB\-\-bytes\-eq\fP \fIvalue\fP
If the packet is matched an element in the set, match only if the
byte counter of the element matches the given value too.
.TP
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 0/4] x86: Add Cache QoS Monitoring (CQM) support
From: Tejun Heo @ 2014-01-04 16:10 UTC (permalink / raw)
To: Peter P Waskiewicz Jr
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Li Zefan,
containers, cgroups, linux-kernel
In-Reply-To: <1388781285-18067-1-git-send-email-peter.p.waskiewicz.jr@intel.com>
Hello,
On Fri, Jan 03, 2014 at 12:34:41PM -0800, Peter P Waskiewicz Jr wrote:
> The CPU features themselves are relatively straight-forward, but
> the presentation of the data is less straight-forward. Since this
> tracks cache usage and occupancy per process (by swapping Resource
> Monitor IDs, or RMIDs, when processes are rescheduled), perf would
> not be a good fit for this data, which does not report on a
> per-process level. Therefore, a new cgroup subsystem, cacheqos, has
> been added. This operates very similarly to the cpu and cpuacct
> cgroup subsystems, where tasks can be grouped into sub-leaves of the
> root-level cgroup.
I don't really understand why this is implemented as part of cgroup.
There doesn't seem to be anything which requires cgroup. Wouldn't
just doing it per-process make more sense? Even grouping would be
better done along the traditional process hierarchy, no? And
per-cgroup accounting can be trivially achieved from userland by just
accumulating the stats according to the process's cgroup membership.
What am I missing here?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 0/4] x86: Add Cache QoS Monitoring (CQM) support
From: Tejun Heo @ 2014-01-04 16:10 UTC (permalink / raw)
To: Peter P Waskiewicz Jr
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H. Peter Anvin,
cgroups-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner, Ingo Molnar
In-Reply-To: <1388781285-18067-1-git-send-email-peter.p.waskiewicz.jr-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Hello,
On Fri, Jan 03, 2014 at 12:34:41PM -0800, Peter P Waskiewicz Jr wrote:
> The CPU features themselves are relatively straight-forward, but
> the presentation of the data is less straight-forward. Since this
> tracks cache usage and occupancy per process (by swapping Resource
> Monitor IDs, or RMIDs, when processes are rescheduled), perf would
> not be a good fit for this data, which does not report on a
> per-process level. Therefore, a new cgroup subsystem, cacheqos, has
> been added. This operates very similarly to the cpu and cpuacct
> cgroup subsystems, where tasks can be grouped into sub-leaves of the
> root-level cgroup.
I don't really understand why this is implemented as part of cgroup.
There doesn't seem to be anything which requires cgroup. Wouldn't
just doing it per-process make more sense? Even grouping would be
better done along the traditional process hierarchy, no? And
per-cgroup accounting can be trivially achieved from userland by just
accumulating the stats according to the process's cgroup membership.
What am I missing here?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 0/4] x86: Add Cache QoS Monitoring (CQM) support
From: Tejun Heo @ 2014-01-04 16:10 UTC (permalink / raw)
To: Peter P Waskiewicz Jr
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Li Zefan,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1388781285-18067-1-git-send-email-peter.p.waskiewicz.jr-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Hello,
On Fri, Jan 03, 2014 at 12:34:41PM -0800, Peter P Waskiewicz Jr wrote:
> The CPU features themselves are relatively straight-forward, but
> the presentation of the data is less straight-forward. Since this
> tracks cache usage and occupancy per process (by swapping Resource
> Monitor IDs, or RMIDs, when processes are rescheduled), perf would
> not be a good fit for this data, which does not report on a
> per-process level. Therefore, a new cgroup subsystem, cacheqos, has
> been added. This operates very similarly to the cpu and cpuacct
> cgroup subsystems, where tasks can be grouped into sub-leaves of the
> root-level cgroup.
I don't really understand why this is implemented as part of cgroup.
There doesn't seem to be anything which requires cgroup. Wouldn't
just doing it per-process make more sense? Even grouping would be
better done along the traditional process hierarchy, no? And
per-cgroup accounting can be trivially achieved from userland by just
accumulating the stats according to the process's cgroup membership.
What am I missing here?
Thanks.
--
tejun
^ permalink raw reply
* Re: [RFC PATCH 1/5] sunrpc: don't wait for write before allowing reads from use-gss-proxy file
From: J. Bruce Fields @ 2014-01-04 16:10 UTC (permalink / raw)
To: Simo Sorce; +Cc: Jeff Layton, linux-nfs, neilb
In-Reply-To: <1388849302.26102.66.camel@willson.li.ssimo.org>
On Sat, Jan 04, 2014 at 10:28:22AM -0500, Simo Sorce wrote:
> On Fri, 2014-01-03 at 17:34 -0500, J. Bruce Fields wrote:
> > On Fri, Jan 03, 2014 at 05:06:00PM -0500, Simo Sorce wrote:
> > > I'd like to use sd_notify, but preferred a more conservative approach
> > > for wider distribution portability.
> > >
> > > Patch here waiting for review upstream:
> > > http://fedorapeople.org/cgit/simo/public_git/gss-proxy.git/commit/?h=usermode&id=ddc5eb950bbd2050dc76b4783f3d3383cd89bccf
> >
> > Thanks. If it's not too much verbage, it might be helpful to document
> > the reason for the ordering; something like:
> >
> > /*
> > * We need to tell nfsd gss-proxy is available before it starts,
> > * as nfsd may need to know this the moment it receives the
> > * first init_sec_context call.
> > *
> > * So now it is safe to tell the init system that we're done
> > * starting up and that it can continue with nfsd startup.
> > */
> >
> > ?
>
> Good idea, I changed the comments loosely after your example:
> http://fedorapeople.org/cgit/simo/public_git/gss-proxy.git/commit/?h=usermode&id=393570b45816b690cb16fd1286d0705142ef2d62
I like how you've done it. Thanks!
--b.
^ permalink raw reply
* Re: [PATCH] mkfs: check sizes of important structs at build time
From: Ryusuke Konishi @ 2014-01-04 16:08 UTC (permalink / raw)
To: Hitoshi Mitake
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA, Hitoshi Mitake,
Vyacheslav Dubeyko
In-Reply-To: <1388842171-16105-1-git-send-email-mitake.hitoshi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, 4 Jan 2014 22:29:31 +0900, Hitoshi Mitake wrote:
> Current nilfs_check_ondisk_sizes() checks sizes of important structs
> at run time. The checking should be done at build time. This patch
> adds a new macro, BUILD_BUG_ON(), for this purpose. It is similar to
> static_assert() of C++11. If an argument is true, the macro causes a
> bulid error.
>
> Below is an example of BUILD_BUG_ON(). When the checked conditions are
> true like below:
>
> /* intentional change for testing BUILD_BUG_ON() */
>
> static __attribute__((used)) void nilfs_check_ondisk_sizes(void)
> {
> BUILD_BUG_ON(sizeof(struct nilfs_inode) > NILFS_MIN_BLOCKSIZE);
> ...
>
> build process of mkfs.o causes errors like this:
>
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include -Wall -g -O2 -MT mkfs.o -MD -MP -MF .deps/mkfs.Tpo -c -o mkfs.o mkfs.c
> mkfs.c: In function 'nilfs_check_ondisk_sizes':
> mkfs.c:429:2: error: negative width in bit-field '<anonymous>'
> mkfs.c:430:2: error: negative width in bit-field '<anonymous>'
> mkfs.c:431:2: error: negative width in bit-field '<anonymous>'
> mkfs.c:432:2: error: negative width in bit-field '<anonymous>'
> mkfs.c:433:2: error: negative width in bit-field '<anonymous>'
> mkfs.c:434:2: error: negative width in bit-field '<anonymous>'
> mkfs.c:435:2: error: negative width in bit-field '<anonymous>'
>
> Signed-off-by: Hitoshi Mitake <mitake.hitoshi-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
This is an interesting patch.
I am inclined to apply this since the every test in the
nilfs_check_ondisk_sizes function is static.
If we will add a new check that depends on block size in a future, we
need to add a separate runtime check function as Vyacheslav wrote, but
I think you are doing right thing.
One my question is why you used bit operator. The BUILD_BUG_ON marcro
of kernel is implemented with negative array index.
Is there any reason for this ?
Thanks,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: anatop-regulator: Fix the error handling on probe
From: Fabio Estevam @ 2014-01-04 16:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mark Brown, Shawn Guo, Anson.Huang@freescale.com, linux-kernel,
Fabio Estevam
In-Reply-To: <20140104000213.GA23926@core.coreip.homeip.net>
Hi Dmitry,
On Fri, Jan 3, 2014 at 10:02 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Dec 24, 2013 at 01:03:57PM +0000, Mark Brown wrote:
>> On Mon, Dec 23, 2013 at 12:44:40PM -0200, Fabio Estevam wrote:
>> > From: Fabio Estevam <fabio.estevam@freescale.com>
>> >
>> > Currently when of_get_parent() or syscon_node_to_regmap() fail
>> > 'kfree(sreg->name)' is not called, which is incorrect.
>>
>> Applied both, thanks.
>
> Sorry for being too later, but why are we making copy to begin with? It
> is not like DT data will disappear later on.
Which lines of code are you referring to, please?
Regards,
Fabio Estevam
^ permalink raw reply
* Re: [PATCH 0/6] phylib: cleanups
From: Richard Cochran @ 2014-01-04 15:53 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev
In-Reply-To: <201401040413.06853.sergei.shtylyov@cogentembedded.com>
On Sat, Jan 04, 2014 at 04:13:06AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> This patchset mainly cleans up the phylib's coding style but then also
> removes some historically unused stuff.
Why not put the author of the code onto CC?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 4/6] phy: kill excess code
From: Richard Cochran @ 2014-01-04 15:51 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev
In-Reply-To: <52C83B25.7030505@cogentembedded.com>
On Sat, Jan 04, 2014 at 07:47:33PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 01/04/2014 06:42 PM, Richard Cochran wrote:
>
> >> Both kinds of empty lines are consistently avoided by all other
> >>code I had to read. They don't really improve anything.
>
> >But both your subject line and body talk about lines of code. Just
> >removing blank lines is not the same as removing "excess code."
>
> To me, all source file lines are code. So what you are
> suggesting, splitting the patch?
Yes, exactly that.
If the title reads, "fix whitespace errors" or "remove blank lines",
then I don't need to waste my time looking at it.
But if it reads, "remove excess code", then I want to make sure that
you don't go and delete something important.
Thanks,
Richard
^ permalink raw reply
* Re: [rt2x00-users] [rt2x00usb] sleeping function called from invalid context at kernel/locking/mutex.c:616
From: Stanislaw Gruszka @ 2014-01-04 15:52 UTC (permalink / raw)
To: Peter Wu; +Cc: linux-wireless, users
In-Reply-To: <11195731.87o6OySWVz@al>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
On Thu, Dec 26, 2013 at 01:00:50PM +0100, Peter Wu wrote:
> [30017.470835] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
> [30017.470840] in_atomic(): 0, irqs_disabled(): 0, pid: 432, name: wpa_supplicant
> [30017.470843] 4 locks held by wpa_supplicant/432:
> [30017.470845] #0: (cb_lock){++++++}, at: [<ffffffff8151c3f9>] genl_rcv+0x19/0x40
> [30017.470856] #1: (genl_mutex){+.+.+.}, at: [<ffffffff8151df02>] genl_rcv_msg+0xc2/0xd0
> [30017.470861] #2: (rtnl_mutex){+.+.+.}, at: [<ffffffff814fdc97>] rtnl_lock+0x17/0x20
> [30017.470870] #3: (rcu_read_lock){.+.+..}, at: [<ffffffffa038efd5>] ieee80211_get_key+0x5/0x2f0 [mac80211]
> [30017.470895] CPU: 2 PID: 432 Comm: wpa_supplicant Tainted: G O 3.13.0-rc4-custom-00256-gb7000ad #1
> [30017.470897] Hardware name: CLEVO CO. B7130 /B7130 , BIOS 6.00 08/27/2010
> [30017.470899] 0000000000000000 ffff880037b87870 ffffffff815da1f9 ffff88019630ea00
> [30017.470903] ffff880037b87880 ffffffff81076a7d ffff880037b878f0 ffffffff815dde6c
> [30017.470907] ffff880037b878b0 ffffffff815e2152 ffff880197cc25c0 0000000000000292
> [30017.470911] Call Trace:
> [30017.470917] [<ffffffff815da1f9>] dump_stack+0x4e/0x7a
> [30017.470923] [<ffffffff81076a7d>] __might_sleep+0xed/0x120
> [30017.470928] [<ffffffff815dde6c>] mutex_lock_nested+0x3c/0x400
> [30017.470931] [<ffffffff815e2152>] ? _raw_write_unlock_irqrestore+0x42/0x70
> [30017.470936] [<ffffffff8117a40c>] ? create_object+0x23c/0x2f0
> [30017.470940] [<ffffffffa05d832c>] rt2x00usb_vendor_request_buff+0x3c/0xd0 [rt2x00usb]
> [30017.470972] [<ffffffffa05f61a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb]
> [30017.470983] [<ffffffffa05e1638>] rt2800_get_tkip_seq+0x48/0x80 [rt2800lib]
get_tkip_seq() must be atomic, we can not assure that easily for USB
devices, hence the only possible fix seems to be disable TKIP
HW acceleration for USB devices.
Does the attached patch fix the problem for you?
BTW: I recommend you to switch to CCMP (AES) encryption anyway.
Stanislaw
[-- Attachment #2: rt2x00_disable_tkip_on_usb.patch --]
[-- Type: text/plain, Size: 527 bytes --]
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index 2183e79..87d7938 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -489,6 +489,8 @@ int rt2x00mac_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
crypto.cipher = rt2x00crypto_key_to_cipher(key);
if (crypto.cipher == CIPHER_NONE)
return -EOPNOTSUPP;
+ if (crypto.cipher == CIPHER_TKIP && rt2x00_is_usb(rt2x00dev))
+ return -EOPNOTSUPP;
crypto.cmd = cmd;
^ permalink raw reply related
* Re: [PATCH 4/6] phy: kill excess code
From: Sergei Shtylyov @ 2014-01-04 16:47 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev
In-Reply-To: <20140104154229.GE4925@netboy>
Hello.
On 01/04/2014 06:42 PM, Richard Cochran wrote:
>> Both kinds of empty lines are consistently avoided by all other
>> code I had to read. They don't really improve anything.
> But both your subject line and body talk about lines of code. Just
> removing blank lines is not the same as removing "excess code."
To me, all source file lines are code. So what you are suggesting,
splitting the patch?
> Thanks,
> Richard
WBR, Sergei
^ permalink raw reply
* Re: XFS File System Monitor
From: Stan Hoeppner @ 2014-01-04 15:45 UTC (permalink / raw)
To: Rotem Ben Arye, xfs@oss.sgi.com
In-Reply-To: <CA+apj_iOy2dqyPGunKe91WLCqy71uE1uq2HZQ_v=+QHewCymeA@mail.gmail.com>
On 1/4/2014 2:21 AM, Rotem Ben Arye wrote:
> Hi Stan,
> Thank you for focused answer ,only to realize , i'm aware that monitor snmp
> checks On /var/log/messages
> Of Production server in power failure ,so that after that will tell us -
> "power outage causes to a file system corruption" is useless.
>
> But for all those cases that you mention " bugs in the XFS code or
> elsewhere in the Linux kernel , transient or permanent hardware failures"
> Is there no some suitable log that we can track to get an indication of
> kind event that you specified .
Errors due to such problems are logged in dmesg. Hardware problems will
usually show up as IO errors generated from the device on which XFS
resides. When these occur XFS will typically initiate automatic
shutdown of the filesystem to prevent (further) corruption. In this
case the log entry occurs simultaneously with the shutdown, so
monitoring logs won't notify you in advance of this problem. Monitoring
your hardware may.
If you get corruption due to a software bug, you may not see an error in
the log until after the filesystem suffers the corruption event.
Usually when you see errors of this nature in the log it is because
corruption has already occurred, possibly long ago, but is just now
being detected by code specifically added to XFS to detect such things.
For example, say your filesystem is 3 years old, corruption occurred in
year one, and an update to XFS 2 years later looks for such corruption
whereas before it did not. Depending on the severity of the corruption,
xfs_repair may be able to fix it, or it may not. If not you ask for
help here.
So again, I'm not away of any proactive monitoring that would help in
these situations. Of course it would be nice to know if something is
going to fail beforehand, but this isn't always possible, unfortunately.
--
Stan
> Thank you.
>
>
>
> On Thu, Jan 2, 2014 at 5:07 PM, Stan Hoeppner <stan@hardwarefreak.com>wrote:
>
>> On 1/2/2014 6:16 AM, Rotem Ben Arye wrote:
>>> Hi, SGI Support Team.
>>> My Name is Rotem , I am a Linux/Unix System Administrator in web company
>> at
>>> Israel.
>>> I have a question I want to appeal to you to get some advice.
>>>
>>> In the last weekend we had crisis in one of the Production server in
>>> the comany ,the problem was defined by the Integrators as "xfs file
>> system
>>> corrupted"
>>> My question is , what are the open source tools , that we can use on
>>> runtime at production environment , to monitor and sample to get
>> indication
>>> on mount XFS ,
>>> That something is not living well, and can lead to problem.
>>>
>>> We are working in a Linux environment on CentOS distributions server.
>>
>> So in a nutshell you're looking for a monitor application that will in
>> essence give you a green, yellow, or red light informing you of the
>> filesystem's health. Or some kind of SNMP logging that suggests a
>> corruption is imminent.
>>
>> There is no such tool, and never will be. Nearly all XFS corruption
>> events are caused by either software bugs in the XFS code or elsewhere
>> in the Linux kernel, transient or permanent hardware failures, or power
>> failures, at some layer in the storage stack. It is not feasible to
>> predict such events.
>>
>> When an XFS corruption occurs, one should report all related log
>> information and errors to this list so that the problem may be analyzed
>> and the root cause identified. Then the proper corrective action can be
>> identified and implemented to fix the problem and hopefully prevent it
>> from reoccurring.
>>
>> --
>> Stan
>>
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [meta-fsl-arm] i.MX6 audio performance
From: Eric Nelson @ 2014-01-04 15:43 UTC (permalink / raw)
To: Gary Thomas, Fabio Estevam; +Cc: meta-freescale@yoctoproject.org
In-Reply-To: <52C7260A.2040209@mlbassoc.com>
Hi Gary,
On 01/03/2014 02:05 PM, Gary Thomas wrote:
> On 2014-01-03 12:24, Eric Nelson wrote:
>> Hi Gary,
>>
>> On 01/03/2014 10:15 AM, Gary Thomas wrote:
>>> On 2014-01-03 10:06, Eric Nelson wrote:
>>>> Hi Gary,
>>>>
>>>> <snip>
>>>>
>>>>> I also noticed that on the SabreLite, mplayer is using an additional
>>>>> library
>>>>> libXxf86dga.so.1
>>>>> and that it was built using hard floating point (the OMAP3 is soft).
>>>>>
>>>>> Any ideas?
>>>>>
>>>> Are you forcing ALSA output using '-ao alsa'? I've seen some issues
>>>> with
>>>> OSS emulation and I'm not sure of the default.
>>>>
>>>> Please advise,
>>>
>>> No, I'm using it straight
>>> # mplayer FILE.mp3
>>> Same on both platforms
>>>
>>
>> Do you see an output line indicating the AO used?
>>
>> It should show something like this:
>> AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
>>
>> Can you try using '-ao alsa'?
>
> Same results. Here's everything printed by mplayer:
>
> root@sabrelite:~# mplayer test.mp3 -ao alsa
> MPlayer2 2.0-379-ge3f5043 (C) 2000-2011 MPlayer Team
> 162 audio & 361 video codecs
>
> Playing test.mp3.
> Detected file format: MPEG audio layer 2/3 (libavformat)
> [mp3 @ 0x2bb83690]max_analyze_duration reached
> [lavf] stream 0: audio (mp3), -aid 0
> Clip info:
> title: Wedding Bells
> artist: Gas House Gang
> album: Face The Music
> TYER: 0
> genre: Vocal
> track: 2
> Load subtitles in .
> ==========================================================================
> Forced audio codec: mad
> Requested audio codec family [mad] (afm=libmad) not available.
> Enable it at compilation.
> Requested audio codec family [mpg123] (afm=mpg123) not available.
> Enable it at compilation.
> Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
> AUDIO: 44100 Hz, 2 ch, floatle, 128.0 kbit/4.54% (ratio: 16002->352800)
> Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
> ==========================================================================
This is likely the culprit. I don't think that floatle is a valid audio
format for either the SGTL5000 or HDMI devices:
> AO: [alsa] 44100Hz 2ch floatle (4 bytes per sample)
> Video: no video
> Starting playback...
>
> To see if this is user code or kernel driver, I tried running my OMAP3
> file system on the SabreLite (the OMAP3/Cortex-A8 is pretty much a subset
> of the CPU). Same results - broken sound when using mplayer :-(
>
Regards,
Eric
^ permalink raw reply
* Re: [PATCH 4/6] phy: kill excess code
From: Richard Cochran @ 2014-01-04 15:42 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev
In-Reply-To: <52C836EF.1010705@cogentembedded.com>
On Sat, Jan 04, 2014 at 07:29:35PM +0300, Sergei Shtylyov wrote:
>
> Both kinds of empty lines are consistently avoided by all other
> code I had to read. They don't really improve anything.
But both your subject line and body talk about lines of code. Just
removing blank lines is not the same as removing "excess code."
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 0/6] phylib: cleanups
From: Sergei Shtylyov @ 2014-01-04 16:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <201401040413.06853.sergei.shtylyov@cogentembedded.com>
Hello.
On 01/04/2014 04:13 AM, Sergei Shtylyov wrote:
> This patchset mainly cleans up the phylib's coding style but then also
> removes some historically unused stuff.
> [1/6] phy: coding style fixes
> [2/6] mdio_bus: coding style fixes
<linux/phy.h> also causes checkpatch.pl errors/warnings/checks but I just
forgot about it. I feel the series should be extended now...
> [3/6] phy: kill useless local variables
> [4/6] phy: kill excess code
> [5/6] phylib: remove unused adjust_state callback
> [6/6] phylib: make phy_scan_fixups() static
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] mkfs: check sizes of important structs at build time
From: Vyacheslav Dubeyko @ 2014-01-04 15:39 UTC (permalink / raw)
To: Hitoshi Mitake; +Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA, Hitoshi Mitake
In-Reply-To: <CAE1WaKLr1EuovgHgXQa1o9LQVk1fRkUXbDrGiKfsdTB347ieqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Jan 4, 2014, at 4:54 PM, Hitoshi Mitake wrote:
> On Sat, Jan 4, 2014 at 11:52 PM, Vyacheslav Dubeyko <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org> wrote:
>>
>> On Jan 4, 2014, at 4:29 PM, Hitoshi Mitake wrote:
>>
>>> Current nilfs_check_ondisk_sizes() checks sizes of important structs
>>> at run time. The checking should be done at build time. This patch
>>> adds a new macro, BUILD_BUG_ON(), for this purpose. It is similar to
>>> static_assert() of C++11. If an argument is true, the macro causes a
>>> bulid error.
>>>
>>> Below is an example of BUILD_BUG_ON(). When the checked conditions are
>>> true like below:
>>>
>>> /* intentional change for testing BUILD_BUG_ON() */
>>>
>>> static __attribute__((used)) void nilfs_check_ondisk_sizes(void)
>>> {
>>> BUILD_BUG_ON(sizeof(struct nilfs_inode) > NILFS_MIN_BLOCKSIZE);
>>
>> So, why do we need to have function for the case of checking on compilation
>> phase?
>
> Just for excluding the checking from other part of code and improve readability.
>
I think that we can have only macro instead of the function nilfs_check_ondisk_sizes().
And this macros can be placed in the begin of main() call. I think that it will be enough
for the compilation phase check.
>>
>> I suppose that we need to have some run-time check anyway. Your approach
>> is correct for the current state of the code. But I feel a necessity in run-time check
>> anyway. Maybe it looks like a paranoia. :) Maybe it needs to extend checking
>> in this place.
>
> Do you mean both of the build time check and the run time check? If
> so, I agree with your opinion. I'll send v2 based on this policy.
>
I mean that block size can be different during volume creation and maybe
it makes sense to extend a block size related checking for run-time phase.
That's all. But right now I haven't any concrete suggestions.
Thanks,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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.