* Re: iwl rfkill suddenly dropped to hard block
From: Evgeniy Polyakov @ 2010-12-16 3:22 UTC (permalink / raw)
To: John W. Linville
Cc: Intel Linux Wireless, netdev, linux-wireless, wey-yi.w.guy
In-Reply-To: <20101215201126.GG2377@tuxdriver.com>
On Wed, Dec 15, 2010 at 03:11:27PM -0500, John W. Linville (linville@tuxdriver.com) wrote:
> Cc'ing linux-wireless and Wey-Yi...
>
> To be honest, nearly every report of "suddenly my rfkill is stuck
> on" is because the laptop has multiple rfkill keys, usually with
> one of them a slider along the edge of the case. In particular,
> Thinkpads have such switches. The slider gets accidently engaged
> (possibly while the laptop is being transported or somesuch) and
> suddenly wireless stops working.
>
> Please check for the above. If you are sure that isn't the case, then
> please try to determine the last working kernel and do a bisection --
> hopefully you don't have to go all the way back to 2.6.33!
I'm pretty sure it would be that simple if there was such a slider.
There is no way I can bisect this problem since, first, i915 does not
work anywhere after 2.6.34 upto current git tree, and second, because
wifi perfectly well worked two days ago with this kernel, and now there
are no good and bad kernels, only bad ones.
Turning on dell_wmi brings 2 more rfkill classes, which are both
hard and soft blocked. Both can not be unblocked (even soft unblock),
although reported case can be soft unblocked (hard block status
obviously does not change). Actually by default it is soft unblocked,
other two (another wifi switch and bluetooth) are both hard and soft
blocked.
I would imagine this is just related to some dellish crap, but I saw a
number of exactly the same cases in the web including linux-kernel mail
lists in the past and also without 'slider on the back' case.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: iwl rfkill suddenly dropped to hard block
From: Larry Finger @ 2010-12-16 4:23 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: John W. Linville, Intel Linux Wireless, netdev, linux-wireless,
wey-yi.w.guy
In-Reply-To: <20101216032247.GA7345@ioremap.net>
On 12/15/2010 09:22 PM, Evgeniy Polyakov wrote:
> On Wed, Dec 15, 2010 at 03:11:27PM -0500, John W. Linville (linville@tuxdriver.com) wrote:
>> Cc'ing linux-wireless and Wey-Yi...
>>
>> To be honest, nearly every report of "suddenly my rfkill is stuck
>> on" is because the laptop has multiple rfkill keys, usually with
>> one of them a slider along the edge of the case. In particular,
>> Thinkpads have such switches. The slider gets accidently engaged
>> (possibly while the laptop is being transported or somesuch) and
>> suddenly wireless stops working.
>>
>> Please check for the above. If you are sure that isn't the case, then
>> please try to determine the last working kernel and do a bisection --
>> hopefully you don't have to go all the way back to 2.6.33!
>
> I'm pretty sure it would be that simple if there was such a slider.
>
> There is no way I can bisect this problem since, first, i915 does not
> work anywhere after 2.6.34 upto current git tree, and second, because
> wifi perfectly well worked two days ago with this kernel, and now there
> are no good and bad kernels, only bad ones.
>
> Turning on dell_wmi brings 2 more rfkill classes, which are both
> hard and soft blocked. Both can not be unblocked (even soft unblock),
> although reported case can be soft unblocked (hard block status
> obviously does not change). Actually by default it is soft unblocked,
> other two (another wifi switch and bluetooth) are both hard and soft
> blocked.
>
> I would imagine this is just related to some dellish crap, but I saw a
> number of exactly the same cases in the web including linux-kernel mail
> lists in the past and also without 'slider on the back' case.
I doubt that it is Dell related, if that is what "dellish" means.
I have had some success in clearing this problem by unloading and reloading the
wireless driver. I had the problem on one box that has no rfkill switch and an
802.11b card that uses b43legacy.
Larry
^ permalink raw reply
* Re: [PATCH] ixgb: Convert to new vlan model.
From: Jesse Gross @ 2010-12-16 4:29 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: David Miller, netdev@vger.kernel.org, Kirsher, Jeffrey T,
Duyck, Alexander H, Ben Hutchings
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A136602D675D4E@rrsmsx501.amr.corp.intel.com>
On Wed, Dec 15, 2010 at 10:09 AM, Tantilov, Emil S
<emil.s.tantilov@intel.com> wrote:
> Jesse Gross wrote:
>> On Tue, Dec 14, 2010 at 11:15 AM, Ben Hutchings
>> <bhutchings@solarflare.com> wrote:
>>> On Tue, 2010-12-14 at 12:08 -0700, Tantilov, Emil S wrote:
>>>> Ben Hutchings wrote:
>>>>> On Tue, 2010-12-14 at 11:09 -0700, Tantilov, Emil S wrote:
>>>>>> Ben Hutchings wrote:
>>>>>>> On Mon, 2010-12-13 at 19:42 -0800, Jesse Gross wrote:
>>>>>>>> This switches the ixgb driver to use the new vlan interfaces.
>>>>>>>> In doing this, it completes the work begun in
>>>>>>>> ae54496f9e8d40c89e5668205c181dccfa9ecda1 allowing the use of
>>>>>>>> hardware vlan insertion without having a vlan group configured.
>>>>>>>> [...] diff --git a/drivers/net/ixgb/ixgb_ethtool.c
>>>>>>>> b/drivers/net/ixgb/ixgb_ethtool.c
>>>>>>>> index 43994c1..0e4c527 100644
>>>>>>>> --- a/drivers/net/ixgb/ixgb_ethtool.c
>>>>>>>> +++ b/drivers/net/ixgb/ixgb_ethtool.c
>>>>>>>> @@ -706,6 +706,45 @@ ixgb_get_strings(struct net_device *netdev,
>>>>>>>> u32 stringset, u8 *data) } }
>>>>>>>>
>>>>>>>> +static int ixgb_set_flags(struct net_device *netdev, u32 data)
>>>>>>>> +{ + struct ixgb_adapter *adapter = netdev_priv(netdev);
>>>>>>>> + bool need_reset; + int rc; + + /* The hardware
>>>>>>>> requires that RX vlan stripping and TX vlan insertion + *
>>>>>>>> be configured together. Therefore, if one setting changes
>>>>>>>> adjust the + * other one to match. + */ +
>>>>>>>> if (!!(data & ETH_FLAG_RXVLAN) != !!(data & ETH_FLAG_TXVLAN)) {
>>>>>>>> + if ((data & ETH_FLAG_RXVLAN) != +
>>>>>>>> (netdev->features & NETIF_F_HW_VLAN_RX)) +
>>>>>>>> data ^= ETH_FLAG_TXVLAN; + else if ((data &
>>>>>>>> ETH_FLAG_TXVLAN) != + (netdev->features &
>>>>>>>> NETIF_F_HW_VLAN_TX)) + data ^=
>>>>>>>> ETH_FLAG_RXVLAN; + }
>>>>>>> [...]
>>>>>>>
>>>>>>> I think this should reject attempts to change just one flag with
>>>>>>> -EINVAL, rather than quietly 'fixing' the setting.
>>>>>>>
>>>>>>> Ben.
>>>>>>
>>>>>> I'm not sure this is a good idea. At least not without some sort
>>>>>> of explanation. Since there is no way for the user to know that
>>>>>> he needs to disable both.
>>>>>
>>>>> Document the limitation in Documentation/networking/ixgb.txt. You
>>>>> could also send a patch for the ethtool manual page stating that
>>>>> this restriction might exist.
>>>>>
>>>>> Ben.
>>>>
>>>> Just to make sure it's clear - there is no hard requirement for both
>>>> settings to be set at the same time. So setting:
>>>> ethtool -K eth0 rxvlan off
>>>>
>>>> Is a valid setting and will disable stripping on Rx, but because of
>>>> the design, stripping on Tx will also be disabled.
>>>
>>> Then it's *not* a valid setting for your hardware/driver.
>>
>> Ben, I agree that limiting the settings to what is actually supported
>> is conceptually cleaner but in practice it's not very intuitive. If
>> you try to turn something off and the response is that it's invalid,
>> most people are going to assume that you just can't do it. This is
>> especially true since you actually can't turn these settings off in
>> most drivers.
>>
>> There's a precedent for this type of thing: turn off TX checksum
>> offloading and watch scatter/gather and TSO be automatically disabled
>> as well. It makes sense - the user requested a change, we do what is
>> necessary to make that happen without requiring them to understand why
>> these features are interrelated.
>>
>> Emil, I realized afterwards that, as you pointed out, TX vlan
>> offloading can be disabled without requiring RX offloading to be
>> disabled. Feel free to make the modification yourself or I can
>> resubmit, whichever is easier.
>
> If it's OK with you I can make whatever changes are needed since I need
> to test this first, so I don't want to go back and forth in case we find
> other issues in testing.
Yes, please go ahead and make the necessary changes - I'm really just
interested in the end result.
^ permalink raw reply
* Re: [PATCH 1/3] Kernel interfaces for multiqueue aware socket
From: Eric Dumazet @ 2010-12-16 4:44 UTC (permalink / raw)
To: Fenghua Yu
Cc: David S. Miller, Fastabend, John R, Tang, Xinan, Junchang Wang,
netdev, linux-kernel
In-Reply-To: <20101216011425.GA17446@linux-os.sc.intel.com>
Le mercredi 15 décembre 2010 à 17:14 -0800, Fenghua Yu a écrit :
> On Wed, Dec 15, 2010 at 12:48:38PM -0800, Eric Dumazet wrote:
> > Le mercredi 15 décembre 2010 à 12:02 -0800, Fenghua Yu a écrit :
> > > From: Fenghua Yu <fenghua.yu@intel.com>
> > >
> > > Multiqueue and multicore provide packet parallel processing methodology.
> > > Current kernel and network drivers place one queue on one core. But the higher
> > > level socket doesn't know multiqueue. Current socket only can receive or send
> > > packets through one network interfaces. In some cases e.g. multi bpf filter
> > > tcpdump and snort, a lot of contentions come from socket operations like ring
> > > buffer. Even if the application itself has been fully parallelized and run on
> > > multi-core systems and NIC handlex tx/rx in multiqueue in parallel, network layer
> > > and NIC device driver assemble packets to a single, serialized queue. Thus the
> > > application cannot actually run in parallel in high speed.
> > >
> > > To break the serialized packets assembling bottleneck in kernel, one way is to
> > > allow socket to know multiqueue associated with a NIC interface. So each socket
> > > can handle tx/rx in one queue in parallel.
> > >
> > > Kernel provides several interfaces by which sockets can be bound to rx/tx queues.
> > > User applications can configure socket by providing several sockets that each
> > > bound to a single queue, applications can get data from kernel in parallel. After
> > > that, competitions mentioned above can be removed.
> > >
> > > With this patch, the user-space receiving speed on a Intel SR1690 server with
> > > a single L5640 6-core processor and a single ixgbe-based NIC goes from 0.73Mpps
> > > to 4.20Mpps, nearly a linear speedup. A Intel SR1625 server two E5530 4-core
> > > processors and a single ixgbe-based NIC goes from 0.80Mpps to 4.6Mpps. We noticed
> > > the performance penalty comes from NUMA memory allocation.
> > >
> >
> > ??? please elaborate on these NUMA memory allocations. This should be OK
> > after commit 564824b0c52c34692d (net: allocate skbs on local node)
> >
No data for this NUMA problem ?
We had to convince Andrew Morton for this patch to get in.
> > > This patch set provides kernel ioctl interfaces for user space. User space can
> > > either directly call the interfaces or libpcap interfaces can be further provided
> > > on the top of the kernel ioctl interfaces.
> >
> > So, say we have 8 queues, you want libpcap opens 8 sockets, and bind
> > them to each queue. Add a bpf filter to each one of them. This seems not
> > generic way, because it wont work for an UDP socket for example.
>
> This only works for AF_PACKET like this patch set shows.
>
Yes, we also should address other sockets, with generic mechanisms.
> > And you already can do this using SKF_AD_QUEUE (added in commit
> > d19742fb)
>
> SKF_AD_QUEUE doesn't know number of rx queues. Thus user application can't
> specify right SKF_AD_QUEUE.
>
> SKF_AD_QUEUE only works for rx. There is no queue bound interfaces for tx.
>
> I can change the patch set to use SKF_AD_QUEUE by removing the set rx queue
> interface and still keep interfaces of
> #define SIOGNUMRXQUEUE 0x8939 /* Get number of rx queues. */
> #define SIOGNUMTXQUEUE 0x893A /* Get number of tx queues. */
> #define SIOSTXQUEUEMAPPING 0x893C /* Set tx queue mapping. */
> #define SIOGRXQUEUEMAPPING 0x893D /* Get rx queue mapping. */
> #define SIOGTXQUEUEMAPPING 0x893E /* Get tx queue mapping. */
>
> >
> > Also your AF_PACKET patch only address mmaped sockets.
> >
> The new patch set will use SKF_AD_QUEUE for rx. So it won't be limited to mmaped
> sockets.
>
We really need to be smarter than that, not adding raw API.
Tom Herbert added RPS, RFS, XPS, in a way applications dont have to use
special API, just run normal code.
Please understand that using 8 AF_PACKET sockets bound to a given device
is a total waste, because the way we loop on ptype_all before entering
AF_PACKET code, and in 12% of the cases deliver the packet into a queue,
and 77.5% of the case reject the packet.
This is absolutely not scalable to say... 64 queues.
I do believe we can handle that using one AF_PACKET socket for the RX
side, in order to not slow down the loop we have in
__netif_receive_skb()
list_for_each_entry_rcu(ptype, &ptype_all, list) {
...
deliver_skb(skb, pt_prev, orig_dev);
}
(Same problem with dev_queue_xmit_nit() by the way, even worse since we
skb_clone() packet _before_ entering af_packet code)
And we can change af_packet to split the load to N skb queues or N ring
buffers, N not being necessarly number of NIC queues, but the number
needed to handle the expected load.
There is nothing preventing us changing af_packet/udp/tcp_listener to
something more scalable in itself, using a set of receive queues, and
NUMA friendly data set. We did multiqueue for a net_device like this,
not adding N pseudo devices as we could have done.
^ permalink raw reply
* Re: [PATCH 1/3] Kernel interfaces for multiqueue aware socket
From: Eric Dumazet @ 2010-12-16 5:00 UTC (permalink / raw)
To: Junchang Wang
Cc: Fenghua Yu, David S. Miller, John Fastabend, Xinan Tang, netdev,
linux-kernel
In-Reply-To: <AANLkTikc+QTPH2He=fKgWiRGk=6sn9Phaa259YdkQNix@mail.gmail.com>
Le jeudi 16 décembre 2010 à 09:52 +0800, Junchang Wang a écrit :
> On Thu, Dec 16, 2010 at 4:48 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> With this patch, the user-space receiving speed on a Intel SR1690 server with
> >> a single L5640 6-core processor and a single ixgbe-based NIC goes from 0.73Mpps
> >> to 4.20Mpps, nearly a linear speedup. A Intel SR1625 server two E5530 4-core
> >> processors and a single ixgbe-based NIC goes from 0.80Mpps to 4.6Mpps. We noticed
> >> the performance penalty comes from NUMA memory allocation.
> >>
> >
> > ??? please elaborate on these NUMA memory allocations. This should be OK
> > after commit 564824b0c52c34692d (net: allocate skbs on local node)
> >
> Hi Eric,
> Commit 564824b0c52c34692d had been used in the experiments, but the problem
> remained unsolved.
>
> SLUB was used, and both servers were equipped with 8G physical memory.
> Is there any
> additional information I can provide?
>
Yes, sure, you could provide a description of the bench you used, and
data you gathered to make the conclusion that NUMA was a problem.
^ permalink raw reply
* [PATCH 5/5 v4] net: add old_queue_mapping into skb->cb
From: Changli Gao @ 2010-12-16 4:56 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: David S. Miller, Stephen Hemminger, Eric Dumazet, Tom Herbert,
Jiri Pirko, netdev, netem, Changli Gao
For the skbs returned from ifb, we should use the queue_mapping
saved before ifb.
We save old queue_mapping in old_queue_mapping just before calling
dev_queue_xmit, and restore the old_queue_mapping to queue_mapping
just before reinjecting the ingress packets.
A new struct dev_skb_cb is added, and valid in qdisc and gso layer.
The original qdisc_skb_cb and DEV_GSO_CB use dev_skb_cb as the first
member.
netem_skb_cb is changed to contain qdisc_skb_cb.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
v4: don't restore the old_queue_mapping for egress packets.
v3: use the method from Eric to allocate memory from skb->cb. Thank him.
v2: save old_queue_mapping in skb->cb
drivers/net/ifb.c | 1 +
include/linux/netdevice.h | 10 ++++++++++
include/net/sch_generic.h | 3 ++-
net/core/dev.c | 15 ++++++++++-----
net/sched/act_mirred.c | 1 +
net/sched/sch_netem.c | 8 ++++----
6 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 918a38e..1632345 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -96,6 +96,7 @@ static void ri_tasklet(unsigned long arg)
dev_queue_xmit(skb);
} else if (from & AT_INGRESS) {
skb_pull(skb, skb->dev->hard_header_len);
+ skb->queue_mapping = dev_skb_cb(skb)->old_queue_mapping;
netif_rx(skb);
} else
BUG();
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d31bc3c..6f128e3 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1295,6 +1295,16 @@ struct napi_gro_cb {
#define NAPI_GRO_CB(skb) ((struct napi_gro_cb *)(skb)->cb)
+struct dev_skb_cb {
+ u16 old_queue_mapping;
+};
+
+static inline struct dev_skb_cb *dev_skb_cb(struct sk_buff *skb)
+{
+ BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct dev_skb_cb));
+ return (struct dev_skb_cb *)skb->cb;
+}
+
struct packet_type {
__be16 type; /* This is really htons(ether_type). */
struct net_device *dev; /* NULL is wildcarded here */
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index ea1f8a8..52c32e3 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -198,8 +198,8 @@ struct tcf_proto {
};
struct qdisc_skb_cb {
+ struct dev_skb_cb dev_cb; /* must be the first */
unsigned int pkt_len;
- char data[];
};
static inline int qdisc_qlen(struct Qdisc *q)
@@ -209,6 +209,7 @@ static inline int qdisc_qlen(struct Qdisc *q)
static inline struct qdisc_skb_cb *qdisc_skb_cb(struct sk_buff *skb)
{
+ BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct qdisc_skb_cb));
return (struct qdisc_skb_cb *)skb->cb;
}
diff --git a/net/core/dev.c b/net/core/dev.c
index d28b3a0..bf5ced5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1901,10 +1901,15 @@ static int illegal_highdma(struct net_device *dev, struct sk_buff *skb)
}
struct dev_gso_cb {
- void (*destructor)(struct sk_buff *skb);
+ struct dev_skb_cb dev_cb; /* must be the first */
+ void (*destructor)(struct sk_buff *skb);
};
-#define DEV_GSO_CB(skb) ((struct dev_gso_cb *)(skb)->cb)
+static inline struct dev_gso_cb *dev_gso_cb(struct sk_buff *skb)
+{
+ BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct dev_gso_cb));
+ return (struct dev_gso_cb *)skb->cb;
+}
static void dev_gso_skb_destructor(struct sk_buff *skb)
{
@@ -1918,7 +1923,7 @@ static void dev_gso_skb_destructor(struct sk_buff *skb)
kfree_skb(nskb);
} while (skb->next);
- cb = DEV_GSO_CB(skb);
+ cb = dev_gso_cb(skb);
if (cb->destructor)
cb->destructor(skb);
}
@@ -1947,7 +1952,7 @@ static int dev_gso_segment(struct sk_buff *skb)
return PTR_ERR(segs);
skb->next = segs;
- DEV_GSO_CB(skb)->destructor = skb->destructor;
+ dev_gso_cb(skb)->destructor = skb->destructor;
skb->destructor = dev_gso_skb_destructor;
return 0;
@@ -2103,7 +2108,7 @@ gso:
out_kfree_gso_skb:
if (likely(skb->next == NULL))
- skb->destructor = DEV_GSO_CB(skb)->destructor;
+ skb->destructor = dev_gso_cb(skb)->destructor;
out_kfree_skb:
kfree_skb(skb);
out:
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 0c311be..419e82f 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -197,6 +197,7 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
skb2->skb_iif = skb->dev->ifindex;
skb2->dev = dev;
+ dev_skb_cb(skb2)->old_queue_mapping = skb->queue_mapping;
dev_queue_xmit(skb2);
err = 0;
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index e5593c0..c2cf72f 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -77,14 +77,14 @@ struct netem_sched_data {
/* Time stamp put into socket buffer control block */
struct netem_skb_cb {
- psched_time_t time_to_send;
+ struct qdisc_skb_cb qdisc_cb; /* must be the first */
+ psched_time_t time_to_send;
};
static inline struct netem_skb_cb *netem_skb_cb(struct sk_buff *skb)
{
- BUILD_BUG_ON(sizeof(skb->cb) <
- sizeof(struct qdisc_skb_cb) + sizeof(struct netem_skb_cb));
- return (struct netem_skb_cb *)qdisc_skb_cb(skb)->data;
+ BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct netem_skb_cb));
+ return (struct netem_skb_cb *)skb->cb;
}
/* init_crandom - initialize correlated random number generator
^ permalink raw reply related
* [PATCH net-next-2.6] filter: optimize accesses to ancillary data
From: Eric Dumazet @ 2010-12-16 5:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev
We can translate pseudo load instructions at filter check time to
dedicated instructions to speed up filtering and avoid one switch().
libpcap currently uses SKF_AD_PROTOCOL, but custom filters probably use
other ancillary accesses.
Note : I made the assertion that ancillary data was always accessed with
BPF_LD|BPF_?|BPF_ABS instructions, not with BPF_LD|BPF_?|BPF_IND ones
(offset given by K constant, not by K + X register)
On x86_64, this saves a few bytes of text :
# size net/core/filter.o.*
text data bss dec hex filename
4864 0 0 4864 1300 net/core/filter.o.new
4944 0 0 4944 1350 net/core/filter.o.old
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/filter.c | 72 ++++++++++++++++++++++++++------------------
1 file changed, 44 insertions(+), 28 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index e8a6ac4..2b27d4e 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -85,6 +85,17 @@ enum {
BPF_S_JMP_JGT_X,
BPF_S_JMP_JSET_K,
BPF_S_JMP_JSET_X,
+ /* Ancillary data */
+ BPF_S_ANC_PROTOCOL,
+ BPF_S_ANC_PKTTYPE,
+ BPF_S_ANC_IFINDEX,
+ BPF_S_ANC_NLATTR,
+ BPF_S_ANC_NLATTR_NEST,
+ BPF_S_ANC_MARK,
+ BPF_S_ANC_QUEUE,
+ BPF_S_ANC_HATYPE,
+ BPF_S_ANC_RXHASH,
+ BPF_S_ANC_CPU,
};
/* No hurry in this branch */
@@ -107,11 +118,7 @@ static inline void *load_pointer(const struct sk_buff *skb, int k,
{
if (k >= 0)
return skb_header_pointer(skb, k, size, buffer);
- else {
- if (k >= SKF_AD_OFF)
- return NULL;
- return __load_pointer(skb, k, size);
- }
+ return __load_pointer(skb, k, size);
}
/**
@@ -269,7 +276,7 @@ load_w:
A = get_unaligned_be32(ptr);
continue;
}
- break;
+ return 0;
case BPF_S_LD_H_ABS:
k = K;
load_h:
@@ -278,7 +285,7 @@ load_h:
A = get_unaligned_be16(ptr);
continue;
}
- break;
+ return 0;
case BPF_S_LD_B_ABS:
k = K;
load_b:
@@ -287,7 +294,7 @@ load_b:
A = *(u8 *)ptr;
continue;
}
- break;
+ return 0;
case BPF_S_LD_W_LEN:
A = skb->len;
continue;
@@ -338,45 +345,35 @@ load_b:
case BPF_S_STX:
mem[K] = X;
continue;
- default:
- WARN_ON(1);
- return 0;
- }
-
- /*
- * Handle ancillary data, which are impossible
- * (or very difficult) to get parsing packet contents.
- */
- switch (k-SKF_AD_OFF) {
- case SKF_AD_PROTOCOL:
+ case BPF_S_ANC_PROTOCOL:
A = ntohs(skb->protocol);
continue;
- case SKF_AD_PKTTYPE:
+ case BPF_S_ANC_PKTTYPE:
A = skb->pkt_type;
continue;
- case SKF_AD_IFINDEX:
+ case BPF_S_ANC_IFINDEX:
if (!skb->dev)
return 0;
A = skb->dev->ifindex;
continue;
- case SKF_AD_MARK:
+ case BPF_S_ANC_MARK:
A = skb->mark;
continue;
- case SKF_AD_QUEUE:
+ case BPF_S_ANC_QUEUE:
A = skb->queue_mapping;
continue;
- case SKF_AD_HATYPE:
+ case BPF_S_ANC_HATYPE:
if (!skb->dev)
return 0;
A = skb->dev->type;
continue;
- case SKF_AD_RXHASH:
+ case BPF_S_ANC_RXHASH:
A = skb->rxhash;
continue;
- case SKF_AD_CPU:
+ case BPF_S_ANC_CPU:
A = raw_smp_processor_id();
continue;
- case SKF_AD_NLATTR: {
+ case BPF_S_ANC_NLATTR: {
struct nlattr *nla;
if (skb_is_nonlinear(skb))
@@ -392,7 +389,7 @@ load_b:
A = 0;
continue;
}
- case SKF_AD_NLATTR_NEST: {
+ case BPF_S_ANC_NLATTR_NEST: {
struct nlattr *nla;
if (skb_is_nonlinear(skb))
@@ -412,6 +409,7 @@ load_b:
continue;
}
default:
+ WARN_ON(1);
return 0;
}
}
@@ -600,6 +598,24 @@ int sk_chk_filter(struct sock_filter *filter, int flen)
pc + ftest->jf + 1 >= flen)
return -EINVAL;
break;
+ case BPF_S_LD_W_ABS:
+ case BPF_S_LD_H_ABS:
+ case BPF_S_LD_B_ABS:
+#define ANCILLARY(CODE) case SKF_AD_OFF + SKF_AD_##CODE: \
+ code = BPF_S_ANC_##CODE; \
+ break
+ switch (ftest->k) {
+ ANCILLARY(PROTOCOL);
+ ANCILLARY(PKTTYPE);
+ ANCILLARY(IFINDEX);
+ ANCILLARY(NLATTR);
+ ANCILLARY(NLATTR_NEST);
+ ANCILLARY(MARK);
+ ANCILLARY(QUEUE);
+ ANCILLARY(HATYPE);
+ ANCILLARY(RXHASH);
+ ANCILLARY(CPU);
+ }
}
ftest->code = code;
}
^ permalink raw reply related
* Re: [PATCH 5/5 v4] net: add old_queue_mapping into skb->cb
From: Eric Dumazet @ 2010-12-16 5:47 UTC (permalink / raw)
To: Changli Gao
Cc: Jamal Hadi Salim, David S. Miller, Stephen Hemminger, Tom Herbert,
Jiri Pirko, netdev, netem
In-Reply-To: <1292475410-24665-1-git-send-email-xiaosuo@gmail.com>
Le jeudi 16 décembre 2010 à 12:56 +0800, Changli Gao a écrit :
> For the skbs returned from ifb, we should use the queue_mapping
> saved before ifb.
>
> We save old queue_mapping in old_queue_mapping just before calling
> dev_queue_xmit, and restore the old_queue_mapping to queue_mapping
> just before reinjecting the ingress packets.
>
> A new struct dev_skb_cb is added, and valid in qdisc and gso layer.
> The original qdisc_skb_cb and DEV_GSO_CB use dev_skb_cb as the first
> member.
>
> netem_skb_cb is changed to contain qdisc_skb_cb.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* [PATCH] net: increase skb->users instead of skb_clone()
From: Changli Gao @ 2010-12-16 5:57 UTC (permalink / raw)
To: David S. Miller
Cc: Eric Dumazet, Tom Herbert, Jiri Pirko, Fenghua Yu, Junchang Wang,
Xinan Tang, netdev, Changli Gao
In dev_queue_xmit_nit(), we have to clone skbs as we need to mangle skbs,
however, we don't need to clone skbs for all the packet_types.
Except for the first packet_type, we increase skb->users instead of
skb_clone().
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/core/dev.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index bf5ced5..888cb74 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1496,6 +1496,14 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
}
EXPORT_SYMBOL_GPL(dev_forward_skb);
+static inline int deliver_skb(struct sk_buff *skb,
+ struct packet_type *pt_prev,
+ struct net_device *orig_dev)
+{
+ atomic_inc(&skb->users);
+ return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+}
+
/*
* Support routine. Sends outgoing frames to any network
* taps currently in use.
@@ -1504,6 +1512,8 @@ EXPORT_SYMBOL_GPL(dev_forward_skb);
static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
{
struct packet_type *ptype;
+ struct sk_buff *skb2 = NULL;
+ struct packet_type *pt_prev = NULL;
#ifdef CONFIG_NET_CLS_ACT
if (!(skb->tstamp.tv64 && (G_TC_FROM(skb->tc_verd) & AT_INGRESS)))
@@ -1520,7 +1530,13 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
if ((ptype->dev == dev || !ptype->dev) &&
(ptype->af_packet_priv == NULL ||
(struct sock *)ptype->af_packet_priv != skb->sk)) {
- struct sk_buff *skb2 = skb_clone(skb, GFP_ATOMIC);
+ if (pt_prev) {
+ deliver_skb(skb2, pt_prev, skb->dev);
+ pt_prev = ptype;
+ continue;
+ }
+
+ skb2 = skb_clone(skb, GFP_ATOMIC);
if (!skb2)
break;
@@ -1542,9 +1558,11 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
skb2->transport_header = skb2->network_header;
skb2->pkt_type = PACKET_OUTGOING;
- ptype->func(skb2, skb->dev, ptype, skb->dev);
+ pt_prev = ptype;
}
}
+ if (pt_prev)
+ pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
rcu_read_unlock();
}
@@ -2788,14 +2806,6 @@ static void net_tx_action(struct softirq_action *h)
}
}
-static inline int deliver_skb(struct sk_buff *skb,
- struct packet_type *pt_prev,
- struct net_device *orig_dev)
-{
- atomic_inc(&skb->users);
- return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
-}
-
#if (defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)) && \
(defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE))
/* This hook is defined here for ATM LANE */
^ permalink raw reply related
* Re: [PATCH net-next-2.6] filter: optimize accesses to ancillary data
From: Changli Gao @ 2010-12-16 6:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1292478328.2603.56.camel@edumazet-laptop>
On Thu, Dec 16, 2010 at 1:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> We can translate pseudo load instructions at filter check time to
> dedicated instructions to speed up filtering and avoid one switch().
> libpcap currently uses SKF_AD_PROTOCOL, but custom filters probably use
> other ancillary accesses.
>
> Note : I made the assertion that ancillary data was always accessed with
> BPF_LD|BPF_?|BPF_ABS instructions, not with BPF_LD|BPF_?|BPF_IND ones
> (offset given by K constant, not by K + X register)
>
> On x86_64, this saves a few bytes of text :
>
> # size net/core/filter.o.*
> text data bss dec hex filename
> 4864 0 0 4864 1300 net/core/filter.o.new
> 4944 0 0 4944 1350 net/core/filter.o.old
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/core/filter.c | 72 ++++++++++++++++++++++++++------------------
> 1 file changed, 44 insertions(+), 28 deletions(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index e8a6ac4..2b27d4e 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -85,6 +85,17 @@ enum {
> BPF_S_JMP_JGT_X,
> BPF_S_JMP_JSET_K,
> BPF_S_JMP_JSET_X,
> + /* Ancillary data */
> + BPF_S_ANC_PROTOCOL,
> + BPF_S_ANC_PKTTYPE,
> + BPF_S_ANC_IFINDEX,
> + BPF_S_ANC_NLATTR,
> + BPF_S_ANC_NLATTR_NEST,
> + BPF_S_ANC_MARK,
> + BPF_S_ANC_QUEUE,
> + BPF_S_ANC_HATYPE,
> + BPF_S_ANC_RXHASH,
> + BPF_S_ANC_CPU,
> };
>
> /* No hurry in this branch */
> @@ -107,11 +118,7 @@ static inline void *load_pointer(const struct sk_buff *skb, int k,
> {
> if (k >= 0)
> return skb_header_pointer(skb, k, size, buffer);
> - else {
> - if (k >= SKF_AD_OFF)
> - return NULL;
> - return __load_pointer(skb, k, size);
> - }
> + return __load_pointer(skb, k, size);
> }
>
> /**
> @@ -269,7 +276,7 @@ load_w:
> A = get_unaligned_be32(ptr);
> continue;
> }
> - break;
> + return 0;
> case BPF_S_LD_H_ABS:
> k = K;
> load_h:
> @@ -278,7 +285,7 @@ load_h:
> A = get_unaligned_be16(ptr);
> continue;
> }
> - break;
> + return 0;
> case BPF_S_LD_B_ABS:
> k = K;
> load_b:
> @@ -287,7 +294,7 @@ load_b:
> A = *(u8 *)ptr;
> continue;
> }
> - break;
> + return 0;
> case BPF_S_LD_W_LEN:
> A = skb->len;
> continue;
> @@ -338,45 +345,35 @@ load_b:
> case BPF_S_STX:
> mem[K] = X;
> continue;
> - default:
> - WARN_ON(1);
> - return 0;
> - }
> -
> - /*
> - * Handle ancillary data, which are impossible
> - * (or very difficult) to get parsing packet contents.
> - */
> - switch (k-SKF_AD_OFF) {
> - case SKF_AD_PROTOCOL:
> + case BPF_S_ANC_PROTOCOL:
> A = ntohs(skb->protocol);
> continue;
> - case SKF_AD_PKTTYPE:
> + case BPF_S_ANC_PKTTYPE:
> A = skb->pkt_type;
> continue;
> - case SKF_AD_IFINDEX:
> + case BPF_S_ANC_IFINDEX:
> if (!skb->dev)
> return 0;
> A = skb->dev->ifindex;
> continue;
> - case SKF_AD_MARK:
> + case BPF_S_ANC_MARK:
> A = skb->mark;
> continue;
> - case SKF_AD_QUEUE:
> + case BPF_S_ANC_QUEUE:
> A = skb->queue_mapping;
> continue;
> - case SKF_AD_HATYPE:
> + case BPF_S_ANC_HATYPE:
> if (!skb->dev)
> return 0;
> A = skb->dev->type;
> continue;
> - case SKF_AD_RXHASH:
> + case BPF_S_ANC_RXHASH:
> A = skb->rxhash;
> continue;
> - case SKF_AD_CPU:
> + case BPF_S_ANC_CPU:
> A = raw_smp_processor_id();
> continue;
> - case SKF_AD_NLATTR: {
> + case BPF_S_ANC_NLATTR: {
> struct nlattr *nla;
>
> if (skb_is_nonlinear(skb))
> @@ -392,7 +389,7 @@ load_b:
> A = 0;
> continue;
> }
> - case SKF_AD_NLATTR_NEST: {
> + case BPF_S_ANC_NLATTR_NEST: {
> struct nlattr *nla;
>
> if (skb_is_nonlinear(skb))
> @@ -412,6 +409,7 @@ load_b:
> continue;
> }
> default:
> + WARN_ON(1);
> return 0;
> }
> }
> @@ -600,6 +598,24 @@ int sk_chk_filter(struct sock_filter *filter, int flen)
> pc + ftest->jf + 1 >= flen)
> return -EINVAL;
> break;
> + case BPF_S_LD_W_ABS:
> + case BPF_S_LD_H_ABS:
> + case BPF_S_LD_B_ABS:
> +#define ANCILLARY(CODE) case SKF_AD_OFF + SKF_AD_##CODE: \
> + code = BPF_S_ANC_##CODE; \
> + break
> + switch (ftest->k) {
> + ANCILLARY(PROTOCOL);
> + ANCILLARY(PKTTYPE);
> + ANCILLARY(IFINDEX);
> + ANCILLARY(NLATTR);
> + ANCILLARY(NLATTR_NEST);
> + ANCILLARY(MARK);
> + ANCILLARY(QUEUE);
> + ANCILLARY(HATYPE);
> + ANCILLARY(RXHASH);
> + ANCILLARY(CPU);
A default case should be handled as you remove the k > SKF_AD_OFF from
load_pointer().
> + }
> }
> ftest->code = code;
> }
>
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH net-next-2.6] filter: optimize accesses to ancillary data
From: Eric Dumazet @ 2010-12-16 7:08 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, netdev
In-Reply-To: <AANLkTikFqwsze0xZ6+aAhzpJJzng6pWHueimpSkWQNeg@mail.gmail.com>
Le jeudi 16 décembre 2010 à 14:34 +0800, Changli Gao a écrit :
> A default case should be handled as you remove the k > SKF_AD_OFF from
> load_pointer().
>
No, __load_pointer will return NULL in this case.
^ permalink raw reply
* Re: [PATCH] net: increase skb->users instead of skb_clone()
From: Eric Dumazet @ 2010-12-16 7:18 UTC (permalink / raw)
To: Changli Gao
Cc: David S. Miller, Tom Herbert, Jiri Pirko, Fenghua Yu,
Junchang Wang, Xinan Tang, netdev
In-Reply-To: <1292479045-3136-1-git-send-email-xiaosuo@gmail.com>
Le jeudi 16 décembre 2010 à 13:57 +0800, Changli Gao a écrit :
> In dev_queue_xmit_nit(), we have to clone skbs as we need to mangle skbs,
> however, we don't need to clone skbs for all the packet_types.
>
> Except for the first packet_type, we increase skb->users instead of
> skb_clone().
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ---
> net/core/dev.c | 30 ++++++++++++++++++++----------
> 1 file changed, 20 insertions(+), 10 deletions(-)
> diff --git a/net/core/dev.c b/net/core/dev.c
> index bf5ced5..888cb74 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1496,6 +1496,14 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
> }
> EXPORT_SYMBOL_GPL(dev_forward_skb);
>
> +static inline int deliver_skb(struct sk_buff *skb,
> + struct packet_type *pt_prev,
> + struct net_device *orig_dev)
> +{
> + atomic_inc(&skb->users);
> + return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
> +}
> +
> /*
> * Support routine. Sends outgoing frames to any network
> * taps currently in use.
> @@ -1504,6 +1512,8 @@ EXPORT_SYMBOL_GPL(dev_forward_skb);
> static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
> {
> struct packet_type *ptype;
> + struct sk_buff *skb2 = NULL;
> + struct packet_type *pt_prev = NULL;
>
> #ifdef CONFIG_NET_CLS_ACT
> if (!(skb->tstamp.tv64 && (G_TC_FROM(skb->tc_verd) & AT_INGRESS)))
> @@ -1520,7 +1530,13 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
> if ((ptype->dev == dev || !ptype->dev) &&
> (ptype->af_packet_priv == NULL ||
> (struct sock *)ptype->af_packet_priv != skb->sk)) {
> - struct sk_buff *skb2 = skb_clone(skb, GFP_ATOMIC);
> + if (pt_prev) {
> + deliver_skb(skb2, pt_prev, skb->dev);
> + pt_prev = ptype;
> + continue;
> + }
> +
> + skb2 = skb_clone(skb, GFP_ATOMIC);
> if (!skb2)
> break;
>
> @@ -1542,9 +1558,11 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
>
> skb2->transport_header = skb2->network_header;
> skb2->pkt_type = PACKET_OUTGOING;
> - ptype->func(skb2, skb->dev, ptype, skb->dev);
> + pt_prev = ptype;
> }
> }
> + if (pt_prev)
> + pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
> rcu_read_unlock();
> }
>
> @@ -2788,14 +2806,6 @@ static void net_tx_action(struct softirq_action *h)
> }
> }
>
> -static inline int deliver_skb(struct sk_buff *skb,
> - struct packet_type *pt_prev,
> - struct net_device *orig_dev)
> -{
> - atomic_inc(&skb->users);
> - return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
> -}
> -
> #if (defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)) && \
> (defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE))
> /* This hook is defined here for ATM LANE */
You beat me, but I was thinking of a different way, adding a new
pt_prev->xmit_func(), handling all the details (no need for atomic ops
on skb users if packet is not delivered at all).
By the way, your patch is not 100% safe/OK, because af_packet rcv()
handler writes on skb (skb_pull() and all)
^ permalink raw reply
* Re: [PATCH] net: increase skb->users instead of skb_clone()
From: Changli Gao @ 2010-12-16 7:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Tom Herbert, Jiri Pirko, Fenghua Yu,
Junchang Wang, Xinan Tang, netdev
In-Reply-To: <1292483902.2603.62.camel@edumazet-laptop>
On Thu, Dec 16, 2010 at 3:18 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> You beat me, but I was thinking of a different way, adding a new
> pt_prev->xmit_func(), handling all the details (no need for atomic ops
> on skb users if packet is not delivered at all).
>
> By the way, your patch is not 100% safe/OK, because af_packet rcv()
> handler writes on skb (skb_pull() and all)
>
But af_packet_rcv() restores skbs at last.
if (skb_head != skb->data && skb_shared(skb)) {
skb->data = skb_head;
skb->len = skb_len;
}
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] net: increase skb->users instead of skb_clone()
From: Eric Dumazet @ 2010-12-16 7:50 UTC (permalink / raw)
To: Changli Gao
Cc: David S. Miller, Tom Herbert, Jiri Pirko, Fenghua Yu,
Junchang Wang, Xinan Tang, netdev
In-Reply-To: <AANLkTi=BX8AMaiwV3aDAVqRA=br00eRo-42vPNwZfwS6@mail.gmail.com>
Le jeudi 16 décembre 2010 à 15:23 +0800, Changli Gao a écrit :
> On Thu, Dec 16, 2010 at 3:18 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > You beat me, but I was thinking of a different way, adding a new
> > pt_prev->xmit_func(), handling all the details (no need for atomic ops
> > on skb users if packet is not delivered at all).
> >
> > By the way, your patch is not 100% safe/OK, because af_packet rcv()
> > handler writes on skb (skb_pull() and all)
> >
>
> But af_packet_rcv() restores skbs at last.
>
> if (skb_head != skb->data && skb_shared(skb)) {
> skb->data = skb_head;
> skb->len = skb_len;
> }
>
Thats right, your patch seems fine, thanks !
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next-2.6] net_sched: sch_sfq: add backlog info in sfq_dump_class_stats()
From: Jarek Poplawski @ 2010-12-16 8:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <1292437116.3427.386.camel@edumazet-laptop>
On 2010-12-15 19:18, Eric Dumazet wrote:
> We currently return for each active SFQ slot the number of packets in
> queue. We can also give number of bytes accounted for these packets.
>
> tc -s class show dev ifb0
>
> Before patch :
>
> class sfq 11:3d9 parent 11:
> (dropped 0, overlimits 0 requeues 0)
> backlog 0b 3p requeues 0
> allot 1266
>
> After patch :
>
> class sfq 11:3e4 parent 11:
> (dropped 0, overlimits 0 requeues 0)
> backlog 4380b 3p requeues 0
> allot 1212
>
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/sched/sch_sfq.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
> index 3cf478d..cb331de 100644
> --- a/net/sched/sch_sfq.c
> +++ b/net/sched/sch_sfq.c
> @@ -548,8 +548,13 @@ static int sfq_dump_class_stats(struct Qdisc *sch, unsigned long cl,
> {
> struct sfq_sched_data *q = qdisc_priv(sch);
> sfq_index idx = q->ht[cl-1];
> - struct gnet_stats_queue qs = { .qlen = q->qs[idx].qlen };
> + struct sk_buff_head *list = &q->qs[idx];
> + struct gnet_stats_queue qs = { .qlen = list->qlen };
> struct tc_sfq_xstats xstats = { .allot = q->allot[idx] };
> + struct sk_buff *skb;
> +
> + skb_queue_walk(list, skb)
> + qs.backlog += qdisc_pkt_len(skb);
I don't think you can walk this list without the qdisc lock.
Jarek P.
^ permalink raw reply
* Buglet in net/pkt_cls.h pointer handling.
From: Ralph Loader @ 2010-12-16 8:56 UTC (permalink / raw)
To: netdev
Hi,
tcf_valid_offset() in net/pkt_cls.h appears to have a couple of
problems (obvious patch below):
(a) there is no check for overflow in the pointer arithmetic.
(b) the pointers are presumably likely to be normally valid, so the
hint should be 'likely()' not 'unlikely()'.
The offsets used to construct the arguments to that function, e.g., as
called in net/sched/em_u32.c, I think come from user-space & in theory
could be crafted to cause an invalid pointer deref if ptr+len overflows?
Possibly the '<' and '>' in that function should be '<=' and '>='
also. I'm not familiar enough with the data-structures to be sure.
Also a question: in em_u32.c em_u32_match(), and in cls_u32.c
u32_classify(), we dereference pointers that have had an offset
(originally from user space) added to them. I can't see anything that
keeps those pointers aligned. Is that a problem on architectures that
don't support unaligned pointers, or am I missing something?
Cheers,
Ralph.
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index dd3031a..99a2d7b 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -323,7 +323,7 @@ static inline unsigned char * tcf_get_base_ptr(struct sk_buff *skb, int layer)
static inline int tcf_valid_offset(const struct sk_buff *skb,
const unsigned char *ptr, const int len)
{
- return unlikely((ptr + len) < skb_tail_pointer(skb) && ptr > skb->head);
+ return likely((ptr + len) < skb_tail_pointer(skb) && ptr > skb->head && ptr <= ptr + len);
}
#ifdef CONFIG_NET_CLS_IND
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Wolfgang Grandegger @ 2010-12-16 9:11 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1292407130-19791-1-git-send-email-bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
Hi Bhupesh,
thanks for your contribution.
On 12/15/2010 10:58 AM, Bhupesh Sharma wrote:
> Bosch C_CAN controller is a full-CAN implementation which is compliant
> to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can be
> obtained from:
> http://www.semiconductors.bosch.de/pdf/Users_Manual_C_CAN.pdf
>
> This patch adds the support for this controller.
> The following are the design choices made while writing the controller driver:
> 1. Interface Register set IF1 has be used only in the current design.
> 2. Out of the 32 Message objects available, 16 are kept aside for RX purposes
> and the rest for TX purposes.
> 3. NAPI implementation is such that both the TX and RX paths function in
> polling mode.
>
> Changes since V1:
> 1. Implemented C_CAN as a platform driver with means of providing the
> platform details and register offsets which may vary for different SoCs
> through platform data struct.
> 2. Implemented NAPI.
> 3. Removed memcpy calls globally.
> 4. Implemented CAN_CTRLMODE_*
> 5. Implemented and used priv->can.do_get_berr_counter.
> 6. Implemented c_can registers as a struct instead of enum.
> 7. Improved the TX path by implementing routines to get next Tx and echo msg
> objects.
>
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/net/can/Kconfig | 7 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/c_can.c | 1217 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1225 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/can/c_can.c
>
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 9d9e453..25d9d2e 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -41,6 +41,13 @@ config CAN_AT91
> ---help---
> This is a driver for the SoC CAN controller in Atmel's AT91SAM9263.
>
> +config CAN_C_CAN
> + tristate "Bosch C_CAN controller"
> + depends on CAN_DEV
> + ---help---
> + If you say yes to this option, support will be included for the
> + Bosch C_CAN controller.
> +
> config CAN_TI_HECC
> depends on CAN_DEV && ARCH_OMAP3
> tristate "TI High End CAN Controller"
> diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
> index 0057537..b6cbe74 100644
> --- a/drivers/net/can/Makefile
> +++ b/drivers/net/can/Makefile
> @@ -12,6 +12,7 @@ obj-y += usb/
> obj-$(CONFIG_CAN_SJA1000) += sja1000/
> obj-$(CONFIG_CAN_MSCAN) += mscan/
> obj-$(CONFIG_CAN_AT91) += at91_can.o
> +obj-$(CONFIG_CAN_C_CAN) += c_can.o
> obj-$(CONFIG_CAN_TI_HECC) += ti_hecc.o
> obj-$(CONFIG_CAN_MCP251X) += mcp251x.o
> obj-$(CONFIG_CAN_BFIN) += bfin_can.o
> diff --git a/drivers/net/can/c_can.c b/drivers/net/can/c_can.c
> new file mode 100644
> index 0000000..c281c17
> --- /dev/null
> +++ b/drivers/net/can/c_can.c
> @@ -0,0 +1,1217 @@
> +/*
> + * CAN bus driver for Bosch C_CAN controller
> + *
> + * Copyright (C) 2010 ST Microelectronics
> + * Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
> + *
> + * Borrowed heavily from the C_CAN driver originally written by:
> + * Copyright (C) 2007
> + * - Sascha Hauer, Marc Kleine-Budde, Pengutronix <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> + * - Simon Kallweit, intefo AG <simon.kallweit-+G9qxTFKJT/tRgLqZ5aouw@public.gmane.org>
> + *
> + * Bosch C_CAN controller is compliant to CAN protocol version 2.0 part A and B.
> + * Bosch C_CAN user manual can be obtained from:
> + * http://www.semiconductors.bosch.de/pdf/Users_Manual_C_CAN.pdf
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/version.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <linux/netdevice.h>
> +#include <linux/if_arp.h>
> +#include <linux/if_ether.h>
> +#include <linux/list.h>
> +#include <linux/delay.h>
> +#include <linux/workqueue.h>
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +
> +#include <linux/can.h>
> +#include <linux/can/dev.h>
> +#include <linux/can/error.h>
> +
> +#define DRV_NAME "c_can"
> +
> +/* control register */
> +#define CONTROL_TEST (1 << 7)
> +#define CONTROL_CCE (1 << 6)
> +#define CONTROL_DISABLE_AR (1 << 5)
> +#define CONTROL_ENABLE_AR (0 << 5)
> +#define CONTROL_EIE (1 << 3)
> +#define CONTROL_SIE (1 << 2)
> +#define CONTROL_IE (1 << 1)
> +#define CONTROL_INIT (1 << 0)
> +
> +/* test register */
> +#define TEST_RX (1 << 7)
> +#define TEST_TX1 (1 << 6)
> +#define TEST_TX2 (1 << 5)
> +#define TEST_LBACK (1 << 4)
> +#define TEST_SILENT (1 << 3)
> +#define TEST_BASIC (1 << 2)
> +
> +/* status register */
> +#define STATUS_BOFF (1 << 7)
> +#define STATUS_EWARN (1 << 6)
> +#define STATUS_EPASS (1 << 5)
> +#define STATUS_RXOK (1 << 4)
> +#define STATUS_TXOK (1 << 3)
> +#define STATUS_LEC_MASK 0x07
> +#define LEC_STUFF_ERROR 1
> +#define LEC_FORM_ERROR 2
> +#define LEC_ACK_ERROR 3
> +#define LEC_BIT1_ERROR 4
> +#define LEC_BIT0_ERROR 5
> +#define LEC_CRC_ERROR 6
> +
> +/* error counter register */
> +#define ERR_COUNTER_TEC_MASK 0xff
> +#define ERR_COUNTER_TEC_SHIFT 0x0
> +#define ERR_COUNTER_REC_SHIFT 8
> +#define ERR_COUNTER_REC_MASK (0x7f << ERR_COUNTER_REC_SHIFT)
> +#define ERR_COUNTER_RP_SHIFT 15
> +#define ERR_COUNTER_RP_MASK (0x1 << ERR_COUNTER_RP_SHIFT)
> +
> +/* bit-timing register */
> +#define BTR_BRP_MASK 0x3f
> +#define BTR_BRP_SHIFT 0
> +#define BTR_SJW_SHIFT 6
> +#define BTR_SJW_MASK (0x3 << BTR_SJW_SHIFT)
> +#define BTR_TSEG1_SHIFT 8
> +#define BTR_TSEG1_MASK (0xf << BTR_TSEG1_SHIFT)
> +#define BTR_TSEG2_SHIFT 12
> +#define BTR_TSEG2_MASK (0x7 << BTR_TSEG2_SHIFT)
> +
> +/* brp extension register */
> +#define BRP_EXT_BRPE_MASK 0x0f
> +#define BRP_EXT_BRPE_SHIFT 0
> +
> +/* IFx command request */
> +#define IF_COMR_BUSY (1 << 15)
> +
> +/* IFx command mask */
> +#define IF_COMM_WR (1 << 7)
> +#define IF_COMM_MASK (1 << 6)
> +#define IF_COMM_ARB (1 << 5)
> +#define IF_COMM_CONTROL (1 << 4)
> +#define IF_COMM_CLR_INT_PND (1 << 3)
> +#define IF_COMM_TXRQST (1 << 2)
> +#define IF_COMM_DATAA (1 << 1)
> +#define IF_COMM_DATAB (1 << 0)
> +#define IF_COMM_ALL (IF_COMM_MASK | IF_COMM_ARB | \
> + IF_COMM_CONTROL | IF_COMM_TXRQST | \
> + IF_COMM_DATAA | IF_COMM_DATAB)
> +
> +/* IFx arbitration */
> +#define IF_ARB_MSGVAL (1 << 15)
> +#define IF_ARB_MSGXTD (1 << 14)
> +#define IF_ARB_TRANSMIT (1 << 13)
> +
> +/* IFx message control */
> +#define IF_MCONT_NEWDAT (1 << 15)
> +#define IF_MCONT_MSGLST (1 << 14)
> +#define IF_MCONT_INTPND (1 << 13)
> +#define IF_MCONT_UMASK (1 << 12)
> +#define IF_MCONT_TXIE (1 << 11)
> +#define IF_MCONT_RXIE (1 << 10)
> +#define IF_MCONT_RMTEN (1 << 9)
> +#define IF_MCONT_TXRQST (1 << 8)
> +#define IF_MCONT_EOB (1 << 7)
> +
> +/*
> + * IFx register masks:
> + * allow easy operation on 16-bit registers when the
> + * argument is 32-bit instead
> + */
> +#define IFX_WRITE_LOW_16BIT(x) (x & 0xFFFF)
> +#define IFX_WRITE_HIGH_16BIT(x) ((x & 0xFFFF0000) >> 16)
> +
> +/* message object split */
> +#define C_CAN_NO_OF_OBJECTS 31
> +#define C_CAN_MSG_OBJ_RX_NUM 16
> +#define C_CAN_MSG_OBJ_TX_NUM 16
> +
> +#define C_CAN_MSG_OBJ_RX_FIRST 0
> +#define C_CAN_MSG_OBJ_RX_LAST (C_CAN_MSG_OBJ_RX_FIRST + \
> + C_CAN_MSG_OBJ_RX_NUM - 1)
> +
> +#define C_CAN_MSG_OBJ_TX_FIRST (C_CAN_MSG_OBJ_RX_LAST + 1)
> +#define C_CAN_MSG_OBJ_TX_LAST (C_CAN_MSG_OBJ_TX_FIRST + \
> + C_CAN_MSG_OBJ_TX_NUM - 1)
> +#define C_CAN_NEXT_MSG_OBJ_MASK (C_CAN_MSG_OBJ_TX_NUM - 1)
> +#define RECEIVE_OBJECT_BITS 0x0000ffff
> +
> +/* status interrupt */
> +#define STATUS_INTERRUPT 0x8000
> +
> +/* napi related */
> +#define C_CAN_NAPI_WEIGHT C_CAN_MSG_OBJ_RX_NUM
> +
> +/* c_can IF registers */
> +struct c_can_if_regs {
> + u16 com_reg;
> + u16 com_mask;
> + u16 mask1;
> + u16 mask2;
> + u16 arb1;
> + u16 arb2;
> + u16 msg_cntrl;
> + u16 data_a1;
> + u16 data_a2;
> + u16 data_b1;
> + u16 data_b2;
> + u16 _reserved[13];
> +};
> +
> +/* c_can hardware registers */
> +struct c_can_regs {
> + u16 control;
> + u16 status;
> + u16 error_counter;
> + u16 btr;
> + u16 ir;
> + u16 test;
> + u16 brp_ext;
> + u16 _reserved1;
> + struct c_can_if_regs ifreg[2]; /* [0] = IF1 and [1] = IF2 */
> + u16 _reserved2[8];
> + u16 txrqst1;
> + u16 txrqst2;
> + u16 _reserved3[6];
> + u16 newdat1;
> + u16 newdat2;
> + u16 _reserved4[6];
> + u16 intpnd1;
> + u16 intpnd2;
> + u16 _reserved5[6];
> + u16 msgval1;
> + u16 msgval2;
> + u16 _reserved6[6];
> +};
Ah, oh, I just realized that the register layout is almost identical to
the recently accepted *pch_can* driver. Tomoya, does pch_can use a c_can
core? Well, then it makes really sense to have a generic c_can driver
for the SPEAR, PCH, etc. Board specific details are handled via platform
definition. This driver already provides that functionality, IFAICS.
Wolfgang.
^ permalink raw reply
* [PATCH] via-velocity: fix the WOL bug on 1000M full duplex forced mode
From: David Lv @ 2010-12-16 9:33 UTC (permalink / raw)
To: netdev, romieu
This patch isn't based on the first patch of the sleep speed 10M.
The VIA velocity card can't be waken up by WOL tool on 1000M full
duplex forced mode.
This patch fixes the bug.
Thanks!
Signed-off-by: David Lv <DavidLv@viatech.com.cn>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/via-velocity.c | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index cab96ad..947af49 100755
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -2925,6 +2925,7 @@ static int velocity_set_wol(struct velocity_info *vptr)
struct mac_regs __iomem *regs = vptr->mac_regs;
static u8 buf[256];
int i;
+ u8 GCR;
static u32 mask_pattern[2][4] = {
{0x00203000, 0x000003C0, 0x00000000, 0x0000000}, /* ARP */
@@ -2968,23 +2969,31 @@ static int velocity_set_wol(struct velocity_info *vptr)
writew(0x0FFF, ®s->WOLSRClr);
- if (vptr->mii_status & VELOCITY_AUTONEG_ENABLE) {
- if (PHYID_GET_PHY_ID(vptr->phy_id) == PHYID_CICADA_CS8201)
- MII_REG_BITS_ON(AUXCR_MDPPS, MII_NCONFIG,
vptr->mac_regs);
-
- MII_REG_BITS_OFF(ADVERTISE_1000FULL |
ADVERTISE_1000HALF, MII_CTRL1000, vptr->mac_regs);
- }
+ if (SPD_DPX_1000_FULL != vptr->options.spd_dpx) {
+ if (SPD_DPX_AUTO == vptr->options.spd_dpx) {
+ if (vptr->mii_status & VELOCITY_AUTONEG_ENABLE) {
+ if (PHYID_GET_PHY_ID(vptr->phy_id) ==
+ PHYID_CICADA_CS8201)
+ MII_REG_BITS_ON(AUXCR_MDPPS,
+ MII_NCONFIG, vptr->mac_regs);
+
+ MII_REG_BITS_OFF(ADVERTISE_1000FULL |
+ ADVERTISE_1000HALF, MII_CTRL1000,
+ vptr->mac_regs);
+ }
- if (vptr->mii_status & VELOCITY_SPEED_1000)
- MII_REG_BITS_ON(BMCR_ANRESTART, MII_BMCR, vptr->mac_regs);
+ if (vptr->mii_status & VELOCITY_SPEED_1000)
+ MII_REG_BITS_ON(BMCR_ANRESTART, MII_BMCR,
+ vptr->mac_regs);
+ }
- BYTE_REG_BITS_ON(CHIPGCR_FCMODE, ®s->CHIPGCR);
+ BYTE_REG_BITS_ON(CHIPGCR_FCMODE, ®s->CHIPGCR);
- {
- u8 GCR;
- GCR = readb(®s->CHIPGCR);
- GCR = (GCR & ~CHIPGCR_FCGMII) | CHIPGCR_FCFDX;
- writeb(GCR, ®s->CHIPGCR);
+ {
+ GCR = readb(®s->CHIPGCR);
+ GCR = (GCR & ~CHIPGCR_FCGMII) | CHIPGCR_FCFDX;
+ writeb(GCR, ®s->CHIPGCR);
+ }
}
BYTE_REG_BITS_OFF(ISR_PWEI, ®s->ISR);
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next-2.6] ifb: fix a lockdep splat
From: Eric Dumazet @ 2010-12-16 9:52 UTC (permalink / raw)
To: David Miller; +Cc: changli Gao, netdev, Jamal Hadi Salim
After recent ifb changes, we must use lockless __skb_dequeue() since
lock is not anymore initialized.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jamal Hadi Salim <hadi@cyberus.ca>
Cc: Changli Gao <xiaosuo@gmail.com>
---
drivers/net/ifb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index bfa03db..8bcacd7 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -71,7 +71,7 @@ static void ri_tasklet(unsigned long dev)
}
}
- while ((skb = skb_dequeue(&dp->tq)) != NULL) {
+ while ((skb = __skb_dequeue(&dp->tq)) != NULL) {
u32 from = G_TC_FROM(skb->tc_verd);
skb->tc_verd = 0;
^ permalink raw reply related
* Re: [PATCH net-next-2.6] ifb: fix a lockdep splat
From: Changli Gao @ 2010-12-16 10:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Jamal Hadi Salim
In-Reply-To: <1292493175.2883.56.camel@edumazet-laptop>
On Thu, Dec 16, 2010 at 5:52 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> After recent ifb changes, we must use lockless __skb_dequeue() since
> lock is not anymore initialized.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jamal Hadi Salim <hadi@cyberus.ca>
> Cc: Changli Gao <xiaosuo@gmail.com>
Acked-by: Changli Gao <xiaosuo@gmail.com>
Then, I have to refine my patch series. Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH v2 net-next-2.6] net_sched: sch_sfq: add backlog info in sfq_dump_class_stats()
From: Eric Dumazet @ 2010-12-16 10:18 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <20101216081621.GA7338@ff.dom.local>
Le jeudi 16 décembre 2010 à 08:16 +0000, Jarek Poplawski a écrit :
> I don't think you can walk this list without the qdisc lock.
>
I assumed it was already the case, but I did not check
Me confused...
If I use following patch, I get a recursive lock :
net/sched/sch_sfq.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 3cf478d..a2cde03 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -547,9 +547,20 @@ static int sfq_dump_class_stats(struct Qdisc *sch, unsigned long cl,
struct gnet_dump *d)
{
struct sfq_sched_data *q = qdisc_priv(sch);
- sfq_index idx = q->ht[cl-1];
- struct gnet_stats_queue qs = { .qlen = q->qs[idx].qlen };
- struct tc_sfq_xstats xstats = { .allot = q->allot[idx] };
+ sfq_index idx;
+ struct gnet_stats_queue qs = { 0 };
+ struct tc_sfq_xstats xstats = { 0 };
+ struct sk_buff_head *list;
+ struct sk_buff *skb;
+
+ spin_lock_bh(qdisc_root_sleeping_lock(sch));
+ idx = q->ht[cl - 1];
+ list = &q->qs[idx];
+ xstats.allot = q->allot[idx];
+ qs.qlen = list->qlen;
+ skb_queue_walk(list, skb)
+ qs.backlog += qdisc_pkt_len(skb);
+ spin_unlock_bh(qdisc_root_sleeping_lock(sch));
if (gnet_stats_copy_queue(d, &qs) < 0)
return -1;
Dec 16 10:49:34 edumdev kernel: [ 616.452080] sch->qstats.backlog=185420
Dec 16 10:49:34 edumdev kernel: [ 616.452146]
Dec 16 10:49:34 edumdev kernel: [ 616.452147] =============================================
Dec 16 10:49:34 edumdev kernel: [ 616.452265] [ INFO: possible recursive locking detected ]
Dec 16 10:49:34 edumdev kernel: [ 616.452329] 2.6.37-rc1-01820-g4be8976-dirty #456
Dec 16 10:49:34 edumdev kernel: [ 616.452425] ---------------------------------------------
Dec 16 10:49:34 edumdev kernel: [ 616.452489] tc/8747 is trying to acquire lock:
Dec 16 10:49:34 edumdev kernel: [ 616.452550] (&qdisc_tx_lock){+.-...}, at: [<ffffffffa01331d5>] sfq_dump_class_stats+0x65/0x160 [sch_sfq]
Dec 16 10:49:34 edumdev kernel: [ 616.452753]
Dec 16 10:49:34 edumdev kernel: [ 616.452754] but task is already holding lock:
Dec 16 10:49:34 edumdev kernel: [ 616.452867] (&qdisc_tx_lock){+.-...}, at: [<ffffffff8145474a>] gnet_stats_start_copy_compat+0x4a/0xc0
Dec 16 10:49:34 edumdev kernel: [ 616.453068]
Dec 16 10:49:34 edumdev kernel: [ 616.453069] other info that might help us debug this:
Dec 16 10:49:34 edumdev kernel: [ 616.453184] 2 locks held by tc/8747:
Dec 16 10:49:34 edumdev kernel: [ 616.453243] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8149dbc2>] netlink_dump+0x52/0x1e0
Dec 16 10:49:34 edumdev kernel: [ 616.453510] #1: (&qdisc_tx_lock){+.-...}, at: [<ffffffff8145474a>] gnet_stats_start_copy_compat+0x4a/0xc0
Dec 16 10:49:34 edumdev kernel: [ 616.453745]
Dec 16 10:49:35 edumdev kernel: [ 616.453746] stack backtrace:
Dec 16 10:49:35 edumdev kernel: [ 616.453857] Pid: 8747, comm: tc Tainted: G W 2.6.37-rc1-01820-g4be8976-dirty #456
Dec 16 10:49:35 edumdev kernel: [ 616.453943] Call Trace:
Dec 16 10:49:35 edumdev kernel: [ 616.454004] [<ffffffff8107bd1e>] validate_chain+0x10be/0x1330
Dec 16 10:49:35 edumdev kernel: [ 616.454072] [<ffffffff8107b144>] ? validate_chain+0x4e4/0x1330
Dec 16 10:49:35 edumdev kernel: [ 616.454142] [<ffffffff810cd6cc>] ? get_page_from_freelist+0x2bc/0x730
Dec 16 10:49:35 edumdev kernel: [ 616.454211] [<ffffffff81079200>] ? trace_hardirqs_on_caller+0x110/0x190
Dec 16 10:49:35 edumdev kernel: [ 616.454281] [<ffffffff8107c3e9>] __lock_acquire+0x459/0xbe0
Dec 16 10:49:35 edumdev kernel: [ 616.454379] [<ffffffff8107cc10>] lock_acquire+0xa0/0x140
Dec 16 10:49:35 edumdev kernel: [ 616.454446] [<ffffffffa01331d5>] ? sfq_dump_class_stats+0x65/0x160 [sch_sfq]
Dec 16 10:49:35 edumdev kernel: [ 616.454520] [<ffffffff815aee46>] _raw_spin_lock_bh+0x36/0x50
Dec 16 10:49:35 edumdev kernel: [ 616.454586] [<ffffffffa01331d5>] ? sfq_dump_class_stats+0x65/0x160 [sch_sfq]
Dec 16 10:49:35 edumdev kernel: [ 616.454657] [<ffffffffa01331d5>] sfq_dump_class_stats+0x65/0x160 [sch_sfq]
Dec 16 10:49:35 edumdev kernel: [ 616.454727] [<ffffffff81202ef4>] ? nla_put+0x34/0x40
Dec 16 10:49:35 edumdev kernel: [ 616.454794] [<ffffffff8145478f>] ? gnet_stats_start_copy_compat+0x8f/0xc0
Dec 16 10:49:35 edumdev kernel: [ 616.454865] [<ffffffff8147a2f1>] tc_fill_tclass+0x1b1/0x250
Dec 16 10:49:35 edumdev kernel: [ 616.454932] [<ffffffff8147a3ce>] qdisc_class_dump+0x3e/0x40
Dec 16 10:49:35 edumdev kernel: [ 616.454999] [<ffffffff81483a68>] ? cbq_walk+0x78/0xc0
Dec 16 10:49:35 edumdev kernel: [ 616.455064] [<ffffffffa013228c>] sfq_walk+0x5c/0x90 [sch_sfq]
Dec 16 10:49:35 edumdev kernel: [ 616.455131] [<ffffffff81479f3a>] tc_dump_tclass_qdisc+0xba/0x110
Dec 16 10:49:35 edumdev kernel: [ 616.455199] [<ffffffff8147a390>] ? qdisc_class_dump+0x0/0x40
Dec 16 10:49:35 edumdev kernel: [ 616.455266] [<ffffffff8147a00f>] tc_dump_tclass_root+0x7f/0xa0
Dec 16 10:49:35 edumdev kernel: [ 616.455332] [<ffffffff8147a0bc>] tc_dump_tclass+0x8c/0x110
Dec 16 10:49:35 edumdev kernel: [ 616.455426] [<ffffffff8149dbdd>] netlink_dump+0x6d/0x1e0
Dec 16 10:49:35 edumdev kernel: [ 616.455494] [<ffffffff814a0c0c>] netlink_dump_start+0x19c/0x210
Dec 16 10:49:35 edumdev kernel: [ 616.455562] [<ffffffff8147a030>] ? tc_dump_tclass+0x0/0x110
Dec 16 10:49:35 edumdev kernel: [ 616.455628] [<ffffffff8147a030>] ? tc_dump_tclass+0x0/0x110
Dec 16 10:49:35 edumdev kernel: [ 616.455694] [<ffffffff8146bfa9>] rtnetlink_rcv_msg+0xb9/0x260
Dec 16 10:49:35 edumdev kernel: [ 616.455763] [<ffffffff8146bef0>] ? rtnetlink_rcv_msg+0x0/0x260
Dec 16 10:49:35 edumdev kernel: [ 616.455832] [<ffffffff8149ef29>] netlink_rcv_skb+0x99/0xc0
Dec 16 10:49:35 edumdev kernel: [ 616.455898] [<ffffffff8146bed5>] rtnetlink_rcv+0x25/0x40
Dec 16 10:49:35 edumdev kernel: [ 616.455963] [<ffffffff8149ea95>] ? netlink_unicast+0xf5/0x2d0
Dec 16 10:49:35 edumdev kernel: [ 616.456030] [<ffffffff8149ec42>] netlink_unicast+0x2a2/0x2d0
Dec 16 10:49:35 edumdev kernel: [ 616.456098] [<ffffffff810e8cb3>] ? might_fault+0x53/0xb0
Dec 16 10:49:35 edumdev kernel: [ 616.456163] [<ffffffff81451fed>] ? memcpy_fromiovec+0x6d/0x90
Dec 16 10:49:35 edumdev kernel: [ 616.456231] [<ffffffff8149fbdd>] netlink_sendmsg+0x24d/0x390
Dec 16 10:49:35 edumdev kernel: [ 616.456299] [<ffffffff814463d0>] sock_sendmsg+0xc0/0xf0
Dec 16 10:49:36 edumdev kernel: [ 616.456390] [<ffffffff810e8cb3>] ? might_fault+0x53/0xb0
Dec 16 10:49:36 edumdev kernel: [ 616.456457] [<ffffffff814767ce>] ? verify_compat_iovec+0x6e/0x110
Dec 16 10:49:36 edumdev kernel: [ 616.456526] [<ffffffff81447164>] sys_sendmsg+0x194/0x320
Dec 16 10:49:36 edumdev kernel: [ 616.456593] [<ffffffff815b2e02>] ? do_page_fault+0x102/0x4e0
Dec 16 10:49:36 edumdev kernel: [ 616.456661] [<ffffffff8107cd4d>] ? lock_release_non_nested+0x9d/0x2e0
Dec 16 10:49:36 edumdev kernel: [ 616.456729] [<ffffffff810e8cb3>] ? might_fault+0x53/0xb0
Dec 16 10:49:36 edumdev kernel: [ 616.456796] [<ffffffff810e8cb3>] ? might_fault+0x53/0xb0
Dec 16 10:49:36 edumdev kernel: [ 616.456863] [<ffffffff81476154>] compat_sys_sendmsg+0x14/0x20
Dec 16 10:49:36 edumdev kernel: [ 616.456929] [<ffffffff814770fe>] compat_sys_socketcall+0x1be/0x210
Dec 16 10:49:36 edumdev kernel: [ 616.457000] [<ffffffff8102f1d0>] sysenter_dispatch+0x7/0x33
Dec 16 10:49:36 edumdev kernel: [ 616.457067] [<ffffffff815ae9a9>] ? trace_hardirqs_on_thunk+0x3a/0x3f
^ permalink raw reply related
* Re: [PATCH net-next-2.6] net_sched: sch_sfq: add backlog info in sfq_dump_class_stats()
From: Eric Dumazet @ 2010-12-16 11:03 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <20101216081621.GA7338@ff.dom.local>
Le jeudi 16 décembre 2010 à 08:16 +0000, Jarek Poplawski a écrit :
> On 2010-12-15 19:18, Eric Dumazet wrote:
> > We currently return for each active SFQ slot the number of packets in
> > queue. We can also give number of bytes accounted for these packets.
> >
> > tc -s class show dev ifb0
> >
> > Before patch :
> >
> > class sfq 11:3d9 parent 11:
> > (dropped 0, overlimits 0 requeues 0)
> > backlog 0b 3p requeues 0
> > allot 1266
> >
> > After patch :
> >
> > class sfq 11:3e4 parent 11:
> > (dropped 0, overlimits 0 requeues 0)
> > backlog 4380b 3p requeues 0
> > allot 1212
> >
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> > net/sched/sch_sfq.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
> > index 3cf478d..cb331de 100644
> > --- a/net/sched/sch_sfq.c
> > +++ b/net/sched/sch_sfq.c
> > @@ -548,8 +548,13 @@ static int sfq_dump_class_stats(struct Qdisc *sch, unsigned long cl,
> > {
> > struct sfq_sched_data *q = qdisc_priv(sch);
> > sfq_index idx = q->ht[cl-1];
> > - struct gnet_stats_queue qs = { .qlen = q->qs[idx].qlen };
> > + struct sk_buff_head *list = &q->qs[idx];
> > + struct gnet_stats_queue qs = { .qlen = list->qlen };
> > struct tc_sfq_xstats xstats = { .allot = q->allot[idx] };
> > + struct sk_buff *skb;
> > +
> > + skb_queue_walk(list, skb)
> > + qs.backlog += qdisc_pkt_len(skb);
>
> I don't think you can walk this list without the qdisc lock.
So after checks, I confirm qdisc lock is held at this point, patch is
valid.
tc_fill_tclass() calls gnet_stats_start_copy_compat() (and locks
qdisc_root_sleeping_lock()), before calling
cl_ops->dump_stats(q, cl, &d)
Thanks !
^ permalink raw reply
* Re: iwl rfkill suddenly dropped to hard block
From: Evgeniy Polyakov @ 2010-12-16 11:57 UTC (permalink / raw)
To: Larry Finger
Cc: John W. Linville, Intel Linux Wireless,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4D099444.5040703-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Wed, Dec 15, 2010 at 10:23:32PM -0600, Larry Finger (Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org) wrote:
> >I would imagine this is just related to some dellish crap, but I saw a
> >number of exactly the same cases in the web including linux-kernel mail
> >lists in the past and also without 'slider on the back' case.
>
> I doubt that it is Dell related, if that is what "dellish" means.
>
> I have had some success in clearing this problem by unloading and
> reloading the wireless driver. I had the problem on one box that has
> no rfkill switch and an 802.11b card that uses b43legacy.
I tried that as well as disabling and enabling wifi in bios (or is it
newr loader), but without success. I called this 'dellish' crap
because of the hell list of problems I had with this laptop and i915
video chipset in it. Apparently brother model e4200 does not have them
at all.
--
Evgeniy Polyakov
--
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 net-next-2.6 v2 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Tomoya MORINAGA @ 2010-12-16 12:09 UTC (permalink / raw)
To: Bhupesh Sharma, Wolfgang Grandegger
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D09D7B1.9080906@grandegger.com>
On Thursday, December 16, 2010 6:11 PM, Wolfgang Grandegger wrote:
> Ah, oh, I just realized that the register layout is almost identical to
> the recently accepted *pch_can* driver. Tomoya, does pch_can use a c_can
> core? Well, then it makes really sense to have a generic c_can driver
> for the SPEAR, PCH, etc. Board specific details are handled via platform
> definition. This driver already provides that functionality, IFAICS.
Hi Wolfgang,
It seems pch_can similar to c_can.
However, sorry, I don't know if pch_can core is the same as c_can since LSI
is provided by Intel.
If necessary, please contact to Intel.
Thanks,
---
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* BUG: while bridging Ethernet and wireless device:
From: Tomas Winkler @ 2010-12-16 12:11 UTC (permalink / raw)
To: linux-netdev, linux-wireless
Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
Thanks
Tomas
Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here
]------------
Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at
include/linux/skbuff.h:1178!
Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file:
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.122712]
Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>]
EFLAGS: 00010283 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at
br_multicast_rcv+0xc95/0xe1c [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX:
f5626318 ECX: 00000000 EDX: 00000000
Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI:
f5626180 EBP: f60b5ca0 ESP: f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.123737] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] ec556500 f6d06800
f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
Dec 15 14:36:41 User-PC kernel: [175576.124181] f572c200 ef463440
f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
Dec 15 14:36:41 User-PC kernel: [175576.124181] ffffffff ec55652c
00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01087d8>] ?
sched_clock+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0138264>] ?
enqueue_entity+0x174/0x440
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e451>] ?
sched_clock_cpu+0x131/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c013e47d>] ?
select_task_rq_fair+0x2ad/0x730
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0524fc1>] ?
nf_iterate+0x71/0x90
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4914>] ?
br_handle_frame_finish+0x184/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ?
br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e46e9>] ?
br_handle_frame+0x189/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ?
br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4560>] ?
br_handle_frame+0x0/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff026>] ?
__netif_receive_skb+0x1b6/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04f7a30>] ?
skb_copy_bits+0x110/0x210
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0503a7f>] ?
netif_receive_skb+0x6f/0x80
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cb74c>] ?
ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cc836>] ?
ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff1f0>] ?
__netif_receive_skb+0x380/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e242>] ?
sched_clock_local+0xb2/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c012b688>] ?
default_spin_lock_flags+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ?
_raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cd621>] ?
ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82ce154>] ?
ieee80211_rx+0x2a4/0x830 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f815a8d6>] ?
iwl_update_stats+0xa6/0x2a0 [iwlcore]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8499212>] ?
iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ?
_raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8483697>] ?
iwl_rx_handle+0xe7/0x350 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8486ab7>] ?
iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01aece1>] ?
__rcu_process_callbacks+0x201/0x2d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150d05>] ?
tasklet_action+0xc5/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150a07>] ?
__do_softirq+0x97/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d910c>] ?
nmi_stack_correct+0x2f/0x34
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150970>] ?
__do_softirq+0x0/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] <IRQ>
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01508f5>] ?
irq_exit+0x65/0x70
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05df062>] ? do_IRQ+0x52/0xc0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01036b0>] ?
common_interrupt+0x30/0x38
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c03a1fc2>] ?
intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.124181] Code: ff ff ff be ea
ff ff ff 8b 82 b0 00 00 00 e9 fb f5 ff ff 89 c8 e8 4c dc ff ff 85 c0
89 c6 0f 84 9b f5 ff ff 66 90 e9 be fe ff ff <0f> 0b eb fe c7 47 20 01
00 00 00 8b 43 04 89 c2 81 e2 ff ff ff
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP: [<f83edd65>]
br_multicast_rcv+0xc95/0xe1c [bridge] SS:ESP 0068:f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.124181] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.124181] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.124181] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.124181]
Dec 15 14:36:41 User-PC kernel: [175576.124181] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.124181] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.124181] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.124181] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124181] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
Dec 15 14:36:41 User-PC kernel: [175576.124181] f6d0aa1c c0817f04
f60b1f60 c04daebb 00000001 00000001 f60b1f84 c0101dea
Dec 15 14:36:41 User-PC kernel: [175576.124181] c07d0ef4 f60b1f7c
e487e262 f2eb6781 85a608d2 00000000 00000000 f60b1fb0
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.124181] Code: f6 89 e0 25 00
e0 ff ff 8b 40 08 a8 08 75 08 b1 01 8b 45 e8 0f 01 c9 e8 cd fc dc ff
29 d8 19 f2 e8 04 d6 da ff 89 c6 89 d3 fb 90 <8d> 74 26 00 85 3d 78 41
7e c0 75 0d 8d 55 f0 b8 05 00 00 00 e8
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>]
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>]
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.487562] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.497058] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.522221] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.550740]
Dec 15 14:36:41 User-PC kernel: [175576.557947] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.565201] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.572280] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.579125] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.585850] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.592460] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.599021] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.605632] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.612158] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
Dec 15 14:36:41 User-PC kernel: [175576.618953] f6d0aa1c c0817f04
f60b1f60 c04daebb 00000001 00000001 f60b1f84 c0101dea
Dec 15 14:36:41 User-PC kernel: [175576.625818] c07d0ef4 f60b1f7c
e487e262 f2eb6781 85a608d2 00000000 00000000 f60b1fb0
Dec 15 14:36:41 User-PC kernel: [175576.632737] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.639461] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.646168] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.652826] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.659441] Code: f6 89 e0 25 00
e0 ff ff 8b 40 08 a8 08 75 08 b1 01 8b 45 e8 0f 01 c9 e8 cd fc dc ff
29 d8 19 f2 e8 04 d6 da ff 89 c6 89 d3 fb 90 <8d> 74 26 00 85 3d 78 41
7e c0 75 0d 8d 55 f0 b8 05 00 00 00 e8
Dec 15 14:36:41 User-PC kernel: [175576.673805] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.680668] [<c04daebb>]
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.687612] [<c0101dea>] cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.694516] [<c05d2702>]
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.711906] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.716280] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.734197] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.753330]
Dec 15 14:36:41 User-PC kernel: [175576.757845] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.762389] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.766809] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.771119] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.775348] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.780037] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.784159] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.788286] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.792375] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
^ 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