* [PATCH 1/7] [PPP] pppoe: Fix skb_unshare_check call position
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[PPP] pppoe: Fix skb_unshare_check call position
The skb_unshare_check call needs to be made before pskb_may_pull,
not after.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/net/pppoe.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 68631a5..5ac3eff 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -385,12 +385,12 @@ static int pppoe_rcv(struct sk_buff *skb,
struct pppoe_hdr *ph;
struct pppox_sock *po;
- if (!pskb_may_pull(skb, sizeof(struct pppoe_hdr)))
- goto drop;
-
if (!(skb = skb_share_check(skb, GFP_ATOMIC)))
goto out;
+ if (!pskb_may_pull(skb, sizeof(struct pppoe_hdr)))
+ goto drop;
+
ph = pppoe_hdr(skb);
po = get_item((unsigned long) ph->sid, eth_hdr(skb)->h_source, dev->ifindex);
^ permalink raw reply related
* [PATCH 4/7] [BRIDGE]: Kill clone argument to br_flood_*
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[BRIDGE]: Kill clone argument to br_flood_*
The clone argument is only used by one caller and that caller can clone
the packet itself. This patch moves the clone call into the caller and
kills the clone argument.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
net/bridge/br_device.c | 4 ++--
net/bridge/br_forward.c | 21 +++++----------------
net/bridge/br_input.c | 48 ++++++++++++++++++++++--------------------------
net/bridge/br_private.h | 8 ++------
4 files changed, 31 insertions(+), 50 deletions(-)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 0eded17..99292e8 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -41,11 +41,11 @@ int br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
skb_pull(skb, ETH_HLEN);
if (dest[0] & 1)
- br_flood_deliver(br, skb, 0);
+ br_flood_deliver(br, skb);
else if ((dst = __br_fdb_get(br, dest)) != NULL)
br_deliver(dst->dst, skb);
else
- br_flood_deliver(br, skb, 0);
+ br_flood_deliver(br, skb);
return 0;
}
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index ada7f49..bdd7c35 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -100,24 +100,13 @@ void br_forward(const struct net_bridge_port *to, struct sk_buff *skb)
}
/* called under bridge lock */
-static void br_flood(struct net_bridge *br, struct sk_buff *skb, int clone,
+static void br_flood(struct net_bridge *br, struct sk_buff *skb,
void (*__packet_hook)(const struct net_bridge_port *p,
struct sk_buff *skb))
{
struct net_bridge_port *p;
struct net_bridge_port *prev;
- if (clone) {
- struct sk_buff *skb2;
-
- if ((skb2 = skb_clone(skb, GFP_ATOMIC)) == NULL) {
- br->statistics.tx_dropped++;
- return;
- }
-
- skb = skb2;
- }
-
prev = NULL;
list_for_each_entry_rcu(p, &br->port_list, list) {
@@ -148,13 +137,13 @@ static void br_flood(struct net_bridge *br, struct sk_buff *skb, int clone,
/* called with rcu_read_lock */
-void br_flood_deliver(struct net_bridge *br, struct sk_buff *skb, int clone)
+void br_flood_deliver(struct net_bridge *br, struct sk_buff *skb)
{
- br_flood(br, skb, clone, __br_deliver);
+ br_flood(br, skb, __br_deliver);
}
/* called under bridge lock */
-void br_flood_forward(struct net_bridge *br, struct sk_buff *skb, int clone)
+void br_flood_forward(struct net_bridge *br, struct sk_buff *skb)
{
- br_flood(br, skb, clone, __br_forward);
+ br_flood(br, skb, __br_forward);
}
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 5c18595..069a4e1 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -43,7 +43,7 @@ int br_handle_frame_finish(struct sk_buff *skb)
struct net_bridge_port *p = rcu_dereference(skb->dev->br_port);
struct net_bridge *br;
struct net_bridge_fdb_entry *dst;
- int passedup = 0;
+ struct sk_buff *skb2;
if (!p || p->state == BR_STATE_DISABLED)
goto drop;
@@ -55,39 +55,35 @@ int br_handle_frame_finish(struct sk_buff *skb)
if (p->state == BR_STATE_LEARNING)
goto drop;
- if (br->dev->flags & IFF_PROMISC) {
- struct sk_buff *skb2;
+ /* The packet skb2 goes to the local host (NULL to skip). */
+ skb2 = NULL;
- skb2 = skb_clone(skb, GFP_ATOMIC);
- if (skb2 != NULL) {
- passedup = 1;
- br_pass_frame_up(br, skb2);
- }
- }
+ if (br->dev->flags & IFF_PROMISC)
+ skb2 = skb;
+
+ dst = NULL;
if (is_multicast_ether_addr(dest)) {
br->statistics.multicast++;
- br_flood_forward(br, skb, !passedup);
- if (!passedup)
- br_pass_frame_up(br, skb);
- goto out;
+ skb2 = skb;
+ } else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
+ skb2 = skb;
+ /* Do not forward the packet since it's local. */
+ skb = NULL;
}
- dst = __br_fdb_get(br, dest);
- if (dst != NULL && dst->is_local) {
- if (!passedup)
- br_pass_frame_up(br, skb);
- else
- kfree_skb(skb);
- goto out;
- }
+ if (skb2 == skb)
+ skb2 = skb_clone(skb, GFP_ATOMIC);
- if (dst != NULL) {
- br_forward(dst->dst, skb);
- goto out;
- }
+ if (skb2)
+ br_pass_frame_up(br, skb2);
- br_flood_forward(br, skb, 0);
+ if (skb) {
+ if (dst)
+ br_forward(dst->dst, skb);
+ else
+ br_flood_forward(br, skb);
+ }
out:
return 0;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 21bf3a9..e6dc6f5 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -170,12 +170,8 @@ extern int br_dev_queue_push_xmit(struct sk_buff *skb);
extern void br_forward(const struct net_bridge_port *to,
struct sk_buff *skb);
extern int br_forward_finish(struct sk_buff *skb);
-extern void br_flood_deliver(struct net_bridge *br,
- struct sk_buff *skb,
- int clone);
-extern void br_flood_forward(struct net_bridge *br,
- struct sk_buff *skb,
- int clone);
+extern void br_flood_deliver(struct net_bridge *br, struct sk_buff *skb);
+extern void br_flood_forward(struct net_bridge *br, struct sk_buff *skb);
/* br_if.c */
extern void br_port_carrier_check(struct net_bridge_port *p);
^ permalink raw reply related
* Re: [ANNOUNCE] iproute2-2.6.23-rc3
From: Patrick McHardy @ 2007-08-31 9:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20070822110804.30c2e803@freepuppy.rosehill.hemminger.net>
On Wed, 22 Aug 2007, Stephen Hemminger wrote:
> There have been a lot of changes for 2.6.23, so here is a test release
> of iproute2 that should capture all the submitted patches
>
> Patrick McHardy (6):
> TC action parsing bug fix
> Bug fix tc action drop
> IPROUTE2: RTNETLINK nested attributes
> Use FRA_* attributes for routing rules
> iplink: use netlink for link configuration
> Fix meta ematch usage of 0 values
I just noticed the iplink_vlan stuff is missing. Do you want me
to resend?
^ permalink raw reply
* [PATCH 3/7] [PPP] pppoe: Fill in header directly in __pppoe_xmit
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[PPP] pppoe: Fill in header directly in __pppoe_xmit
This patch removes the hdr variable (which is copied into the skb)
and instead sets the header directly in the skb.
It also uses __skb_push instead of skb_push since we've just checked
using skb_cow for enough head room.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/net/pppoe.c | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 8818253..bac3654 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -848,19 +848,12 @@ static int __pppoe_xmit(struct sock *sk, struct sk_buff *skb)
{
struct pppox_sock *po = pppox_sk(sk);
struct net_device *dev = po->pppoe_dev;
- struct pppoe_hdr hdr;
struct pppoe_hdr *ph;
int data_len = skb->len;
if (sock_flag(sk, SOCK_DEAD) || !(sk->sk_state & PPPOX_CONNECTED))
goto abort;
- hdr.ver = 1;
- hdr.type = 1;
- hdr.code = 0;
- hdr.sid = po->num;
- hdr.length = htons(skb->len);
-
if (!dev)
goto abort;
@@ -870,12 +863,17 @@ static int __pppoe_xmit(struct sock *sk, struct sk_buff *skb)
if (skb_cow(skb, sizeof(*ph) + dev->hard_header_len))
goto abort;
- ph = (struct pppoe_hdr *) skb_push(skb, sizeof(struct pppoe_hdr));
- memcpy(ph, &hdr, sizeof(struct pppoe_hdr));
- skb->protocol = __constant_htons(ETH_P_PPP_SES);
-
+ __skb_push(skb, sizeof(*ph));
skb_reset_network_header(skb);
+ ph = pppoe_hdr(skb);
+ ph->ver = 1;
+ ph->type = 1;
+ ph->code = 0;
+ ph->sid = po->num;
+ ph->length = htons(data_len);
+
+ skb->protocol = __constant_htons(ETH_P_PPP_SES);
skb->dev = dev;
dev->hard_header(skb, dev, ETH_P_PPP_SES,
^ permalink raw reply related
* [PATCH 2/7] [PPP] pppoe: Fix data clobbering in __pppoe_xmit and return value
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[PPP] pppoe: Fix data clobbering in __pppoe_xmit and return value
The function __pppoe_xmit modifies the skb data and therefore it needs
to copy and skb data if it's cloned.
In fact, it currently allocates a new skb so that it can return 0 in
case of error without freeing the original skb. This is totally wrong
because returning zero is meant to indicate congestion whereupon pppoe
is supposed to wake up the upper layer once the congestion subsides.
This makes sense for ppp_async and ppp_sync but is out-of-place for
pppoe. This patch makes it always return 1 and free the skb.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/net/pppoe.c | 50 +++++++++++++-------------------------------------
1 files changed, 13 insertions(+), 37 deletions(-)
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 5ac3eff..8818253 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -850,9 +850,7 @@ static int __pppoe_xmit(struct sock *sk, struct sk_buff *skb)
struct net_device *dev = po->pppoe_dev;
struct pppoe_hdr hdr;
struct pppoe_hdr *ph;
- int headroom = skb_headroom(skb);
int data_len = skb->len;
- struct sk_buff *skb2;
if (sock_flag(sk, SOCK_DEAD) || !(sk->sk_state & PPPOX_CONNECTED))
goto abort;
@@ -866,53 +864,31 @@ static int __pppoe_xmit(struct sock *sk, struct sk_buff *skb)
if (!dev)
goto abort;
- /* Copy the skb if there is no space for the header. */
- if (headroom < (sizeof(struct pppoe_hdr) + dev->hard_header_len)) {
- skb2 = dev_alloc_skb(32+skb->len +
- sizeof(struct pppoe_hdr) +
- dev->hard_header_len);
-
- if (skb2 == NULL)
- goto abort;
-
- skb_reserve(skb2, dev->hard_header_len + sizeof(struct pppoe_hdr));
- skb_copy_from_linear_data(skb, skb_put(skb2, skb->len),
- skb->len);
- } else {
- /* Make a clone so as to not disturb the original skb,
- * give dev_queue_xmit something it can free.
- */
- skb2 = skb_clone(skb, GFP_ATOMIC);
-
- if (skb2 == NULL)
- goto abort;
- }
+ /* Copy the data if there is no space for the header or if it's
+ * read-only.
+ */
+ if (skb_cow(skb, sizeof(*ph) + dev->hard_header_len))
+ goto abort;
- ph = (struct pppoe_hdr *) skb_push(skb2, sizeof(struct pppoe_hdr));
+ ph = (struct pppoe_hdr *) skb_push(skb, sizeof(struct pppoe_hdr));
memcpy(ph, &hdr, sizeof(struct pppoe_hdr));
- skb2->protocol = __constant_htons(ETH_P_PPP_SES);
+ skb->protocol = __constant_htons(ETH_P_PPP_SES);
- skb_reset_network_header(skb2);
+ skb_reset_network_header(skb);
- skb2->dev = dev;
+ skb->dev = dev;
- dev->hard_header(skb2, dev, ETH_P_PPP_SES,
+ dev->hard_header(skb, dev, ETH_P_PPP_SES,
po->pppoe_pa.remote, NULL, data_len);
- /* We're transmitting skb2, and assuming that dev_queue_xmit
- * will free it. The generic ppp layer however, is expecting
- * that we give back 'skb' (not 'skb2') in case of failure,
- * but free it in case of success.
- */
-
- if (dev_queue_xmit(skb2) < 0)
+ if (dev_queue_xmit(skb) < 0)
goto abort;
- kfree_skb(skb);
return 1;
abort:
- return 0;
+ kfree_skb(skb);
+ return 1;
}
^ permalink raw reply related
* [0/7] [PPP]: Fix shared/cloned/non-linear skb bugs (was: malformed captured packets)
From: Herbert Xu @ 2007-08-31 9:06 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras
Cc: Toralf Förster, netdev
In-Reply-To: <46D69323.3070503@katalix.com>
On Thu, Aug 30, 2007 at 09:51:31AM +0000, James Chapman wrote:
>
> The captured PPPoE stream seems to show incorrect data lengths in the
> PPPoE header for some captured PPPoE packets. The kernel's PPPoE
> datapath uses this length to extract the PPP frame and send it through
> to the ppp interface. Since your ppp stream is fine, the actual PPPoE
> header contents must be correct when it is parsed by the kernel PPPoE
> code. It seems more likely that this is a wireshark bug to me.
If he were using the kernel pppoe driver, then this is because
PPP filtering is writing over a cloned skb without copying it.
In fact, there seems to be quite a few bugs of this kind in
the various ppp*.c files.
Please try the following patches to see if they make a
difference.
I've audited ppp_generic.c and pppoe.c. I'll do pppol2tp
tomorrow.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-08-31 9:05 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <46D7D072.5060508@bigtelecom.ru>
On Fri, Aug 31, 2007 at 12:25:22PM +0400, Badalian Vyacheslav wrote:
> i not have testing mashine.
> we have 2 mashine and dynamic routing. if 1 mashine down - all traffic
> go to second mashine.
> I can test is on this mashines but i need that testing mashine will
> reboot on kernel panic (sysctl message). No freezes =)
>
> Ok. i try 2.6.23-rc4.
...but without testing machine it can be too much risk! New versions
of kernel can break your applications (sometimes they should be at
least rebuilded).
So, maybe you would better try this, 'less testing', version of my patch:
Jarek P.
---
diff -Nurp linux-2.6.22.5-/net/sched/sch_htb.c linux-2.6.22.5/net/sched/sch_htb.c
--- linux-2.6.22.5-/net/sched/sch_htb.c 2007-07-09 01:32:17.000000000 +0200
+++ linux-2.6.22.5/net/sched/sch_htb.c 2007-08-31 08:43:45.000000000 +0200
@@ -688,7 +688,11 @@ static void htb_rate_timer(unsigned long
/* lock queue so that we can muck with it */
- spin_lock_bh(&sch->dev->queue_lock);
+ if (!spin_trylock_bh(&sch->dev->queue_lock)) {
+ q->rttim.expires = jiffies + 1;
+ add_timer(&q->rttim);
+ return;
+ }
q->rttim.expires = jiffies + HZ;
add_timer(&q->rttim);
@@ -1306,7 +1310,8 @@ static void htb_destroy(struct Qdisc *sc
qdisc_watchdog_cancel(&q->watchdog);
#ifdef HTB_RATECM
- del_timer_sync(&q->rttim);
+ if (!del_timer_sync(&q->rttim))
+ del_timer(&q->rttim);
#endif
/* This line used to be after htb_destroy_class call below
and surprisingly it worked in 2.4. But it must precede it
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-08-31 8:49 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <46D7D072.5060508@bigtelecom.ru>
On Fri, Aug 31, 2007 at 12:25:22PM +0400, Badalian Vyacheslav wrote:
> i not have testing mashine.
> we have 2 mashine and dynamic routing. if 1 mashine down - all traffic
> go to second mashine.
> I can test is on this mashines but i need that testing mashine will
> reboot on kernel panic (sysctl message). No freezes =)
>
> Ok. i try 2.6.23-rc4.
>
> >On Fri, Aug 31, 2007 at 11:04:21AM +0400, Badalian Vyacheslav wrote:
> >
> >>I try you patch. Also i try add more debug options to kernel. I catch
> >>(BUG: spinlock lockup on CPU#3, tc/6403, f742e200)
BTW, I think after this BUG could be something more about other CPUs.
Could you check this?
Jarek P.
PS: If it's possible try to not cut too much: if there is something
confidential mask this with some XXX or mark the cut with... There
could matter what else is run at the same time (including other
driver's warnings). If you think it's too much for a list you can
send it to me only.
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-08-31 8:25 UTC (permalink / raw)
To: Jarek Poplawski, netdev
In-Reply-To: <20070831075909.GA1772@ff.dom.local>
i not have testing mashine.
we have 2 mashine and dynamic routing. if 1 mashine down - all traffic
go to second mashine.
I can test is on this mashines but i need that testing mashine will
reboot on kernel panic (sysctl message). No freezes =)
Ok. i try 2.6.23-rc4.
> On Fri, Aug 31, 2007 at 11:04:21AM +0400, Badalian Vyacheslav wrote:
>
>> I try you patch. Also i try add more debug options to kernel. I catch
>> (BUG: spinlock lockup on CPU#3, tc/6403, f742e200)
>> All info in file. Ready for next patch ;)
>>
>
> I've to look at this, but actually my patch wrongly added this one
> warning. I hope you did this on a testing machine...
>
> Anyway there could be something new but I need some time. If possible,
> 2.6.23-rc4 should be the best thing for testing yet.
>
> Thanks,
> Jarek P.
>
>
^ permalink raw reply
* tcp user timeout option
From: Joakim Koskela @ 2007-08-31 8:23 UTC (permalink / raw)
To: netdev
Hi,
Does anybody know of any effort put into implementing support for the TCP user
timeout option in Linux?
The related draft:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-06.txt
Basically its a per-connection parameter which says how long data can remain
unacknowledged before the connection is closed.
br, j
^ permalink raw reply
* zd1211rw regression, device does not enumerate
From: Oliver Neukum @ 2007-08-31 7:59 UTC (permalink / raw)
To: netdev, linux-usb-devel, Daniel Drake, John W.Linville,
Michal Piotrowski
Hi,
after bisection it boils down to this patch:
oliver@oenone:/home/olli2/Trees/linux-2.6> git bisect bad
74553aedd46b3a2cae986f909cf2a3f99369decc is first bad commit
commit 74553aedd46b3a2cae986f909cf2a3f99369decc
Author: Daniel Drake <dsd@gentoo.org>
Date: Sun Jul 1 18:22:32 2007 +0100
[PATCH] zd1211rw: Defer firmware load until first ifup
that plugging in my device I get an error:
Aug 16 13:17:11 oenone kernel: zd1211rw 3-4.3:1.0: zd1211b chip 0ace:1215 v4810 high 00-02-72 AL2230_RF pa0 g--NS
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh1-0001/ffff810037c04960 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: ehci_hcd 0000:00:02.2: reused qh ffff810037c04960 schedule
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh1-0001/ffff810037c04960 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:12 oenone ifup: Cannot enable interface eth2.
Aug 16 13:17:12 oenone kernel: zd1211rw 3-4.3:1.0: error ioread32(CR_REG1): -110
Aug 16 13:17:12 oenone kernel: usb 3-4.3: unlink qh1-0001/ffff810037c04960 start 0 [2/0 us]
Aug 16 13:17:12 oenone ifup-route: interface eth2 is not up
Bus 003 Device 006: ID 0ace:1215 ZyDAS
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x0ace ZyDAS
idProduct 0x1215
bcdDevice 48.10
iManufacturer 16 ZyDAS
iProduct 32 USB2.0 WLAN
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Regards
Oliver
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* zd1211rw regression, device does not enumerate
From: Oliver Neukum @ 2007-08-31 7:58 UTC (permalink / raw)
To: netdev, linux-usb-devel, Daniel Drake, John W.Linville,
Michal Piotrowski
Hi,
after bisection it boils down to this patch:
oliver@oenone:/home/olli2/Trees/linux-2.6> git bisect bad
74553aedd46b3a2cae986f909cf2a3f99369decc is first bad commit
commit 74553aedd46b3a2cae986f909cf2a3f99369decc
Author: Daniel Drake <dsd@gentoo.org>
Date: Sun Jul 1 18:22:32 2007 +0100
[PATCH] zd1211rw: Defer firmware load until first ifup
that plugging in my device I get an error:
Aug 16 13:17:11 oenone kernel: zd1211rw 3-4.3:1.0: zd1211b chip 0ace:1215 v4810 high 00-02-72 AL2230_RF pa0 g--NS
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh1-0001/ffff810037c04960 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: ehci_hcd 0000:00:02.2: reused qh ffff810037c04960 schedule
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh1-0001/ffff810037c04960 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: link qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:11 oenone kernel: usb 3-4.3: unlink qh0-00ff/ffff810037c04a00 start 0 [2/0 us]
Aug 16 13:17:12 oenone ifup: Cannot enable interface eth2.
Aug 16 13:17:12 oenone kernel: zd1211rw 3-4.3:1.0: error ioread32(CR_REG1): -110
Aug 16 13:17:12 oenone kernel: usb 3-4.3: unlink qh1-0001/ffff810037c04960 start 0 [2/0 us]
Aug 16 13:17:12 oenone ifup-route: interface eth2 is not up
Bus 003 Device 006: ID 0ace:1215 ZyDAS
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x0ace ZyDAS
idProduct 0x1215
bcdDevice 48.10
iManufacturer 16 ZyDAS
iProduct 32 USB2.0 WLAN
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Regards
Oliver
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-08-31 7:59 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <46D7BD75.3080008@bigtelecom.ru>
On Fri, Aug 31, 2007 at 11:04:21AM +0400, Badalian Vyacheslav wrote:
>
> I try you patch. Also i try add more debug options to kernel. I catch
> (BUG: spinlock lockup on CPU#3, tc/6403, f742e200)
> All info in file. Ready for next patch ;)
I've to look at this, but actually my patch wrongly added this one
warning. I hope you did this on a testing machine...
Anyway there could be something new but I need some time. If possible,
2.6.23-rc4 should be the best thing for testing yet.
Thanks,
Jarek P.
^ permalink raw reply
* Re: malformed captured packets
From: Toralf Förster @ 2007-08-31 7:36 UTC (permalink / raw)
To: James Chapman; +Cc: netdev, wireshark-dev
In-Reply-To: <46D69323.3070503@katalix.com>
[-- Attachment #1.1: Type: text/plain, Size: 3945 bytes --]
@wireshark-devs:
The topic is related to
http://www.wireshark.org/lists/wireshark-users/200707/msg00187.html
and http://bugzilla.kernel.org/show_bug.cgi?id=8793
@all:
Hi,
Am Donnerstag, 30. August 2007 schrieb James Chapman:
> Toralf Förster wrote:
> > Am Mittwoch, 29. August 2007 schrieb James Chapman:
> >
> >> Can you provide more information about the problem, please? Are you
> >> using a simple DSL modem with PPPoE, such that the ppp0 interface is
> >> that of the pppd started by a local PPPoE server? Is this a problem only
> >> with packet capture or are you seeing actual data corruption? Did this
> >> work with previous kernels? What is the network topology related to the
> >> DSL interface?
> >>
> >
> > I use a ThinkPad T41 with this Ethernet controller:
> >
> > n22 ~ # lspci | grep Eth
> > 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)
> > 02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
> >
> > My DSL provider is Alice DSL (formerly Hansenet) in Hamburg. The T41 is connected
> > with an Ethernet cable to a Siemens DSL modem. The modem (just a modem, not a
> > router) itself is connected to the DSL splitter which itself is plugged into socket.
> >
> > The current ppp version I'm using is net-dialup/ppp-2.4.4-r9
> >
> > Here are my kernel config settings:
> >
> > n22 ~ # zgrep PPP /proc/config.gz
> > CONFIG_PPP=m
> > # CONFIG_PPP_MULTILINK is not set
> > CONFIG_PPP_FILTER=y
> > # CONFIG_PPP_ASYNC is not set
> > # CONFIG_PPP_SYNC_TTY is not set
> > CONFIG_PPP_DEFLATE=m
> > # CONFIG_PPP_BSDCOMP is not set
> > # CONFIG_PPP_MPPE is not set
> > CONFIG_PPPOE=m
> >
> > I observed this problem since a long time with different kernel versions (Gentoo,
> > plain vanilla kernel, git sources) while playing with ethereal - currently known
> > as wireshark.
> >
> > I'm wondering b/c for kscd eg. it is always the IP packet containing the content
> > information of a CD (or even a <CD is unknown> message) with is struggled.
> > This packets prevents me from using the "Follow TCP Strem" feature of wireshark
> > for an easy look into the plain text of all TCP packets of this HTTP stream
> > (which was in fact the trigger for me to have a deeper look into the sniffed
> > stream from ppp0 and eth0).
> >
> > For other apps I observed similar things which cannot fully be explained by
> > terms like "TCP checksum offloading".
> >
> > I didn't observed any malfunction at application level so it might be an issue
> > with the capturing itself.
> >
> > Why is the ppp stream always ok in opposite to the eth0 stream ?
>
> Toralf, thanks for providing more info about your setup.
>
> Are you using kernel-mode PPPoE? I know some PPPoE servers do the PPPoE
> datapath in userspace...
>
> The captured PPPoE stream seems to show incorrect data lengths in the
> PPPoE header for some captured PPPoE packets. The kernel's PPPoE
> datapath uses this length to extract the PPP frame and send it through
> to the ppp interface. Since your ppp stream is fine, the actual PPPoE
> header contents must be correct when it is parsed by the kernel PPPoE
> code. It seems more likely that this is a wireshark bug to me.
>
> Is it possible to get captures from ppp0 and eth0 simultaneously such
> that they show the same ppp instance? This might give more clues.
>
Hi,
yes, I'm using kernel-mode PPPoE. I sniffed at both interfaces the same network stream with the commands:
$>tcpdump -i eth0 -p -s 0 -w tcpdump_eth0.pcap
$>tcpdump -i eth0 -p -s 0 -w tcpdump_eth0.pcap
After that I made an
$>rm -rf .cddb/; kscd
at the 3rd konsole and attached the 2 pcap streams onto this mail.
Thanks for your help.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #1.2: tcpdump_ppp0.pcap --]
[-- Type: application/octet-stream, Size: 6294 bytes --]
[-- Attachment #1.3: tcpdump_eth0.pcap --]
[-- Type: application/octet-stream, Size: 6684 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-08-31 7:04 UTC (permalink / raw)
To: Jarek Poplawski, netdev
In-Reply-To: <20070830123751.GA2778@ff.dom.local>
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
I try you patch. Also i try add more debug options to kernel. I catch
(BUG: spinlock lockup on CPU#3, tc/6403, f742e200)
All info in file. Ready for next patch ;)
>> Jarek Poplawski ??????????:
>>
> ...
>
>>> On the other hand disabling local interrupts shouldn't be enough here,
>>> so it's really strange... Did you get this remotely? Are you sure LOC
>>> only? (Anyway this 2.6.23-rc4 should be interesting.)
>>>
> ...
>
>> Only LOC changes... icmp answer = 50-70ms... after 1-2 hours traffic
>> level is down and SI on CPU0 and CPU2 change to above 50%. ksoftirqd
>> free CPU usage. I have this bug 3-4 times in week. If you need info what
>> i can see only in bug still processing - i may try get this info for you.
>>
>
> Any additional info could be helpful. I'm not sure if all these
> computers do similar htb processing, or it's another problem?
> As I've written before htb before 2.6.23-rc1 has a problem with
> timer lockup during qdisc_destroy, so softirqs would be hit.
> If it's htb's fault 2.6.23-rc4 or my testing patch should help.
>
> I try to find in htb code another weak points. BTW, if during
> such lockups any processes are killed 'by hand' etc., without
> restarting the whole system, please let us know.
>
>
>> maybe help:
>>
>> 1U server INTEL, mb se7501w2
>>
>> nat-new ~ # lspci
>>
>
> lspci -v (or -vv should be more usable - but with dmesg at least)
>
> Jarek P.
>
>
>
[-- Attachment #2: bug.txt --]
[-- Type: text/plain, Size: 15944 bytes --]
[ 133.592929] HTB: quantum of class 10002 is big. Consider r2q change.
[ 133.606638] HTB: quantum of class 10004 is big. Consider r2q change.
[ 133.609442] HTB: quantum of class 10005 is big. Consider r2q change.
[ 133.612331] HTB: quantum of class 10007 is big. Consider r2q change.
[ 133.615099] HTB: quantum of class 10008 is big. Consider r2q change.
[ 133.624105] HTB: quantum of class 10002 is big. Consider r2q change.
[ 133.628133] HTB: quantum of class 10004 is big. Consider r2q change.
[ 133.630870] HTB: quantum of class 10005 is big. Consider r2q change.
[ 133.633649] HTB: quantum of class 10007 is big. Consider r2q change.
[ 133.636379] HTB: quantum of class 10008 is big. Consider r2q change.
[ 133.648717] u32 classifier
[ 133.648839] Performance counters on
[ 133.648957] input device check on
[ 133.649064] Actions configured
[ 135.430122] WARNING: at net/sched/sch_htb.c:404 htb_safe_rb_erase()
[ 135.430322] [<f88394c5>] htb_deactivate_prios+0x135/0x18c [sch_htb]
[ 135.430491] [<f883addd>] htb_dequeue+0x468/0x6d6 [sch_htb]
[ 135.430643] [<c02bcf9b>] __qdisc_run+0x1e/0x190
[ 135.430801] [<c02b352c>] dev_queue_xmit+0x152/0x266
[ 135.430920] [<c02b7a40>] neigh_resolve_output+0x1f2/0x224
[ 135.431085] [<c02ceaee>] ip_output+0x28f/0x2bd
[ 135.431261] [<c02cbd94>] dst_output+0x0/0x7
[ 135.431419] [<c02ce48b>] ip_build_and_send_pkt+0x1da/0x1ef
[ 135.431560] [<c02cbd94>] dst_output+0x0/0x7
[ 135.431698] [<c02dfbed>] tcp_v4_send_synack+0x9f/0xf3
[ 135.431842] [<c02e140a>] tcp_v4_conn_request+0x379/0x3ae
[ 135.431979] [<c02c6913>] rt_intern_hash+0x31f/0x331
[ 135.432121] [<c02da4f5>] tcp_rcv_state_process+0x62/0xad1
[ 135.432265] [<c02e090a>] tcp_v4_do_rcv+0x2be/0x311
[ 135.432405] [<c02e2938>] tcp_v4_rcv+0x86a/0x8de
[ 135.432547] [<c02c9ec9>] ip_local_deliver+0x18b/0x232
[ 135.432683] [<c02c9608>] ip_local_deliver_finish+0x0/0x1b2
[ 135.432824] [<c02c9d05>] ip_rcv+0x484/0x4bd
[ 135.432962] [<c02b155f>] netif_receive_skb+0x2bc/0x32b
[ 135.433105] [<c023ca05>] e1000_clean_rx_irq+0x375/0x444
[ 135.433252] [<c023c690>] e1000_clean_rx_irq+0x0/0x444
[ 135.433388] [<c023baa9>] e1000_clean+0x7a/0x249
[ 135.433528] [<c02b32e6>] net_rx_action+0x91/0x185
[ 135.433668] [<c011c8c6>] __do_softirq+0x5d/0xc1
[ 135.433806] [<c011c95c>] do_softirq+0x32/0x36
[ 135.433939] [<c01043e6>] do_IRQ+0x7e/0x90
[ 135.434075] [<c010d65d>] smp_apic_timer_interrupt+0x74/0x80
[ 135.434219] [<c010c7c5>] smp_call_function_interrupt+0x3c/0x52
[ 135.434352] [<c0102f1f>] common_interrupt+0x23/0x28
[ 135.434488] [<c0100ab1>] mwait_idle_with_hints+0x3b/0x3f
[ 135.434627] [<c0100bbc>] cpu_idle+0x59/0x6e
[ 135.434765] [<c0421bcd>] start_kernel+0x2ea/0x2f2
[ 135.434908] [<c0421440>] unknown_bootoption+0x0/0x202
[ 135.435044] =======================
[ 140.454198] WARNING: at net/sched/sch_htb.c:404 htb_safe_rb_erase()
[ 140.454311] [<f88394c5>] htb_deactivate_prios+0x135/0x18c [sch_htb]
[ 140.454469] [<f883addd>] htb_dequeue+0x468/0x6d6 [sch_htb]
[ 140.454616] [<c02bcf9b>] __qdisc_run+0x1e/0x190
[ 140.454764] [<c02b352c>] dev_queue_xmit+0x152/0x266
[ 140.454910] [<c02b7a40>] neigh_resolve_output+0x1f2/0x224
[ 140.455053] [<c02ceaee>] ip_output+0x28f/0x2bd
[ 140.455199] [<c02cbd94>] dst_output+0x0/0x7
[ 140.455341] [<c02cc13d>] ip_push_pending_frames+0x2f2/0x3b6
[ 140.455484] [<c02cbd94>] dst_output+0x0/0x7
[ 140.455625] [<c02cde53>] ip_send_reply+0x1a2/0x1f8
[ 140.455772] [<c0303e1b>] _read_unlock_bh+0x5/0xd
[ 140.455914] [<c02dfb1f>] tcp_v4_send_reset+0x10c/0x13b
[ 140.456059] [<c02e2948>] tcp_v4_rcv+0x87a/0x8de
[ 140.456202] [<c02c9ec9>] ip_local_deliver+0x18b/0x232
[ 140.456343] [<c02c9608>] ip_local_deliver_finish+0x0/0x1b2
[ 140.456490] [<c02c9d05>] ip_rcv+0x484/0x4bd
[ 140.456633] [<c023c5cb>] e1000_alloc_rx_buffers+0x1bb/0x280
[ 140.456784] [<c02b155f>] netif_receive_skb+0x2bc/0x32b
[ 140.456925] [<c023ca05>] e1000_clean_rx_irq+0x375/0x444
[ 140.457069] [<c023c690>] e1000_clean_rx_irq+0x0/0x444
[ 140.457210] [<c023baa9>] e1000_clean+0x7a/0x249
[ 140.457351] [<c02b32e6>] net_rx_action+0x91/0x185
[ 140.457493] [<c011c8c6>] __do_softirq+0x5d/0xc1
[ 140.457637] [<c011c95c>] do_softirq+0x32/0x36
[ 140.457781] [<c01043e6>] do_IRQ+0x7e/0x90
[ 140.457924] [<c010d65d>] smp_apic_timer_interrupt+0x74/0x80
[ 140.458068] [<c010c7c5>] smp_call_function_interrupt+0x3c/0x52
[ 140.458212] [<c0102f1f>] common_interrupt+0x23/0x28
[ 140.458354] [<c0100ab1>] mwait_idle_with_hints+0x3b/0x3f
[ 140.458495] [<c0100bbc>] cpu_idle+0x59/0x6e
[ 140.458635] [<c0421bcd>] start_kernel+0x2ea/0x2f2
[ 140.458783] [<c0421440>] unknown_bootoption+0x0/0x202
[ 140.458925] =======================
[ 383.290939] BUG: spinlock lockup on CPU#3, tc/6403, f742e200
[ 383.291058] [<c01c5fe9>] _raw_spin_lock+0xbb/0xdc
[ 383.291203] [<c02bcb1d>] qdisc_lock_tree+0x14/0x1c
[ 383.291346] [<f883a22e>] htb_change_class+0x23a/0x505 [sch_htb]
[ 383.291495] [<c02bda57>] tc_ctl_tclass+0x1ae/0x1fd
[ 383.291633] [<c02bd8a9>] tc_ctl_tclass+0x0/0x1fd
[ 383.291774] [<c02b8898>] rtnetlink_rcv_msg+0x18d/0x1a7
[ 383.291911] [<c02c2a16>] netlink_run_queue+0x65/0xdb
[ 383.292055] [<c02b870b>] rtnetlink_rcv_msg+0x0/0x1a7
[ 383.292195] [<c02b86c7>] rtnetlink_rcv+0x25/0x3d
[ 383.292332] [<c02c2e58>] netlink_data_ready+0x12/0x52
[ 383.292468] [<c02c1e92>] netlink_sendskb+0x1c/0x33
[ 383.292605] [<c02c2e3a>] netlink_sendmsg+0x23b/0x247
[ 383.292746] [<c02a837b>] sock_sendmsg+0xbc/0xd4
[ 383.292890] [<c0127bad>] autoremove_wake_function+0x0/0x35
[ 383.293035] [<c0127bad>] autoremove_wake_function+0x0/0x35
[ 383.293179] [<c01c44a3>] copy_from_user+0x2d/0x59
[ 383.293314] [<c02ae8d9>] verify_iovec+0x3e/0x6d
[ 383.293452] [<c02a8527>] sys_sendmsg+0x194/0x1f9
[ 383.293590] [<c02a8d9b>] sys_recvmsg+0x14d/0x1cf
[ 383.293727] [<c01c44a3>] copy_from_user+0x2d/0x59
[ 383.293864] [<c013bfc4>] __alloc_pages+0x63/0x297
[ 383.294004] [<c0143be0>] __handle_mm_fault+0x7bd/0x7ef
[ 383.294148] [<c02ab565>] sock_def_write_space+0x15/0x8e
[ 383.294284] [<c02ab054>] sock_setsockopt+0x4bb/0x4c5
[ 383.295769] [<c02a949a>] sys_socketcall+0x223/0x242
[ 383.295911] [<c030520e>] do_page_fault+0x0/0x534
[ 383.296051] [<c010250e>] sysenter_past_esp+0x5f/0x85
[ 383.296192] =======================
############# SYSTEM IS FREEZE. reboot on panic not work. Reboot manual
[ 30.748000] HTB: quantum of class 10002 is big. Consider r2q change.
[ 30.774000] HTB: quantum of class 10004 is big. Consider r2q change.
[ 30.777000] HTB: quantum of class 10005 is big. Consider r2q change.
[ 30.779000] HTB: quantum of class 10007 is big. Consider r2q change.
[ 30.782000] HTB: quantum of class 10008 is big. Consider r2q change.
[ 30.790000] HTB: quantum of class 10002 is big. Consider r2q change.
[ 30.794000] HTB: quantum of class 10004 is big. Consider r2q change.
[ 30.797000] HTB: quantum of class 10005 is big. Consider r2q change.
[ 30.800000] HTB: quantum of class 10007 is big. Consider r2q change.
[ 30.803000] HTB: quantum of class 10008 is big. Consider r2q change.
[ 30.815000] u32 classifier
[ 30.815000] Performance counters on
[ 30.815000] input device check on
[ 30.816000] Actions configured
[ 32.684000] WARNING: at net/sched/sch_htb.c:404 htb_safe_rb_erase()
[ 32.684000] [<f88394c5>] htb_deactivate_prios+0x135/0x18c [sch_htb]
[ 32.684000] [<f883addd>] htb_dequeue+0x468/0x6d6 [sch_htb]
[ 32.684000] [<c02bcf9b>] __qdisc_run+0x1e/0x190
[ 32.684000] [<c02b352c>] dev_queue_xmit+0x152/0x266
[ 32.684000] [<c02b7a40>] neigh_resolve_output+0x1f2/0x224
[ 32.684000] [<c02ceaee>] ip_output+0x28f/0x2bd
[ 32.684000] [<c02cbd94>] dst_output+0x0/0x7
[ 32.684000] [<c02ce1c2>] ip_queue_xmit+0x319/0x35e
[ 32.684000] [<c02cbd94>] dst_output+0x0/0x7
[ 32.684000] [<c02c700a>] __ip_route_output_key+0x6e5/0x6ff
[ 32.684000] [<c02e0fd3>] tcp_v4_send_check+0x80/0xb6
[ 32.684000] [<c02dc494>] tcp_transmit_skb+0x65c/0x68f
[ 32.684000] [<c02ad694>] __alloc_skb+0x49/0xf5
[ 32.684000] [<c02de876>] tcp_connect+0x2a8/0x327
[ 32.684000] [<c02e1a15>] tcp_v4_connect+0x468/0x586
[ 32.684000] [<c02ec4d5>] inet_stream_connect+0x7f/0x1ff
[ 32.684000] [<c013e195>] mark_page_accessed+0x1c/0x30
[ 32.684000] [<c01c44a3>] copy_from_user+0x2d/0x59
[ 32.684000] [<c02a7eca>] sys_connect+0x72/0x9c
[ 32.684000] [<c02a9d5f>] release_sock+0x13/0x94
[ 32.684000] [<c02e0b3f>] tcp_v4_init_sock+0x6f/0x141
[ 32.684000] [<c0303e2d>] _spin_unlock_bh+0x5/0xd
[ 32.684000] [<c02ab054>] sock_setsockopt+0x4bb/0x4c5
[ 32.684000] [<c0161002>] d_instantiate+0x3f/0x4c
[ 32.684000] [<c02a7e22>] sys_setsockopt+0x53/0x89
[ 32.684000] [<c02a9306>] sys_socketcall+0x8f/0x242
[ 32.684000] [<c010250e>] sysenter_past_esp+0x5f/0x85
[ 32.684000] =======================
### System is freeze. Keyboard not work. reboot on panic not work. Reboot
manual
[ 127.698542] HTB: quantum of class 10002 is big. Consider r2q change.
[ 127.722805] HTB: quantum of class 10004 is big. Consider r2q change.
[ 127.725820] HTB: quantum of class 10005 is big. Consider r2q change.
[ 127.728585] HTB: quantum of class 10007 is big. Consider r2q change.
[ 127.731314] HTB: quantum of class 10008 is big. Consider r2q change.
[ 127.743386] HTB: quantum of class 10002 is big. Consider r2q change.
[ 127.747382] HTB: quantum of class 10004 is big. Consider r2q change.
[ 127.750136] HTB: quantum of class 10005 is big. Consider r2q change.
[ 127.752952] HTB: quantum of class 10007 is big. Consider r2q change.
[ 127.755631] WARNING: at net/sched/sch_htb.c:404 htb_safe_rb_erase()
[ 127.755692] HTB: quantum of class 10008 is big. Consider r2q change.
[ 127.755853] [<f88394c5>] htb_deactivate_prios+0x135/0x18c [sch_htb]
[ 127.756000] [<f883addd>] htb_dequeue+0x468/0x6d6 [sch_htb]
[ 127.756144] [<c01d7148>] extract_entropy+0x45/0x89
[ 127.756289] [<c02bcf9b>] __qdisc_run+0x1e/0x190
[ 127.756434] [<c02b352c>] dev_queue_xmit+0x152/0x266
[ 127.756574] [<c02e80d0>] arp_send+0x4c/0x64
[ 127.756720] [<c02e76d2>] arp_xmit+0x4d/0x51
[ 127.756857] [<c02e839b>] arp_process+0x2b3/0x50b
[ 127.757001] [<c013a5dc>] mempool_free+0x66/0x6b
[ 127.757151] [<c0303ed7>] _spin_lock_irqsave+0x9/0xd
[ 127.757291] [<c01d6c48>] __add_entropy_words+0x58/0x184
[ 127.757430] [<c02e86e2>] arp_rcv+0xef/0x103
[ 127.757567] [<c02b155f>] netif_receive_skb+0x2bc/0x32b
[ 127.757705] [<c023ca05>] e1000_clean_rx_irq+0x375/0x444
[ 127.757853] [<c023c690>] e1000_clean_rx_irq+0x0/0x444
[ 127.757990] [<c023baa9>] e1000_clean+0x7a/0x249
[ 127.758126] [<c02b32e6>] net_rx_action+0x91/0x185
[ 127.758264] [<c011c8c6>] __do_softirq+0x5d/0xc1
[ 127.758404] [<c011c95c>] do_softirq+0x32/0x36
[ 127.758547] [<c01043e6>] do_IRQ+0x7e/0x90
[ 127.758696] [<c010d65d>] smp_apic_timer_interrupt+0x74/0x80
[ 127.758840] [<c010c7c5>] smp_call_function_interrupt+0x3c/0x52
[ 127.758978] [<c0102f1f>] common_interrupt+0x23/0x28
[ 127.759115] [<c0100ab1>] mwait_idle_with_hints+0x3b/0x3f
[ 127.759254] [<c0100bbc>] cpu_idle+0x59/0x6e
[ 127.759390] [<c0421bcd>] start_kernel+0x2ea/0x2f2
[ 127.759534] [<c0421440>] unknown_bootoption+0x0/0x202
[ 127.759672] =======================
[ 127.765948] u32 classifier
[ 127.766062] Performance counters on
[ 127.766177] input device check on
[ 127.766293] Actions configured
[ 128.857330] WARNING: at net/sched/sch_htb.c:404 htb_safe_rb_erase()
[ 128.857449] [<f88394c5>] htb_deactivate_prios+0x135/0x18c [sch_htb]
[ 128.857606] [<f883addd>] htb_dequeue+0x468/0x6d6 [sch_htb]
[ 128.857754] [<c02bcf9b>] __qdisc_run+0x1e/0x190
[ 128.857901] [<c02b352c>] dev_queue_xmit+0x152/0x266
[ 128.858048] [<c02e80d0>] arp_send+0x4c/0x64
[ 128.858191] [<c02e76d2>] arp_xmit+0x4d/0x51
[ 128.858331] [<c02e8936>] arp_solicit+0x132/0x190
[ 128.858469] [<c02b814f>] neigh_timer_handler+0x238/0x281
[ 128.858606] [<c02b7f17>] neigh_timer_handler+0x0/0x281
[ 128.858744] [<c011f798>] run_timer_softirq+0xfa/0x15d
[ 128.858887] [<c011c8c6>] __do_softirq+0x5d/0xc1
[ 128.859027] [<c011c95c>] do_softirq+0x32/0x36
[ 128.859166] [<c010d65d>] smp_apic_timer_interrupt+0x74/0x80
[ 128.859307] [<c010c7c5>] smp_call_function_interrupt+0x3c/0x52
[ 128.859449] [<c0102fdc>] apic_timer_interrupt+0x28/0x30
[ 128.859589] [<c0100ab1>] mwait_idle_with_hints+0x3b/0x3f
[ 128.859727] [<c0100bbc>] cpu_idle+0x59/0x6e
[ 128.859862] [<c0421bcd>] start_kernel+0x2ea/0x2f2
[ 128.860007] [<c0421440>] unknown_bootoption+0x0/0x202
[ 128.860144] =======================
[ 189.139227] megaraid: aborting-1187 cmd=28 <c=2 t=0 l=0>
[ 189.139337] megaraid: 1187:11[255:0], abort from completed list
### System is freeze. Keyboard not work. reboot on panic not work. Reboot
manual
[ 31.131000] HTB: quantum of class 10002 is big. Consider r2q change.
[ 31.156000] HTB: quantum of class 10004 is big. Consider r2q change.
[ 31.159000] HTB: quantum of class 10005 is big. Consider r2q change.
[ 31.162000] HTB: quantum of class 10007 is big. Consider r2q change.
[ 31.165000] HTB: quantum of class 10008 is big. Consider r2q change.
[ 31.177000] HTB: quantum of class 10002 is big. Consider r2q change.
[ 31.181000] HTB: quantum of class 10004 is big. Consider r2q change.
[ 31.183000] HTB: quantum of class 10005 is big. Consider r2q change.
[ 31.186000] HTB: quantum of class 10007 is big. Consider r2q change.
[ 31.189000] HTB: quantum of class 10008 is big. Consider r2q change.
[ 31.200000] u32 classifier
[ 31.200000] Performance counters on
[ 31.200000] input device check on
[ 31.200000] Actions configured
[ 32.480000] WARNING: at net/sched/sch_htb.c:404 htb_safe_rb_erase()
[ 32.480000] [<f88394c5>] htb_deactivate_prios+0x135/0x18c [sch_htb]
[ 32.480000] [<f883addd>] htb_dequeue+0x468/0x6d6 [sch_htb]
[ 32.480000] [<c02bcf9b>] __qdisc_run+0x1e/0x190
[ 32.480000] [<c02b352c>] dev_queue_xmit+0x152/0x266
[ 32.480000] [<c02b7a40>] neigh_resolve_output+0x1f2/0x224
[ 32.480000] [<c02ceaee>] ip_output+0x28f/0x2bd
[ 32.480000] [<c02cbd94>] dst_output+0x0/0x7
[ 32.480000] [<c02ce48b>] ip_build_and_send_pkt+0x1da/0x1ef
[ 32.480000] [<c02cbd94>] dst_output+0x0/0x7
[ 32.480000] [<c02dfbed>] tcp_v4_send_synack+0x9f/0xf3
[ 32.480000] [<c02e140a>] tcp_v4_conn_request+0x379/0x3ae
[ 32.480000] [<c02c6913>] rt_intern_hash+0x31f/0x331
[ 32.480000] [<c02da4f5>] tcp_rcv_state_process+0x62/0xad1
[ 32.480000] [<c02e090a>] tcp_v4_do_rcv+0x2be/0x311
[ 32.480000] [<c02e2938>] tcp_v4_rcv+0x86a/0x8de
[ 32.480000] [<c02c9ec9>] ip_local_deliver+0x18b/0x232
[ 32.480000] [<c02c9608>] ip_local_deliver_finish+0x0/0x1b2
[ 32.480000] [<c02c9d05>] ip_rcv+0x484/0x4bd
[ 32.480000] [<c02b155f>] netif_receive_skb+0x2bc/0x32b
[ 32.480000] [<c023ca05>] e1000_clean_rx_irq+0x375/0x444
[ 32.480000] [<c023c690>] e1000_clean_rx_irq+0x0/0x444
[ 32.480000] [<c023baa9>] e1000_clean+0x7a/0x249
[ 32.480000] [<c02b32e6>] net_rx_action+0x91/0x185
[ 32.480000] [<c011c8c6>] __do_softirq+0x5d/0xc1
[ 32.480000] [<c011c95c>] do_softirq+0x32/0x36
[ 32.480000] [<c01043e6>] do_IRQ+0x7e/0x90
[ 32.480000] [<c010d65d>] smp_apic_timer_interrupt+0x74/0x80
[ 32.480000] [<c010c7c5>] smp_call_function_interrupt+0x3c/0x52
[ 32.480000] [<c0102f1f>] common_interrupt+0x23/0x28
[ 32.480000] [<c0100ab1>] mwait_idle_with_hints+0x3b/0x3f
[ 32.480000] [<c0100bbc>] cpu_idle+0x59/0x6e
[ 32.480000] [<c0421bcd>] start_kernel+0x2ea/0x2f2
[ 32.480000] [<c0421440>] unknown_bootoption+0x0/0x202
[ 32.480000] =======================
[ 76.104000] input: AT Translated Set 2 keyboard as /class/input/input2
### System is freeze. Keyboard not work. reboot on panic not work. Reboot
manual
^ permalink raw reply
* Re: [PATCH] Remove write-only variable from pktgen_thread
From: David Miller @ 2007-08-31 5:46 UTC (permalink / raw)
To: sukadev; +Cc: xemul, akpm, oleg, containers, linux-kernel, netdev
In-Reply-To: <20070829213356.GC18542@us.ibm.com>
From: sukadev@us.ibm.com
Date: Wed, 29 Aug 2007 14:33:56 -0700
> Pavel Emelianov [xemul@openvz.org] wrote:
> | The pktgen_thread.pid is set to current->pid and is never used
> | after this. So remove this at all.
> |
> | Found during isolating the explicit pid/tgid usage.
> |
> | Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Good observation that its not being used :-)
>
> Acked-by: Sukadev Bhattiprolu <sukadev@us.ibm.com>
Patch applied, thanks.
^ permalink raw reply
* Re: [patch 0/1][RFC] add a private field to the sock structure
From: David Miller @ 2007-08-31 5:40 UTC (permalink / raw)
To: acme; +Cc: dlezcano, netdev, ralf
In-Reply-To: <20070829191831.GA16184@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Wed, 29 Aug 2007 16:18:31 -0300
> Nah, it still there, sk_protinfo, its just ax25 that uses it
> (nudge(Ralf)). How do we state that a struct field is deprecated and
> will be removed soon(tm)?
You get rid of all the in-tree users and then just kill it :)
More seriously, I don't think we need a deprecation schedule
for a struct member, either it's not used in-tree anymore or
it isn't. We'll go crazy with any other policy and it's
difficult enough shrinking these things :-)
^ permalink raw reply
* some weird corruption in net-2.6.24
From: David Miller @ 2007-08-31 5:39 UTC (permalink / raw)
To: netdev; +Cc: tgraf
Every so often some piece of userland dies, and often it's
bad enough that my desktop session logs out.
I've been trying to find some clues and it seems to happen
about as often as openswan rekeys my VPN, so one suspect
area is the netlink cleanups to xfrm_user.
I plan to do some auditing of those changes looking for
errors, but if someone can beat me to it... :-)
^ permalink raw reply
* Re: [PATCH] [NET_SCHED] sch_prio.c: remove duplicate call of tc_classify()
From: David Miller @ 2007-08-31 5:36 UTC (permalink / raw)
To: lucas.nussbaum; +Cc: netdev, kaber
In-Reply-To: <20070830072817.GA9617@xanadu.blop.info>
From: Lucas Nussbaum <lucas.nussbaum@imag.fr>
Date: Thu, 30 Aug 2007 09:28:17 +0200
> Hi,
>
> When CONFIG_NET_CLS_ACT is enabled, tc_classify() is called twice in
> prio_classify(). This causes "interesting" behaviour: with the setup
> below, packets are duplicated, sent twice to ifb0, and then loop in and
> out of ifb0.
>
> The patch uses the previously calculated return value in the switch,
> which is probably what Patrick had in mind in commit
> bdba91ec70fb5ccbdeb1c7068319adc6ea9e1a7d -- maybe Patrick can
> double-check this?
>
> -- example setup --
> ifconfig ifb0 up
> tc qdisc add dev ifb0 root netem delay 2s
> tc qdisc add dev $ETH root handle 1: prio
> tc filter add dev $ETH parent 1: protocol ip prio 10 u32 \
> match ip dst 172.24.110.6/32 flowid 1:1 \
> action mirred egress redirect dev ifb0
> ping -c1 172.24.110.6
>
> Signed-off-by: Lucas Nussbaum <lucas.nussbaum@imag.fr>
Thank you for finding and fixing this bug, patch applied.
^ permalink raw reply
* Re: net-2.6.24 rebased
From: David Miller @ 2007-08-31 5:21 UTC (permalink / raw)
To: johannes; +Cc: joe, netdev, linville
In-Reply-To: <1188475093.2963.13.camel@johannes.berg>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 30 Aug 2007 13:58:12 +0200
> Huh? I'm fairly sure I sent a patch to remove it from that driver, no
> idea where it got lost. FWIW, you can simply delete the "|
> IEEE80211_HW_DATA_NULLFUNC_ACK" part.
It might have been a mis-merge between John and myself.
A few times because I had rebased I had to take his
directory of patches and one of us might have made a
mistake somewhere along the line.
In any event, I've removed the offending line from
the driver.
^ permalink raw reply
* Re: pktgen terminating condition
From: David Miller @ 2007-08-31 5:19 UTC (permalink / raw)
To: hadi
Cc: Robert.Olsson, mandeep.baines, rick.jones2, msb, netdev, grundler,
robert.olsson, venza
In-Reply-To: <1188475721.22423.35.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Thu, 30 Aug 2007 08:08:40 -0400
> I was confusing it with another issue where pktgen could send a lot of
> packets without waiting for them to be freed; there are some drivers
> (10G) which may hold onto 8K skbs. A gazillion ooms start spewing ;-> My
> thinking in resolving that was to do something like waht sockets do and
> charge pktgen so it doesnt have too many outstanding packets in flight.
You could implement this quite simply using skb->destructor.
It will add some atomics, so on weaker pktgen source systems
it might decrease the generators rate.
^ permalink raw reply
* Re: [Lksctp-developers] SCTP: Fix dead loop while received unexpected chunk with length set to zero
From: David Miller @ 2007-08-31 5:17 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: yjwei, lksctp-developers, netdev
In-Reply-To: <46D6C9F2.5020702@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Thu, 30 Aug 2007 09:45:22 -0400
> But now we are doing the same thing twice (and this is not the only
> place). I know I am being really picky here, but I am starting to
> thing the ootb handling\ is a mess and I really don't want to add to
> the mess. Until I (or someone else) prove that it's not a mess or
> fix it, I am going to hold off on these patches.
>
> Feel free to go through the spec and fix all the OOTB handling.
I think you should reprioritize, because as Wei emphasized this
is remotely triggerable stuff.
I realize what a pain it is, but a band-aid fix is better than a
remote hole.
^ permalink raw reply
* Re: [PATCH] bridge: fix OOPS when bridging device without ethtool
From: David Miller @ 2007-08-31 5:16 UTC (permalink / raw)
To: matthew
Cc: shemminger, johannes, voss, linux-wireless, linville, netdev,
bridge
In-Reply-To: <20070830164812.GW14130@parisc-linux.org>
From: Matthew Wilcox <matthew@wil.cx>
Date: Thu, 30 Aug 2007 10:48:13 -0600
> On Thu, Aug 30, 2007 at 08:29:32AM -0700, Stephen Hemminger wrote:
> > Bridge code calls ethtool to get speed. The conversion to using
> > only ethtool_ops broke the case of devices without ethtool_ops.
> > This is a new regression in 2.6.23.
> >
> > Rearranged the switch to a logical order, and use gcc initializer.
> >
> > Ps: speed should have been part of the network device structure from
> > the start rather than burying it in ethtool.
>
> Feel free to do the conversion ;-) One of the things I like about the
> ethtool framework is it gives us a way to take stuff out of the drivers
> and put it in the midlayer without disturbing userspace.
>
> > Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
> Acked-by: Matthew Wilcox <matthew@wil.cx>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] bridge: packets leaking out of disabled/blocked ports
From: David Miller @ 2007-08-31 5:15 UTC (permalink / raw)
To: linville; +Cc: shemminger, dy_wang, bridge, netdev
In-Reply-To: <20070830200313.GF5140@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 30 Aug 2007 16:03:13 -0400
> On Thu, Aug 30, 2007 at 12:22:58PM -0700, Stephen Hemminger wrote:
> > This patch fixes some packet leakage in bridge. The bridging code
> > was allowing forward table entries to be generated even if a device
> > was being blocked. The fix is to not add forwarding database entries
> > unless the port is active.
>
> Seems reasonable -- ACK
Applied, thanks.
^ permalink raw reply
* Re: [GIT PULL] SCTP updates
From: David Miller @ 2007-08-31 5:14 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11885091901093-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Thu, 30 Aug 2007 17:26:30 -0400
> that are available in the git repository at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/vxy/lksctp-dev.git master
Pulled, thanks a lot Vlad.
^ 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