* [PATCH 2.6.39] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
From: Mauro Carvalho Chehab @ 2011-04-11 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201104110048.08764.jkrzyszt@tis.icnet.pl>
Em 10-04-2011 19:47, Janusz Krzysztofik escreveu:
> After switching from mem->dma_handle to virt_to_phys(mem->vaddr) used
> for obtaining page frame number passed to remap_pfn_range()
> (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig
> stopped working on my ARM based board. The ARM architecture maintainer,
> Russell King, confirmed that using something like
> virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be
> broken on other architectures as well. The author of the change, Jiri
> Slaby, also confirmed that his code may not work on all architectures.
>
> The patch takes two different countermeasures against this regression:
>
> 1. On architectures which provide dma_mmap_coherent() function (ARM for
> now), use it instead of just remap_pfn_range(). The code is stollen
> from sound/core/pcm_native.c:snd_pcm_default_mmap().
> Set vma->vm_pgoff to 0 before calling dma_mmap_coherent(), or it
> fails.
>
> 2. On other architectures, use virt_to_phys(bus_to_virt(mem->dma_handle))
> instead of problematic virt_to_phys(mem->vaddr). This should work
> even if those translations would occure inaccurate for DMA addresses,
> since possible errors introduced by both calculations, performed in
> opposite directions, should compensate.
>
> Both solutions tested on ARM OMAP1 based Amstrad Delta board.
>
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> ---
> drivers/media/video/videobuf-dma-contig.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> --- linux-2.6.39-rc2/drivers/media/video/videobuf-dma-contig.c.orig 2011-04-09 00:38:45.000000000 +0200
> +++ linux-2.6.39-rc2/drivers/media/video/videobuf-dma-contig.c 2011-04-10 15:00:23.000000000 +0200
> @@ -295,13 +295,26 @@ static int __videobuf_mmap_mapper(struct
>
> /* Try to remap memory */
>
> +#ifndef ARCH_HAS_DMA_MMAP_COHERENT
> +/* This should be defined / handled globally! */
> +#ifdef CONFIG_ARM
> +#define ARCH_HAS_DMA_MMAP_COHERENT
> +#endif
> +#endif
> +
> +#ifdef ARCH_HAS_DMA_MMAP_COHERENT
Hmm... IMHO, this seems too confusing. Why not use just something like:
#if defined(CONFIG_ARM) || defined(ARCH_HAS_DMA_MMAP_COHERENT)
Better yet: why should CONFIG_ARM should explicitly be checked here? Is it the
only architecture where this would fail?dma_mmap_coherent
Hmm...
$ git grep ARCH_HAS_DMA_MMAP_COHERENT arch
arch/powerpc/include/asm/dma-mapping.h:#define ARCH_HAS_DMA_MMAP_COHERENT
The code is saying that dma_mmap_coherent should be used only on ARM and PPC architectures,
and remap_pfn_range should be used otherwise. Are you sure that this will work on the
other architectures? I really prefer to have one standard way for doing it, that
would be architecture-independent. Media drivers or core should not have arch-dependent
code inside.
> + vma->vm_pgoff = 0;
> + retval = dma_mmap_coherent(q->dev, vma, mem->vaddr, mem->dma_handle,
> + mem->size);
> +#else
> size = vma->vm_end - vma->vm_start;
> size = (size < mem->size) ? size : mem->size;
>
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> retval = remap_pfn_range(vma, vma->vm_start,
> - PFN_DOWN(virt_to_phys(mem->vaddr)),
> - size, vma->vm_page_prot);
> + PFN_DOWN(virt_to_phys(bus_to_virt(mem->dma_handle))),
> + size, vma->vm_page_prot);
> +#endif
> if (retval) {
> dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
> dma_free_coherent(q->dev, mem->size,
^ permalink raw reply
* Re: hibernate/resume regression
From: CAI Qian @ 2011-04-11 0:29 UTC (permalink / raw)
To: linux-kernel; +Cc: yinghai, stefano.stabellini, hpa
In-Reply-To: <638226361.789131.1302158410535.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
OK, reverted the following patch fixed the problem.
CAI Qian
commit e5f15b45ddf3afa2bbbb10c7ea34fb32b6de0a0e
Author: Yinghai Lu <yinghai@kernel.org>
Date: Fri Feb 18 11:30:30 2011 +0000
x86: Cleanup highmap after brk is concluded
Now cleanup_highmap actually is in two steps: one is early in head64.c
and only clears above _end; a second one is in init_memory_mapping() and
tries to clean from _brk_end to _end.
It should check if those boundaries are PMD_SIZE aligned but currently
does not.
Also init_memory_mapping() is called several times for numa or memory
hotplug, so we really should not handle initial kernel mappings there.
This patch moves cleanup_highmap() down after _brk_end is settled so
we can do everything in one step.
Also we honor max_pfn_mapped in the implementation of cleanup_highmap.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 2d2673c..5655c22 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -77,9 +77,6 @@ void __init x86_64_start_kernel(char * real_mode_data)
/* Make NULL pointers segfault */
zap_identity_mappings();
- /* Cleanup the over mapped high alias */
- cleanup_highmap();
-
max_pfn_mapped = KERNEL_IMAGE_SIZE >> PAGE_SHIFT;
for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index b176f2b..4a52a5f 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -294,30 +294,11 @@ static void __init init_gbpages(void)
else
direct_gbpages = 0;
}
-
-static void __init cleanup_highmap_brk_end(void)
-{
- pud_t *pud;
- pmd_t *pmd;
-
- mmu_cr4_features = read_cr4();
-
- /*
- * _brk_end cannot change anymore, but it and _end may be
- * located on different 2M pages. cleanup_highmap(), however,
- * can only consider _end when it runs, so destroy any
- * mappings beyond _brk_end here.
- */
- pud = pud_offset(pgd_offset_k(_brk_end), _brk_end);
- pmd = pmd_offset(pud, _brk_end - 1);
- while (++pmd <= pmd_offset(pud, (unsigned long)_end - 1))
- pmd_clear(pmd);
-}
#else
static inline void init_gbpages(void)
{
}
-static inline void cleanup_highmap_brk_end(void)
+static void __init cleanup_highmap(void)
{
}
#endif
@@ -330,8 +311,6 @@ static void __init reserve_brk(void)
/* Mark brk area as locked down and no longer taking any
new allocations */
_brk_start = 0;
-
- cleanup_highmap_brk_end();
}
#ifdef CONFIG_BLK_DEV_INITRD
@@ -950,6 +929,8 @@ void __init setup_arch(char **cmdline_p)
*/
reserve_brk();
+ cleanup_highmap();
+
memblock.current_limit = get_max_mapped();
memblock_x86_fill();
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index a08a62c..7026505 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -51,6 +51,7 @@
#include <asm/numa.h>
#include <asm/cacheflush.h>
#include <asm/init.h>
+#include <asm/setup.h>
static int __init parse_direct_gbpages_off(char *arg)
{
@@ -293,18 +294,18 @@ void __init init_extra_mapping_uc(unsigned long phys, unsigned long size)
* to the compile time generated pmds. This results in invalid pmds up
* to the point where we hit the physaddr 0 mapping.
*
- * We limit the mappings to the region from _text to _end. _end is
- * rounded up to the 2MB boundary. This catches the invalid pmds as
+ * We limit the mappings to the region from _text to _brk_end. _brk_end
+ * is rounded up to the 2MB boundary. This catches the invalid pmds as
* well, as they are located before _text:
*/
void __init cleanup_highmap(void)
{
unsigned long vaddr = __START_KERNEL_map;
- unsigned long end = roundup((unsigned long)_end, PMD_SIZE) - 1;
+ unsigned long vaddr_end = __START_KERNEL_map + (max_pfn_mapped << PAGE_SHIFT);
+ unsigned long end = roundup((unsigned long)_brk_end, PMD_SIZE) - 1;
pmd_t *pmd = level2_kernel_pgt;
- pmd_t *last_pmd = pmd + PTRS_PER_PMD;
- for (; pmd < last_pmd; pmd++, vaddr += PMD_SIZE) {
+ for (; vaddr + PMD_SIZE - 1 < vaddr_end; pmd++, vaddr += PMD_SIZE) {
if (pmd_none(*pmd))
continue;
if (vaddr < (unsigned long) _text || vaddr > end)
----- Original Message -----
> The latest Linus tree had a regression that prevent hibernate/resume
> from working.
>
> It is now failing to resume every time tried after hibernate.
>
> PM: Starting manual resume from disk
> Freezing user space processes ...
> EXT4-fs (dm-0): INFO: recovery required on readonly filesystem
> EXT4-fs (dm-0): write access will be enabled during recovery
> EXT4-fs (dm-0): recovery complete
> EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
> (null)
> (elapsed 0.18 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> PM: Loading and decompressing image data (301765 pages) ... done
> PM: Read 1207060 kbytes in 6.47 seconds (186.56 MB/s)
> serial 00:08: disabled
>
> I have not had a chance to track down the offensive patch(es) yet.
>
> CAI Qian
^ permalink raw reply related
* Re: [PATCH] nfsd4: set right access bmap when initializing lock stateid
From: Mi Jinlong @ 2011-04-11 0:28 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: NFS
In-Reply-To: <20110410162056.GB26233@fieldses.org>
J. Bruce Fields:
> On Tue, Mar 29, 2011 at 11:41:39AM +0800, Mi Jinlong wrote:
>>
>> J. Bruce Fields:
>>> On Mon, Mar 28, 2011 at 03:15:09PM +0800, Mi Jinlong wrote:
>>>>
>>>> Content-Type: text/plain; charset=ISO-2022-JP
>>>> Content-Transfer-Encoding: 7bit
>>> Thanks, Mi Jinlong, the analysis is helpful, but I don't think your fix
>>> is right.
>>>
>>> I think the problem here is basically that the cleanup on exit from
>>> nfsd4_lock() may have to deal with a lock stateid that is partially
>>> initialized, in that everything has been setup except the stuff that's
>>> done by get_lock_access().
>> You are right.
>>
>>> Maybe something like this?? But I'm not able to test right now.
>>>
>>> --b.
>>>
>>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>>> index fbde6f7..9e8ef31 100644
>>> --- a/fs/nfsd/nfs4state.c
>>> +++ b/fs/nfsd/nfs4state.c
>>> @@ -397,10 +397,13 @@ static void unhash_generic_stateid(struct nfs4_stateid *stp)
>>>
>>> static void free_generic_stateid(struct nfs4_stateid *stp)
>>> {
>>> - int oflag = nfs4_access_bmap_to_omode(stp);
>>> + int oflag;
>>>
>>> - nfs4_file_put_access(stp->st_file, oflag);
>>> - put_nfs4_file(stp->st_file);
>>> + if (stp->st_access_bmap) {
>>> + nfs4_access_bmap_to_omode(stp);
>> This line should be
>>
>> oflag = nfs4_access_bmap_to_omode(stp);
>>
>> otherwise, uninitialized oflag will be used at the next line.
>>
>> After this patch, kernel runs correctly!
>
> So you tested something like this?--b.
Yes, I have test this patch again, that's OK.
--
----
thanks
Mi Jinlong
>
> commit f93a86b66b1778ce698051b4ebfc228abccce956
> Author: J. Bruce Fields <bfields@redhat.com>
> Date: Mon Mar 28 15:15:09 2011 +0800
>
> nfsd4: fix oops on lock failure
>
> Lock stateid's can have access_bmap 0 if they were only partially
> initialized (due to a failed lock request); handle that case in
> free_generic_stateid.
>
> ------------[ cut here ]------------
> kernel BUG at fs/nfsd/nfs4state.c:380!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/kernel/mm/ksm/run
> Modules linked in: nfs fscache md4 nls_utf8 cifs ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc nfsd lockd nfs_acl auth_rpcgss sunrpc ipv6 ppdev parport_pc parport pcnet32 mii pcspkr microcode i2c_piix4 BusLogic floppy [last unloaded: mperf]
>
> Pid: 1468, comm: nfsd Not tainted 2.6.38+ #120 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
> EIP: 0060:[<e24f180d>] EFLAGS: 00010297 CPU: 0
> EIP is at nfs4_access_to_omode+0x1c/0x29 [nfsd]
> EAX: ffffffff EBX: dd758120 ECX: 00000000 EDX: 00000004
> ESI: dd758120 EDI: ddfe657c EBP: dd54dde0 ESP: dd54dde0
> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> Process nfsd (pid: 1468, ti=dd54c000 task=ddc92580 task.ti=dd54c000)
> Stack:
> dd54ddf0 e24f19ca 00000000 ddfe6560 dd54de08 e24f1a5d dd758130 deee3a20
> ddfe6560 31270000 dd54df1c e24f52fd 0000000f dd758090 e2505dd0 0be304cf
> dbb51d68 0000000e ddfe657c ddcd8020 dd758130 dd758128 dd7580d8 dd54de68
> Call Trace:
> [<e24f19ca>] free_generic_stateid+0x1c/0x3e [nfsd]
> [<e24f1a5d>] release_lockowner+0x71/0x8a [nfsd]
> [<e24f52fd>] nfsd4_lock+0x617/0x66c [nfsd]
> [<e24e57b6>] ? nfsd_setuser+0x199/0x1bb [nfsd]
> [<e24e056c>] ? nfsd_setuser_and_check_port+0x65/0x81 [nfsd]
> [<c07a0052>] ? _cond_resched+0x8/0x1c
> [<c04ca61f>] ? slab_pre_alloc_hook.clone.33+0x23/0x27
> [<c04cac01>] ? kmem_cache_alloc+0x1a/0xd2
> [<c04835a0>] ? __call_rcu+0xd7/0xdd
> [<e24e0dfb>] ? fh_verify+0x401/0x452 [nfsd]
> [<e24f0b61>] ? nfsd4_encode_operation+0x52/0x117 [nfsd]
> [<e24ea0d7>] ? nfsd4_putfh+0x33/0x3b [nfsd]
> [<e24f4ce6>] ? nfsd4_delegreturn+0xd4/0xd4 [nfsd]
> [<e24ea2c9>] nfsd4_proc_compound+0x1ea/0x33e [nfsd]
> [<e24de6ee>] nfsd_dispatch+0xd1/0x1a5 [nfsd]
> [<e1d6e1c7>] svc_process_common+0x282/0x46f [sunrpc]
> [<e1d6e578>] svc_process+0xdc/0xfa [sunrpc]
> [<e24de0fa>] nfsd+0xd6/0x115 [nfsd]
> [<e24de024>] ? nfsd_shutdown+0x24/0x24 [nfsd]
> [<c0454322>] kthread+0x62/0x67
> [<c04542c0>] ? kthread_worker_fn+0x114/0x114
> [<c07a6ebe>] kernel_thread_helper+0x6/0x10
> Code: eb 05 b8 00 00 27 4f 8d 65 f4 5b 5e 5f 5d c3 83 e0 03 55 83 f8 02 89 e5 74 17 83 f8 03 74 05 48 75 09 eb 09 b8 02 00 00 00 eb 0b <0f> 0b 31 c0 eb 05 b8 01 00 00 00 5d c3 55 89 e5 57 56 89 d6 8d
> EIP: [<e24f180d>] nfs4_access_to_omode+0x1c/0x29 [nfsd] SS:ESP 0068:dd54dde0
> ---[ end trace 2b0bf6c6557cb284 ]---
>
> The trace route is:
>
> -> nfsd4_lock()
> -> if (lock->lk_is_new) {
> -> alloc_init_lock_stateid()
>
> 3739: stp->st_access_bmap = 0;
>
> ->if (status && lock->lk_is_new && lock_sop)
> -> release_lockowner()
> -> free_generic_stateid()
> -> nfs4_access_bmap_to_omode()
> -> nfs4_access_to_omode()
>
> 380: BUG(); *****
>
> This problem was introduced by 0997b173609b9229ece28941c118a2a9b278796e.
>
> Reported-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
> Tested-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index fbde6f7..8e3c407 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -397,10 +397,13 @@ static void unhash_generic_stateid(struct nfs4_stateid *stp)
>
> static void free_generic_stateid(struct nfs4_stateid *stp)
> {
> - int oflag = nfs4_access_bmap_to_omode(stp);
> + int oflag;
>
> - nfs4_file_put_access(stp->st_file, oflag);
> - put_nfs4_file(stp->st_file);
> + if (stp->st_access_bmap) {
> + oflag = nfs4_access_bmap_to_omode(stp);
> + nfs4_file_put_access(stp->st_file, oflag);
> + put_nfs4_file(stp->st_file);
> + }
> kmem_cache_free(stateid_slab, stp);
> }
>
>
^ permalink raw reply
* Re: HVR-1600 (model 74351 rev F1F5) analog Red Screen
From: Andy Walls @ 2011-04-11 0:25 UTC (permalink / raw)
To: Eric B Munson; +Cc: Mauro Carvalho Chehab, mchehab, linux-media
In-Reply-To: <BANLkTimQkDHmDsqSsQ9jiYnHWXnc7umeWw@mail.gmail.com>
On Wed, 2011-04-06 at 13:28 -0400, Eric B Munson wrote:
> On Tue, Apr 5, 2011 at 10:58 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> > On Mon, 2011-04-04 at 14:36 -0400, Eric B Munson wrote:
> >> On Mon, Apr 4, 2011 at 11:16 AM, Eric B Munson <emunson@mgebm.net> wrote:
> >> > On Mon, Apr 4, 2011 at 9:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> >> >> On Mon, 2011-04-04 at 08:20 -0400, Eric B Munson wrote:
> >> >>> I the above mentioned capture card and the digital side of the card
> >> >>> works well. However, when I try to get video from the analog side of
> >> >>> the card, all I get is a red screen and no sound regardless of channel
> >> >>> requested. This is a problem I see in 2.6.39-rc1 though I typically
> >> >>> run the ubuntu 10.10 kernel with the newest drivers built from source.
> >> >>> Is there something in setup or configuration that I may be missing?
> >> >>
> >> >> Eric,
> >> >>
> >> >> You are likely missing the last 3 fixes here:
> >> >>
> >> >> http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/cx18_39
> >> >>
> >> >> (one of which is critical for analog to work).
> >> >>
> >> >> Also check the ivtv-users and ivtv-devel list for past discussions on
> >> >> the "red screen" showing up for known well supported models and what to
> >> >> try.
> >> >>
> >> > Thanks, I will try hand applying these.
> >> >
> >>
> >> I don't have a red screen anymore, now all get from analog static and
> >> mythtv's digital channel scanner now seems broken.
> >
> > Hmmm.
> >
> > 1. Please provide the output of dmesg when the cx18 driver loads.
>
> [ 2.882590] cx18: Start initialization, version 1.4.1
> [ 2.882623] cx18-0: Initializing card 0
> [ 2.882626] cx18-0: Autodetected Hauppauge card
> [ 2.882666] cx18 0000:04:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [ 2.920427] cx18-0: cx23418 revision 01010000 (B)
> [ 3.202139] tveeprom 0-0050: Hauppauge model 74351, rev F1F5
> [ 3.202146] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54)
> [ 3.202149] tveeprom 0-0050: TV standards PAL(B/G) NTSC(M) PAL(I)
> SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
> [ 3.202152] tveeprom 0-0050: audio processor is CX23418 (idx 38)
> [ 3.202154] tveeprom 0-0050: decoder processor is CX23418 (idx 31)
> [ 3.202157] tveeprom 0-0050: has no radio
> [ 3.202159] cx18-0: Autodetected Hauppauge HVR-1600
> [ 3.349248] cx18-0: Simultaneous Digital and Analog TV capture supported
> [ 3.709066] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
(Richard Nixon-esque gap in the tape recording...)
> [ 20.825012] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB)
> [ 20.825015] DVB: registering new adapter (cx18)
> [ 21.156176] cx18-0: DVB Frontend registered
> [ 21.156180] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
> [ 21.156216] cx18-0: Registered device video32 for encoder YUV (20 x
> 101.25 kB)
> [ 21.156272] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
> [ 21.156308] cx18-0: Registered device video24 for encoder PCM audio
> (256 x 4.00 kB)
> [ 21.156311] cx18-0: Initialized card: Hauppauge HVR-1600
> [ 21.156363] cx18: End initialization
> [ 21.161137] cx18-alsa: module loading...
> [ 21.278026] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
> [ 21.403872] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
> (141200 bytes)
> [ 21.410240] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> [ 22.247372] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> [ 22.267064] cx18-0 843: verified load of v4l-cx23418-dig.fw
> firmware (16382 bytes)
It appears you grep-ped for cx18. That dropped all the messagea about
the tuner chips which I'd like to see.
If you are unsure of what boot-up dmesg crud to snip and what to keep
pass along, you can do this:
kill the mythbackend
unload the cx18 module
reload the cx18 module.
At the end of the dmesg output will be messages relating only to the
init of the card and all it's tuner chips.
> >
> > 2. Please provide the output of v4l2-ctl -d /dev/video0 --log status
> > when tuned to an analog channel.
>
> Status Log:
>
> [ 289.758052] cx18-0: ================= START STATUS CARD #0
> =================
> [ 289.758059] cx18-0: Version: 1.4.1 Card: Hauppauge HVR-1600
> [ 289.801911] tveeprom 0-0050: Hauppauge model 74351, rev F1F5,
> serial# XXXXXXX
> [ 289.801917] tveeprom 0-0050: MAC address is XX:XX:XX:XX:XX:XX
> [ 289.801922] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54)
> [ 289.801928] tveeprom 0-0050: TV standards PAL(B/G) NTSC(M)
> PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
> [ 289.801934] tveeprom 0-0050: audio processor is CX23418 (idx 38)
> [ 289.801938] tveeprom 0-0050: decoder processor is CX23418 (idx 31)
> [ 289.801942] tveeprom 0-0050: has no radio
> [ 289.801950] cx18-0 843: Video signal: not present
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well there's your problem. ;)
> [ 289.801953] cx18-0 843: Detected format: NTSC-M
> [ 289.801957] cx18-0 843: Specified standard: NTSC-M
> [ 289.801960] cx18-0 843: Specified video input: Composite 7
> [ 289.801964] cx18-0 843: Specified audioclock freq: 32000 Hz
> [ 289.801975] cx18-0 843: Detected audio mode: mono
> [ 289.801979] cx18-0 843: Detected audio standard: BTSC
> [ 289.801982] cx18-0 843: Audio muted: yes
> [ 289.801985] cx18-0 843: Audio microcontroller: running
> [ 289.801989] cx18-0 843: Configured audio standard: automatic detection
> [ 289.801992] cx18-0 843: Configured audio system: BTSC
> [ 289.801996] cx18-0 843: Specified audio input: Tuner (In8)
> [ 289.801999] cx18-0 843: Preferred audio mode: stereo
> [ 289.802021] cx18-0 gpio-reset-ctrl: GPIO: direction 0x00003801,
> value 0x00003801
> [ 289.804291] cs5345 0-004c: Input: 1
> [ 289.804293] cs5345 0-004c: Volume: 0 dB
For older boards, somewhere before this point, the analog tuner driver
should have logged what frequency it is tuned to. (I need to check if
this happens for my newer HVR-1600 board.)
This gives me the feeling that something didn't init correctly with the
analog tuner.
> [ 289.804295] cx18-0: Video Input: Tuner 1
> [ 289.804297] cx18-0: Audio Input: Tuner 1
> [ 289.804299] cx18-0: GPIO: direction 0x00003801, value 0x00003801
> [ 289.804301] cx18-0: Tuner: TV
> [ 289.804303] cx18-0: Stream Type: MPEG-2 Program Stream (grabbed)
> [ 289.804306] cx18-0: Stream VBI Format: Private packet, IVTV
> format (grabbed)
> [ 289.804310] cx18-0: Audio Sampling Frequency: 32 kHz (grabbed)
> [ 289.804313] cx18-0: Audio Encoding: MPEG-1/2 Layer II (grabbed)
> [ 289.804316] cx18-0: Audio Layer II Bitrate: 384 kbps (grabbed)
> [ 289.804319] cx18-0: Audio Stereo Mode: Stereo
> [ 289.804322] cx18-0: Audio Stereo Mode Extension: Bound 4 (inactive)
> [ 289.804325] cx18-0: Audio Emphasis: No Emphasis
> [ 289.804328] cx18-0: Audio CRC: No CRC
> [ 289.804330] cx18-0: Audio Mute: false
> [ 289.804332] cx18-0: Video Encoding: MPEG-2
> [ 289.804335] cx18-0: Video Aspect: 4x3
> [ 289.804337] cx18-0: Video B Frames: 2
> [ 289.804340] cx18-0: Video GOP Size: 15
> [ 289.804342] cx18-0: Video GOP Closure: true
> [ 289.804345] cx18-0: Video Bitrate Mode: Variable Bitrate (grabbed)
> [ 289.804348] cx18-0: Video Bitrate: 4500000 (grabbed)
> [ 289.804351] cx18-0: Video Peak Bitrate: 6000000 (grabbed)
> [ 289.804354] cx18-0: Video Temporal Decimation: 0
> [ 289.804356] cx18-0: Video Mute: false
> [ 289.804359] cx18-0: Video Mute YUV: 32896
> [ 289.804362] cx18-0: Spatial Filter Mode: Manual
> [ 289.804364] cx18-0: Spatial Filter: 0
> [ 289.804367] cx18-0: Spatial Luma Filter Type: 1D Horizontal
> [ 289.804370] cx18-0: Spatial Chroma Filter Type: 1D Horizontal
> [ 289.804373] cx18-0: Temporal Filter Mode: Manual
> [ 289.804375] cx18-0: Temporal Filter: 8
> [ 289.804378] cx18-0: Median Filter Type: Off
> [ 289.804380] cx18-0: Median Luma Filter Minimum: 0 (inactive)
> [ 289.804383] cx18-0: Median Luma Filter Maximum: 255 (inactive)
> [ 289.804386] cx18-0: Median Chroma Filter Minimum: 0 (inactive)
> [ 289.804389] cx18-0: Median Chroma Filter Maximum: 255 (inactive)
> [ 289.804392] cx18-0: Insert Navigation Packets: false
> [ 289.804395] cx18-0: Status flags: 0x00200001
> [ 289.804398] cx18-0: Stream encoder MPEG: status 0x0118, 1% of
> 2048 KiB (64 buffers) in use
> [ 289.804401] cx18-0: Stream encoder YUV: status 0x0000, 0% of
> 2025 KiB (20 buffers) in use
> [ 289.804404] cx18-0: Stream encoder VBI: status 0x0038, 10% of
> 1015 KiB (20 buffers) in use
> [ 289.804407] cx18-0: Stream encoder PCM audio: status 0x0000, 0%
> of 1024 KiB (256 buffers) in use
> [ 289.804409] cx18-0: Read MPEG/VBI: 165570560/328504 bytes
> [ 289.804411] cx18-0: ================== END STATUS CARD #0
> ==================
>
>
> >
> > 3. Please provide the relevant portion of the mythbackend log where
> > where the digital scanner starts and then fails.
>
> So the Digital scanner doesn't fail per se, it just doesn't pick up
> most of the digital channels available. The same is true of scan, it
> seems to find only 1 channel when I know that I have access to 18.
Make sure it's not a signal integrity problem:
http://ivtvdriver.org/index.php/Howto:Improve_signal_quality
wild speculation: If the analog tuner driver init failed, maybe that is
having some bad EMI efect on the digital tuner
I'm assumiong you got more than the 1 channel before trying to enable
analog tuning.
> >
> > 4. Does digital tuning still work in MythTV despite the digital scanner
> > not working?
>
> Using the command line tools you linked I am able to tune to the
> channel that is found and watch it via mplayer.
Can you tune to other known digital channels?
> Let me know if you need anything else.
Are you tuning digital cable (North American QAM) or digital Over The
Air (ATSC)?
I tune ATSC with a high gain antenna and a Winegard preamplifer for
fringe areas; I'm 75 miles away from the city. One of the most
important contributions to getting a good signal was a lightning
protection/grounding block for the coaxial cable shield near the antenna
end of the cable. I suspect I was picking up a lot of EMI from in-home
sources and other local sources.
If using a preamp, make sure you are not over-amplifying the signal. It
will cause clipping in the tuner's front end, inducing intermodulation
products which look like noise and degrade the SNR.
Regards,
Andy
^ permalink raw reply
* Re: Tracking file metadata in git -- fix metastore or enhance git?
From: Richard Hartmann @ 2011-04-11 0:12 UTC (permalink / raw)
To: Git List; +Cc: Harley J Pig
In-Reply-To: <BANLkTimbAmW+ueq1Z9PJN9opXggywdxdnA@mail.gmail.com>
FYI, Harley J Pig <harleypig@gmail.com> had this to say on the
vcs-home mailing list
> I've written a metastore clone for a project where we need to store a
> linux distribution in version control (legacy code). I'm also using
> it for my personal vcs-home stuff. It is a naive and bluntly
> straightforward way to do this, but it seems to be working. You can
> find it at https://github.com/harleypig/gitperms
>
> I use git hooks and a central file to (re)store the metadata. Maybe
> it can be of some use to someone else.
Richard
^ permalink raw reply
* Re: ipset-6.2 testsuite failure
From: Jan Engelhardt @ 2011-04-11 0:07 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Netfilter Developer Mailing List
In-Reply-To: <alpine.DEB.2.00.1104102013230.3680@blackhole.kfki.hu>
On Sunday 2011-04-10 20:18, Jozsef Kadlecsik wrote:
>> >Also, the testsuite in ipset-6.2 contains the tests against the kernel in
>> >the package itself: the patches I have submitted today are missing from
>> >2.6.39-rc1+
>>
>> Tried with ipset 6.3 and modules from ipset-6.3, and seems to work.
>
>Thanks! The kernel is a little bit behind the package.
The testsuite should use diff -u at least, the context numbers are not very
telling.
^ permalink raw reply
* [PATCH 1/1] staging: sep: resolve issue with false zero length of page
From: Mark Allyn @ 2011-04-11 0:03 UTC (permalink / raw)
To: linux-kernel, greg, mark.a.allyn, alan
Signed-off-by: Mark Allyn <mark.a.allyn@intel.com>
---
drivers/staging/sep/sep_driver.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sep/sep_driver.c b/drivers/staging/sep/sep_driver.c
index 890eede..52342c1 100644
--- a/drivers/staging/sep/sep_driver.c
+++ b/drivers/staging/sep/sep_driver.c
@@ -1095,13 +1095,16 @@ static int sep_lock_user_pages(struct sep_device *sep,
if (num_pages > 1) {
lli_array[num_pages - 1].block_size =
(app_virt_addr + data_size) & (~PAGE_MASK);
+ if (lli_array[num_pages - 1].block_size == 0)
+ lli_array[num_pages - 1].block_size = PAGE_SIZE;
dev_warn(&sep->pdev->dev,
- "lli_array[%x].bus_address is %08lx, lli_array[%x].block_size is %x\n",
+ "lli_array[%x].bus_address is "
+ "%08lx, lli_array[%x].block_size is %x\n",
num_pages - 1,
- (unsigned long)lli_array[count].bus_address,
+ (unsigned long)lli_array[num_pages -1].bus_address,
num_pages - 1,
- lli_array[count].block_size);
+ lli_array[num_pages -1].block_size);
}
/* Set output params according to the in_out flag */
--
1.7.0.4
^ permalink raw reply related
* [U-Boot] [PATCH] cfi_flash: reverse geometry for M29W800DT parts
From: Marek Vasut @ 2011-04-11 0:01 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1302465989-23952-1-git-send-email-vapier@gentoo.org>
On Sunday 10 April 2011 22:06:29 Mike Frysinger wrote:
> The M29W800DT parts also report their geometry with the sector layout
> reversed. So add that ID to the flash_fixup_stm function.
Maybe rework the stuff below into some table or it'll be a mess soon?
Cheers
>
> Otherwise, we get:
> bfin> flinfo
>
> Bank # 1: CFI conformant FLASH (16 x 16) Size: 1 MB in 19 Sectors
> AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x22D7
> Erase timeout: 8192 ms, write timeout: 1 ms
>
> Sector Start Addresses:
> 20000000 20004000 20006000 20008000 20010000
> 20020000 20030000 20040000 20050000 20060000
> 20070000 20080000 20090000 200A0000 200B0000
> 200C0000 200D0000 200E0000 200F0000
>
> Reported-by: Jianxi Fu <fujianxi@gmail.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> ---
> drivers/mtd/cfi_flash.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index 0909fe7..69f12d3 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -1852,9 +1852,10 @@ static void flash_fixup_stm(flash_info_t *info,
> struct cfi_qry *qry) if (qry->num_erase_regions > 1) {
> /* reverse geometry if top boot part */
> if (info->cfi_version < 0x3131) {
> - /* CFI < 1.1, guess by device id (M29W320{DT,ET} only) */
> - if (info->device_id == 0x22CA ||
> - info->device_id == 0x2256) {
> + /* CFI < 1.1, guess by device id */
> + if (info->device_id == 0x22CA || /* M29W320DT */
> + info->device_id == 0x2256 || /* M29W320ET */
> + info->device_id == 0x22D7) { /* M29W800DT */
> cfi_reverse_geometry(qry);
> }
> }
^ permalink raw reply
* [PATCH] PXA: Use dev_pm_ops in z2_battery
From: Marek Vasut @ 2011-04-10 23:40 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
---
btw. Anton, do you want to apply it or shall pxa tree pick this up?
Cheers :)
drivers/power/z2_battery.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/power/z2_battery.c b/drivers/power/z2_battery.c
index e5ed52d..82dae53 100644
--- a/drivers/power/z2_battery.c
+++ b/drivers/power/z2_battery.c
@@ -269,24 +269,33 @@ static int __devexit z2_batt_remove(struct i2c_client *client)
}
#ifdef CONFIG_PM
-static int z2_batt_suspend(struct i2c_client *client, pm_message_t state)
+static int z2_batt_suspend(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
struct z2_charger *charger = i2c_get_clientdata(client);
flush_work_sync(&charger->bat_work);
return 0;
}
-static int z2_batt_resume(struct i2c_client *client)
+static int z2_batt_resume(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
struct z2_charger *charger = i2c_get_clientdata(client);
schedule_work(&charger->bat_work);
return 0;
}
+
+static const struct dev_pm_ops z2_battery_pm_ops = {
+ .suspend = z2_batt_suspend,
+ .resume = z2_batt_resume,
+};
+
+#define Z2_BATTERY_PM_OPS (&z2_battery_pm_ops)
+
#else
-#define z2_batt_suspend NULL
-#define z2_batt_resume NULL
+#define Z2_BATTERY_PM_OPS (NULL)
#endif
static const struct i2c_device_id z2_batt_id[] = {
@@ -298,11 +307,10 @@ static struct i2c_driver z2_batt_driver = {
.driver = {
.name = "z2-battery",
.owner = THIS_MODULE,
+ .pm = Z2_BATTERY_PM_OPS
},
.probe = z2_batt_probe,
.remove = z2_batt_remove,
- .suspend = z2_batt_suspend,
- .resume = z2_batt_resume,
.id_table = z2_batt_id,
};
--
1.7.4.1
^ permalink raw reply related
* [Buildroot] uclibc vs glibc
From: Khem Raj @ 2011-04-10 23:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <BANLkTikSPG0y+0BnAxNrPedQLHWwFbAMEw@mail.gmail.com>
On (10/04/11 16:08), Charles Krinke wrote:
> I have a quesiton on a different subject and that is the difference between
> uclibc and glibc from the MPC8323ERDB target viewpoint.
>
they are entirely different root file systems.
> Here is what I think I know:
> 1. The toolchain is independent of the notion of uclibc vs glibc.
> 2. Several of the .so files in /lib on the target will be different between
> uclibc and glibc.
> 3. An application needs to be compiled with the static (or dynamic)
> libraries pertinent to glibc or uclibc with appropriate header files to
> expect it to run on the target.
>
> Questions:
> 1. Which .so files on the target are different? ld, libc, libstdc++ only, or
> others?
> 2. Are the differing files on the target going to have the same names behind
> their softlinks
> like ld.so.1->ld-2.11.1.so for instance?
> 3. Can I configure the CodeSourcery toolchain to produce a rootfs with
> either uclibc or glibc and if so, what might be some of the steps?
Try using -muclibc or -mglibc options.
>
> --
> Charles Krinke
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
--
-Khem
^ permalink raw reply
* Re: [PATCH] fix build warnings on defconfigs
From: wanlong gao @ 2011-04-10 23:34 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux, hans-christian.egtvedt, ralf, benh, paulus,
david.woodhouse, akpm, mingo, rientjes, nicolas.ferre, eric, tony,
santosh.shilimkar, khilman, ben-linux, sam, manuel.lauss, galak,
anton, grant.likely, sfr, jwboyer, linux-arm-kernel, linux-kernel,
linux-mips, linuxppc-dev
In-Reply-To: <20110410181238.GE18601@pengutronix.de>
On 4/11/11, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> On Sun, Apr 10, 2011 at 03:04:18AM +0800, wanlong.gao@gmail.com wrote:
>> From: Wanlong Gao <wanlong.gao@gmail.com>
>>
>> Change the BT_L2CAP and BT_SCO defconfigs from 'm' to 'y',
>> since BT_L2CAP and BT_SCO had changed to bool configs.
> Pointing out the commit that changed these two in the commit log would
> be nice. Something like:
>
> The BT_L2CAP and BT_SCO configs are bool since
>
> 6427451 (Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko)
>
> . So change all defconfigs from =m to =y.
>
> Other than that
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks .
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* Re: [PATCH] fix build warnings on defconfigs
From: wanlong gao @ 2011-04-10 23:34 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-mips, david.woodhouse, tony, nicolas.ferre, paulus, eric,
sam, sfr, linux, khilman, manuel.lauss, rientjes, mingo, anton,
ben-linux, linux-arm-kernel, linux-kernel, ralf,
santosh.shilimkar, akpm, linuxppc-dev, hans-christian.egtvedt
In-Reply-To: <20110410181238.GE18601@pengutronix.de>
On 4/11/11, Uwe Kleine-K=F6nig <u.kleine-koenig@pengutronix.de> wrote:
> On Sun, Apr 10, 2011 at 03:04:18AM +0800, wanlong.gao@gmail.com wrote:
>> From: Wanlong Gao <wanlong.gao@gmail.com>
>>
>> Change the BT_L2CAP and BT_SCO defconfigs from 'm' to 'y',
>> since BT_L2CAP and BT_SCO had changed to bool configs.
> Pointing out the commit that changed these two in the commit log would
> be nice. Something like:
>
> The BT_L2CAP and BT_SCO configs are bool since
>
> 6427451 (Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko)
>
> . So change all defconfigs from =3Dm to =3Dy.
>
> Other than that
> Acked-by: Uwe Kleine-K=F6nig <u.kleine-koenig@pengutronix.de>
Thanks .
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K=F6nig =
|
> Industrial Linux Solutions | http://www.pengutronix.de/ =
|
>
^ permalink raw reply
* [PATCH] fix build warnings on defconfigs
From: wanlong gao @ 2011-04-10 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110410181238.GE18601@pengutronix.de>
On 4/11/11, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> On Sun, Apr 10, 2011 at 03:04:18AM +0800, wanlong.gao at gmail.com wrote:
>> From: Wanlong Gao <wanlong.gao@gmail.com>
>>
>> Change the BT_L2CAP and BT_SCO defconfigs from 'm' to 'y',
>> since BT_L2CAP and BT_SCO had changed to bool configs.
> Pointing out the commit that changed these two in the commit log would
> be nice. Something like:
>
> The BT_L2CAP and BT_SCO configs are bool since
>
> 6427451 (Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko)
>
> . So change all defconfigs from =m to =y.
>
> Other than that
> Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Thanks .
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* Re: [PATCH] unify usage of VOID
From: Jan Pokorný @ 2011-04-10 23:34 UTC (permalink / raw)
To: Christopher Li; +Cc: linux-sparse
In-Reply-To: <BANLkTi=VYG-YwbSXksBgUayZfwTOWtfYiQ@mail.gmail.com>
On 04/11/2011 12:20 AM, Christopher Li wrote:
> Hi Jan,
>
> You are one fire with this sparse code :-)
>
> I will take a closer look of your patch series tonight.
>
> Thanks
>
> Chris
>
>
> On Sun, Apr 10, 2011 at 9:24 AM, Jan Pokorný <pokorny_jan@seznam.cz> wrote:
>> Also remove unneeded empty initializator of `void_pseudo'.
>>
>> Signed-off-by: Jan Pokorny <pokorny_jan@seznam.cz>
>> ---
>> linearize.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/linearize.c b/linearize.c
>> index f2034ce..46c9726 100644
>> --- a/linearize.c
>> +++ b/linearize.c
>> @@ -33,7 +33,7 @@ struct access_data;
>> static pseudo_t add_load(struct entrypoint *ep, struct access_data *);
>> static pseudo_t linearize_initializer(struct entrypoint *ep, struct expression *initializer, struct access_data *);
>>
>> -struct pseudo void_pseudo = {};
>> +struct pseudo void_pseudo;
>>
>> static struct position current_pos;
>>
>> @@ -1880,7 +1880,7 @@ pseudo_t linearize_statement(struct entrypoint *ep, struct statement *stmt)
>> struct basic_block *active;
>> pseudo_t src = linearize_expression(ep, expr);
>> active = ep->active;
>> - if (active && src != &void_pseudo) {
>> + if (active && src != VOID) {
>> struct instruction *phi_node = first_instruction(bb_return->insns);
>> pseudo_t phi;
>> if (!phi_node) {
>> --
>> 1.7.1
>> --
Hi Chris,
thank you for considering these patches, feel free to bother me with
complains :-)
I think I will have some more patches to send, but it should not be
tightly related to what I have already posted (if so, I'll make it explicit).
--
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192ce: Fix LED initialization
From: Larry Finger @ 2011-04-10 23:30 UTC (permalink / raw)
To: John W Linville; +Cc: chaoming_li, linux-wireless
From: Chaoming Li <chaoming_li@realsil.com.cn>
Driver rtl8192ce does not initialize the LED correctly.
Signed-off-by: Chaoming Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
This patch should probably be in 2.6.39, but I would not force the issue.
Larry
---
Index: wireless-testing/drivers/net/wireless/rtlwifi/base.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtlwifi/base.c
+++ wireless-testing/drivers/net/wireless/rtlwifi/base.c
@@ -251,14 +251,16 @@ void rtl_init_rfkill(struct ieee80211_hw
bool blocked;
u8 valid = 0;
- radio_state = rtlpriv->cfg->ops->radio_onoff_checking(hw, &valid);
+ /*set init state to on */
+ rtlpriv->rfkill.rfkill_state = 1;
+ wiphy_rfkill_set_hw_state(hw->wiphy, 0);
- /*set init state to that of switch */
- rtlpriv->rfkill.rfkill_state = radio_state;
- printk(KERN_INFO "rtlwifi: wireless switch is %s\n",
- rtlpriv->rfkill.rfkill_state ? "on" : "off");
+ radio_state = rtlpriv->cfg->ops->radio_onoff_checking(hw, &valid);
if (valid) {
+ printk(KERN_INFO "rtlwifi: wireless switch is %s\n",
+ rtlpriv->rfkill.rfkill_state ? "on" : "off");
+
rtlpriv->rfkill.rfkill_state = radio_state;
blocked = (rtlpriv->rfkill.rfkill_state == 1) ? 0 : 1;
Index: wireless-testing/drivers/net/wireless/rtlwifi/rtl8192ce/led.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtlwifi/rtl8192ce/led.c
+++ wireless-testing/drivers/net/wireless/rtlwifi/rtl8192ce/led.c
@@ -32,6 +32,14 @@
#include "reg.h"
#include "led.h"
+static void _rtl92ce_init_led(struct ieee80211_hw *hw,
+ struct rtl_led *pled, enum rtl_led_pin ledpin)
+{
+ pled->hw = hw;
+ pled->ledpin = ledpin;
+ pled->ledon = false;
+}
+
void rtl92ce_sw_led_on(struct ieee80211_hw *hw, struct rtl_led *pled)
{
u8 ledcfg;
@@ -97,10 +105,10 @@ void rtl92ce_sw_led_off(struct ieee80211
void rtl92ce_init_sw_leds(struct ieee80211_hw *hw)
{
-}
+ struct rtl_pci_priv *pcipriv = rtl_pcipriv(hw);
-void rtl92ce_deinit_sw_leds(struct ieee80211_hw *hw)
-{
+ _rtl92ce_init_led(hw, &(pcipriv->ledctl.sw_led0), LED_PIN_LED0);
+ _rtl92ce_init_led(hw, &(pcipriv->ledctl.sw_led1), LED_PIN_LED1);
}
void _rtl92ce_sw_led_control(struct ieee80211_hw *hw,
Index: wireless-testing/drivers/net/wireless/rtlwifi/pci.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtlwifi/pci.c
+++ wireless-testing/drivers/net/wireless/rtlwifi/pci.c
@@ -1785,7 +1785,8 @@ void rtl_pci_disconnect(struct pci_dev *
rtl_pci_deinit(hw);
rtl_deinit_core(hw);
- rtlpriv->cfg->ops->deinit_sw_leds(hw);
+ if (rtlpriv->cfg->ops->deinit_sw_leds)
+ rtlpriv->cfg->ops->deinit_sw_leds(hw);
_rtl_pci_io_handler_release(hw);
rtlpriv->cfg->ops->deinit_sw_vars(hw);
Index: wireless-testing/drivers/net/wireless/rtlwifi/rtl8192ce/led.h
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtlwifi/rtl8192ce/led.h
+++ wireless-testing/drivers/net/wireless/rtlwifi/rtl8192ce/led.h
@@ -31,7 +31,6 @@
#define __RTL92CE_LED_H__
void rtl92ce_init_sw_leds(struct ieee80211_hw *hw);
-void rtl92ce_deinit_sw_leds(struct ieee80211_hw *hw);
void rtl92ce_sw_led_on(struct ieee80211_hw *hw, struct rtl_led *pled);
void rtl92ce_sw_led_off(struct ieee80211_hw *hw, struct rtl_led *pled);
void rtl92ce_led_control(struct ieee80211_hw *hw, enum led_ctl_mode ledaction);
Index: wireless-testing/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ wireless-testing/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
@@ -131,7 +131,6 @@ static struct rtl_hal_ops rtl8192ce_hal_
.enable_hw_sec = rtl92ce_enable_hw_security_config,
.set_key = rtl92ce_set_key,
.init_sw_leds = rtl92ce_init_sw_leds,
- .deinit_sw_leds = rtl92ce_deinit_sw_leds,
.get_bbreg = rtl92c_phy_query_bb_reg,
.set_bbreg = rtl92c_phy_set_bb_reg,
.get_rfreg = rtl92ce_phy_query_rf_reg,
^ permalink raw reply
* Re: [PATCHv2 0/3] --dirstat fixes
From: Linus Torvalds @ 2011-04-10 23:17 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <1302475732-741-1-git-send-email-johan@herland.net>
On Sun, Apr 10, 2011 at 3:48 PM, Johan Herland <johan@herland.net> wrote:
> Here's a reroll of the previous series. Changes since v1:
The series looks fine to me,
Linus
^ permalink raw reply
* [Buildroot] uclibc vs glibc
From: Charles Krinke @ 2011-04-10 23:08 UTC (permalink / raw)
To: buildroot
I have a quesiton on a different subject and that is the difference between
uclibc and glibc from the MPC8323ERDB target viewpoint.
Here is what I think I know:
1. The toolchain is independent of the notion of uclibc vs glibc.
2. Several of the .so files in /lib on the target will be different between
uclibc and glibc.
3. An application needs to be compiled with the static (or dynamic)
libraries pertinent to glibc or uclibc with appropriate header files to
expect it to run on the target.
Questions:
1. Which .so files on the target are different? ld, libc, libstdc++ only, or
others?
2. Are the differing files on the target going to have the same names behind
their softlinks
like ld.so.1->ld-2.11.1.so for instance?
3. Can I configure the CodeSourcery toolchain to produce a rootfs with
either uclibc or glibc and if so, what might be some of the steps?
--
Charles Krinke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110410/1147ec6b/attachment.html>
^ permalink raw reply
* HVR-1250/CX23885 IR Rx (Re: [PATCH] Fix cx88 remote control input)
From: Andy Walls @ 2011-04-10 23:08 UTC (permalink / raw)
To: Jarod Wilson; +Cc: Devin Heitmueller, Lawrence Rust, Linux Media Mailing List
In-Reply-To: <099D978B-BC30-4527-870E-85ECEE74501D@wilsonet.com>
On Sat, 2011-04-09 at 21:39 -0400, Jarod Wilson wrote:
> > Jarod,
> >
> > The HVR-1850 uses a raw IR receiver in the CX23888 and older
> HVR-1250s use the raw IR receiver in the CX23885. They both work for
> Rx (I need to tweak the Cx23885 rx watermark though), but I never
> found time to finish Tx (lack of kernel interface when I had time).
> >
> > If you obtain one of these I can answer any driver questions.
>
> Quite some time back, I bought an HVR-1800 and an HVR-1250. I know one of
> them came with an mceusb transceiver and remote, as was pretty sure it was
> the 1800. For some reason, I didn't recall the 1250 coming with anything at
> all, but looking at dmesg output for it:
>
> cx23885 driver version 0.0.2 loaded
> cx23885 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> CORE cx23885[0]: subsystem: 0070:7911, board: Hauppauge WinTV-HVR1250 [card=3,autodetected]
> tveeprom 0-0050: Hauppauge model 79001, rev E3D9, serial# 4904656
> tveeprom 0-0050: MAC address is 00:0d:fe:4a:d6:d0
> tveeprom 0-0050: tuner model is Microtune MT2131 (idx 139, type 4)
> tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
> tveeprom 0-0050: audio processor is CX23885 (idx 39)
> tveeprom 0-0050: decoder processor is CX23885 (idx 33)
> tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter
>
> So it seems I do have hardware. However, its one of the two tuner cards in
> my "production" mythtv backend right now, making it a bit hard to do any
> experimenting with. If I can get it out of there, it looks like I just add
> an enable_885_ir=1, and I should be able to poke at it...
Yeah. Igor's TeVii S470 CX23885 based card had interrupt storms when
enabled, so IR for '885 chips is disabled by default. To investigate, I
tried to by an HVR-1250 with a CX23885, but instead got an HVR-1275 with
a CX23888. dandel, on IRC, did a pretty decent job in testing HVR-1250
operation and finding it works, despite climbing kernel
build/development learning curve at the time.
You may also want to set ir_debug=2 for the *cx25840* module, if you
want to see the raw pulse/space measurements in the logs. The cx25840
module handles the CX23885 IR controller.
When testing, you may want to add pci=nomsi to your kernel comandline.
Unless Igor has submitted his fix to reset some CX23885 hardware on
module unload or reload, CX23885 interrupts won't work right after
unloading and reloading the cx23885 module with MSI enabled. :(
In the cx25840 module you may also want to change the call in
drivers/media/video/cx25840/cx25840-ir.c:
control_rx_irq_watermark(c, RX_FIFO_HALF_FULL);
to
control_rx_irq_watermark(c, RX_FIFO_NOT_EMPTY);
That's a design bug on my part. The CX23885 IR controller is I2C
connected. Waiting unitl the RX FIFO is half full risks losing some
pulse measurements.
Regards,
Andy
^ permalink raw reply
* dvb-t: crash with smsmdtv/smsdvb (2.6.38.2)
From: Lasse Lindner @ 2011-04-10 22:52 UTC (permalink / raw)
To: linux-kernel
Hi,
this happens on 2.6.38.2 (I had the problem in .37 too, therefore I
upgraded) on an ARM machine (Guruplug ServerPlus) with my USB DVB-T
Stick from Hauppauge ("WinTV Ministick") in use with the
corresponding smsmdtv and smsdvb modules. The DVB-T Stick is 24/7 in
use by vdr (http://www.tvdr.de). I get this crash only "every now
and then", like, a couple of hours or a couple of days (but it comes,
for sure). So I can only reproduce it by patience.
dmesg output:
--------------------------------------------------------------------------------------------------------------
[...]
Unable to handle kernel paging request at virtual address e1682000
pgd = df3fc000
[e1682000] *pgd=1f22e811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1]
last sysfs file: /sys/devices/platform/orion-ehci.0/usb1/1-1/1-1.1/bcdDevice
Modules linked in: rfcomm l2cap xt_tcpudp iptable_filter ipt_addrtype ip_tables x_tables smsdvb dvb_core ir_lirc_codec smsusb lirc_dev smsmdtv rc_core pl2303 usbserial usb_storage btmrvl_sdio libertas_sdio btmrvl libertas bluetooth sg ehci_hcd
CPU: 0 Not tainted (2.6.38.2 #1)
PC is at memcpy+0x188/0x3a4
LR is at 0xd95d0430
pc : [<c01d85a8>] lr : [<d95d0430>] psr: 20000013
sp : dbd73e90 ip : 7275626d fp : dbd73eb0
r10: e1681f14 r9 : 61482073 r8 : 614405f9
r7 : 00726567 r6 : 00ff4e57 r5 : 01003000 r4 : 00450270
r3 : 00d95d04 r2 : 00000100 r1 : e1681ff4 r0 : 42f78e60
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005397f Table: 1f3fc000 DAC: 00000015
Process vdr (pid: 5708, stack limit = 0xdbd72270)
Stack: (0xdbd73e90 to 0xdbd74000)
3e80: 42f78d93 dbd72000 0000026d 00000000
3ea0: dbd73eb4 42f78d93 000004fc c01e137c ddcd0340 dbd7f5e0 000004fc e131c194
3ec0: 42f78d93 000004fc 000004fc dbd72000 dbd73f10 000004fc 00000000 bf0c06d0
3ee0: e131c194 e131c194 42f78d93 000004fc dbd73f04 bf0b7424 e131c1a8 00000800
3f00: 00000d28 db469740 df2fd2d4 df2fd318 00000013 df2fd2d4 0000c089 e131c140
3f20: 00000003 42f78d93 dcd56300 00000ffd e131c1b0 00000000 42f79dbc bf0b75bc
3f40: 00001000 dcd56300 42f78d90 dbd73f80 00001000 dbd72000 00000000 c009dbf4
3f60: dcd56300 42f78d90 dcd56300 42f78d90 00000000 00000000 00001000 c009dd08
3f80: 00000000 00000000 00001000 00000001 00000005 00001000 42f78d90 00000003
3fa0: c0029c04 c0029a80 00000005 00001000 00000005 42f78d90 00001000 00000005
3fc0: 00000005 00001000 42f78d90 00000003 42f78d20 00000012 42f79d90 42f79dbc
3fe0: 00000000 42f78cf8 400358cc 40036034 80000010 00000005 1fffe831 1fffec31
Code: f5d1f07c e8b100f0 e1a0342e e2522020 (e8b15300)
---[ end trace 27b9f433ce7b3d20 ]---
^ permalink raw reply
* Re: Firmware files for Ralink RT28x0
From: Xose Vazquez Perez @ 2011-04-10 22:56 UTC (permalink / raw)
To: Larry Finger; +Cc: Ben Hutchings, users, linux-wireless
In-Reply-To: <4DA2312B.8080303@lwfinger.net>
On 04/11/2011 12:37 AM, Larry Finger wrote:
> Do you still have the patch from one year ago? I would like to see what you proposed in changes to WHENCE.
Déjà vu
me: http://marc.info/?l=linux-wireless&m=129798073407070&w=2
ivo: http://marc.info/?l=linux-wireless&m=128844402626603&w=2
ralink: http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2011-March/003381.html
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2011-March/003382.html
^ permalink raw reply
* Bug report in Obex code
From: Claudiu Coman @ 2011-04-10 22:56 UTC (permalink / raw)
To: linux-bluetooth
Hello,
While doing some documentation for my GSOC application, I found a small
bug in the Obex code, in src/obex.c, function "obex_write_stream".
There's the declaration:
"uint8_t hi;"
If the "if" statement body between lines 640-648 is executed, after the jump
to the "add_header" tag, the switch statement will test an
uninitialized variable.
At first I thought about sending a patch myself, but I don't know what value
the header index variable should be initialized with.
Cheers,
Claudiu
^ permalink raw reply
* Re: What's cooking in git.git (Apr 2011, #02; Wed, 6)
From: Jens Lehmann @ 2011-04-10 22:55 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git
In-Reply-To: <BANLkTinTVinnDLPnHGoF9DY97ky_MFiLAQ@mail.gmail.com>
Am 10.04.2011 20:52, schrieb Ævar Arnfjörð Bjarmason:
> On Wed, Apr 6, 2011 at 22:04, Junio C Hamano <gitster@pobox.com> wrote:
>
>> * jl/submodule-fetch-on-demand (2011-03-06) 7 commits
>> (merged to 'next' on 2011-03-20 at a5e452d)
>> + fetch/pull: Describe --recurse-submodule restrictions in the BUGS section
>> + submodule update: Don't fetch when the submodule commit is already present
>> + fetch/pull: Don't recurse into a submodule when commits are already present
>> + Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option
>> + config: teach the fetch.recurseSubmodules option the 'on-demand' value
>> + fetch/pull: Add the 'on-demand' value to the --recurse-submodules option
>> + fetch/pull: recurse into submodules when necessary
>
> This series needs to be fixed to not fail tests with GETTEXT_POISON=YesPlease.
Maybe something like this? Junio, do you want me to squash the changes in
the patch series and resend it or should I send a new commit?
-----------------8<-------------
diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh
index af78e21..3279aec 100755
--- a/t/t5526-fetch-submodules.sh
+++ b/t/t5526-fetch-submodules.sh
@@ -230,7 +230,7 @@ test_expect_success "Recursion doesn't happen when no new commits are fetched in
! test -s actual.err
'
-test_expect_success "Recursion stops when no new submodule commits are fetched" '
+test_expect_success C_LOCALE_OUTPUT "Recursion stops when no new submodule commits are fetched" '
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "new submodule" &&
@@ -247,7 +247,7 @@ test_expect_success "Recursion stops when no new submodule commits are fetched"
test_cmp expect.out.sub actual.out
'
-test_expect_success "Recursion doesn't happen when new superproject commits don't change any submodules" '
+test_expect_success C_LOCALE_OUTPUT "Recursion doesn't happen when new superproject commits don't change any submodules" '
add_upstream_commit &&
head1=$(git rev-parse --short HEAD) &&
echo a > file &&
@@ -264,7 +264,7 @@ test_expect_success "Recursion doesn't happen when new superproject commits don'
test_cmp expect.err.file actual.err
'
-test_expect_success "Recursion picks up config in submodule" '
+test_expect_success C_LOCALE_OUTPUT "Recursion picks up config in submodule" '
(
cd downstream &&
git fetch --recurse-submodules &&
@@ -293,7 +293,7 @@ test_expect_success "Recursion picks up config in submodule" '
test_cmp expect.out actual.out
'
-test_expect_success "Recursion picks up all submodules when necessary" '
+test_expect_success C_LOCALE_OUTPUT "Recursion picks up all submodules when necessary" '
add_upstream_commit &&
(
cd submodule &&
@@ -351,7 +351,7 @@ test_expect_success "'--recurse-submodules=on-demand' doesn't recurse when no ne
! test -s actual.err
'
-test_expect_success "'--recurse-submodules=on-demand' recurses as deep as necessary (and ignores config)" '
+test_expect_success C_LOCALE_OUTPUT "'--recurse-submodules=on-demand' recurses as deep as necessary (and ignores config)" '
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "new submodule" &&
@@ -379,7 +379,7 @@ test_expect_success "'--recurse-submodules=on-demand' recurses as deep as necess
test_cmp expect.err actual.err
'
-test_expect_success "'--recurse-submodules=on-demand' stops when no new submodule commits are found in the superproject (and ignores config)" '
+test_expect_success C_LOCALE_OUTPUT "'--recurse-submodules=on-demand' stops when no new submodule commits are found in the superproject (and ignores config)" '
add_upstream_commit &&
head1=$(git rev-parse --short HEAD) &&
echo a >> file &&
@@ -396,7 +396,7 @@ test_expect_success "'--recurse-submodules=on-demand' stops when no new submodul
test_cmp expect.err.file actual.err
'
-test_expect_success "'fetch.recurseSubmodules=on-demand' overrides global config" '
+test_expect_success C_LOCALE_OUTPUT "'fetch.recurseSubmodules=on-demand' overrides global config" '
(
cd downstream &&
git fetch --recurse-submodules
@@ -424,7 +424,7 @@ test_expect_success "'fetch.recurseSubmodules=on-demand' overrides global config
test_cmp expect.err.2 actual.err
'
-test_expect_success "'submodule.<sub>.fetchRecurseSubmodules=on-demand' overrides fetch.recurseSubmodules" '
+test_expect_success C_LOCALE_OUTPUT "'submodule.<sub>.fetchRecurseSubmodules=on-demand' overrides fetch.recurseSubmodules" '
(
cd downstream &&
git fetch --recurse-submodules
@@ -452,7 +452,7 @@ test_expect_success "'submodule.<sub>.fetchRecurseSubmodules=on-demand' override
test_cmp expect.err.2 actual.err
'
-test_expect_success "don't fetch submodule when newly recorded commits are already present" '
+test_expect_success C_LOCALE_OUTPUT "don't fetch submodule when newly recorded commits are already present" '
(
cd submodule &&
git checkout -q HEAD^^
^ permalink raw reply related
* [PATCHv2 3/3] Teach --dirstat to not completely ignore rearranged lines within a file
From: Johan Herland @ 2011-04-10 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Johan Herland
In-Reply-To: <1302475732-741-1-git-send-email-johan@herland.net>
Currently, the --dirstat analysis fails to detect when lines within a
file are rearranged, because the "damage" calculated by show_dirstat()
is 0. However, if the SHA1 sum has changed, we already now that there
should be at least some minimum amount of damage.
This patch teaches show_dirstat() to assign a minimum amount of damage
(== 1) to entries for which the analysis otherwise yields zero damage.
Obviously this is not a complete fix, but it's at least better to
underrepresent these changes, rather than simply pretending that they
don't exist.
Also, with the added SHA1 comparison, we can safely skip the --dirstat
analysis when the SHA1s do happen to match (e.g. for a pure file rename)
Signed-off-by: Johan Herland <johan@herland.net>
---
Documentation/diff-options.txt | 4 ++--
diff.c | 19 ++++++++++++++++++-
t/t4013-diff-various.sh | 2 --
t/t4013/diff.diff_--dirstat_initial_rearrange | 1 +
4 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 23772d6..7e4bd42 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -74,8 +74,8 @@ endif::git-format-patch[]
counted for the parent directory, unless `--cumulative` is used.
+
Note that the `--dirstat` option computes the changes while ignoring
-pure code movements within a file. In other words, rearranging lines
-in a file is not counted as a change.
+the amount of pure code movements within a file. In other words,
+rearranging lines in a file is not counted as much as other changes.
--dirstat-by-file[=<limit>]::
Same as `--dirstat`, but counts changed files instead of lines.
diff --git a/diff.c b/diff.c
index a224048..3e0bc1f 100644
--- a/diff.c
+++ b/diff.c
@@ -1547,6 +1547,16 @@ static void show_dirstat(struct diff_options *options)
else
content_changed = 1;
+ if (!content_changed) {
+ /*
+ * The SHA1 has not changed, so pre-/post-content is
+ * identical. We can therefore skip looking at the
+ * file contents altogether.
+ */
+ damage = 0;
+ goto found_damage;
+ }
+
if (DIFF_OPT_TST(options, DIRSTAT_BY_FILE)) {
/*
* In --dirstat-by-file mode, we don't really need to
@@ -1555,7 +1565,7 @@ static void show_dirstat(struct diff_options *options)
* add this file to the list of results
* (with each file contributing equal damage).
*/
- damage = content_changed ? 1 : 0;
+ damage = 1;
goto found_damage;
}
@@ -1582,8 +1592,15 @@ static void show_dirstat(struct diff_options *options)
* Original minus copied is the removed material,
* added is the new material. They are both damages
* made to the preimage.
+ * If the resulting damage is zero, we know that
+ * diffcore_count_changes() considers the two entries to
+ * be identical, but since content_changed is true, we
+ * know that there must have been _some_ kind of change,
+ * so we force all entries to have damage > 0.
*/
damage = (p->one->size - copied) + added;
+ if (!damage)
+ damage = 1;
found_damage:
ALLOC_GROW(dir.files, dir.nr + 1, dir.alloc);
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 6428a90..93a6f20 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -300,9 +300,7 @@ diff --no-index --name-status -- dir2 dir
diff --no-index dir dir3
diff master master^ side
diff --dirstat master~1 master~2
-# --dirstat doesn't notice changes that simply rearrange existing lines
diff --dirstat initial rearrange
-# ...but --dirstat-by-file does notice changes that only rearrange lines
diff --dirstat-by-file initial rearrange
EOF
diff --git a/t/t4013/diff.diff_--dirstat_initial_rearrange b/t/t4013/diff.diff_--dirstat_initial_rearrange
index fb2e17d..5fb02c1 100644
--- a/t/t4013/diff.diff_--dirstat_initial_rearrange
+++ b/t/t4013/diff.diff_--dirstat_initial_rearrange
@@ -1,2 +1,3 @@
$ git diff --dirstat initial rearrange
+ 100.0% dir/
$
--
1.7.5.rc1.3.g4d7b
^ permalink raw reply related
* [PATCHv2 2/3] --dirstat-by-file: Make it faster and more correct
From: Johan Herland @ 2011-04-10 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Johan Herland
In-Reply-To: <1302475732-741-1-git-send-email-johan@herland.net>
Currently, when using --dirstat-by-file, it first does the full --dirstat
analysis (using diffcore_count_changes()), and then resets 'damage' to 1,
if any damage was found by diffcore_count_changes().
But --dirstat-by-file is not interested in the file damage per se. It only
cares if the file changed at all. In that sense it only cares if the blob
SHA1 for a file has changed. We therefore only need to compare the SHA1s
of each file pair in the diff queue. As a result, we can skip the entire
--dirstat analysis and simply set 'damage' to 1 for each entry where the
SHA1 has changed.
This makes --dirstat-by-file faster, and also bypasses --dirstat's practice
of ignoring rearranged lines within a file.
The patch also contains an added testcase verifying that --dirstat-by-file
now detects changes that only rearrange lines within a file.
Signed-off-by: Johan Herland <johan@herland.net>
---
diff.c | 25 ++++++++++++++++----
t/t4013-diff-various.sh | 2 +
.../diff.diff_--dirstat-by-file_initial_rearrange | 3 ++
3 files changed, 25 insertions(+), 5 deletions(-)
create mode 100644 t/t4013/diff.diff_--dirstat-by-file_initial_rearrange
diff --git a/diff.c b/diff.c
index 9fa8410..a224048 100644
--- a/diff.c
+++ b/diff.c
@@ -1538,9 +1538,27 @@ static void show_dirstat(struct diff_options *options)
struct diff_filepair *p = q->queue[i];
const char *name;
unsigned long copied, added, damage;
+ int content_changed;
name = p->one->path ? p->one->path : p->two->path;
+ if (p->one->sha1_valid && p->two->sha1_valid)
+ content_changed = hashcmp(p->one->sha1, p->two->sha1);
+ else
+ content_changed = 1;
+
+ if (DIFF_OPT_TST(options, DIRSTAT_BY_FILE)) {
+ /*
+ * In --dirstat-by-file mode, we don't really need to
+ * look at the actual file contents at all.
+ * The fact that the SHA1 changed is enough for us to
+ * add this file to the list of results
+ * (with each file contributing equal damage).
+ */
+ damage = content_changed ? 1 : 0;
+ goto found_damage;
+ }
+
if (DIFF_FILE_VALID(p->one) && DIFF_FILE_VALID(p->two)) {
diff_populate_filespec(p->one, 0);
diff_populate_filespec(p->two, 0);
@@ -1563,14 +1581,11 @@ static void show_dirstat(struct diff_options *options)
/*
* Original minus copied is the removed material,
* added is the new material. They are both damages
- * made to the preimage. In --dirstat-by-file mode, count
- * damaged files, not damaged lines. This is done by
- * counting only a single damaged line per file.
+ * made to the preimage.
*/
damage = (p->one->size - copied) + added;
- if (DIFF_OPT_TST(options, DIRSTAT_BY_FILE) && damage > 0)
- damage = 1;
+found_damage:
ALLOC_GROW(dir.files, dir.nr + 1, dir.alloc);
dir.files[dir.nr].name = name;
dir.files[dir.nr].changed = damage;
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 3b1b392..6428a90 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -302,6 +302,8 @@ diff master master^ side
diff --dirstat master~1 master~2
# --dirstat doesn't notice changes that simply rearrange existing lines
diff --dirstat initial rearrange
+# ...but --dirstat-by-file does notice changes that only rearrange lines
+diff --dirstat-by-file initial rearrange
EOF
test_expect_success 'log -S requires an argument' '
diff --git a/t/t4013/diff.diff_--dirstat-by-file_initial_rearrange b/t/t4013/diff.diff_--dirstat-by-file_initial_rearrange
new file mode 100644
index 0000000..e48e33f
--- /dev/null
+++ b/t/t4013/diff.diff_--dirstat-by-file_initial_rearrange
@@ -0,0 +1,3 @@
+$ git diff --dirstat-by-file initial rearrange
+ 100.0% dir/
+$
--
1.7.5.rc1.3.g4d7b
^ permalink raw reply related
* [PATCH 2/2] KVM test: Turning off debug output for frequently called monitor commands
From: Lucas Meneghel Rodrigues @ 2011-04-10 22:49 UTC (permalink / raw)
To: autotest; +Cc: kvm
In-Reply-To: <1302475794-10361-1-git-send-email-lmr@redhat.com>
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
---
client/tests/kvm/kvm_monitor.py | 14 +++++++-------
client/tests/kvm/kvm_preprocessing.py | 6 +++---
client/tests/kvm/tests/stepmaker.py | 4 ++--
client/tests/kvm/tests/steps.py | 2 +-
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/client/tests/kvm/kvm_monitor.py b/client/tests/kvm/kvm_monitor.py
index 507e8dd..159c575 100644
--- a/client/tests/kvm/kvm_monitor.py
+++ b/client/tests/kvm/kvm_monitor.py
@@ -176,7 +176,7 @@ class HumanMonitor(Monitor):
"Output so far: %r" % o)
# Save the output of 'help' for future use
- self._help_str = self.cmd("help")
+ self._help_str = self.cmd("help", debug=False)
except MonitorError, e:
if suppress_exceptions:
@@ -279,7 +279,7 @@ class HumanMonitor(Monitor):
"""
Make sure the monitor is responsive by sending a command.
"""
- self.cmd("info status")
+ self.cmd("info status", debug=False)
# Command wrappers
@@ -310,14 +310,14 @@ class HumanMonitor(Monitor):
return self.info(what)
- def screendump(self, filename):
+ def screendump(self, filename, debug=True):
"""
Request a screendump.
@param filename: Location for the screendump
@return: The command's output
"""
- return self.cmd("screendump %s" % filename)
+ return self.cmd(command="screendump %s" % filename, debug=debug)
def migrate(self, uri, full_copy=False, incremental_copy=False, wait=False):
@@ -647,7 +647,7 @@ class QMPMonitor(Monitor):
"""
Make sure the monitor is responsive by sending a command.
"""
- self.cmd("query-status")
+ self.cmd(cmd="query-status", debug=False)
def get_events(self):
@@ -725,7 +725,7 @@ class QMPMonitor(Monitor):
return self.info(what)
- def screendump(self, filename):
+ def screendump(self, filename, debug=True):
"""
Request a screendump.
@@ -733,7 +733,7 @@ class QMPMonitor(Monitor):
@return: The response to the command
"""
args = {"filename": filename}
- return self.cmd("screendump", args)
+ return self.cmd(cmd="screendump", args=args, debug=debug)
def migrate(self, uri, full_copy=False, incremental_copy=False, wait=False):
diff --git a/client/tests/kvm/kvm_preprocessing.py b/client/tests/kvm/kvm_preprocessing.py
index e2cafe9..f679be0 100644
--- a/client/tests/kvm/kvm_preprocessing.py
+++ b/client/tests/kvm/kvm_preprocessing.py
@@ -85,7 +85,7 @@ def preprocess_vm(test, params, env, name):
scrdump_filename = os.path.join(test.debugdir, "pre_%s.ppm" % name)
try:
if vm.monitor:
- vm.monitor.screendump(scrdump_filename)
+ vm.monitor.screendump(scrdump_filename, debug=False)
except kvm_monitor.MonitorError, e:
logging.warn(e)
@@ -121,7 +121,7 @@ def postprocess_vm(test, params, env, name):
scrdump_filename = os.path.join(test.debugdir, "post_%s.ppm" % name)
try:
if vm.monitor:
- vm.monitor.screendump(scrdump_filename)
+ vm.monitor.screendump(scrdump_filename, debug=False)
except kvm_monitor.MonitorError, e:
logging.warn(e)
@@ -414,7 +414,7 @@ def _take_screendumps(test, params, env):
if not vm.is_alive():
continue
try:
- vm.monitor.screendump(temp_filename)
+ vm.monitor.screendump(filename=temp_filename, debug=False)
except kvm_monitor.MonitorError, e:
logging.warn(e)
continue
diff --git a/client/tests/kvm/tests/stepmaker.py b/client/tests/kvm/tests/stepmaker.py
index 5a9acdc..54f0e2b 100755
--- a/client/tests/kvm/tests/stepmaker.py
+++ b/client/tests/kvm/tests/stepmaker.py
@@ -138,7 +138,7 @@ class StepMaker(stepeditor.StepMakerWindow):
os.unlink(self.screendump_filename)
try:
- self.vm.monitor.screendump(self.screendump_filename)
+ self.vm.monitor.screendump(self.screendump_filename, debug=False)
except kvm_monitor.MonitorError, e:
logging.warn(e)
else:
@@ -292,7 +292,7 @@ class StepMaker(stepeditor.StepMakerWindow):
os.unlink(self.screendump_filename)
try:
- self.vm.monitor.screendump(self.screendump_filename)
+ self.vm.monitor.screendump(self.screendump_filename, debug=False)
except kvm_monitor.MonitorError, e:
logging.warn(e)
else:
diff --git a/client/tests/kvm/tests/steps.py b/client/tests/kvm/tests/steps.py
index 91b864d..3ad0143 100644
--- a/client/tests/kvm/tests/steps.py
+++ b/client/tests/kvm/tests/steps.py
@@ -86,7 +86,7 @@ def barrier_2(vm, words, params, debug_dir, data_scrdump_filename,
# Request screendump
try:
- vm.monitor.screendump(scrdump_filename)
+ vm.monitor.screendump(scrdump_filename, debug=False)
except kvm_monitor.MonitorError, e:
logging.warn(e)
continue
--
1.7.4.2
^ permalink raw reply related
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.