* Re: linux-next: manual merge of the isci tree with the scsi tree
From: Williams, Dan J @ 2012-03-13 2:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, James Bottomley
In-Reply-To: <20120313134512.848baf17f46729fa0fac195d@canb.auug.org.au>
On Mon, Mar 12, 2012 at 7:45 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Dan,
>
> Today's linux-next merge of the isci tree produced a large number of
> conflicts against the scsi.
>
> Merging isci/all
> +CONFLICT (content): Merge conflict in include/scsi/sas_ata.h
> CONFLICT (content): Merge conflict in include/scsi/libsas.h
> +CONFLICT (content): Merge conflict in include/linux/libata.h
> CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_scsi_host.c
> +CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_internal.h
> CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_init.c
> CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_expander.c
> +CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_event.c
> CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_discover.c
> +CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_ata.c
> +CONFLICT (content): Merge conflict in drivers/scsi/isci/request.h
> CONFLICT (content): Merge conflict in drivers/scsi/isci/registers.h
> +CONFLICT (content): Merge conflict in drivers/scsi/isci/port.h
> +CONFLICT (content): Merge conflict in drivers/scsi/isci/port.c
> +CONFLICT (content): Merge conflict in drivers/scsi/isci/phy.c
> CONFLICT (content): Merge conflict in drivers/scsi/isci/init.c
>
> Since you are feeding patches into the scsi tree (instaed of having you
> tree merged into the scsi tree), you should rebase your tree in the scsi
> tree after your patches have been accepted. The above conflicts are
> (almost completely) caused by having the same patches in both trees with
> additional changes to those files in your tree.
I was wondering why it had not happened prior to this point... in any
event I'll get my tree rebased on top scsi-misc so that isci.git#all
will just be the pending delta.
^ permalink raw reply
* linux-next: manual merge of the isci tree with the scsi tree
From: Stephen Rothwell @ 2012-03-13 2:45 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-next, linux-kernel, James Bottomley
[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]
Hi Dan,
Today's linux-next merge of the isci tree produced a large number of
conflicts against the scsi.
Merging isci/all
+CONFLICT (content): Merge conflict in include/scsi/sas_ata.h
CONFLICT (content): Merge conflict in include/scsi/libsas.h
+CONFLICT (content): Merge conflict in include/linux/libata.h
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_scsi_host.c
+CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_internal.h
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_init.c
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_expander.c
+CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_event.c
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_discover.c
+CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_ata.c
+CONFLICT (content): Merge conflict in drivers/scsi/isci/request.h
CONFLICT (content): Merge conflict in drivers/scsi/isci/registers.h
+CONFLICT (content): Merge conflict in drivers/scsi/isci/port.h
+CONFLICT (content): Merge conflict in drivers/scsi/isci/port.c
+CONFLICT (content): Merge conflict in drivers/scsi/isci/phy.c
CONFLICT (content): Merge conflict in drivers/scsi/isci/init.c
Since you are feeding patches into the scsi tree (instaed of having you
tree merged into the scsi tree), you should rebase your tree in the scsi
tree after your patches have been accepted. The above conflicts are
(almost completely) caused by having the same patches in both trees with
additional changes to those files in your tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the cpuidle-cons tree with the arm-soc tree
From: Rob Lee @ 2012-03-13 1:50 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Nicolas Ferre, Daniel Lezcano, Arnd Bergmann, linux-next,
linux-kernel, Olof Johansson, linux-arm-kernel
In-Reply-To: <20120313100625.b500f0efb546a9f4ceeb12ba@canb.auug.org.au>
On Mon, Mar 12, 2012 at 6:06 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Rob,
>
> On Mon, 12 Mar 2012 12:03:48 -0500 Rob Lee <rob.lee@linaro.org> wrote:
>>
>> On Mon, Mar 12, 2012 at 11:05 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 03/09/2012 08:37 AM, Stephen Rothwell :
>> >>
>> >> Today's linux-next merge of the cpuidle-cons tree got a conflict
>> >> in arch/arm/mach-at91/cpuidle.c between commit 00482a4078f4 ("ARM:
>> >> at91: implement the standby function for pm/cpuidle") from the
>> >> arm-soc tree and commit 7a1f6e72dce1 ("ARM: at91: Consolidate time
>> >> keeping and irq enable") from the cpuidle-cons tree.
>> >>
>> >> I fixed it up (I think - see below) and can carry the fix as
>> >> necessary.
>> >
>> > Yes: resolution correct. Please carry it.
>>
>> Who should carry this fixup and related necessary at91 changes? Me?
>> FYI, my at91 changes are dependent on my core cpuidle change, but my
>> core cpuidle changes do not require any at91 changes as the at91 and
>> other platform changes were only made to consolidate duplicate code.
>
> I will carry the fixup and Linus will presumably do the same fix when he
> merges these trees in his tree. I am not sure what you mean by "related
> at91 changes".
>
Thanks Stephen. By "related changes" I just meant that if I were to
make a branch to carry the fixup, I'd need to all merge in the at91
related changes that are on linux-next but not on an rc tag yet. But
please ignore this statement if it doesn't make sense. I'm not yet
knowledgeable on the workflow once submitted patchsets reach this
level.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
^ permalink raw reply
* linux-next: manual merge of the pci tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-13 1:43 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-next, linux-kernel, Bjorn Helgaas, Benjamin Herrenschmidt,
ppc-dev, Gavin Shan
[-- Attachment #1: Type: text/plain, Size: 4556 bytes --]
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
arch/powerpc/include/asm/ppc-pci.h between commit cb3bc9d0de1e
("powerpc/eeh: Cleanup comments in the EEH core") from the powerpc tree
and commit 673c97562489 ("powerpc/PCI: replace pci_probe_only with
pci_flags") from the pci tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/powerpc/include/asm/ppc-pci.h
index e660b37,f4f7ad8..0000000
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@@ -45,23 -45,92 +45,21 @@@ extern void init_pci_config_tokens (voi
extern unsigned long get_phb_buid (struct device_node *);
extern int rtas_setup_phb(struct pci_controller *phb);
- extern unsigned long pci_probe_only;
-
-/* ---- EEH internal-use-only related routines ---- */
#ifdef CONFIG_EEH
+void pci_addr_cache_build(void);
void pci_addr_cache_insert_device(struct pci_dev *dev);
void pci_addr_cache_remove_device(struct pci_dev *dev);
-void pci_addr_cache_build(void);
-struct pci_dev *pci_get_device_by_addr(unsigned long addr);
-
-/**
- * eeh_slot_error_detail -- record and EEH error condition to the log
- * @pdn: pci device node
- * @severity: EEH_LOG_TEMP_FAILURE or EEH_LOG_PERM_FAILURE
- *
- * Obtains the EEH error details from the RTAS subsystem,
- * and then logs these details with the RTAS error log system.
- */
-#define EEH_LOG_TEMP_FAILURE 1
-#define EEH_LOG_PERM_FAILURE 2
-void eeh_slot_error_detail (struct pci_dn *pdn, int severity);
-
-/**
- * rtas_pci_enable - enable IO transfers for this slot
- * @pdn: pci device node
- * @function: either EEH_THAW_MMIO or EEH_THAW_DMA
- *
- * Enable I/O transfers to this slot
- */
-#define EEH_THAW_MMIO 2
-#define EEH_THAW_DMA 3
-int rtas_pci_enable(struct pci_dn *pdn, int function);
-
-/**
- * rtas_set_slot_reset -- unfreeze a frozen slot
- * @pdn: pci device node
- *
- * Clear the EEH-frozen condition on a slot. This routine
- * does this by asserting the PCI #RST line for 1/8th of
- * a second; this routine will sleep while the adapter is
- * being reset.
- *
- * Returns a non-zero value if the reset failed.
- */
-int rtas_set_slot_reset (struct pci_dn *);
-int eeh_wait_for_slot_status(struct pci_dn *pdn, int max_wait_msecs);
-
-/**
- * eeh_restore_bars - Restore device configuration info.
- * @pdn: pci device node
- *
- * A reset of a PCI device will clear out its config space.
- * This routines will restore the config space for this
- * device, and is children, to values previously obtained
- * from the firmware.
- */
-void eeh_restore_bars(struct pci_dn *);
-
-/**
- * rtas_configure_bridge -- firmware initialization of pci bridge
- * @pdn: pci device node
- *
- * Ask the firmware to configure all PCI bridges devices
- * located behind the indicated node. Required after a
- * pci device reset. Does essentially the same hing as
- * eeh_restore_bars, but for brdges, and lets firmware
- * do the work.
- */
-void rtas_configure_bridge(struct pci_dn *);
-
+struct pci_dev *pci_addr_cache_get_device(unsigned long addr);
+void eeh_slot_error_detail(struct eeh_dev *edev, int severity);
+int eeh_pci_enable(struct eeh_dev *edev, int function);
+int eeh_reset_pe(struct eeh_dev *);
+void eeh_restore_bars(struct eeh_dev *);
int rtas_write_config(struct pci_dn *, int where, int size, u32 val);
int rtas_read_config(struct pci_dn *, int where, int size, u32 *val);
-
-/**
- * eeh_mark_slot -- set mode flags for pertition endpoint
- * @pdn: pci device node
- *
- * mark and clear slots: find "partition endpoint" PE and set or
- * clear the flags for each subnode of the PE.
- */
-void eeh_mark_slot (struct device_node *dn, int mode_flag);
-void eeh_clear_slot (struct device_node *dn, int mode_flag);
-
-/**
- * find_device_pe -- Find the associated "Partiationable Endpoint" PE
- * @pdn: pci device node
- */
-struct device_node * find_device_pe(struct device_node *dn);
+void eeh_mark_slot(struct device_node *dn, int mode_flag);
+void eeh_clear_slot(struct device_node *dn, int mode_flag);
+struct device_node *eeh_find_device_pe(struct device_node *dn);
void eeh_sysfs_add_device(struct pci_dev *pdev);
void eeh_sysfs_remove_device(struct pci_dev *pdev);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the tegra tree with the arm tree
From: Stephen Rothwell @ 2012-03-13 0:41 UTC (permalink / raw)
To: Stephen Warren, Colin Cross, Olof Johansson
Cc: linux-next, linux-kernel, Marc Zyngier, Arnd Bergmann, Alan Ott,
Russell King
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
Hi all,
Today's linux-next merge of the tegra tree got a conflict in
arch/arm/mach-tegra/Makefile between commit 598695a02180 ("ARM: tegra:
convert to twd_local_timer_register() interface")from the arm tree and
commits 249c5172e80a ("ARM: tegra: build localtimer support only when
needed") and 7ff43eeabd19 ("ARM: tegra: enable tegra30 clock framework")
from the tegra tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-tegra/Makefile
index f7d0443,7bea5d1..0000000
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@@ -13,9 -17,12 +17,11 @@@ obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += teg
obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += pinmux-tegra20-tables.o
obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += pinmux-tegra30-tables.o
obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += board-dt-tegra30.o
-obj-$(CONFIG_SMP) += platsmp.o headsmp.o
+obj-$(CONFIG_SMP) += platsmp.o headsmp.o
+ obj-$(CONFIG_SMP) += reset.o
-obj-$(CONFIG_LOCAL_TIMERS) += localtimer.o
+ obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30_clocks.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
- obj-$(CONFIG_TEGRA_SYSTEM_DMA) += dma.o
+ obj-$(CONFIG_TEGRA_SYSTEM_DMA) += dma.o apbio.o
obj-$(CONFIG_CPU_FREQ) += cpu-tegra.o
obj-$(CONFIG_TEGRA_PCI) += pcie.o
obj-$(CONFIG_USB_SUPPORT) += usb_phy.o
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the arm tree with Linus' tree
From: Stephen Rothwell @ 2012-03-13 0:08 UTC (permalink / raw)
To: Russell King
Cc: linux-next, linux-kernel, Catalin Marinas, Peter Zijlstra,
Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
Hi Russell,
Today's linux-next merge of the arm tree got a conflict in
kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
from the arm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc kernel/sched/core.c
index b342f57,ea13a09..0000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -1932,6 -1932,8 +1932,7 @@@ static void finish_task_switch(struct r
local_irq_enable();
#endif /* __ARCH_WANT_INTERRUPTS_ON_CTXSW */
finish_lock_switch(rq, prev);
+ finish_arch_post_lock_switch();
- trace_sched_stat_sleeptime(current, rq->clock);
fire_sched_in_preempt_notifiers(current);
if (mm)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the cpuidle-cons tree with the tip tree
From: Stephen Rothwell @ 2012-03-12 23:08 UTC (permalink / raw)
To: Steven Rostedt
Cc: Rob Lee, linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <1331572403.1149.19.camel@fedora>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
Hi Rob,
On Mon, 12 Mar 2012 13:13:23 -0400 Steven Rostedt <srostedt@redhat.com> wrote:
>
> On Mon, 2012-03-12 at 12:06 -0500, Rob Lee wrote:
>
> >
> > Looks good to me as well.
> >
> > Who should carry this fixup?
>
> I think it's trivial enough that Linus can handle it. He always said
> that he likes to fix merge conflicts and has yelled at people who did
> things to prevent them.
Yeah, I just carry it in my tree and Linus will fix it up when he merges
the trees in his.
[The assumption is that anything I can figure out so can Linus :-)]
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the cpuidle-cons tree with the arm-soc tree
From: Stephen Rothwell @ 2012-03-12 23:06 UTC (permalink / raw)
To: Rob Lee
Cc: Nicolas Ferre, Daniel Lezcano, Arnd Bergmann, linux-next,
linux-kernel, Olof Johansson, linux-arm-kernel
In-Reply-To: <CAMXH7KH_vgri3EPRvkXR+LddRUc=0ve=4u7yr51utBfgV5bF3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
Hi Rob,
On Mon, 12 Mar 2012 12:03:48 -0500 Rob Lee <rob.lee@linaro.org> wrote:
>
> On Mon, Mar 12, 2012 at 11:05 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 03/09/2012 08:37 AM, Stephen Rothwell :
> >>
> >> Today's linux-next merge of the cpuidle-cons tree got a conflict
> >> in arch/arm/mach-at91/cpuidle.c between commit 00482a4078f4 ("ARM:
> >> at91: implement the standby function for pm/cpuidle") from the
> >> arm-soc tree and commit 7a1f6e72dce1 ("ARM: at91: Consolidate time
> >> keeping and irq enable") from the cpuidle-cons tree.
> >>
> >> I fixed it up (I think - see below) and can carry the fix as
> >> necessary.
> >
> > Yes: resolution correct. Please carry it.
>
> Who should carry this fixup and related necessary at91 changes? Me?
> FYI, my at91 changes are dependent on my core cpuidle change, but my
> core cpuidle changes do not require any at91 changes as the at91 and
> other platform changes were only made to consolidate duplicate code.
I will carry the fixup and Linus will presumably do the same fix when he
merges these trees in his tree. I am not sure what you mean by "related
at91 changes".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] staging: fix powerpc linux-next break on zsmalloc
From: Marc Dietrich @ 2012-03-12 20:26 UTC (permalink / raw)
To: Seth Jennings
Cc: Greg KH, Stephen Rothwell, linux-next, linux-kernel, Nitin Gupta,
Robert Jennings
In-Reply-To: <4F5E097B.4070605@linux.vnet.ibm.com>
Hi Seth,
On Monday 12 March 2012 09:34:35 Seth Jennings wrote:
> On 02/14/2012 10:21 AM, Marc Dietrich wrote:
> > On Tuesday 14 February 2012 08:35:13 Seth Jennings wrote:
> >> On 02/14/2012 05:39 AM, Marc Dietrich wrote:
> >>> Am 14.02.2012 12:22, schrieb Marc Dietrich:
> >>>> Am 13.02.2012 15:47, schrieb Seth Jennings:
> >>>>> linux/vmalloc.h added to zsmalloc-main.c to resolve implicit
> >>>>> declaration errors.
> >>>>>
> >>>>> X86 dependency added to zsmalloc and dependent drivers zcache
> >>>>> and
> >>>>> zram.
> >>>>>
> >>>>> This X86 only requirement is not ideal. Working to find
> >>>>> portable
> >>>>> functions for __flush_tlb_one and set_pte.
> >>>>
> >>>> sorry, zcache/zram works fine one ARM here. Why not depend on
> >>>> !POWERPC?
> >>>
> >>> ups, sorry again, I tested an older version only. flush_tlb_one and
> >>> set_pte is only used with the new allocator as it seems.
> >>
> >> It would seem that the cpu-local tlb page flushing function for ARM
> >> is local_flush_tlb_kernel_page(), by look at the kmap_atomic() code
> >> in arch/arm/mm/highmem.c.
> >>
> >> So each arch is using a slightly different approach here.
> >>
> >> A simple #define per-arch could make a it a common call. I think
> >> I'm going to code it up and see how it goes.
> >
> > ... and I'm happy to test it ;-)
>
> So I have a branch ready for you to test if your are willing
>
> git://github.com/spartacus06/linux.git -b portable
ok, I took three patches I found relavant:
454bded136: staging: zsmalloc: change type of vm_area
33258b4c9d: staging: zcache: use portable cpu-local tlb flush
15959dc488: staging: add ARM/PPC64 to zcache/zram/zsmalloc Kconfig
and also backported:
cd12909cb5: xen: map foreign pages for shared rings by updating the PTEs
directly
to my 3.0 tree which has all changes for zcache/frontswap/zram/cleancache
backported from linux-next (sorry, other kernels are more hard to test on this
machine).
> The branch is based on Greg's staging-next, since my
> patches that remove the sparsemem dependency are in there.
> The frontswap_v11 patches are in that branch as well.
>
> I did a simple make test with my ARM cross compiler and it
> builds cleanly. Now I just need to know if it _works_.
>
> I'm not sure if you have been experimenting with frontswap
> since it's not in mainline yet, but you can enable/disable
> it in:
>
> Kernel Features -> Enable frontswap to cache swap pages if tmem is present
>
> Only the frontswap paths use zsmalloc right now. We are looking
> to use it for the cleancache paths too soon (I'm working on
> that now).
>
> I'd appreciate any feedback you can provide!
I enabled zram (for swap), frontswap and cleancache.
In a short test, my half proprietary display driver crashes
[ 204.951006] Unable to handle kernel NULL pointer dereference at virtual
address 00000000
[ 204.959130] pgd = c1018000
[ 204.961829] [00000000] *pgd=00000000
[ 204.965421] Internal error: Oops: 5 [#1] SMP
[ 204.969682] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat fuse
zram(C) snd_soc_alc5632 rt2800usb snd_seq_dummy rt2800lib rt2x00usb
snd_soc_tegra_pcm rt2x00lib mac80211 snd_seq_oss snd_seq_midi_event cdc_ether
snd_soc_tegra_i2s usbnet snd_soc_tegra_das snd_pcm_oss snd_soc_tegra_alc5632
cdc_wdm snd_mixer_oss mii snd_soc_core cdc_acm cfg80211 uvcvideo snd_seq
videodev snd_pcm tegra_wdt snd_seq_device snd_timer snd_soc_tegra_utils lm90
snd soundcore snd_page_alloc
[ 205.011152] CPU: 0 Tainted: G C (3.0.19 #28)
[ 205.016551] PC is at get_zspage_mapping+0x14/0x48
[ 205.021247] LR is at zs_map_object+0x60/0x1a0
[ 205.025597] pc : [<c036179c>] lr : [<c0361b70>] psr: 400f0013
[ 205.025603] sp : c3ca5978 ip : c3ca5988 fp : c3ca5984
[ 205.037062] r10: 000197c8 r9 : d86c5000 r8 : 00005045
[ 205.042275] r7 : c06ae000 r6 : dacf0000 r5 : 00000fc3 r4 : c074e8a0
[ 205.048790] r3 : 00080068 r2 : c3ca5994 r1 : c3ca5990 r0 : 00000000
[ 205.055306] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
user
[ 205.062428] Control: 10c5387d Table: 0101804a DAC: 00000015
[ 205.068164] Process plugin-containe (pid: 1771, stack limit = 0xc3ca42f8)
[ 205.074940] Stack: (0xc3ca5978 to 0xc3ca6000)
<stack snipped>
[ 205.512112] [<c036179c>] (get_zspage_mapping+0x14/0x48) from [<c0361b70>]
(zs_map_object+0x60/0x1a0)
[ 205.521247] [<c0361b70>] (zs_map_object+0x60/0x1a0) from [<bf0186a0>]
(zram_bvec_rw.isra.4+0x4b4/0x5b8 [zram])
[ 205.531262] [<bf0186a0>] (zram_bvec_rw.isra.4+0x4b4/0x5b8 [zram]) from
[<bf018c20>] (zram_make_request+0x178/0x244 [zram])
[ 205.542304] [<bf018c20>] (zram_make_request+0x178/0x244 [zram]) from
[<c0242490>] (generic_make_request+0x46c/0x504)
[ 205.552816] [<c0242490>] (generic_make_request+0x46c/0x504) from
[<c024264c>] (submit_bio+0x124/0x164)
[ 205.562117] [<c024264c>] (submit_bio+0x124/0x164) from [<c012c37c>]
(swap_writepage+0xfc/0x114)
[ 205.570818] [<c012c37c>] (swap_writepage+0xfc/0x114) from [<c010fc50>]
(shrink_page_list+0x3ec/0x810)
[ 205.580030] [<c010fc50>] (shrink_page_list+0x3ec/0x810) from [<c011046c>]
(shrink_inactive_list+0x1fc/0x3f4)
[ 205.589846] [<c011046c>] (shrink_inactive_list+0x1fc/0x3f4) from
[<c0110a50>] (shrink_zone+0x3ec/0x508)
[ 205.599230] [<c0110a50>] (shrink_zone+0x3ec/0x508) from [<c01115f4>]
(try_to_free_pages+0x188/0x434)
[ 205.608364] [<c01115f4>] (try_to_free_pages+0x188/0x434) from [<c0106e10>]
(__alloc_pages_nodemask+0x3f0/0x634)
[ 205.618450] [<c0106e10>] (__alloc_pages_nodemask+0x3f0/0x634) from
[<c02a0fc0>] (nvmap_alloc_pages_exact.constprop.4+0x4c/0x108)
[ 205.630004] [<c02a0fc0>] (nvmap_alloc_pages_exact.constprop.4+0x4c/0x108)
from [<c02a1150>] (handle_page_alloc.isra.3+0xd4/0x16c)
[ 205.641644] [<c02a1150>] (handle_page_alloc.isra.3+0xd4/0x16c) from
[<c02a1480>] (nvmap_alloc_handle_id+0x198/0x2c4)
[ 205.652156] [<c02a1480>] (nvmap_alloc_handle_id+0x198/0x2c4) from
[<c02a3184>] (nvmap_ioctl_alloc+0xa0/0xb8)
[ 205.661974] [<c02a3184>] (nvmap_ioctl_alloc+0xa0/0xb8) from [<c029fd48>]
(nvmap_ioctl+0x1b4/0x234)
[ 205.670925] [<c029fd48>] (nvmap_ioctl+0x1b4/0x234) from [<c0146734>]
(do_vfs_ioctl+0x4fc/0x570)
[ 205.679615] [<c0146734>] (do_vfs_ioctl+0x4fc/0x570) from [<c0146808>]
(sys_ioctl+0x60/0x84)
[ 205.687971] [<c0146808>] (sys_ioctl+0x60/0x84) from [<c0053dc0>]
(ret_fast_syscall+0x0/0x30)
[ 205.696399] Code: e92dd800 e24cb004 e92d4000 e8bd4000 (e5903000)
[ 205.703172] ---[ end trace 679c2bb67298abde ]---
nvmap used alloc_vm_area which got a second paramter in newer kernels. I just
replaced it with NULL, but that seems to be the wrong way. I don't want to
bother you with boring details.
I booted without the xorg driver (so the kernel interface is not used) and got
Mar 12 21:20:28 ac100 kernel: [ 118.264433] ------------[ cut here
]------------
Mar 12 21:20:28 ac100 kernel: [ 118.264523] WARNING: at
/home/marc/ac100/marvin24s-kernel/drivers/staging/zcache/zcache-main.c:755
zcache_pampd_get_data+0x88/0x14c()
Mar 12 21:20:28 ac100 kernel: [ 118.264586] Modules linked in: nls_iso8859_1
nls_cp437 vfat fat fuse zram(C) snd_soc_alc5632 snd_seq_dummy rt2800usb
rt2800lib rt2x00usb rt2x00lib snd_soc_tegra_alc5632 mac80211 snd_seq_oss
snd_soc_tegra_pcm snd_soc_tegra_i2s snd_seq_midi_event snd_soc_tegra_das
snd_soc_core snd_pcm_oss snd_mixer_oss uvcvideo videodev cfg80211 tegra_wdt
snd_seq cdc_ether usbnet snd_pcm cdc_wdm cdc_acm mii snd_seq_device lm90
snd_timer snd soundcore snd_page_alloc snd_soc_tegra_utils
Mar 12 21:20:28 ac100 kernel: [ 118.265176] [<c005acac>]
(unwind_backtrace+0x0/0xec) from [<c0444314>] (dump_stack+0x20/0x24)
Mar 12 21:20:28 ac100 kernel: [ 118.265290] [<c0444314>]
(dump_stack+0x20/0x24) from [<c00860bc>] (warn_slowpath_common+0x5c/0x74)
Mar 12 21:20:28 ac100 kernel: [ 118.265385] [<c00860bc>]
(warn_slowpath_common+0x5c/0x74) from [<c0086100>]
(warn_slowpath_null+0x2c/0x34)
Mar 12 21:20:28 ac100 kernel: [ 118.265474] [<c0086100>]
(warn_slowpath_null+0x2c/0x34) from [<c035ed9c>]
(zcache_pampd_get_data+0x88/0x14c)
Mar 12 21:20:28 ac100 kernel: [ 118.265566] [<c035ed9c>]
(zcache_pampd_get_data+0x88/0x14c) from [<c0361028>] (tmem_get+0x160/0x19c)
Mar 12 21:20:28 ac100 kernel: [ 118.265651] [<c0361028>]
(tmem_get+0x160/0x19c) from [<c035fc98>]
(zcache_get_page.constprop.16+0x8c/0xa8)
Mar 12 21:20:28 ac100 kernel: [ 118.265737] [<c035fc98>]
(zcache_get_page.constprop.16+0x8c/0xa8) from [<c035fd9c>]
(zcache_frontswap_get_page+0x90/0xa0)
Mar 12 21:20:28 ac100 kernel: [ 118.265843] [<c035fd9c>]
(zcache_frontswap_get_page+0x90/0xa0) from [<c013037c>]
(__frontswap_get_page+0x90/0xd8)
Mar 12 21:20:28 ac100 kernel: [ 118.265934] [<c013037c>]
(__frontswap_get_page+0x90/0xd8) from [<c012c3d8>] (swap_readpage+0x44/0xdc)
Mar 12 21:20:28 ac100 kernel: [ 118.266020] [<c012c3d8>]
(swap_readpage+0x44/0xdc) from [<c012c9c8>] (read_swap_cache_async+0xc8/0x11c)
Mar 12 21:20:28 ac100 kernel: [ 118.266106] [<c012c9c8>]
(read_swap_cache_async+0xc8/0x11c) from [<c012cab0>]
(swapin_readahead+0x94/0x9c)
Mar 12 21:20:28 ac100 kernel: [ 118.266204] [<c012cab0>]
(swapin_readahead+0x94/0x9c) from [<c011ff20>] (handle_pte_fault+0x2f4/0x6c4)
Mar 12 21:20:28 ac100 kernel: [ 118.266292] [<c011ff20>]
(handle_pte_fault+0x2f4/0x6c4) from [<c01203a8>] (handle_mm_fault+0xb8/0xd0)
Mar 12 21:20:28 ac100 kernel: [ 118.266382] [<c01203a8>]
(handle_mm_fault+0xb8/0xd0) from [<c005f114>] (do_page_fault+0xf8/0x28c)
Mar 12 21:20:28 ac100 kernel: [ 118.266483] [<c005f114>]
(do_page_fault+0xf8/0x28c) from [<c004e170>] (do_DataAbort+0x44/0xa8)
Mar 12 21:20:28 ac100 kernel: [ 118.266588] [<c004e170>]
(do_DataAbort+0x44/0xa8) from [<c0053d64>] (ret_from_exception+0x0/0x10)
Mar 12 21:20:28 ac100 kernel: [ 118.266645] Exception stack(0xdb86dfb0 to
0xdb86dff8)
Mar 12 21:20:28 ac100 kernel: [ 118.266697] dfa0:
b6f4cf68 b6f4e658 00000001 b6f4cee8
Mar 12 21:20:28 ac100 kernel: [ 118.266769] dfc0: 00000011 b6f4c8e8 b6f806ac
b6f4b9c0 00000001 b6f4b988 bec64998 00000011
Mar 12 21:20:28 ac100 kernel: [ 118.266835] dfe0: b6f4cf68 bec64948 b6f2fc07
b6f2fc66 200f0030 ffffffff
Mar 12 21:20:28 ac100 kernel: [ 118.266885] ---[ end trace 3a9bf99eb36a0d77
]---
Mar 12 21:20:28 ac100 kernel: [ 118.266940] kernel BUG at
/home/marc/ac100/marvin24s-kernel/drivers/staging/zcache/zcache-main.c:761!
Mar 12 21:20:28 ac100 kernel: [ 118.276268] Unable to handle kernel NULL
pointer dereference at virtual address 00000000
Mar 12 21:20:28 ac100 kernel: [ 118.284396] pgd = db2b4000
Mar 12 21:20:28 ac100 kernel: [ 118.287123] [00000000] *pgd=00000000
Mar 12 21:20:28 ac100 kernel: [ 118.290746] Internal error: Oops: 805 [#1]
SMP
Mar 12 21:20:28 ac100 kernel: [ 118.295212] Modules linked in: nls_iso8859_1
nls_cp437 vfat fat fuse zram(C) snd_soc_alc5632 snd_seq_dummy rt2800usb
rt2800lib rt2x00usb rt2x00lib snd_soc_tegra_alc5632 mac80211 snd_seq_oss
snd_soc_tegra_pcm snd_soc_tegra_i2s snd_seq_midi_event snd_soc_tegra_das
snd_soc_core snd_pcm_oss snd_mixer_oss uvcvideo videodev cfg80211 tegra_wdt
snd_seq cdc_ether usbnet snd_pcm cdc_wdm cdc_acm mii snd_seq_device lm90
snd_timer snd soundcore snd_page_alloc snd_soc_tegra_utils
Mar 12 21:20:28 ac100 kernel: [ 118.337316] CPU: 1 Tainted: G WC
(3.0.19 #29)
Mar 12 21:20:28 ac100 kernel: [ 118.342765] PC is at __bug+0x2c/0x38
Mar 12 21:20:28 ac100 kernel: [ 118.346387] LR is at
console_unlock+0x1ac/0x1c8
Mar 12 21:20:28 ac100 kernel: [ 118.350958] pc : [<c00576bc>] lr :
[<c0086c70>] psr: 600f0193
Mar 12 21:20:28 ac100 kernel: [ 118.350985] sp : db86dc50 ip : db86db68 fp
: db86dc5c
Mar 12 21:20:28 ac100 kernel: [ 118.362488] r10: 00000001 r9 : 00000000 r8
: 00000018
Mar 12 21:20:28 ac100 kernel: [ 118.367744] r7 : ffffffea r6 : 0ca61001 r5 :
d572b000 r4 : c06a8304
Mar 12 21:20:28 ac100 kernel: [ 118.374302] r3 : 00000000 r2 : 271aed0f r1
: 00000001 r0 : 0000006f
Mar 12 21:20:28 ac100 kernel: [ 118.380864] Flags: nZCv IRQs off FIQs on
Mode SVC_32 ISA ARM Segment user
Mar 12 21:20:28 ac100 kernel: [ 118.388122] Control: 10c5387d Table:
1b2b404a DAC: 00000015
Mar 12 21:20:28 ac100 kernel: [ 118.393901] Process init (pid: 1, stack limit
= 0xdb86c2f8)
Mar 12 21:20:28 ac100 kernel: [ 118.399503] Stack: (0xdb86dc50 to 0xdb86e000)
Mar 12 21:20:28 ac100 kernel: [ 118.403898] dc40:
db86dc8c db86dc60 c035ed80 c005769c
Mar 12 21:20:28 ac100 kernel: [ 118.412128] dc60: db86dc6c c0104dd8 00000000
00001000 db86dd18 daed1794 daed1000 0ca61001
Mar 12 21:20:28 ac100 kernel: [ 118.420359] dc80: db86dcd4 db86dc90 c0361028
c035ed20 daed1000 db86dd18 00000018 00000000
Mar 12 21:20:28 ac100 kernel: [ 118.428586] dca0: 00000000 c095c560 ffffffff
000f0113 daed1000 db86dd18 c095c560 00000018
Mar 12 21:20:28 ac100 kernel: [ 118.436813] dcc0: 00000000 00000000 db86dd14
db86dcd8 c035fc98 c0360ed4 db86dcec 00000000
Mar 12 21:20:28 ac100 kernel: [ 118.445038] dce0: 00000000 000200da 00000000
00001000 00000000 c095c560 0000183f 0000003f
Mar 12 21:20:28 ac100 kernel: [ 118.453266] dd00: 000000d0 c095c560 db86dd64
db86dd18 c035fd9c c035fc18 0000003f 00000000
Mar 12 21:20:28 ac100 kernel: [ 118.461488] dd20: 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000
Mar 12 21:20:28 ac100 kernel: [ 118.469716] dd40: 00000000 00000000 c05f9798
effffff0 000000c1 000200da db86dd7c db86dd68
Mar 12 21:20:28 ac100 kernel: [ 118.477944] dd60: c013037c c035fd18 c095c560
00000000 db86dd94 db86dd80 c012c3d8 c01302f8
Mar 12 21:20:28 ac100 kernel: [ 118.486171] dd80: 0000183f 00000000 db86ddc4
db86dd98 c012c9c8 c012c3a0 b6f4e000 db2f5498
Mar 12 21:20:28 ac100 kernel: [ 118.494399] dda0: 000200da 0000183f b6f4e000
db2f4d40 00000000 00000000 db86ddf4 db86ddc8
Mar 12 21:20:28 ac100 kernel: [ 118.502628] ddc0: c012cab0 c012c90c c0699498
db2f4d40 db2f4d40 db2b4000 db2f5498 b6f4e000
Mar 12 21:20:28 ac100 kernel: [ 118.510857] dde0: 00000000 00307e00 db86de44
db86ddf8 c011ff20 c012ca28 00000000 c00d5918
Mar 12 21:20:28 ac100 kernel: [ 118.519086] de00: c05d0020 db3ec580 db2f4d74
db2f4d74 0000184e 0000183f db86de34 b6f4e000
Mar 12 21:20:28 ac100 kernel: [ 118.527316] de20: db2b4000 000005b7 db2b6db8
db2f4d40 db2f5498 00000000 db86de7c db86de48
Mar 12 21:20:28 ac100 kernel: [ 118.535544] de40: c01203a8 c011fc38 db2b6db8
00000000 c025bf1c db2f5498 db86dfb0 db857a80
Mar 12 21:20:28 ac100 kernel: [ 118.543774] de60: b6f4e670 db2f4d40 db2f4d78
00000017 db86df04 db86de80 c005f114 c01202fc
Mar 12 21:20:28 ac100 kernel: [ 118.552001] de80: db86df70 00000000 00000000
db86df58 db86df3c db86dea0 c01356b0 c013e99c
Mar 12 21:20:28 ac100 kernel: [ 118.560223] dea0: 00000000 00000000 00000000
00000000 00000000 00000000 001a2000 00000000
Mar 12 21:20:28 ac100 kernel: [ 118.568449] dec0: 05802400 00000000 00001198
00000000 00004ccd 00000000 0091aee5 00000017
Mar 12 21:20:28 ac100 kernel: [ 118.576678] dee0: c05e4dec b6f4e670 db86dfb0
00000001 b6f4b988 bec64998 db86dfac db86df08
Mar 12 21:20:28 ac100 kernel: [ 118.584909] df00: c004e170 c005f028 db86df58
db857a80 db86df54 db86df20 c0089b14 c00a5f18
Mar 12 21:20:28 ac100 kernel: [ 118.593134] df20: bec64c24 00000001 00000001
bec649d0 00000000 00000003 00000000 c008aa50
Mar 12 21:20:28 ac100 kernel: [ 118.601362] df40: 00000000 bec649d0 db86dfa4
db86df58 c008aa50 c00a2394 00000003 0000000f
Mar 12 21:20:28 ac100 kernel: [ 118.609590] df60: 00000000 bec649d0 00000000
00000000 00000000 db857a80 c0088748 00100100
Mar 12 21:20:28 ac100 kernel: [ 118.617817] df80: 00200200 00000000 00000000
0000000f ffffffff b6f4c8e8 b6f806ac b6f4b9c0
Mar 12 21:20:28 ac100 kernel: [ 118.626044] dfa0: 00000000 db86dfb0 c0053d64
c004e138 b6f4cf68 b6f4e658 00000001 b6f4cee8
Mar 12 21:20:28 ac100 kernel: [ 118.634273] dfc0: 00000011 b6f4c8e8 b6f806ac
b6f4b9c0 00000001 b6f4b988 bec64998 00000011
Mar 12 21:20:28 ac100 kernel: [ 118.642503] dfe0: b6f4cf68 bec64948 b6f2fc07
b6f2fc66 200f0030 ffffffff 86950214 104188c8
Mar 12 21:20:28 ac100 kernel: [ 118.650758] [<c00576bc>] (__bug+0x2c/0x38)
from [<c035ed80>] (zcache_pampd_get_data+0x6c/0x14c)
Mar 12 21:20:28 ac100 kernel: [ 118.659532] [<c035ed80>]
(zcache_pampd_get_data+0x6c/0x14c) from [<c0361028>] (tmem_get+0x160/0x19c)
Mar 12 21:20:28 ac100 kernel: [ 118.668733] [<c0361028>]
(tmem_get+0x160/0x19c) from [<c035fc98>]
(zcache_get_page.constprop.16+0x8c/0xa8)
Mar 12 21:20:28 ac100 kernel: [ 118.678449] [<c035fc98>]
(zcache_get_page.constprop.16+0x8c/0xa8) from [<c035fd9c>]
(zcache_frontswap_get_page+0x90/0xa0)
Mar 12 21:20:28 ac100 kernel: [ 118.689483] [<c035fd9c>]
(zcache_frontswap_get_page+0x90/0xa0) from [<c013037c>]
(__frontswap_get_page+0x90/0xd8)
Mar 12 21:20:28 ac100 kernel: [ 118.699814] [<c013037c>]
(__frontswap_get_page+0x90/0xd8) from [<c012c3d8>] (swap_readpage+0x44/0xdc)
Mar 12 21:20:28 ac100 kernel: [ 118.709100] [<c012c3d8>]
(swap_readpage+0x44/0xdc) from [<c012c9c8>] (read_swap_cache_async+0xc8/0x11c)
Mar 12 21:20:28 ac100 kernel: [ 118.718560] [<c012c9c8>]
(read_swap_cache_async+0xc8/0x11c) from [<c012cab0>]
(swapin_readahead+0x94/0x9c)
Mar 12 21:20:28 ac100 kernel: [ 118.728282] [<c012cab0>]
(swapin_readahead+0x94/0x9c) from [<c011ff20>] (handle_pte_fault+0x2f4/0x6c4)
Mar 12 21:20:28 ac100 kernel: [ 118.737654] [<c011ff20>]
(handle_pte_fault+0x2f4/0x6c4) from [<c01203a8>] (handle_mm_fault+0xb8/0xd0)
Mar 12 21:20:28 ac100 kernel: [ 118.746939] [<c01203a8>]
(handle_mm_fault+0xb8/0xd0) from [<c005f114>] (do_page_fault+0xf8/0x28c)
Mar 12 21:20:28 ac100 kernel: [ 118.755884] [<c005f114>]
(do_page_fault+0xf8/0x28c) from [<c004e170>] (do_DataAbort+0x44/0xa8)
Mar 12 21:20:28 ac100 kernel: [ 118.764574] [<c004e170>]
(do_DataAbort+0x44/0xa8) from [<c0053d64>] (ret_from_exception+0x0/0x10)
Mar 12 21:20:28 ac100 kernel: [ 118.773481] Exception stack(0xdb86dfb0 to
0xdb86dff8)
Mar 12 21:20:28 ac100 kernel: [ 118.778571] dfa0:
b6f4cf68 b6f4e658 00000001 b6f4cee8
Mar 12 21:20:28 ac100 kernel: [ 118.786802] dfc0: 00000011 b6f4c8e8 b6f806ac
b6f4b9c0 00000001 b6f4b988 bec64998 00000011
Mar 12 21:20:28 ac100 kernel: [ 118.795026] dfe0: b6f4cf68 bec64948 b6f2fc07
b6f2fc66 200f0030 ffffffff
Mar 12 21:20:28 ac100 kernel: [ 118.801690] Code: e59f0010 e1a01003 eb0fb47d
e3a03000 (e5833000)
Mar 12 21:20:28 ac100 kernel: [ 118.808264] ---[ end trace 3a9bf99eb36a0d78
]---
Mar 12 21:20:28 ac100 kernel: [ 118.826844] ------------[ cut here
]------------
Mar 12 21:20:28 ac100 kernel: [ 118.831491] WARNING: at
/home/marc/ac100/marvin24s-kernel/drivers/staging/zcache/zcache-main.c:732
zcache_pampd_free+0x90/0x14c()
Mar 12 21:20:28 ac100 kernel: [ 118.843128] Modules linked in: nls_iso8859_1
nls_cp437 vfat fat fuse zram(C) snd_soc_alc5632 snd_seq_dummy rt2800usb
rt2800lib rt2x00usb rt2x00lib snd_soc_tegra_alc5632 mac80211 snd_seq_oss
snd_soc_tegra_pcm snd_soc_tegra_i2s snd_seq_midi_event snd_soc_tegra_das
snd_soc_core snd_pcm_oss snd_mixer_oss uvcvideo videodev cfg80211 tegra_wdt
snd_seq cdc_ether usbnet snd_pcm cdc_wdm cdc_acm mii snd_seq_device lm90
snd_timer snd soundcore snd_page_alloc snd_soc_tegra_utils
Mar 12 21:20:28 ac100 kernel: [ 118.884648] [<c005acac>]
(unwind_backtrace+0x0/0xec) from [<c0444314>] (dump_stack+0x20/0x24)
Mar 12 21:20:28 ac100 kernel: [ 118.893177] [<c0444314>]
(dump_stack+0x20/0x24) from [<c00860bc>] (warn_slowpath_common+0x5c/0x74)
Mar 12 21:20:28 ac100 kernel: [ 118.902131] [<c00860bc>]
(warn_slowpath_common+0x5c/0x74) from [<c0086100>]
(warn_slowpath_null+0x2c/0x34)
Mar 12 21:20:28 ac100 kernel: [ 118.911784] [<c0086100>]
(warn_slowpath_null+0x2c/0x34) from [<c035ea90>]
(zcache_pampd_free+0x90/0x14c)
Mar 12 21:20:28 ac100 kernel: [ 118.921259] [<c035ea90>]
(zcache_pampd_free+0x90/0x14c) from [<c03610f0>] (tmem_flush_page+0x8c/0xe8)
Mar 12 21:20:28 ac100 kernel: [ 118.930470] [<c03610f0>]
(tmem_flush_page+0x8c/0xe8) from [<c035fe18>]
(zcache_flush_page.constprop.17+0x6c/0x9c)
Mar 12 21:20:28 ac100 kernel: [ 118.940720] [<c035fe18>]
(zcache_flush_page.constprop.17+0x6c/0x9c) from [<c035ff0c>]
(zcache_frontswap_flush_page+0x70/0x7c)
Mar 12 21:20:28 ac100 kernel: [ 118.952020] [<c035ff0c>]
(zcache_frontswap_flush_page+0x70/0x7c) from [<c0130440>]
(__frontswap_invalidate_page+0x7c/0xe4)
Mar 12 21:20:28 ac100 kernel: [ 118.963055] [<c0130440>]
(__frontswap_invalidate_page+0x7c/0xe4) from [<c012d38c>]
(swap_entry_free+0x11c/0x158)
Mar 12 21:20:28 ac100 kernel: [ 118.973220] [<c012d38c>]
(swap_entry_free+0x11c/0x158) from [<c012ed70>]
(free_swap_and_cache+0x30/0xfc)
Mar 12 21:20:28 ac100 kernel: [ 118.982695] [<c012ed70>]
(free_swap_and_cache+0x30/0xfc) from [<c011f02c>] (unmap_vmas+0x3b4/0x5ac)
Mar 12 21:20:28 ac100 kernel: [ 118.991736] [<c011f02c>]
(unmap_vmas+0x3b4/0x5ac) from [<c0123614>] (exit_mmap+0x13c/0x254)
Mar 12 21:20:28 ac100 kernel: [ 119.000081] [<c0123614>]
(exit_mmap+0x13c/0x254) from [<c0083b38>] (mmput+0x54/0x11c)
Mar 12 21:20:28 ac100 kernel: [ 119.007908] [<c0083b38>] (mmput+0x54/0x11c)
from [<c0088488>] (exit_mm+0x16c/0x178)
Mar 12 21:20:28 ac100 kernel: [ 119.015573] [<c0088488>]
(exit_mm+0x16c/0x178) from [<c008a088>] (do_exit+0x218/0x710)
Mar 12 21:20:28 ac100 kernel: [ 119.023489] [<c008a088>]
(do_exit+0x218/0x710) from [<c0057c8c>] (die+0x2e0/0x338)
Mar 12 21:20:28 ac100 kernel: [ 119.031057] [<c0057c8c>] (die+0x2e0/0x338)
from [<c04443bc>] (__do_kernel_fault.part.3+0x64/0x84)
Mar 12 21:20:28 ac100 kernel: [ 119.039925] [<c04443bc>]
(__do_kernel_fault.part.3+0x64/0x84) from [<c005f28c>]
(do_page_fault+0x270/0x28c)
Mar 12 21:20:28 ac100 kernel: [ 119.049656] [<c005f28c>]
(do_page_fault+0x270/0x28c) from [<c005f364>] (do_translation_fault+0x2c/0xb0)
Mar 12 21:20:28 ac100 kernel: [ 119.059046] [<c005f364>]
(do_translation_fault+0x2c/0xb0) from [<c004e170>] (do_DataAbort+0x44/0xa8)
Mar 12 21:20:28 ac100 kernel: [ 119.068175] [<c004e170>]
(do_DataAbort+0x44/0xa8) from [<c005392c>] (__dabt_svc+0x4c/0x60)
Mar 12 21:20:28 ac100 kernel: [ 119.076427] Exception stack(0xdb86dc08 to
0xdb86dc50)
Mar 12 21:20:28 ac100 kernel: [ 119.081470] dc00: 0000006f
00000001 271aed0f 00000000 c06a8304 d572b000
Mar 12 21:20:28 ac100 kernel: [ 119.089637] dc20: 0ca61001 ffffffea 00000018
00000000 00000001 db86dc5c db86db68 db86dc50
Mar 12 21:20:28 ac100 kernel: [ 119.097800] dc40: c0086c70 c00576bc 600f0193
ffffffff
Mar 12 21:20:28 ac100 kernel: [ 119.102849] [<c005392c>]
(__dabt_svc+0x4c/0x60) from [<c00576bc>] (__bug+0x2c/0x38)
Mar 12 21:20:28 ac100 kernel: [ 119.110498] [<c00576bc>] (__bug+0x2c/0x38)
from [<c035ed80>] (zcache_pampd_get_data+0x6c/0x14c)
Mar 12 21:20:28 ac100 kernel: [ 119.119189] [<c035ed80>]
(zcache_pampd_get_data+0x6c/0x14c) from [<c0361028>] (tmem_get+0x160/0x19c)
Mar 12 21:20:28 ac100 kernel: [ 119.128313] [<c0361028>]
(tmem_get+0x160/0x19c) from [<c035fc98>]
(zcache_get_page.constprop.16+0x8c/0xa8)
Mar 12 21:20:28 ac100 kernel: [ 119.137957] [<c035fc98>]
(zcache_get_page.constprop.16+0x8c/0xa8) from [<c035fd9c>]
(zcache_frontswap_get_page+0x90/0xa0)
Mar 12 21:20:28 ac100 kernel: [ 119.148904] [<c035fd9c>]
(zcache_frontswap_get_page+0x90/0xa0) from [<c013037c>]
(__frontswap_get_page+0x90/0xd8)
Mar 12 21:20:28 ac100 kernel: [ 119.159156] [<c013037c>]
(__frontswap_get_page+0x90/0xd8) from [<c012c3d8>] (swap_readpage+0x44/0xdc)
Mar 12 21:20:28 ac100 kernel: [ 119.168368] [<c012c3d8>]
(swap_readpage+0x44/0xdc) from [<c012c9c8>] (read_swap_cache_async+0xc8/0x11c)
Mar 12 21:20:28 ac100 kernel: [ 119.177753] [<c012c9c8>]
(read_swap_cache_async+0xc8/0x11c) from [<c012cab0>]
(swapin_readahead+0x94/0x9c)
Mar 12 21:20:28 ac100 kernel: [ 119.187398] [<c012cab0>]
(swapin_readahead+0x94/0x9c) from [<c011ff20>] (handle_pte_fault+0x2f4/0x6c4)
Mar 12 21:20:28 ac100 kernel: [ 119.196696] [<c011ff20>]
(handle_pte_fault+0x2f4/0x6c4) from [<c01203a8>] (handle_mm_fault+0xb8/0xd0)
Mar 12 21:20:28 ac100 kernel: [ 119.205905] [<c01203a8>]
(handle_mm_fault+0xb8/0xd0) from [<c005f114>] (do_page_fault+0xf8/0x28c)
Mar 12 21:20:28 ac100 kernel: [ 119.214769] [<c005f114>]
(do_page_fault+0xf8/0x28c) from [<c004e170>] (do_DataAbort+0x44/0xa8)
Mar 12 21:20:28 ac100 kernel: [ 119.223375] [<c004e170>]
(do_DataAbort+0x44/0xa8) from [<c0053d64>] (ret_from_exception+0x0/0x10)
Mar 12 21:20:28 ac100 kernel: [ 119.232231] Exception stack(0xdb86dfb0 to
0xdb86dff8)
Mar 12 21:20:28 ac100 kernel: [ 119.237273] dfa0:
b6f4cf68 b6f4e658 00000001 b6f4cee8
Mar 12 21:20:28 ac100 kernel: [ 119.245441] dfc0: 00000011 b6f4c8e8 b6f806ac
b6f4b9c0 00000001 b6f4b988 bec64998 00000011
Mar 12 21:20:28 ac100 kernel: [ 119.253606] dfe0: b6f4cf68 bec64948 b6f2fc07
b6f2fc66 200f0030 ffffffff
Mar 12 21:20:28 ac100 kernel: [ 119.260209] ---[ end trace 3a9bf99eb36a0d79
]---
Mar 12 21:20:28 ac100 kernel: [ 119.264943] ------------[ cut here
]------------
Mar 12 21:20:29 ac100 kernel: [ 119.269578] WARNING: at
/home/marc/ac100/marvin24s-kernel/drivers/staging/zcache/zcache-main.c:732
zcache_pampd_free+0x90/0x14c()
Mar 12 21:20:29 ac100 kernel: [ 119.281213] Modules linked in: nls_iso8859_1
nls_cp437 vfat fat fuse zram(C) snd_soc_alc5632 snd_seq_dummy rt2800usb
rt2800lib rt2x00usb rt2x00lib snd_soc_tegra_alc5632 mac80211 snd_seq_oss
snd_soc_tegra_pcm snd_soc_tegra_i2s snd_seq_midi_event snd_soc_tegra_das
snd_soc_core snd_pcm_oss snd_mixer_oss uvcvideo videodev cfg80211 tegra_wdt
snd_seq cdc_ether usbnet snd_pcm cdc_wdm cdc_acm mii snd_seq_device lm90
snd_timer snd soundcore snd_page_alloc snd_soc_tegra_utils
Mar 12 21:20:29 ac100 kernel: [ 119.322726] [<c005acac>]
(unwind_backtrace+0x0/0xec) from [<c0444314>] (dump_stack+0x20/0x24)
Mar 12 21:20:29 ac100 kernel: [ 119.331253] [<c0444314>]
(dump_stack+0x20/0x24) from [<c00860bc>] (warn_slowpath_common+0x5c/0x74)
Mar 12 21:20:29 ac100 kernel: [ 119.340205] [<c00860bc>]
(warn_slowpath_common+0x5c/0x74) from [<c0086100>]
(warn_slowpath_null+0x2c/0x34)
Mar 12 21:20:29 ac100 kernel: [ 119.349855] [<c0086100>]
(warn_slowpath_null+0x2c/0x34) from [<c035ea90>]
(zcache_pampd_free+0x90/0x14c)
Mar 12 21:20:29 ac100 kernel: [ 119.359329] [<c035ea90>]
(zcache_pampd_free+0x90/0x14c) from [<c03610f0>] (tmem_flush_page+0x8c/0xe8)
Mar 12 21:20:29 ac100 kernel: [ 119.368540] [<c03610f0>]
(tmem_flush_page+0x8c/0xe8) from [<c035fe18>]
(zcache_flush_page.constprop.17+0x6c/0x9c)
Mar 12 21:20:29 ac100 kernel: [ 119.378794] [<c035fe18>]
(zcache_flush_page.constprop.17+0x6c/0x9c) from [<c035ff0c>]
(zcache_frontswap_flush_page+0x70/0x7c)
Mar 12 21:20:29 ac100 kernel: [ 119.390096] [<c035ff0c>]
(zcache_frontswap_flush_page+0x70/0x7c) from [<c0130440>]
(__frontswap_invalidate_page+0x7c/0xe4)
Mar 12 21:20:29 ac100 kernel: [ 119.401133] [<c0130440>]
(__frontswap_invalidate_page+0x7c/0xe4) from [<c012d38c>]
(swap_entry_free+0x11c/0x158)
Mar 12 21:20:29 ac100 kernel: [ 119.411300] [<c012d38c>]
(swap_entry_free+0x11c/0x158) from [<c012ed70>]
(free_swap_and_cache+0x30/0xfc)
Mar 12 21:20:29 ac100 kernel: [ 119.420774] [<c012ed70>]
(free_swap_and_cache+0x30/0xfc) from [<c011f02c>] (unmap_vmas+0x3b4/0x5ac)
Mar 12 21:20:29 ac100 kernel: [ 119.429815] [<c011f02c>]
(unmap_vmas+0x3b4/0x5ac) from [<c0123614>] (exit_mmap+0x13c/0x254)
Mar 12 21:20:29 ac100 kernel: [ 119.438161] [<c0123614>]
(exit_mmap+0x13c/0x254) from [<c0083b38>] (mmput+0x54/0x11c)
Mar 12 21:20:29 ac100 kernel: [ 119.445987] [<c0083b38>] (mmput+0x54/0x11c)
from [<c0088488>] (exit_mm+0x16c/0x178)
Mar 12 21:20:29 ac100 kernel: [ 119.453638] [<c0088488>]
(exit_mm+0x16c/0x178) from [<c008a088>] (do_exit+0x218/0x710)
Mar 12 21:20:29 ac100 kernel: [ 119.461549] [<c008a088>]
(do_exit+0x218/0x710) from [<c0057c8c>] (die+0x2e0/0x338)
Mar 12 21:20:29 ac100 kernel: [ 119.469113] [<c0057c8c>] (die+0x2e0/0x338)
from [<c04443bc>] (__do_kernel_fault.part.3+0x64/0x84)
Mar 12 21:20:29 ac100 kernel: [ 119.477982] [<c04443bc>]
(__do_kernel_fault.part.3+0x64/0x84) from [<c005f28c>]
(do_page_fault+0x270/0x28c)
Mar 12 21:20:29 ac100 kernel: [ 119.487715] [<c005f28c>]
(do_page_fault+0x270/0x28c) from [<c005f364>] (do_translation_fault+0x2c/0xb0)
Mar 12 21:20:29 ac100 kernel: [ 119.497105] [<c005f364>]
(do_translation_fault+0x2c/0xb0) from [<c004e170>] (do_DataAbort+0x44/0xa8)
Mar 12 21:20:29 ac100 kernel: [ 119.506236] [<c004e170>]
(do_DataAbort+0x44/0xa8) from [<c005392c>] (__dabt_svc+0x4c/0x60)
Mar 12 21:20:29 ac100 kernel: [ 119.514486] Exception stack(0xdb86dc08 to
0xdb86dc50)
Mar 12 21:20:29 ac100 kernel: [ 119.519530] dc00: 0000006f
00000001 271aed0f 00000000 c06a8304 d572b000
Mar 12 21:20:29 ac100 kernel: [ 119.527698] dc20: 0ca61001 ffffffea 00000018
00000000 00000001 db86dc5c db86db68 db86dc50
Mar 12 21:20:29 ac100 kernel: [ 119.535862] dc40: c0086c70 c00576bc 600f0193
ffffffff
Mar 12 21:20:29 ac100 kernel: [ 119.540910] [<c005392c>]
(__dabt_svc+0x4c/0x60) from [<c00576bc>] (__bug+0x2c/0x38)
Mar 12 21:20:29 ac100 kernel: [ 119.548560] [<c00576bc>] (__bug+0x2c/0x38)
from [<c035ed80>] (zcache_pampd_get_data+0x6c/0x14c)
Mar 12 21:20:29 ac100 kernel: [ 119.557251] [<c035ed80>]
(zcache_pampd_get_data+0x6c/0x14c) from [<c0361028>] (tmem_get+0x160/0x19c)
Mar 12 21:20:29 ac100 kernel: [ 119.566375] [<c0361028>]
(tmem_get+0x160/0x19c) from [<c035fc98>]
(zcache_get_page.constprop.16+0x8c/0xa8)
Mar 12 21:20:29 ac100 kernel: [ 119.576018] [<c035fc98>]
(zcache_get_page.constprop.16+0x8c/0xa8) from [<c035fd9c>]
(zcache_frontswap_get_page+0x90/0xa0)
Mar 12 21:20:29 ac100 kernel: [ 119.586964] [<c035fd9c>]
(zcache_frontswap_get_page+0x90/0xa0) from [<c013037c>]
(__frontswap_get_page+0x90/0xd8)
Mar 12 21:20:29 ac100 kernel: [ 119.597216] [<c013037c>]
(__frontswap_get_page+0x90/0xd8) from [<c012c3d8>] (swap_readpage+0x44/0xdc)
Mar 12 21:20:29 ac100 kernel: [ 119.606427] [<c012c3d8>]
(swap_readpage+0x44/0xdc) from [<c012c9c8>] (read_swap_cache_async+0xc8/0x11c)
Mar 12 21:20:29 ac100 kernel: [ 119.615812] [<c012c9c8>]
(read_swap_cache_async+0xc8/0x11c) from [<c012cab0>]
(swapin_readahead+0x94/0x9c)
Mar 12 21:20:29 ac100 kernel: [ 119.625457] [<c012cab0>]
(swapin_readahead+0x94/0x9c) from [<c011ff20>] (handle_pte_fault+0x2f4/0x6c4)
Mar 12 21:20:29 ac100 kernel: [ 119.634755] [<c011ff20>]
(handle_pte_fault+0x2f4/0x6c4) from [<c01203a8>] (handle_mm_fault+0xb8/0xd0)
Mar 12 21:20:29 ac100 kernel: [ 119.643966] [<c01203a8>]
(handle_mm_fault+0xb8/0xd0) from [<c005f114>] (do_page_fault+0xf8/0x28c)
Mar 12 21:20:29 ac100 kernel: [ 119.652830] [<c005f114>]
(do_page_fault+0xf8/0x28c) from [<c004e170>] (do_DataAbort+0x44/0xa8)
Mar 12 21:20:29 ac100 kernel: [ 119.661434] [<c004e170>]
(do_DataAbort+0x44/0xa8) from [<c0053d64>] (ret_from_exception+0x0/0x10)
Mar 12 21:20:29 ac100 kernel: [ 119.670289] Exception stack(0xdb86dfb0 to
0xdb86dff8)
Mar 12 21:20:29 ac100 kernel: [ 119.675331] dfa0:
b6f4cf68 b6f4e658 00000001 b6f4cee8
Mar 12 21:20:29 ac100 kernel: [ 119.683497] dfc0: 00000011 b6f4c8e8 b6f806ac
b6f4b9c0 00000001 b6f4b988 bec64998 00000011
Mar 12 21:20:29 ac100 kernel: [ 119.691661] dfe0: b6f4cf68 bec64948 b6f2fc07
b6f2fc66 200f0030 ffffffff
Mar 12 21:20:29 ac100 kernel: [ 119.698262] ---[ end trace 3a9bf99eb36a0d7a
]---
It's possible that the 3.0 doesn't like the driver from linux-next, but maybe
you have some other idea.
Thanks!
Marc
^ permalink raw reply
* Re: rtl2830: __udivdi3 undefined
From: Antti Palosaari @ 2012-03-12 19:58 UTC (permalink / raw)
To: gennarone
Cc: Geert Uytterhoeven, linux-media, Mauro Carvalho Chehab,
Linux-Next
In-Reply-To: <4F53EA7D.4090402@gmail.com>
On 05.03.2012 00:19, Gianluca Gennari wrote:
> Il 29/02/2012 22:30, Geert Uytterhoeven ha scritto:
>> http://kisskb.ellerman.id.au/kisskb/buildresult/5759200/ ERROR:
>> "__udivdi3" [drivers/media/dvb/frontends/rtl2830.ko] undefined!
>>
>> I didn't look too deeply into it, but I think it's caused by the
>> "num /= priv->cfg.xtal" in rtl2830_init() (with num being u64).
>>
>> Can't it use do_div() instead?
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>> geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a
>> hacker. But when I'm talking to journalists I just say "programmer"
>> or something like that. -- Linus Torvalds -- To unsubscribe from this
>> list: send the line "unsubscribe linux-media" in the body of a
>> message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>>
>
> Probably the best solution is to use div_u64.
> The following patch fixed the warning on my 32 bit system.
>
> Signed-off-by: Gianluca Gennari<gennarone@gmail.com>
> ---
> drivers/media/dvb/frontends/rtl2830.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/dvb/frontends/rtl2830.c
> b/drivers/media/dvb/frontends/rtl2830.c
> index f971d94..45196c5 100644
> --- a/drivers/media/dvb/frontends/rtl2830.c
> +++ b/drivers/media/dvb/frontends/rtl2830.c
> @@ -244,7 +244,7 @@ static int rtl2830_init(struct dvb_frontend *fe)
>
> num = priv->cfg.if_dvbt % priv->cfg.xtal;
> num *= 0x400000;
> - num /= priv->cfg.xtal;
> + num = div_u64(num, priv->cfg.xtal);
> num = -num;
> if_ctl = num& 0x3fffff;
> dbg("%s: if_ctl=%08x", __func__, if_ctl);
Acked-by: Antti Palosaari <crope@iki.fi>
I have been two weeks on skiing trip and since didn't acked that earlier.
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply
* Re: linux-next: manual merge of the cpuidle-cons tree with the tip tree
From: Steven Rostedt @ 2012-03-12 17:13 UTC (permalink / raw)
To: Rob Lee
Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
In-Reply-To: <CAMXH7KHdfzjZCsBMkFOnwYtyaqBztMY99QcZ7VwLP0JASUiVAw@mail.gmail.com>
On Mon, 2012-03-12 at 12:06 -0500, Rob Lee wrote:
>
> Looks good to me as well.
>
> Who should carry this fixup?
I think it's trivial enough that Linus can handle it. He always said
that he likes to fix merge conflicts and has yelled at people who did
things to prevent them.
-- Steve
^ permalink raw reply
* Re: linux-next: manual merge of the cpuidle-cons tree with the tip tree
From: Rob Lee @ 2012-03-12 17:06 UTC (permalink / raw)
To: Steven Rostedt, Stephen Rothwell
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <1331300109.1149.17.camel@fedora>
Steven and Stephen,
On Fri, Mar 9, 2012 at 7:35 AM, Steven Rostedt <srostedt@redhat.com> wrote:
> On Fri, 2012-03-09 at 18:40 +1100, Stephen Rothwell wrote:
>> diff --cc drivers/cpuidle/cpuidle.c
>> index 6588f43,56de5f7..0000000
>> --- a/drivers/cpuidle/cpuidle.c
>> +++ b/drivers/cpuidle/cpuidle.c
>> @@@ -92,15 -109,13 +109,13 @@@ int cpuidle_idle_call(void
>> return 0;
>> }
>>
>> - target_state = &drv->states[next_state];
>> -
>> - trace_power_start(POWER_CSTATE, next_state, dev->cpu);
>> - trace_cpu_idle(next_state, dev->cpu);
>> + trace_power_start_rcuidle(POWER_CSTATE, next_state, dev->cpu);
>> + trace_cpu_idle_rcuidle(next_state, dev->cpu);
>>
>> - entered_state = target_state->enter(dev, drv, next_state);
>> + entered_state = cpuidle_enter_ops(dev, drv, next_state);
>>
>> - trace_power_end(dev->cpu);
>> - trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu);
>> + trace_power_end_rcuidle(dev->cpu);
>> + trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
>>
>
> Looks good. My change was just a rename of trace_power_* and
> trace_cpu_*, and it looks like another change was the clean up of
> target_state. This is a trivial conflict, and there should be no
> surprises here.
>
> -- Steve
>
Looks good to me as well.
Who should carry this fixup?
Best Regards,
Rob
>
>
>> if (entered_state >= 0) {
>> /* Update cpuidle counters */
>
^ permalink raw reply
* Re: linux-next: manual merge of the cpuidle-cons tree with the arm-soc tree
From: Rob Lee @ 2012-03-12 17:03 UTC (permalink / raw)
To: Nicolas Ferre, Stephen Rothwell, Daniel Lezcano, Arnd Bergmann
Cc: linux-next, linux-kernel, Olof Johansson, linux-arm-kernel
In-Reply-To: <4F5E1ECC.1040605@atmel.com>
Arnd, Stephen, Nicolas, Daniel,
On Mon, Mar 12, 2012 at 11:05 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/09/2012 08:37 AM, Stephen Rothwell :
>> Hi Rob,
>>
>> Today's linux-next merge of the cpuidle-cons tree got a conflict
>> in arch/arm/mach-at91/cpuidle.c between commit 00482a4078f4 ("ARM:
>> at91: implement the standby function for pm/cpuidle") from the
>> arm-soc tree and commit 7a1f6e72dce1 ("ARM: at91: Consolidate time
>> keeping and irq enable") from the cpuidle-cons tree.
>>
>> I fixed it up (I think - see below) and can carry the fix as
>> necessary.
>
> Yes: resolution correct. Please carry it.
>
Who should carry this fixup and related necessary at91 changes? Me?
FYI, my at91 changes are dependent on my core cpuidle change, but my
core cpuidle changes do not require any at91 changes as the at91 and
other platform changes were only made to consolidate duplicate code.
Best Regards,
Rob
> Thanks to Rob and Daniel for their answers.
>
Thank you as well Nicolas.
> Best regards,
> - --
> Nicolas Ferre
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPXh7HAAoJEAf03oE53VmQSQwH/15D3okPxJSEiH0k8IFt6Df0
> RDY/CdaGYDllGMq7Yc1LiQAPrlHkv+gFNAJkhH8aJvC603pYBFGIa5IPLeZEE+XD
> MkXiO7pQAOdGtojqSrZI8Sp0kxtfdR6QlNu5o518yvlKIkxbWJoXdVty9+MuciOv
> GOR+164hJtlr4fLLg7bTzsdnxquDVBBbks9qLhSYEQBEuNkgXKgNfdMouwVI/Zuj
> sX9DSKnVVm5LS/rrq888JRPPtBf8/HkmOeFRWKktq7Q8WldQbBI79vj01osH++jf
> rwDiM/CSC0nhXY0IWEof+Hz1mSinM07XGZglDYwqI1ca7HId2C/txaFI3NtcC7A=
> =rZpG
> -----END PGP SIGNATURE-----
^ permalink raw reply
* Re: linux-next: manual merge of the cpuidle-cons tree with the arm-soc tree
From: Nicolas Ferre @ 2012-03-12 16:05 UTC (permalink / raw)
To: Stephen Rothwell, Rob Lee, Daniel Lezcano
Cc: linux-next, linux-kernel, Olof Johansson, Arnd Bergmann,
linux-arm-kernel
In-Reply-To: <20120309183732.512d3676599da324f4747219@canb.auug.org.au>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/09/2012 08:37 AM, Stephen Rothwell :
> Hi Rob,
>
> Today's linux-next merge of the cpuidle-cons tree got a conflict
> in arch/arm/mach-at91/cpuidle.c between commit 00482a4078f4 ("ARM:
> at91: implement the standby function for pm/cpuidle") from the
> arm-soc tree and commit 7a1f6e72dce1 ("ARM: at91: Consolidate time
> keeping and irq enable") from the cpuidle-cons tree.
>
> I fixed it up (I think - see below) and can carry the fix as
> necessary.
Yes: resolution correct. Please carry it.
Thanks to Rob and Daniel for their answers.
Best regards,
- --
Nicolas Ferre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPXh7HAAoJEAf03oE53VmQSQwH/15D3okPxJSEiH0k8IFt6Df0
RDY/CdaGYDllGMq7Yc1LiQAPrlHkv+gFNAJkhH8aJvC603pYBFGIa5IPLeZEE+XD
MkXiO7pQAOdGtojqSrZI8Sp0kxtfdR6QlNu5o518yvlKIkxbWJoXdVty9+MuciOv
GOR+164hJtlr4fLLg7bTzsdnxquDVBBbks9qLhSYEQBEuNkgXKgNfdMouwVI/Zuj
sX9DSKnVVm5LS/rrq888JRPPtBf8/HkmOeFRWKktq7Q8WldQbBI79vj01osH++jf
rwDiM/CSC0nhXY0IWEof+Hz1mSinM07XGZglDYwqI1ca7HId2C/txaFI3NtcC7A=
=rZpG
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] staging: fix powerpc linux-next break on zsmalloc
From: Seth Jennings @ 2012-03-12 14:34 UTC (permalink / raw)
To: Marc Dietrich
Cc: Greg KH, Stephen Rothwell, linux-next, linux-kernel, Nitin Gupta,
Robert Jennings
In-Reply-To: <5736714.Unq6oKkpjO@ax5200p>
Hey Marc,
On 02/14/2012 10:21 AM, Marc Dietrich wrote:
> Hi Seth,
>
> On Tuesday 14 February 2012 08:35:13 Seth Jennings wrote:
>> On 02/14/2012 05:39 AM, Marc Dietrich wrote:
>>> Am 14.02.2012 12:22, schrieb Marc Dietrich:
>>>> Am 13.02.2012 15:47, schrieb Seth Jennings:
>>>>> linux/vmalloc.h added to zsmalloc-main.c to resolve implicit
>>>>> declaration errors.
>>>>>
>>>>> X86 dependency added to zsmalloc and dependent drivers zcache and
>>>>> zram.
>>>>>
>>>>> This X86 only requirement is not ideal. Working to find portable
>>>>> functions for __flush_tlb_one and set_pte.
>>>>
>>>> sorry, zcache/zram works fine one ARM here. Why not depend on
>>>> !POWERPC?
>>>
>>> ups, sorry again, I tested an older version only. flush_tlb_one and
>>> set_pte is only used with the new allocator as it seems.
>>
>> It would seem that the cpu-local tlb page flushing function for ARM
>> is local_flush_tlb_kernel_page(), by look at the kmap_atomic() code
>> in arch/arm/mm/highmem.c.
>>
>> So each arch is using a slightly different approach here.
>>
>> A simple #define per-arch could make a it a common call. I think
>> I'm going to code it up and see how it goes.
>
> ... and I'm happy to test it ;-)
So I have a branch ready for you to test if your are willing
git://github.com/spartacus06/linux.git -b portable
The branch is based on Greg's staging-next, since my
patches that remove the sparsemem dependency are in there.
The frontswap_v11 patches are in that branch as well.
I did a simple make test with my ARM cross compiler and it
builds cleanly. Now I just need to know if it _works_.
I'm not sure if you have been experimenting with frontswap
since it's not in mainline yet, but you can enable/disable
it in:
Kernel Features -> Enable frontswap to cache swap pages if tmem is present
Only the frontswap paths use zsmalloc right now. We are looking
to use it for the cleancache paths too soon (I'm working on
that now).
I'd appreciate any feedback you can provide!
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH] crypto: fix build failure in mv_cesa.c (missing of header)
From: Jason @ 2012-03-12 2:32 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: michael, linux-crypto, linux-next
In-Reply-To: <CAP=VYLpm9B7i9MSGTc4ogVPACmC3J1SVtNDugoYop5mJ8gLb9g@mail.gmail.com>
On Sun, Mar 11, 2012 at 12:17:29PM -0400, Paul Gortmaker wrote:
> On Sat, Mar 10, 2012 at 8:42 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Fri, Mar 09, 2012 at 02:58:25PM -0500, Paul Gortmaker wrote:
> >> Commit 737b75872487f560397ba34846a19823b1addf88 (linux-next)
> >>
> >> "ARM: kirkwood: mv_cesa devicetree bindings"
> >>
> >> fails to compile as follows:
> >>
> >> CC drivers/crypto/mv_cesa.o
> >> drivers/crypto/mv_cesa.c:1139: error: implicit declaration of function 'of_match_ptr'
> >> drivers/crypto/mv_cesa.c:1139: error: 'mv_cesa_dt_ids' undeclared here (not in a function)
> >> drivers/crypto/mv_cesa.c:1139: error: initializer element is not constant
> >> drivers/crypto/mv_cesa.c:1139: error: (near initialization for 'marvell_crypto.driver.of_match_table')
> >>
> >> because it is missing the linux/of.h header file.
> >>
> >> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> >
> > Paul,
> >
> > Thanks for the patch. Unfortunately, I'm not learning fast enough. ;-)
> > This series has been in a lot of flux lately, as you've experienced.
> >
> > The good news is, after talking with Olaf and Arnd, I think I have a
> > good workflow figured out. Hopefully, failures like this won't happen
> > in the future.
>
> Sounds good -- don't be too hard on yourself wrt. a minor breakage.
> Feel free to just squish the above patch into whatever updates you
> have going. I don't see it needing to exist as a standalone commit.
Thanks, it's definitely better that it be squashed into the existing
commit. I wouldn't want a bisect to land in between it down the road.
thx,
Jason.
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Paul Mundt @ 2012-03-12 1:12 UTC (permalink / raw)
To: Rob Herring
Cc: Benjamin Herrenschmidt, Russell King, Stephen Rothwell,
Michael Neuling, Paul Mackerras, linuxppc-dev, linux-next,
linux-kernel, Grant Likely, linux-sh
In-Reply-To: <4F5A350F.3090905@calxeda.com>
On Fri, Mar 09, 2012 at 10:51:27AM -0600, Rob Herring wrote:
> On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote:
> > On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
> >> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> >>> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> >>> I remove it, then I get Kconfig warnings:
> >>>
> >>> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> >>> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
> >>
> >> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
> >
> > Nope, Grant patch didn't mention a dependency.
>
> My opinion is that SPARSE_IRQ shouldn't be user visible option, and the
> simple solution was to just make it hidden. It wasn't clear if this was
> desired or not for other arches at the time. There is a mixture of
> settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves
> it user selectable for 64-bit.
>
> I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ
> a hidden option. It really just needs the okay from SuperH folks.
>
We basically want it always-enabled for 32-bit and it doesn't matter much
about 64-bit. In the future I'll probably fix up the 64-bit stuff to use
it too and then we'll just leave it on all the time, but it's not such a
big deal if it's not visible for enabling on 64-bit at the moment given
that it's probably broken there at the moment.
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the powerpc tree
From: David Miller @ 2012-03-11 22:56 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, benh, paulus, linuxppc-dev, joe
In-Reply-To: <20120309174416.2b936c5a4a116d56f9a25502@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 9 Mar 2012 17:44:16 +1100
> On Thu, 08 Mar 2012 22:15:34 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Fri, 9 Mar 2012 13:36:46 +1100
>>
>> > Today's linux-next merge of the net-next tree got a conflict in
>> > drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
>> > ("net: powerpc: remove the legacy iSeries ethernet driver") from the
>> > powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
>> > error messages") from the net-next tree.
>> >
>> > I just removed the file.
>>
>> If it makes life easier for anyone I can put the driver removal patch
>> into net-next.
>
> In this case, I think it will actually help, thanks. Note that it won;t
> apply cleanly to your tree, but the fixup is easy :-)
>
> And I discovered that "git am" doesn't like the style of patch I did
> (without the body of the deleted file). If you just delete
> drivers/net/ethernet/ibm/iseries_veth.c before trying to apply the patch
> it will probably work.
I took care of this the other night.
^ permalink raw reply
* Re: fix for "error: implicit declaration of function 'devres_alloc'" in Mar9 tree
From: Mark Brown @ 2012-03-11 19:32 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-next
In-Reply-To: <CAP=VYLoSgAdL6VzJE_gG0mFbb+cAjsEiHGp6gbhMo6Zx4=3dbA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3914 bytes --]
On Sun, Mar 11, 2012 at 12:09:39PM -0400, Paul Gortmaker wrote:
> On Sun, Mar 11, 2012 at 8:48 AM, Mark Brown
> > On Fri, Mar 09, 2012 at 10:11:56AM -0500, Paul Gortmaker wrote:
> >> This is caused by commit 19694b5ea1d3 which just appeared in today's next
> >> tree exposing another implicit device.h user. Just a quick note that I'll
> >> take care of it by adding regmap.c to the below commit.
> > relied on here. You've gone and deleted that inclusion without CCing
> > the patch to the subsystem and now you're sending a fix again without a
> > CC to either me or the relevant list, and without even a mention in the
> > subject line.
> We are talking about a trivial fix here, and the deletion was one of about
> fifty similar one-line deletions in include/linux, of which many files don't
> even have clear owners. So, while I can appreciate you wanting a CC,
> it just wasn't practical in this case in my opinion.
The above doesn't just apply to the original patch, it applies even more
strongly to the followup patch where none of the above issues apply.
Honestly I do think that if you made at least some effort to let
subsytem maintainers know about all this header reorganisation you're
doing you'd introduce a lot less breakage, it's hardly surprising that
people keep on developing with the headers they can see.
> > In order to avoid bisection breakage I've applied one of the several
> > fixes for this that were sent to me today, please drop your change.
> I don't see how this avoids any bisection breakage -- you've now introduced
> a dependency that wasn't there before -- i.e. I would have to make sure
> your change is present before my changes get pulled. In any case I can
> just ensure I have the exact same change as you and it will make sure
> my series remains bisectable.
It will be fine, there's no dependency. If regmap is merged first
there's obviously no issue as it doesn't have your header faffing in.
If regmap is merged second then the branch that gets pulled will have
Stephen's change applied to it before it gets Linus' tree so no commit
will exist where we've only got your commit which introduces the problem
and no fix. On the other hand an incremental fix in your tree only
means that if your tree is merged second there will be at least one
commit which is broken.
This applies to any fixups for the fallout from your changes, except in
very rare circumstances adding the extra includes is always going to be
safe in any tree and this means that people working in the tree can see
what's going to be happening, making things less error prone.
> > This stuff would go a lot more smoothly if you were to at least let
> > people know when you make changes, especially when issues introduced by
> > your changes get noticed.
> I've worked to get at least three different regulator regression fixes in,
> None of those were related to any changes I made. You were on the
> to/CC of those fixes, and I even made changes as you requested. My
> point is that I do my best to follow implicit and explicit processes. If
> you've somehow come to conclude otherwise, I'm sorry to hear that.
If you'd CCed me when you noticed the additional breakage from your
change or you'd written followups to the people submitting fixes
normally which said something like "This is due to more header
reorganisations I've done, I've fixed it on my branch see X for details"
things would've worked better.
As it is I was seeing fixes from people which made no sense given the
recent activity in the tree plus followups from you which had no content
other than links (which isn't good practice) to a message which itself
just references git changes things by hash (which is quite bad, commit
IDs aren't directly legible and can change) and had to faff around with
the logs to figure out what you'd done.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Mar 9 (netfilter)
From: Pablo Neira Ayuso @ 2012-03-11 16:58 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, netdev,
netfilter-devel
In-Reply-To: <20120311165630.GA27265@1984>
Hi Hans,
On Sun, Mar 11, 2012 at 05:14:01PM +0100, Hans Schillstrom wrote:
> >Perhaps I'm missing anything but either way (IPv6 as module or
> >built-in) the symbol is still defined. With my patch applied, xt_LOG
> >now depends on IP6_NF_IPTABLES, which depends on IPV6.
> >
> >Moreover we've got other xt_ target and matches that contain both IPv4
> >and IPv6 support that don't require this.
> >
> >Let me know.
>
> if you compile ipv6 as a module and xt_LOG as builtin (=y) there is a missing ref to `ip6t_ext_hdr' at link time ...
ip6t_ext_hdr is defined by ip6_tables:
net/ipv6/netfilter/ip6_tables.c:ip6t_ext_hdr(u8 nexthdr)
AFAICS the dependency should rely on CONFIG_IP6_NF_IPTABLES.
An alternative is to define ip6t_ext_hdr as static inline in
include/linux/netfilter_ipv6/ip6_tables.h, it's fairly small and it's
invoked in the typical packet path if this LOG is used.
> What I did was to resolve that issue i.e. force xt_LOG to be a module if ipv6 is a module
Thanks for reporting this.
^ permalink raw reply
* Re: [PATCH] crypto: fix build failure in mv_cesa.c (missing of header)
From: Paul Gortmaker @ 2012-03-11 16:17 UTC (permalink / raw)
To: Jason Cooper; +Cc: michael, linux-crypto, linux-next
In-Reply-To: <20120311014226.GU5050@titan.lakedaemon.net>
On Sat, Mar 10, 2012 at 8:42 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Fri, Mar 09, 2012 at 02:58:25PM -0500, Paul Gortmaker wrote:
>> Commit 737b75872487f560397ba34846a19823b1addf88 (linux-next)
>>
>> "ARM: kirkwood: mv_cesa devicetree bindings"
>>
>> fails to compile as follows:
>>
>> CC drivers/crypto/mv_cesa.o
>> drivers/crypto/mv_cesa.c:1139: error: implicit declaration of function 'of_match_ptr'
>> drivers/crypto/mv_cesa.c:1139: error: 'mv_cesa_dt_ids' undeclared here (not in a function)
>> drivers/crypto/mv_cesa.c:1139: error: initializer element is not constant
>> drivers/crypto/mv_cesa.c:1139: error: (near initialization for 'marvell_crypto.driver.of_match_table')
>>
>> because it is missing the linux/of.h header file.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> Paul,
>
> Thanks for the patch. Unfortunately, I'm not learning fast enough. ;-)
> This series has been in a lot of flux lately, as you've experienced.
>
> The good news is, after talking with Olaf and Arnd, I think I have a
> good workflow figured out. Hopefully, failures like this won't happen
> in the future.
Sounds good -- don't be too hard on yourself wrt. a minor breakage.
Feel free to just squish the above patch into whatever updates you
have going. I don't see it needing to exist as a standalone commit.
THanks,
Paul.
--
>
> As an fyi, I'm probably going to take kirkwood_dt_staging down (or, label
> it broken ;-) ) I intended it as a publicly viewable branch of "what's
> coming down the pipe", but it's not working out the way I intended.
>
> As for mv_cesa, it's next on my list. As soon as I figure out the irq
> stuff.
>
> Thanks for testing.
>
> Jason.
>
>>
>> diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
>> index b7a3d48..093e214 100644
>> --- a/drivers/crypto/mv_cesa.c
>> +++ b/drivers/crypto/mv_cesa.c
>> @@ -10,6 +10,7 @@
>> #include <crypto/algapi.h>
>> #include <linux/crypto.h>
>> #include <linux/interrupt.h>
>> +#include <linux/of.h>
>> #include <linux/io.h>
>> #include <linux/kthread.h>
>> #include <linux/platform_device.h>
>> --
>> 1.7.9.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: fix for "error: implicit declaration of function 'devres_alloc'" in Mar9 tree
From: Paul Gortmaker @ 2012-03-11 16:09 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-next
In-Reply-To: <20120311124846.GA6081@opensource.wolfsonmicro.com>
On Sun, Mar 11, 2012 at 8:48 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Mar 09, 2012 at 10:11:56AM -0500, Paul Gortmaker wrote:
>
>> drivers/base/regmap/regmap.c:421: error: implicit declaration of function 'dev_err'
>> make[4]: *** [drivers/base/regmap/regmap.o] Error 1
>
>> This is caused by commit 19694b5ea1d3 which just appeared in today's next
>> tree exposing another implicit device.h user. Just a quick note that I'll
>> take care of it by adding regmap.c to the below commit.
>
> No, it's not caused by that - in the subsystem tree there's an explicit
> inclusion of linux/device.h in the public header which is what is being
> relied on here. You've gone and deleted that inclusion without CCing
> the patch to the subsystem and now you're sending a fix again without a
> CC to either me or the relevant list, and without even a mention in the
> subject line.
We are talking about a trivial fix here, and the deletion was one of about
fifty similar one-line deletions in include/linux, of which many files don't
even have clear owners. So, while I can appreciate you wanting a CC,
it just wasn't practical in this case in my opinion.
>
> In order to avoid bisection breakage I've applied one of the several
> fixes for this that were sent to me today, please drop your change.
I don't see how this avoids any bisection breakage -- you've now introduced
a dependency that wasn't there before -- i.e. I would have to make sure
your change is present before my changes get pulled. In any case I can
just ensure I have the exact same change as you and it will make sure
my series remains bisectable.
>
> This stuff would go a lot more smoothly if you were to at least let
> people know when you make changes, especially when issues introduced by
> your changes get noticed.
I've worked to get at least three different regulator regression fixes in,
None of those were related to any changes I made. You were on the
to/CC of those fixes, and I even made changes as you requested. My
point is that I do my best to follow implicit and explicit processes. If
you've somehow come to conclude otherwise, I'm sorry to hear that.
Paul.
^ permalink raw reply
* Re: linux-next: Tree for Mar 9 (netfilter)
From: Pablo Neira Ayuso @ 2012-03-11 15:52 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, netdev,
netfilter-devel
In-Reply-To: <giupeu1.ee21a87813f836d9f587ea0b0e19a695@obelix.schillstrom.com>
Hi Hans,
On Sun, Mar 11, 2012 at 01:37:25PM +0100, Hans Schillstrom wrote:
> Hello
> >On Fri, Mar 09, 2012 at 12:30:42PM -0800, Randy Dunlap wrote:
> >> On 03/09/2012 12:11 AM, Stephen Rothwell wrote:
> >>
> >> > Hi all,
> >> >
> >> > There will be no linux-next release on March 12 due to a public holiday.
> >> >
> >> > Changes since 20120308:
> >>
> >>
> >> xt_LOG.c:(.text+0x789b1): undefined reference to `ip6t_ext_hdr'
> >>
> >> Full randconfig file is attached.
> >
> >The patch attached fixes this problem, thanks!
>
>
> This one is needed as well,
>
> To force xt_LOG to be configured as a module if ipv6 is a module,
> otherwise you end up in the same linking problem
Perhaps I'm missing anything but either way (IPv6 as module or
built-in) the symbol is still defined. With my patch applied, xt_LOG
now depends on IP6_NF_IPTABLES, which depends on IPV6.
Moreover we've got other xt_ target and matches that contain both IPv4
and IPv6 support that don't require this.
Let me know.
^ permalink raw reply
* Re: fix for "error: implicit declaration of function 'devres_alloc'" in Mar9 tree
From: Mark Brown @ 2012-03-11 12:48 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-next
In-Reply-To: <4F5A1DBC.3090701@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]
On Fri, Mar 09, 2012 at 10:11:56AM -0500, Paul Gortmaker wrote:
> drivers/base/regmap/regmap.c:421: error: implicit declaration of function 'dev_err'
> make[4]: *** [drivers/base/regmap/regmap.o] Error 1
> This is caused by commit 19694b5ea1d3 which just appeared in today's next
> tree exposing another implicit device.h user. Just a quick note that I'll
> take care of it by adding regmap.c to the below commit.
No, it's not caused by that - in the subsystem tree there's an explicit
inclusion of linux/device.h in the public header which is what is being
relied on here. You've gone and deleted that inclusion without CCing
the patch to the subsystem and now you're sending a fix again without a
CC to either me or the relevant list, and without even a mention in the
subject line.
In order to avoid bisection breakage I've applied one of the several
fixes for this that were sent to me today, please drop your change.
This stuff would go a lot more smoothly if you were to at least let
people know when you make changes, especially when issues introduced by
your changes get noticed.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re[2]: linux-next: Tree for Mar 9 (netfilter)
From: Hans Schillstrom @ 2012-03-11 12:37 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, netdev,
netfilter-devel
Hello
>On Fri, Mar 09, 2012 at 12:30:42PM -0800, Randy Dunlap wrote:
>> On 03/09/2012 12:11 AM, Stephen Rothwell wrote:
>>
>> > Hi all,
>> >
>> > There will be no linux-next release on March 12 due to a public holiday.
>> >
>> > Changes since 20120308:
>>
>>
>> xt_LOG.c:(.text+0x789b1): undefined reference to `ip6t_ext_hdr'
>>
>> Full randconfig file is attached.
>
>The patch attached fixes this problem, thanks!
This one is needed as well,
To force xt_LOG to be configured as a module if ipv6 is a module,
otherwise you end up in the same linking problem
Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
---
net/netfilter/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 0c6f67e..4ef9c80 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -547,6 +547,7 @@ config NETFILTER_XT_TARGET_LED
config NETFILTER_XT_TARGET_LOG
tristate "LOG target support"
+ depends on (IPV6 || IPV6=n)
default m if NETFILTER_ADVANCED=n
help
This option adds a `LOG' target, which allows you to create rules in
--
1.7.3.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox