* Re: next Feb 10: mm/slqb build break
From: Nick Piggin @ 2009-02-12 1:45 UTC (permalink / raw)
To: Pekka Enberg
Cc: Sachin P. Sant, Stephen Rothwell, linux-next, LKML, linuxppc-dev
In-Reply-To: <84144f020902100353x4074f342ne4d61483074a06b7@mail.gmail.com>
On Tue, Feb 10, 2009 at 01:53:51PM +0200, Pekka Enberg wrote:
> On Tue, Feb 10, 2009 at 11:54 AM, Sachin P. Sant <sachinp@in.ibm.com> wrote:
> > Sachin P. Sant wrote:
> >>
> >> Hi Stephen,
> >>
> >> Todays next randconfig build on powerpc fails with
> >>
> >> CC mm/slqb.o
> >> mm/slqb.c: In function __slab_free:
> >> mm/slqb.c:1648: error: implicit declaration of function
> >> slab_free_to_remote
> >> mm/slqb.c: In function kmem_cache_open:
> >> mm/slqb.c:2174: error: implicit declaration of function
> >> kmem_cache_dyn_array_free
> >> mm/slqb.c:2175: warning: label error_cpu_array defined but not used
> >> mm/slqb.c: In function kmem_cache_destroy:
> >> mm/slqb.c:2294: error: implicit declaration of function
> >> claim_remote_free_list
> >> mm/slqb.c: In function kmem_cache_reap_percpu:
> >> mm/slqb.c:2547: error: implicit declaration of function
> >> flush_remote_free_cache
> >> mm/slqb.c: In function kmem_cache_init:
> >> mm/slqb.c:2783: error: per_cpu__kmem_cpu_nodes undeclared (first use in
> >> this function)
> >> mm/slqb.c:2783: error: (Each undeclared identifier is reported only once
> >> mm/slqb.c:2783: error: for each function it appears in.)
> >> mm/slqb.c:2784: error: kmem_cpu_cache undeclared (first use in this
> >> function)
> >> make[1]: *** [mm/slqb.o] Error 1
> >> make: *** [mm] Error 2
> >
> > CONFIG_SMP is not set hence the failure.
>
> Actually, that's not the root cause here. You seem to have CONFIG_SMP
> disabled but CONFIG_NUMA enabled. That's not possible on x86 which
> makes me think it's a ppc kconfig bug. Hmm?
If it is really a valid config, then we should be able to make
slqb build with it...
^ permalink raw reply
* Re: [PATCH 2.6.30] RDMA/cxgb3: remove modulo math from build_rdma_recv().
From: David Miller @ 2009-02-11 23:00 UTC (permalink / raw)
To: swise; +Cc: rdreier, general, randy.dunlap, linux-next, linux-kernel
In-Reply-To: <20090211222915.19520.22647.stgit@dell3.ogc.int>
From: Steve Wise <swise@opengridcomputing.com>
Date: Wed, 11 Feb 2009 16:29:15 -0600
> From: Steve Wise <swise@opengridcomputing.com>
>
> - remove modulo usage
>
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH 2.6.30] RDMA/cxgb3: remove modulo math from build_rdma_recv().
From: Steve Wise @ 2009-02-11 22:29 UTC (permalink / raw)
To: rdreier; +Cc: general, randy.dunlap, linux-next, linux-kernel
From: Steve Wise <swise@opengridcomputing.com>
- remove modulo usage
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
drivers/infiniband/hw/cxgb3/iwch_qp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c b/drivers/infiniband/hw/cxgb3/iwch_qp.c
index c2b3cf7..bf549ed 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_qp.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_qp.c
@@ -263,8 +263,8 @@ static int build_rdma_recv(struct iwch_qp *qhp, union t3_wr *wqe,
wqe->recv.sgl[i].len = cpu_to_be32(wr->sg_list[i].length);
/* to in the WQE == the offset into the page */
- wqe->recv.sgl[i].to = cpu_to_be64(((u32) wr->sg_list[i].addr) %
- (1UL << (12 + page_size[i])));
+ wqe->recv.sgl[i].to = cpu_to_be64(((u32)wr->sg_list[i].addr) &
+ ((1UL << (12 + page_size[i]) - 1)));
/* pbl_addr is the adapters address in the PBL */
wqe->recv.pbl_addr[i] = cpu_to_be32(pbl_addr[i]);
^ permalink raw reply related
* Re: pull request: wireless-2.6 2009-02-11
From: David Miller @ 2009-02-11 21:58 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090211191212.GA7033-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 11 Feb 2009 14:12:12 -0500
> Here are a few more intended for 2.6.29. The ath5k one is already in
> -next, but it turns-out to affect 2.6.29 as well. The two zd1211rw ones
> are one-liners that enable new hardware for that driver.
>
> The iwlwifi patch corrects a problem (introduced by the previous iwlwifi
> fix) that disables the iwlwifi devices after suspend/resume. It will
> conflict with what is already in -next -- just take the hunks that are
> already in -next and ignore the hunks introduced here.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Ingo Molnar @ 2009-02-11 20:25 UTC (permalink / raw)
To: Luck, Tony
Cc: Dean Nelson, Andrew Morton, Tejun Heo, linux-ia64, linux-next,
LKML
In-Reply-To: <57C9024A16AD2D4C97DC78E552063EA361689D7D@orsmsx505.amr.corp.intel.com>
* Luck, Tony <tony.luck@intel.com> wrote:
> > What question was that? Folding back across that distance is not possible
> > in a Git workflow. I do regular cross-builds - the build bug did not trigger
> > with the ia64 defconfig.
>
> I'm confused by this, as it definitely triggered for me. Perhaps
> my build scripts do things a bit differently. Essentially I do:
>
> $ for c in `ls arch/ia64/configs`
> > do
> > cp arch/ia64/configs/$i .config
> > yes '' | make oldconfig
> > make
> > done
>
> Which takes the default answer for any new questions that crop
> up. This enabled the GRU driver in the case of the generic_defconfig,
> and so the build failed because of the lack of asm/uv.h
hm, my build scripts do (in essence):
make mrproper
make ARCH=ia64 defconfig
hm, GRU is enabled as a module. I generally build the =y items, i.e. the
vmlinux. There's around 20 thousand modules enabled in various defconfigs,
that's a _lot_ of time to build.
Ingo
^ permalink raw reply
* Re: [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Dean Nelson @ 2009-02-11 19:33 UTC (permalink / raw)
To: Luck, Tony
Cc: Ingo Molnar, Andrew Morton, Tejun Heo, linux-ia64, linux-next,
LKML
In-Reply-To: <57C9024A16AD2D4C97DC78E552063EA361689D7D@orsmsx505.amr.corp.intel.com>
On Wed, Feb 11, 2009 at 10:58:19AM -0800, Luck, Tony wrote:
> > What question was that? Folding back across that distance is not possible
> > in a Git workflow. I do regular cross-builds - the build bug did not trigger
> > with the ia64 defconfig.
>
> I'm confused by this, as it definitely triggered for me. Perhaps
> my build scripts do things a bit differently. Essentially I do:
>
> $ for c in `ls arch/ia64/configs`
> > do
> > cp arch/ia64/configs/$i .config
> > yes '' | make oldconfig
> > make
> > done
>
> Which takes the default answer for any new questions that crop
> up. This enabled the GRU driver in the case of the generic_defconfig,
> and so the build failed because of the lack of asm/uv.h
It always triggers for me as well. I also use generic_defconfig and
request the default for any NEW questions.
^ permalink raw reply
* pull request: wireless-2.6 2009-02-11
From: John W. Linville @ 2009-02-11 19:12 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA
Dave,
Here are a few more intended for 2.6.29. The ath5k one is already in
-next, but it turns-out to affect 2.6.29 as well. The two zd1211rw ones
are one-liners that enable new hardware for that driver.
The iwlwifi patch corrects a problem (introduced by the previous iwlwifi
fix) that disables the iwlwifi devices after suspend/resume. It will
conflict with what is already in -next -- just take the hunks that are
already in -next and ignore the hunks introduced here.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 7b7a799d664a46eec6cb7de200c90f40730497a7:
Meelis Roos (1):
sunhme: Fix Quattro HME irq registration on proble failures
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Bob Copeland (1):
ath5k: fix bf->skb==NULL panic in ath5k_tasklet_rx
Hin-Tak Leung (2):
zd1211rw: adding 0ace:0xa211 as a ZD1211 device
zd1211rw: treat MAXIM_NEW_RF(0x08) as UW2453_RF(0x09) for TP-Link WN322/422G
Johannes Berg (1):
mac80211: restrict to AP in outgoing interface heuristic
Reinette Chatre (1):
iwlwifi: fix suspend/resume and its usage of pci saved state
drivers/net/wireless/ath5k/base.c | 85 +++++++++++++++++----------
drivers/net/wireless/iwlwifi/iwl-agn.c | 15 ++++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 15 ++++-
drivers/net/wireless/zd1211rw/zd_rf.c | 1 +
drivers/net/wireless/zd1211rw/zd_usb.c | 1 +
net/mac80211/tx.c | 2 +
6 files changed, 83 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index a533ed6..1d77ee9 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -1098,6 +1098,42 @@ ath5k_hw_to_driver_rix(struct ath5k_softc *sc, int hw_rix)
* Buffers setup *
\***************/
+static
+struct sk_buff *ath5k_rx_skb_alloc(struct ath5k_softc *sc, dma_addr_t *skb_addr)
+{
+ struct sk_buff *skb;
+ unsigned int off;
+
+ /*
+ * Allocate buffer with headroom_needed space for the
+ * fake physical layer header at the start.
+ */
+ skb = dev_alloc_skb(sc->rxbufsize + sc->cachelsz - 1);
+
+ if (!skb) {
+ ATH5K_ERR(sc, "can't alloc skbuff of size %u\n",
+ sc->rxbufsize + sc->cachelsz - 1);
+ return NULL;
+ }
+ /*
+ * Cache-line-align. This is important (for the
+ * 5210 at least) as not doing so causes bogus data
+ * in rx'd frames.
+ */
+ off = ((unsigned long)skb->data) % sc->cachelsz;
+ if (off != 0)
+ skb_reserve(skb, sc->cachelsz - off);
+
+ *skb_addr = pci_map_single(sc->pdev,
+ skb->data, sc->rxbufsize, PCI_DMA_FROMDEVICE);
+ if (unlikely(pci_dma_mapping_error(sc->pdev, *skb_addr))) {
+ ATH5K_ERR(sc, "%s: DMA mapping failed\n", __func__);
+ dev_kfree_skb(skb);
+ return NULL;
+ }
+ return skb;
+}
+
static int
ath5k_rxbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf)
{
@@ -1105,37 +1141,11 @@ ath5k_rxbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf)
struct sk_buff *skb = bf->skb;
struct ath5k_desc *ds;
- if (likely(skb == NULL)) {
- unsigned int off;
-
- /*
- * Allocate buffer with headroom_needed space for the
- * fake physical layer header at the start.
- */
- skb = dev_alloc_skb(sc->rxbufsize + sc->cachelsz - 1);
- if (unlikely(skb == NULL)) {
- ATH5K_ERR(sc, "can't alloc skbuff of size %u\n",
- sc->rxbufsize + sc->cachelsz - 1);
+ if (!skb) {
+ skb = ath5k_rx_skb_alloc(sc, &bf->skbaddr);
+ if (!skb)
return -ENOMEM;
- }
- /*
- * Cache-line-align. This is important (for the
- * 5210 at least) as not doing so causes bogus data
- * in rx'd frames.
- */
- off = ((unsigned long)skb->data) % sc->cachelsz;
- if (off != 0)
- skb_reserve(skb, sc->cachelsz - off);
-
bf->skb = skb;
- bf->skbaddr = pci_map_single(sc->pdev,
- skb->data, sc->rxbufsize, PCI_DMA_FROMDEVICE);
- if (unlikely(pci_dma_mapping_error(sc->pdev, bf->skbaddr))) {
- ATH5K_ERR(sc, "%s: DMA mapping failed\n", __func__);
- dev_kfree_skb(skb);
- bf->skb = NULL;
- return -ENOMEM;
- }
}
/*
@@ -1664,7 +1674,8 @@ ath5k_tasklet_rx(unsigned long data)
{
struct ieee80211_rx_status rxs = {};
struct ath5k_rx_status rs = {};
- struct sk_buff *skb;
+ struct sk_buff *skb, *next_skb;
+ dma_addr_t next_skb_addr;
struct ath5k_softc *sc = (void *)data;
struct ath5k_buf *bf, *bf_last;
struct ath5k_desc *ds;
@@ -1749,10 +1760,17 @@ ath5k_tasklet_rx(unsigned long data)
goto next;
}
accept:
+ next_skb = ath5k_rx_skb_alloc(sc, &next_skb_addr);
+
+ /*
+ * If we can't replace bf->skb with a new skb under memory
+ * pressure, just skip this packet
+ */
+ if (!next_skb)
+ goto next;
+
pci_unmap_single(sc->pdev, bf->skbaddr, sc->rxbufsize,
PCI_DMA_FROMDEVICE);
- bf->skb = NULL;
-
skb_put(skb, rs.rs_datalen);
/* The MAC header is padded to have 32-bit boundary if the
@@ -1825,6 +1843,9 @@ accept:
ath5k_check_ibss_tsf(sc, skb, &rxs);
__ieee80211_rx(sc->hw, skb, &rxs);
+
+ bf->skb = next_skb;
+ bf->skbaddr = next_skb_addr;
next:
list_move_tail(&bf->list, &sc->rxbuf);
} while (ath5k_rxbuf_setup(sc, bf) == 0);
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index c01ea48..36bafeb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -4042,7 +4042,19 @@ static int iwl_pci_suspend(struct pci_dev *pdev, pm_message_t state)
priv->is_open = 1;
}
- pci_save_state(pdev);
+ /* pci driver assumes state will be saved in this function.
+ * pci state is saved and device disabled when interface is
+ * stopped, so at this time pci device will always be disabled -
+ * whether interface was started or not. saving pci state now will
+ * cause saved state be that of a disabled device, which will cause
+ * problems during resume in that we will end up with a disabled device.
+ *
+ * indicate that the current saved state (from when interface was
+ * stopped) is valid. if interface was never up at time of suspend
+ * then the saved state will still be valid as it was saved during
+ * .probe. */
+ pdev->state_saved = true;
+
pci_set_power_state(pdev, PCI_D3hot);
return 0;
@@ -4053,7 +4065,6 @@ static int iwl_pci_resume(struct pci_dev *pdev)
struct iwl_priv *priv = pci_get_drvdata(pdev);
pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
if (priv->is_open)
iwl_mac_start(priv->hw);
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 5b44d32..93be74a 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -8143,7 +8143,19 @@ static int iwl3945_pci_suspend(struct pci_dev *pdev, pm_message_t state)
priv->is_open = 1;
}
- pci_save_state(pdev);
+ /* pci driver assumes state will be saved in this function.
+ * pci state is saved and device disabled when interface is
+ * stopped, so at this time pci device will always be disabled -
+ * whether interface was started or not. saving pci state now will
+ * cause saved state be that of a disabled device, which will cause
+ * problems during resume in that we will end up with a disabled device.
+ *
+ * indicate that the current saved state (from when interface was
+ * stopped) is valid. if interface was never up at time of suspend
+ * then the saved state will still be valid as it was saved during
+ * .probe. */
+ pdev->state_saved = true;
+
pci_set_power_state(pdev, PCI_D3hot);
return 0;
@@ -8154,7 +8166,6 @@ static int iwl3945_pci_resume(struct pci_dev *pdev)
struct iwl3945_priv *priv = pci_get_drvdata(pdev);
pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
if (priv->is_open)
iwl3945_mac_start(priv->hw);
diff --git a/drivers/net/wireless/zd1211rw/zd_rf.c b/drivers/net/wireless/zd1211rw/zd_rf.c
index 7207bfd..c875ee0 100644
--- a/drivers/net/wireless/zd1211rw/zd_rf.c
+++ b/drivers/net/wireless/zd1211rw/zd_rf.c
@@ -86,6 +86,7 @@ int zd_rf_init_hw(struct zd_rf *rf, u8 type)
case AL7230B_RF:
r = zd_rf_init_al7230b(rf);
break;
+ case MAXIM_NEW_RF:
case UW2453_RF:
r = zd_rf_init_uw2453(rf);
break;
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index 17527f7..f0e5e94 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -37,6 +37,7 @@
static struct usb_device_id usb_ids[] = {
/* ZD1211 */
{ USB_DEVICE(0x0ace, 0x1211), .driver_info = DEVICE_ZD1211 },
+ { USB_DEVICE(0x0ace, 0xa211), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x07b8, 0x6001), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x126f, 0xa006), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x6891, 0xa727), .driver_info = DEVICE_ZD1211 },
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 4278e54..94de503 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1343,6 +1343,8 @@ int ieee80211_master_start_xmit(struct sk_buff *skb, struct net_device *dev)
list) {
if (!netif_running(sdata->dev))
continue;
+ if (sdata->vif.type != NL80211_IFTYPE_AP)
+ continue;
if (compare_ether_addr(sdata->dev->dev_addr,
hdr->addr2)) {
dev_hold(sdata->dev);
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Luck, Tony @ 2009-02-11 18:58 UTC (permalink / raw)
To: Ingo Molnar, Dean Nelson
Cc: Andrew Morton, Tejun Heo, linux-ia64, linux-next, LKML
In-Reply-To: <20090211150536.GE10525@elte.hu>
> What question was that? Folding back across that distance is not possible
> in a Git workflow. I do regular cross-builds - the build bug did not trigger
> with the ia64 defconfig.
I'm confused by this, as it definitely triggered for me. Perhaps
my build scripts do things a bit differently. Essentially I do:
$ for c in `ls arch/ia64/configs`
> do
> cp arch/ia64/configs/$i .config
> yes '' | make oldconfig
> make
> done
Which takes the default answer for any new questions that crop
up. This enabled the GRU driver in the case of the generic_defconfig,
and so the build failed because of the lack of asm/uv.h
-Tony
^ permalink raw reply
* RE: [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Luck, Tony @ 2009-02-11 18:49 UTC (permalink / raw)
To: Ingo Molnar, Dean Nelson; +Cc: Andrew Morton, linux-ia64, linux-next, LKML
In-Reply-To: <20090211123249.GE16535@elte.hu>
> Tony, since this breakage is an accidental side-effect of the x86 tree (that
> has to be fixed there), mind if we carry it there?
Ingo,
I don't mind at all.
-Tony
^ permalink raw reply
* Re: [ofa-general] [PATCH 2.6.30] RDMA/cxgb3: Remove modulo math.
From: Steve Wise @ 2009-02-11 18:44 UTC (permalink / raw)
To: Roland Dreier; +Cc: randy.dunlap, linux-next, linux-kernel, general
In-Reply-To: <adak57w95ym.fsf@cisco.com>
Roland Dreier wrote:
> > > Is it possible for the page to be bigger than 4GB? If so then yes you
> > > might be chopping off high-order bits or something.
>
> > Yes it is possible.
> >
> > A MR can be created with an iov_base of say 0xffffffff00000000.
> >
> > Then any sge.addr entries would be the iob_base + any offset.
>
> But the code we're talking about is:
>
> /* to in the WQE == the offset into the page */
> wqe->recv.sgl[i].to = cpu_to_be64(((u32) wr->sg_list[i].addr) %
> (1UL << (12 + page_size[i])));
>
> so it seems the top address bits don't matter unless page_size[i] is at
> least 20 -- in which case using 1UL to shift overflows on 32 bits anyway...
>
>
Yes yes...you're right. This code is really just saving the offset in
a page.
I'll send a new patch.
^ permalink raw reply
* Re: [ofa-general] [PATCH 2.6.30] RDMA/cxgb3: Remove modulo math.
From: Roland Dreier @ 2009-02-11 18:36 UTC (permalink / raw)
To: Steve Wise; +Cc: randy.dunlap, linux-next, linux-kernel, general
In-Reply-To: <499319CF.6050204@opengridcomputing.com>
> > Is it possible for the page to be bigger than 4GB? If so then yes you
> > might be chopping off high-order bits or something.
> Yes it is possible.
>
> A MR can be created with an iov_base of say 0xffffffff00000000.
>
> Then any sge.addr entries would be the iob_base + any offset.
But the code we're talking about is:
/* to in the WQE == the offset into the page */
wqe->recv.sgl[i].to = cpu_to_be64(((u32) wr->sg_list[i].addr) %
(1UL << (12 + page_size[i])));
so it seems the top address bits don't matter unless page_size[i] is at
least 20 -- in which case using 1UL to shift overflows on 32 bits anyway...
> So you are handling the offset patch that will make it u64 and remove
> the mod usage, correct?
Yeah, I rolled the fix into the "offset needs to be u64" patch, it
should be in linux-next by now (or at least in my for-next branch).
- R.
^ permalink raw reply
* Re: [ofa-general] [PATCH 2.6.30] RDMA/cxgb3: Remove modulo math.
From: Steve Wise @ 2009-02-11 18:32 UTC (permalink / raw)
To: Roland Dreier; +Cc: randy.dunlap, linux-next, linux-kernel, general
In-Reply-To: <adatz70972e.fsf@cisco.com>
Roland Dreier wrote:
> > Note that wr->sg_list[i].addr was being cast to a u32. That was wrong.
>
> Is it possible for the page to be bigger than 4GB? If so then yes you
> might be chopping off high-order bits or something.
>
Yes it is possible.
A MR can be created with an iov_base of say 0xffffffff00000000.
Then any sge.addr entries would be the iob_base + any offset.
> Anyway please send me this change as a separate patch with a changelog
> explaining that you're avoiding the div etc.... I don't want to roll it
> in with the other unrelated fix (which changes code that was never
> upstream anyway).
>
will do.
So you are handling the offset patch that will make it u64 and remove
the mod usage, correct?
I will post a new patch with just this send change.
Steve.
^ permalink raw reply
* Re: [ofa-general] [PATCH 2.6.30] RDMA/cxgb3: Remove modulo math.
From: Roland Dreier @ 2009-02-11 18:12 UTC (permalink / raw)
To: Steve Wise; +Cc: randy.dunlap, linux-next, linux-kernel, general
In-Reply-To: <4992F26A.4030800@opengridcomputing.com>
> Note that wr->sg_list[i].addr was being cast to a u32. That was wrong.
Is it possible for the page to be bigger than 4GB? If so then yes you
might be chopping off high-order bits or something.
Anyway please send me this change as a separate patch with a changelog
explaining that you're avoiding the div etc.... I don't want to roll it
in with the other unrelated fix (which changes code that was never
upstream anyway).
^ permalink raw reply
* Re: [ofa-general] [PATCH 2.6.30] RDMA/cxgb3: Remove modulo math.
From: Steve Wise @ 2009-02-11 15:44 UTC (permalink / raw)
To: Roland Dreier; +Cc: randy.dunlap, linux-next, linux-kernel, general
In-Reply-To: <adamyctajv8.fsf@cisco.com>
Roland Dreier wrote:
> I'll roll this into the offending patch (that is in -next).
>
> But:
>
> > - wqe->recv.sgl[i].to = cpu_to_be64(((u32) wr->sg_list[i].addr) %
> > - (1UL << (12 + page_size[i])));
> > + wqe->recv.sgl[i].to = cpu_to_be64(((u64) wr->sg_list[i].addr) &
> > + ((1UL << (12 + page_size[i]))-1));
>
> Is this required? Strength reduction optimization should do this
> automatically (and the code has been there for quite a while, so
> obviously it isn't causing problems)
>
> - R.
>
Note that wr->sg_list[i].addr was being cast to a u32. That was wrong.
^ permalink raw reply
* Re: [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Dean Nelson @ 2009-02-11 15:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Tejun Heo, Tony Luck, linux-ia64, linux-next, LKML
In-Reply-To: <20090211150536.GE10525@elte.hu>
On Wed, Feb 11, 2009 at 04:05:36PM +0100, Ingo Molnar wrote:
>
> * Dean Nelson <dcn@sgi.com> wrote:
>
> > On Tue, Feb 10, 2009 at 01:25:55PM -0800, Andrew Morton wrote:
> > > On Mon, 9 Feb 2009 10:25:20 -0600
> > > Dean Nelson <dcn@sgi.com> wrote:
> > >
> > > > Fix the ia64 build error that occurs in the linux-next tree by introducing
> > > > an ia64 version of uv.h. Additionally, clean up the usage of is_uv_system().
> > >
> > > Would I be correct in believing that this repairs (and should be folded
> > > into)
> > >
> > > commit 5b221278d61e3907a5e4104a844b63bc8bb3d43a
> > > Author: Ingo Molnar <mingo@elte.hu>
> > > Date: Wed Jan 21 11:30:07 2009 +0100
> > >
> > > x86: uv cleanup, build fix #2
> > >
> > > ?
> > >
> > > (it looks like 5b221278d61e3907a5e4104a844b63bc8bb3d43a should be
> > > folded into something else, too. What hath we wrought?)
> >
> > Yes, it does fix an issue introduced by:
> >
> > commit: bdbcdd48883940bbd8d17eb01172d58a261a413a
> > author: Tejun Heo <tj@kernel.org>
> > date: Wed, 21 Jan 2009 08:26:06 +0000
> >
> > x86: uv cleanup
> >
> > which the commit you mention above attempted to fix.
> >
> > I'll leave it to you and Ingo to determine whether my patch should be
> > folded into Ingo's or Tejun's patch.
> >
> > Ingo, I see that you've applied my patch to your tip tree. What are
> > your thoughts on Andrew's question?
>
> What question was that? Folding back across that distance is not possible
> in a Git workflow. I do regular cross-builds - the build bug did not trigger
> with the ia64 defconfig.
The question was the one of folding the patch back. And by your response, I
see we'll be leaving things as they are.
Thanks,
Dean
^ permalink raw reply
* Re: [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Ingo Molnar @ 2009-02-11 15:05 UTC (permalink / raw)
To: Dean Nelson
Cc: Andrew Morton, Tejun Heo, Tony Luck, linux-ia64, linux-next, LKML
In-Reply-To: <20090211150103.GA15814@sgi.com>
* Dean Nelson <dcn@sgi.com> wrote:
> On Tue, Feb 10, 2009 at 01:25:55PM -0800, Andrew Morton wrote:
> > On Mon, 9 Feb 2009 10:25:20 -0600
> > Dean Nelson <dcn@sgi.com> wrote:
> >
> > > Fix the ia64 build error that occurs in the linux-next tree by introducing
> > > an ia64 version of uv.h. Additionally, clean up the usage of is_uv_system().
> >
> > Would I be correct in believing that this repairs (and should be folded
> > into)
> >
> > commit 5b221278d61e3907a5e4104a844b63bc8bb3d43a
> > Author: Ingo Molnar <mingo@elte.hu>
> > Date: Wed Jan 21 11:30:07 2009 +0100
> >
> > x86: uv cleanup, build fix #2
> >
> > ?
> >
> > (it looks like 5b221278d61e3907a5e4104a844b63bc8bb3d43a should be
> > folded into something else, too. What hath we wrought?)
>
> Yes, it does fix an issue introduced by:
>
> commit: bdbcdd48883940bbd8d17eb01172d58a261a413a
> author: Tejun Heo <tj@kernel.org>
> date: Wed, 21 Jan 2009 08:26:06 +0000
>
> x86: uv cleanup
>
> which the commit you mention above attempted to fix.
>
> I'll leave it to you and Ingo to determine whether my patch should be
> folded into Ingo's or Tejun's patch.
>
> Ingo, I see that you've applied my patch to your tip tree. What are
> your thoughts on Andrew's question?
What question was that? Folding back across that distance is not possible
in a Git workflow. I do regular cross-builds - the build bug did not trigger
with the ia64 defconfig.
Ingo
^ permalink raw reply
* Re: [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Dean Nelson @ 2009-02-11 15:01 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar
Cc: Tejun Heo, Tony Luck, linux-ia64, linux-next, LKML
In-Reply-To: <20090210132555.be1c1462.akpm@linux-foundation.org>
On Tue, Feb 10, 2009 at 01:25:55PM -0800, Andrew Morton wrote:
> On Mon, 9 Feb 2009 10:25:20 -0600
> Dean Nelson <dcn@sgi.com> wrote:
>
> > Fix the ia64 build error that occurs in the linux-next tree by introducing
> > an ia64 version of uv.h. Additionally, clean up the usage of is_uv_system().
>
> Would I be correct in believing that this repairs (and should be folded
> into)
>
> commit 5b221278d61e3907a5e4104a844b63bc8bb3d43a
> Author: Ingo Molnar <mingo@elte.hu>
> Date: Wed Jan 21 11:30:07 2009 +0100
>
> x86: uv cleanup, build fix #2
>
> ?
>
> (it looks like 5b221278d61e3907a5e4104a844b63bc8bb3d43a should be
> folded into something else, too. What hath we wrought?)
Yes, it does fix an issue introduced by:
commit: bdbcdd48883940bbd8d17eb01172d58a261a413a
author: Tejun Heo <tj@kernel.org>
date: Wed, 21 Jan 2009 08:26:06 +0000
x86: uv cleanup
which the commit you mention above attempted to fix.
I'll leave it to you and Ingo to determine whether my patch should be
folded into Ingo's or Tejun's patch.
Ingo, I see that you've applied my patch to your tip tree. What are
your thoughts on Andrew's question?
Thanks,
Dean
^ permalink raw reply
* Re: next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low!
From: Chris Mason @ 2009-02-11 14:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Alexander Beregalov, linux-next@vger.kernel.org, LKML,
Ingo Molnar
In-Reply-To: <1234360834.23438.162.camel@twins>
On Wed, 2009-02-11 at 15:00 +0100, Peter Zijlstra wrote:
> > > > Could you run with the below patch, so that we can see where this
> > > > happens?
> >
> > Tssk, Chris what you have been doing?
>
> Would something like this work?
>
It's almost perfect ;) I just need BTRFS_MAX_LEVEL, which is 8, will
test and merge up. Thanks!
-chris
^ permalink raw reply
* Re: next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low!
From: Peter Zijlstra @ 2009-02-11 14:00 UTC (permalink / raw)
To: Alexander Beregalov
Cc: linux-next@vger.kernel.org, LKML, Ingo Molnar, Chris Mason
In-Reply-To: <1234357467.23438.151.camel@twins>
On Wed, 2009-02-11 at 14:04 +0100, Peter Zijlstra wrote:
> On Wed, 2009-02-11 at 15:52 +0300, Alexander Beregalov wrote:
> > 2009/2/11 Peter Zijlstra <peterz@infradead.org>:
> > > On Wed, 2009-02-11 at 13:24 +0100, Peter Zijlstra wrote:
> > >> On Wed, 2009-02-11 at 13:23 +0100, Peter Zijlstra wrote:
> > >> > On Wed, 2009-02-11 at 15:14 +0300, Alexander Beregalov wrote:
> > >> > > Hi
> > >> > >
> > >> > > Full dmesg is attached.
> > >> > >
> > >> > > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> > >> > > .... MAX_LOCKDEP_SUBCLASSES: 8
> > >> > > .... MAX_LOCK_DEPTH: 48
> > >> > > .... MAX_LOCKDEP_KEYS: 8191
> > >> > > .... CLASSHASH_SIZE: 4096
> > >> > > .... MAX_LOCKDEP_ENTRIES: 8192
> > >> > > .... MAX_LOCKDEP_CHAINS: 16384
> > >> > > .... CHAINHASH_SIZE: 8192
> > >> > > memory used by lock dependency info: 4351 kB
> > >> > > per task-struct memory footprint: 2688 bytes
> > >> > > <..>
> > >> > > BUG: MAX_LOCKDEP_SUBCLASSES too low!
> > >> > > turning off the locking correctness validator.
> > >> >
> > >> > Is this an allyesconfig or something other massive bloated?
> > >>
> > >> Sorry, not playing attention, its SUB classes.. let me look at that,
> > >> that smells like a rotten annotation.
> > >
> > > Could you run with the below patch, so that we can see where this
> > > happens?
>
> Tssk, Chris what you have been doing?
Would something like this work?
---
fs/btrfs/extent_io.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
fs/btrfs/locking.c | 11 -----------
2 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 37d43b5..d6cf792 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2972,6 +2972,45 @@ static inline unsigned long num_extent_pages(u64 start, u64 len)
(start >> PAGE_CACHE_SHIFT);
}
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+#define BTRFS_MAX_EXTENT_DEPTH 32 /* mason knows */
+static struct lock_class_key btrfs_eb_class[BTRFS_MAX_EXTENT_DEPTH];
+static const char *btrfs_eb_name[BTRFS_MAX_EXTENT_DEPTH] = {
+ "btrfs-extent-00",
+ "btrfs-extent-01",
+ "btrfs-extent-02",
+ "btrfs-extent-03",
+ "btrfs-extent-04",
+ "btrfs-extent-05",
+ "btrfs-extent-06",
+ "btrfs-extent-07",
+ "btrfs-extent-08",
+ "btrfs-extent-09",
+ "btrfs-extent-10",
+ "btrfs-extent-11",
+ "btrfs-extent-12",
+ "btrfs-extent-13",
+ "btrfs-extent-14",
+ "btrfs-extent-15",
+ "btrfs-extent-16",
+ "btrfs-extent-17",
+ "btrfs-extent-18",
+ "btrfs-extent-19",
+ "btrfs-extent-20",
+ "btrfs-extent-21",
+ "btrfs-extent-22",
+ "btrfs-extent-23",
+ "btrfs-extent-24",
+ "btrfs-extent-25",
+ "btrfs-extent-26",
+ "btrfs-extent-27",
+ "btrfs-extent-28",
+ "btrfs-extent-29",
+ "btrfs-extent-30",
+ "btrfs-extent-31",
+};
+#endif
+
static struct extent_buffer *__alloc_extent_buffer(struct extent_io_tree *tree,
u64 start,
unsigned long len,
@@ -3070,6 +3109,16 @@ struct extent_buffer *alloc_extent_buffer(struct extent_io_tree *tree,
if (uptodate)
set_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags);
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ /*
+ * apparently we're done loading the eb here
+ */
+ i = btrfs_header_level(eb);
+ lockdep_set_class_and_name(eb->lock,
+ &btrfs_eb_class[i],
+ btrfs_eb_name[i]);
+#endif
+
spin_lock(&tree->buffer_lock);
exists = buffer_tree_insert(tree, start, &eb->rb_node);
if (exists) {
diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
index 9ebe938..85506c4 100644
--- a/fs/btrfs/locking.c
+++ b/fs/btrfs/locking.c
@@ -25,21 +25,10 @@
#include "extent_io.h"
#include "locking.h"
-/*
- * btrfs_header_level() isn't free, so don't call it when lockdep isn't
- * on
- */
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
-static inline void spin_nested(struct extent_buffer *eb)
-{
- spin_lock_nested(&eb->lock, BTRFS_MAX_LEVEL - btrfs_header_level(eb));
-}
-#else
static inline void spin_nested(struct extent_buffer *eb)
{
spin_lock(&eb->lock);
}
-#endif
/*
* Setting a lock to blocking will drop the spinlock and set the
^ permalink raw reply related
* Re: next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low!
From: Peter Zijlstra @ 2009-02-11 13:04 UTC (permalink / raw)
To: Alexander Beregalov
Cc: linux-next@vger.kernel.org, LKML, Ingo Molnar, Chris Mason
In-Reply-To: <a4423d670902110452s5fb6d041l2363c8ad9b9618fb@mail.gmail.com>
On Wed, 2009-02-11 at 15:52 +0300, Alexander Beregalov wrote:
> 2009/2/11 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, 2009-02-11 at 13:24 +0100, Peter Zijlstra wrote:
> >> On Wed, 2009-02-11 at 13:23 +0100, Peter Zijlstra wrote:
> >> > On Wed, 2009-02-11 at 15:14 +0300, Alexander Beregalov wrote:
> >> > > Hi
> >> > >
> >> > > Full dmesg is attached.
> >> > >
> >> > > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> >> > > .... MAX_LOCKDEP_SUBCLASSES: 8
> >> > > .... MAX_LOCK_DEPTH: 48
> >> > > .... MAX_LOCKDEP_KEYS: 8191
> >> > > .... CLASSHASH_SIZE: 4096
> >> > > .... MAX_LOCKDEP_ENTRIES: 8192
> >> > > .... MAX_LOCKDEP_CHAINS: 16384
> >> > > .... CHAINHASH_SIZE: 8192
> >> > > memory used by lock dependency info: 4351 kB
> >> > > per task-struct memory footprint: 2688 bytes
> >> > > <..>
> >> > > BUG: MAX_LOCKDEP_SUBCLASSES too low!
> >> > > turning off the locking correctness validator.
> >> >
> >> > Is this an allyesconfig or something other massive bloated?
> >>
> >> Sorry, not playing attention, its SUB classes.. let me look at that,
> >> that smells like a rotten annotation.
> >
> > Could you run with the below patch, so that we can see where this
> > happens?
Tssk, Chris what you have been doing?
> BUG: MAX_LOCKDEP_SUBCLASSES too low!
> turning off the locking correctness validator.
> Pid: 2105, comm: btrfs-endio-wri Not tainted 2.6.29-rc4-next-20090211-dirty #2
> Call Trace:
> [<ffffffff8026cbf9>] __lock_acquire+0x6b9/0x12c0
> [<ffffffff8026d891>] lock_acquire+0x91/0xc0
> [<ffffffff80447324>] ? btrfs_tree_lock+0xc4/0x160
> [<ffffffff8062eb36>] _spin_lock_nested+0x46/0x80
> [<ffffffff80447324>] ? btrfs_tree_lock+0xc4/0x160
> [<ffffffff80447324>] btrfs_tree_lock+0xc4/0x160
> [<ffffffff804471a0>] ? btrfs_wake_function+0x0/0x10
> [<ffffffff8040bce6>] btrfs_init_new_buffer+0xa6/0x150
> [<ffffffff80412fa1>] btrfs_alloc_free_block+0x81/0x90
> [<ffffffff80402a16>] __btrfs_cow_block+0x7a6/0xb70
> [<ffffffff804034e2>] btrfs_cow_block+0x112/0x2d0
> [<ffffffff804072f3>] btrfs_search_slot+0x223/0xb00
> [<ffffffff80235a99>] ? sub_preempt_count+0xa9/0xf0
> [<ffffffff804178d1>] btrfs_lookup_csum+0x61/0x150
> [<ffffffff8026c2ed>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff80418356>] btrfs_csum_file_blocks+0xc6/0x7d0
> [<ffffffff802c2315>] ? kmem_cache_free+0xb5/0x110
> [<ffffffff802c2315>] ? kmem_cache_free+0xb5/0x110
> [<ffffffff8026c2ed>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff80437c76>] ? free_extent_state+0x46/0x70
> [<ffffffff80439462>] ? clear_extent_bit+0xe2/0x2e0
> [<ffffffff8042166a>] add_pending_csums+0x4a/0x70
> [<ffffffff80422ac5>] btrfs_finish_ordered_io+0x115/0x1e0
> [<ffffffff80422ba0>] btrfs_writepage_end_io_hook+0x10/0x20
> [<ffffffff8043abf4>] end_bio_extent_writepage+0x104/0x1e0
> [<ffffffff8026c282>] ? trace_hardirqs_on_caller+0x182/0x1e0
> [<ffffffff802ef0cc>] bio_endio+0x1c/0x40
> [<ffffffff8041b02b>] end_workqueue_fn+0xeb/0x120
> [<ffffffff804446ea>] worker_loop+0x7a/0x1b0
> [<ffffffff80444670>] ? worker_loop+0x0/0x1b0
> [<ffffffff80259126>] kthread+0x56/0x90
> [<ffffffff8020cc5a>] child_rip+0xa/0x20
> [<ffffffff80235969>] ? finish_task_switch+0x89/0x110
> [<ffffffff8062f546>] ? _spin_unlock_irq+0x36/0x60
> [<ffffffff8020c640>] ? restore_args+0x0/0x30
> [<ffffffff802590d0>] ? kthread+0x0/0x90
> [<ffffffff8020cc50>] ? child_rip+0x0/0x20
^ permalink raw reply
* Re: next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low!
From: Alexander Beregalov @ 2009-02-11 12:52 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linux-next@vger.kernel.org, LKML, Ingo Molnar
In-Reply-To: <1234355201.23438.134.camel@twins>
2009/2/11 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2009-02-11 at 13:24 +0100, Peter Zijlstra wrote:
>> On Wed, 2009-02-11 at 13:23 +0100, Peter Zijlstra wrote:
>> > On Wed, 2009-02-11 at 15:14 +0300, Alexander Beregalov wrote:
>> > > Hi
>> > >
>> > > Full dmesg is attached.
>> > >
>> > > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
>> > > .... MAX_LOCKDEP_SUBCLASSES: 8
>> > > .... MAX_LOCK_DEPTH: 48
>> > > .... MAX_LOCKDEP_KEYS: 8191
>> > > .... CLASSHASH_SIZE: 4096
>> > > .... MAX_LOCKDEP_ENTRIES: 8192
>> > > .... MAX_LOCKDEP_CHAINS: 16384
>> > > .... CHAINHASH_SIZE: 8192
>> > > memory used by lock dependency info: 4351 kB
>> > > per task-struct memory footprint: 2688 bytes
>> > > <..>
>> > > BUG: MAX_LOCKDEP_SUBCLASSES too low!
>> > > turning off the locking correctness validator.
>> >
>> > Is this an allyesconfig or something other massive bloated?
>>
>> Sorry, not playing attention, its SUB classes.. let me look at that,
>> that smells like a rotten annotation.
>
> Could you run with the below patch, so that we can see where this
> happens?
BUG: MAX_LOCKDEP_SUBCLASSES too low!
turning off the locking correctness validator.
Pid: 2105, comm: btrfs-endio-wri Not tainted 2.6.29-rc4-next-20090211-dirty #2
Call Trace:
[<ffffffff8026cbf9>] __lock_acquire+0x6b9/0x12c0
[<ffffffff8026d891>] lock_acquire+0x91/0xc0
[<ffffffff80447324>] ? btrfs_tree_lock+0xc4/0x160
[<ffffffff8062eb36>] _spin_lock_nested+0x46/0x80
[<ffffffff80447324>] ? btrfs_tree_lock+0xc4/0x160
[<ffffffff80447324>] btrfs_tree_lock+0xc4/0x160
[<ffffffff804471a0>] ? btrfs_wake_function+0x0/0x10
[<ffffffff8040bce6>] btrfs_init_new_buffer+0xa6/0x150
[<ffffffff80412fa1>] btrfs_alloc_free_block+0x81/0x90
[<ffffffff80402a16>] __btrfs_cow_block+0x7a6/0xb70
[<ffffffff804034e2>] btrfs_cow_block+0x112/0x2d0
[<ffffffff804072f3>] btrfs_search_slot+0x223/0xb00
[<ffffffff80235a99>] ? sub_preempt_count+0xa9/0xf0
[<ffffffff804178d1>] btrfs_lookup_csum+0x61/0x150
[<ffffffff8026c2ed>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff80418356>] btrfs_csum_file_blocks+0xc6/0x7d0
[<ffffffff802c2315>] ? kmem_cache_free+0xb5/0x110
[<ffffffff802c2315>] ? kmem_cache_free+0xb5/0x110
[<ffffffff8026c2ed>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff80437c76>] ? free_extent_state+0x46/0x70
[<ffffffff80439462>] ? clear_extent_bit+0xe2/0x2e0
[<ffffffff8042166a>] add_pending_csums+0x4a/0x70
[<ffffffff80422ac5>] btrfs_finish_ordered_io+0x115/0x1e0
[<ffffffff80422ba0>] btrfs_writepage_end_io_hook+0x10/0x20
[<ffffffff8043abf4>] end_bio_extent_writepage+0x104/0x1e0
[<ffffffff8026c282>] ? trace_hardirqs_on_caller+0x182/0x1e0
[<ffffffff802ef0cc>] bio_endio+0x1c/0x40
[<ffffffff8041b02b>] end_workqueue_fn+0xeb/0x120
[<ffffffff804446ea>] worker_loop+0x7a/0x1b0
[<ffffffff80444670>] ? worker_loop+0x0/0x1b0
[<ffffffff80259126>] kthread+0x56/0x90
[<ffffffff8020cc5a>] child_rip+0xa/0x20
[<ffffffff80235969>] ? finish_task_switch+0x89/0x110
[<ffffffff8062f546>] ? _spin_unlock_irq+0x36/0x60
[<ffffffff8020c640>] ? restore_args+0x0/0x30
[<ffffffff802590d0>] ? kthread+0x0/0x90
[<ffffffff8020cc50>] ? child_rip+0x0/0x20
^ permalink raw reply
* Re: [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Ingo Molnar @ 2009-02-11 12:32 UTC (permalink / raw)
To: Dean Nelson; +Cc: Tony Luck, Andrew Morton, linux-ia64, linux-next, LKML
In-Reply-To: <20090209162520.GA4882@sgi.com>
* Dean Nelson <dcn@sgi.com> wrote:
> Fix the ia64 build error that occurs in the linux-next tree by introducing
> an ia64 version of uv.h. Additionally, clean up the usage of is_uv_system().
>
> Signed-off-by: Dean Nelson <dcn@sgi.com>
> Signed-off-by: Jack Steiner <steiner@sgi.com>
Applied, thanks Dean!
Tony, since this breakage is an accidental side-effect of the x86 tree (that
has to be fixed there), mind if we carry it there?
Ingo
^ permalink raw reply
* Re: next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low!
From: Peter Zijlstra @ 2009-02-11 12:26 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next@vger.kernel.org, LKML, Ingo Molnar
In-Reply-To: <1234355070.23438.133.camel@twins>
On Wed, 2009-02-11 at 13:24 +0100, Peter Zijlstra wrote:
> On Wed, 2009-02-11 at 13:23 +0100, Peter Zijlstra wrote:
> > On Wed, 2009-02-11 at 15:14 +0300, Alexander Beregalov wrote:
> > > Hi
> > >
> > > Full dmesg is attached.
> > >
> > > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> > > .... MAX_LOCKDEP_SUBCLASSES: 8
> > > .... MAX_LOCK_DEPTH: 48
> > > .... MAX_LOCKDEP_KEYS: 8191
> > > .... CLASSHASH_SIZE: 4096
> > > .... MAX_LOCKDEP_ENTRIES: 8192
> > > .... MAX_LOCKDEP_CHAINS: 16384
> > > .... CHAINHASH_SIZE: 8192
> > > memory used by lock dependency info: 4351 kB
> > > per task-struct memory footprint: 2688 bytes
> > > <..>
> > > BUG: MAX_LOCKDEP_SUBCLASSES too low!
> > > turning off the locking correctness validator.
> >
> > Is this an allyesconfig or something other massive bloated?
>
> Sorry, not playing attention, its SUB classes.. let me look at that,
> that smells like a rotten annotation.
Could you run with the below patch, so that we can see where this
happens?
---
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 06b0c35..4fe272c 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2542,6 +2542,7 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
debug_locks_off();
printk("BUG: MAX_LOCKDEP_SUBCLASSES too low!\n");
printk("turning off the locking correctness validator.\n");
+ dump_stack();
return 0;
}
^ permalink raw reply related
* Re: next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low!
From: Peter Zijlstra @ 2009-02-11 12:24 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next@vger.kernel.org, LKML, Ingo Molnar
In-Reply-To: <1234355010.23438.132.camel@twins>
On Wed, 2009-02-11 at 13:23 +0100, Peter Zijlstra wrote:
> On Wed, 2009-02-11 at 15:14 +0300, Alexander Beregalov wrote:
> > Hi
> >
> > Full dmesg is attached.
> >
> > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> > .... MAX_LOCKDEP_SUBCLASSES: 8
> > .... MAX_LOCK_DEPTH: 48
> > .... MAX_LOCKDEP_KEYS: 8191
> > .... CLASSHASH_SIZE: 4096
> > .... MAX_LOCKDEP_ENTRIES: 8192
> > .... MAX_LOCKDEP_CHAINS: 16384
> > .... CHAINHASH_SIZE: 8192
> > memory used by lock dependency info: 4351 kB
> > per task-struct memory footprint: 2688 bytes
> > <..>
> > BUG: MAX_LOCKDEP_SUBCLASSES too low!
> > turning off the locking correctness validator.
>
> Is this an allyesconfig or something other massive bloated?
Sorry, not playing attention, its SUB classes.. let me look at that,
that smells like a rotten annotation.
^ permalink raw reply
* Re: next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low!
From: Peter Zijlstra @ 2009-02-11 12:23 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next@vger.kernel.org, LKML, Ingo Molnar
In-Reply-To: <a4423d670902110414r72f14c1eq850cda59533bd9db@mail.gmail.com>
On Wed, 2009-02-11 at 15:14 +0300, Alexander Beregalov wrote:
> Hi
>
> Full dmesg is attached.
>
> Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> .... MAX_LOCKDEP_SUBCLASSES: 8
> .... MAX_LOCK_DEPTH: 48
> .... MAX_LOCKDEP_KEYS: 8191
> .... CLASSHASH_SIZE: 4096
> .... MAX_LOCKDEP_ENTRIES: 8192
> .... MAX_LOCKDEP_CHAINS: 16384
> .... CHAINHASH_SIZE: 8192
> memory used by lock dependency info: 4351 kB
> per task-struct memory footprint: 2688 bytes
> <..>
> BUG: MAX_LOCKDEP_SUBCLASSES too low!
> turning off the locking correctness validator.
Is this an allyesconfig or something other massive bloated?
^ permalink raw reply
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