* Re: [PATCH 1/2] igb: Allow extra 4 bytes on RX for vlan tags.
From: Alexander Duyck @ 2011-08-25 23:31 UTC (permalink / raw)
To: Ben Greear
Cc: Alexander Duyck, jeffrey.t.kirsher, Jesse Gross,
netdev@vger.kernel.org
In-Reply-To: <4E569999.8050006@candelatech.com>
On 08/25/2011 11:51 AM, Ben Greear wrote:
> On 07/20/2011 11:35 PM, Alexander Duyck wrote:
>> On Wed, Jul 20, 2011 at 6:21 PM, Jeff Kirsher
>> <jeffrey.t.kirsher@intel.com> wrote:
>>> On Wed, 2011-07-20 at 17:27 -0700, Ben Greear wrote:
>>>> On 07/20/2011 05:18 PM, Jesse Gross wrote:
>>>>> On Thu, Feb 17, 2011 at 9:28 AM, Ben
>>>>> Greear<greearb@candelatech.com> wrote:
>>>>>> On 02/17/2011 03:04 AM, Jeff Kirsher wrote:
>>>>>>>
>>>>>>> On Thu, Feb 10, 2011 at 13:59,<greearb@candelatech.com> wrote:
>>>>>>>>
>>>>>>>> From: Ben Greear<greearb@candelatech.com>
>>>>>>>>
>>>>>>>> This allows the NIC to receive 1518 byte (not counting
>>>>>>>> FCS) packets when MTU is 1500, thus allowing 1500 MTU
>>>>>>>> VLAN frames to be received. Please note that no VLANs
>>>>>>>> were actually configured on the NIC...it was just acting
>>>>>>>> as pass-through device.
>>>>>>>>
>>>>>>>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>>>>>>>> ---
>>>>>>>> :100644 100644 58c665b... 30c9cc6... M drivers/net/igb/igb_main.c
>>>>>>>> drivers/net/igb/igb_main.c | 5 +++--
>>>>>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/igb/igb_main.c
>>>>>>>> b/drivers/net/igb/igb_main.c
>>>>>>>> index 58c665b..30c9cc6 100644
>>>>>>>> --- a/drivers/net/igb/igb_main.c
>>>>>>>> +++ b/drivers/net/igb/igb_main.c
>>>>>>>> @@ -2281,7 +2281,8 @@ static int __devinit igb_sw_init(struct
>>>>>>>> igb_adapter
>>>>>>>> *adapter)
>>>>>>>> adapter->rx_itr_setting = IGB_DEFAULT_ITR;
>>>>>>>> adapter->tx_itr_setting = IGB_DEFAULT_ITR;
>>>>>>>>
>>>>>>>> - adapter->max_frame_size = netdev->mtu + ETH_HLEN +
>>>>>>>> ETH_FCS_LEN;
>>>>>>>> + adapter->max_frame_size = (netdev->mtu + ETH_HLEN +
>>>>>>>> ETH_FCS_LEN
>>>>>>>> + + VLAN_HLEN);
>>>>>>>> adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
>>>>>>>>
>>>>>>>> spin_lock_init(&adapter->stats64_lock);
>>>>>>>> @@ -4303,7 +4304,7 @@ static int igb_change_mtu(struct net_device
>>>>>>>> *netdev, int new_mtu)
>>>>>>>> {
>>>>>>>> struct igb_adapter *adapter = netdev_priv(netdev);
>>>>>>>> struct pci_dev *pdev = adapter->pdev;
>>>>>>>> - int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
>>>>>>>> + int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN +
>>>>>>>> VLAN_HLEN;
>>>>>>>> u32 rx_buffer_len, i;
>>>>>>>>
>>>>>>>> if ((new_mtu< 68) || (max_frame>
>>>>>>>> MAX_JUMBO_FRAME_SIZE)) {
>>>>>>>
>>>>>>> While testing this patch, validation found that the patch
>>>>>>> reduces the
>>>>>>> maximum mtu size
>>>>>>> by 4 bytes (reduces it from 9216 to 9212). This is not a
>>>>>>> desired side
>>>>>>> effect of this patch.
>>>>>>
>>>>>> You could add handling for that case and have it act as it used
>>>>>> to when
>>>>>> new_mtu is greater than 9212?
>>>>>>
>>>>>> I tested e1000e and it worked w/out hacking at 1500 MTU, so maybe
>>>>>> check how it does it?
>>>>>
>>>>> I just wanted to bring this up again to see if any progress had been
>>>>> made. We were looking at this driver and trying to figure out the
>>>>> best way to convert it to use the new vlan model but I'm not familiar
>>>>
>>>> I've been watching :)
>>>>
>>>>> enough with the hardware to know. It seems that all of the other
>>>>> Intel drivers unconditionally add space for the vlan tag to the
>>>>> receive buffer (and would therefore have similar effects as this
>>>>> patch), is there something different about this card?
>>>>>
>>>>> I believe that Alex was working on something in this area (in the
>>>>> context of one of my patches from a long time ago) but I'm not sure
>>>>> what came of that.
>>>>
>>>> Truth is, I don't really see why it's a problem to decrease the
>>>> maximum MTU slightly in order to make it work with VLANs.
>>>>
>>>> I'm not sure if there is some way to make it work with VLANs
>>>> and not decrease the maximum MTU.
>>>
>>> This was the reason this did not get accepted. I was looking into what
>>> could be done so that we did not decease the maximum MTU, but I got
>>> side-tracked and have not done anything on it in several months.
>>>
>>
>> I can take a look at fixing this most likely tomorrow. I have some
>> work planned for igb anyway over the next few days.
>>
>> Odds are it is just a matter of where the VLAN_HLEN is added. As I
>> recall for our drivers the correct spot is in the setting of
>> rx_buffer_len since that is the area more concerned with maximum
>> receive frame size versus the mtu section which is more concerned with
>> the transmit side of things.
>
> Did a patch for this ever get posted? I'll be happy to test it
> if so...
>
> Thanks,
> Ben
>
We haven't posted one yet. I have one written up but it is currently
mixed in with a set of 30 patches that I am testing/cleaning
up/formatting before submitting to our formal validation team. I will
likely be submitting it to Jeff Kirsher sometime next week and the
patches will probably be available a few weeks after that.
Thanks,
Alex
^ permalink raw reply
* [PATCH net-next-2.6] e1000: save skb counts in TX to avoid cache misses
From: Dean Nelson @ 2011-08-26 0:39 UTC (permalink / raw)
To: netdev, Jeff Kirshier; +Cc: Andy Gospodarek
Virtual Machines with emulated e1000 network adapter running on Parallels'
server were seeing kernel panics due to the e1000 driver dereferencing an
unexpected NULL pointer retrieved from buffer_info->skb.
The problem has been addressed for the e1000e driver, but not for the e1000.
Since the two drivers share similar code in the affected area, a port of the
following e1000e driver commit solves the issue for the e1000 driver:
commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180
Author: Tom Herbert <therbert@google.com>
Date: Wed May 5 14:02:27 2010 +0000
e1000e: save skb counts in TX to avoid cache misses
In e1000_tx_map, precompute number of segements and bytecounts which
are derived from fields in skb; these are stored in buffer_info. When
cleaning tx in e1000_clean_tx_irq use the values in the associated
buffer_info for statistics counting, this eliminates cache misses
on skb fields.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch (backported to RHEL6.2) was verified by Dmitry Skorodumov to solve
Parallels' reported problem.
drivers/net/ethernet/intel/e1000/e1000.h | 2 ++
drivers/net/ethernet/intel/e1000/e1000_main.c | 18 +++++++++---------
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000.h b/drivers/net/ethernet/intel/e1000/e1000.h
index 24f41da..4ea87b1 100644
--- a/drivers/net/ethernet/intel/e1000/e1000.h
+++ b/drivers/net/ethernet/intel/e1000/e1000.h
@@ -150,6 +150,8 @@ struct e1000_buffer {
unsigned long time_stamp;
u16 length;
u16 next_to_watch;
+ unsigned int segs;
+ unsigned int bytecount;
u16 mapped_as_page;
};
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 7c280e5..4a32c15 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -2848,7 +2848,7 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
struct e1000_buffer *buffer_info;
unsigned int len = skb_headlen(skb);
unsigned int offset = 0, size, count = 0, i;
- unsigned int f;
+ unsigned int f, bytecount, segs;
i = tx_ring->next_to_use;
@@ -2949,7 +2949,13 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
}
}
+ segs = skb_shinfo(skb)->gso_segs ?: 1;
+ /* multiply data chunks by size of headers */
+ bytecount = ((segs - 1) * skb_headlen(skb)) + skb->len;
+
tx_ring->buffer_info[i].skb = skb;
+ tx_ring->buffer_info[i].segs = segs;
+ tx_ring->buffer_info[i].bytecount = bytecount;
tx_ring->buffer_info[first].next_to_watch = i;
return count;
@@ -3623,14 +3629,8 @@ static bool e1000_clean_tx_irq(struct e1000_adapter *adapter,
cleaned = (i == eop);
if (cleaned) {
- struct sk_buff *skb = buffer_info->skb;
- unsigned int segs, bytecount;
- segs = skb_shinfo(skb)->gso_segs ?: 1;
- /* multiply data chunks by size of headers */
- bytecount = ((segs - 1) * skb_headlen(skb)) +
- skb->len;
- total_tx_packets += segs;
- total_tx_bytes += bytecount;
+ total_tx_packets += buffer_info->segs;
+ total_tx_bytes += buffer_info->bytecount;
}
e1000_unmap_and_free_tx_resource(adapter, buffer_info);
tx_desc->upper.data = 0;
^ permalink raw reply related
* Re: slow performance on disk/network i/o full speed after drop_caches
From: Wu Fengguang @ 2011-08-26 2:16 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG
Cc: Pekka Enberg, LKML, linux-mm@kvack.org, Andrew Morton, Mel Gorman,
Jens Axboe, Linux Netdev List
In-Reply-To: <4E560F2A.1030801@profihost.ag>
Hi Stefan,
> Here is the data you requested:
>
> root@server1015-han:~# grep . /sys/devices/system/node/node*/vmstat
> /sys/devices/system/node/node0/vmstat:nr_written 5546561
> /sys/devices/system/node/node0/vmstat:nr_dirtied 5572497
> /sys/devices/system/node/node1/vmstat:nr_written 3936
> /sys/devices/system/node/node1/vmstat:nr_dirtied 4190
Ah you are running an older kernel that didn't show all the vmstat
numbers. But still it's revealing that node 0 is used heavily and node
1 is almost idle. So I won't be surprised to see most free pages lie
in node 1.
> modified it a little bit:
> ~# while [ true ]; do ps -eo
> user,pid,tid,class,rtprio,ni,pri,psr,pcpu,vsz,rss,pmem,stat,wchan:28,cmd
> | grep scp | grep -v grep; sleep 1; done
>
> root 12409 12409 TS - 0 19 0 59.8 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
It's mostly doing poll() waits. There must be some dependency on
something other to make progress. Would you post the full ps output
for all tasks, and even better, run
echo t > /proc/sysrq-trigger
To dump the kernel stacks?
Thanks,
Fengguang
> root 12409 12409 TS - 0 19 0 64.0 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 0 67.7 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 8 70.6 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 8 73.5 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 8 76.0 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 8 78.2 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 8 80.0 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 8 80.9 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 2 76.7 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 1 75.6 42136 1724 0.0 Ds
> pipe_read scp -t /tmp/
> root 12409 12409 TS - 0 19 0 76.0 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 1 75.2 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 1 76.6 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 1 77.9 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 1 79.0 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 1 72.8 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 0 73.0 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 0 73.8 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 1 74.3 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 1 73.4 42136 1724 0.0 Ss
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 1 71.3 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 1 71.9 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 0 72.7 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 3 73.5 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 3 74.4 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 3 75.2 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 0 76.0 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 8 76.6 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 1 74.8 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 1 73.2 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 1 73.9 42136 1724 0.0 Rs
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 0 72.4 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 8 72.0 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 8 72.5 42136 1724 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12409 12409 TS - 0 19 8 72.9 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12409 12409 TS - 0 19 8 73.5 42136 1724 0.0 Rs
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 1 0.0 42136 1728 0.0 Rs
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 1 23.0 42136 1728 0.0 Rs
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 1 49.5 42136 1728 0.0 Rs
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 2 63.3 42136 1728 0.0 Rs
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 1 71.5 42136 1728 0.0 Rs
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 1 77.4 42136 1728 0.0 Rs
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 1 70.3 42136 1728 0.0 Rs
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 1 73.1 42136 1728 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12566 12566 TS - 0 19 0 65.7 42136 1728 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
> root 12566 12566 TS - 0 19 1 61.2 42136 1728 0.0 Ss
> - scp -t /tmp/
> root 12566 12566 TS - 0 19 1 63.7 42136 1728 0.0 Rs
> - scp -t /tmp/
> root 12636 12636 TS - 0 19 8 0.0 42136 1728 0.0 Ss
> poll_schedule_timeout scp -t /tmp/
>
>
> Stefan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: slow performance on disk/network i/o full speed after drop_caches
From: Stefan Priebe - Profihost AG @ 2011-08-26 2:54 UTC (permalink / raw)
To: Wu Fengguang
Cc: Pekka Enberg, LKML, linux-mm@kvack.org, Andrew Morton, Mel Gorman,
Jens Axboe, Linux Netdev List
In-Reply-To: <20110826021648.GA19529@localhost>
Hi Wu,
> Ah you are running an older kernel that didn't show all the vmstat
> numbers. But still it's revealing that node 0 is used heavily and node
> 1 is almost idle. So I won't be surprised to see most free pages lie
> in node 1.
I'm running a 2.6.38 kernel.
There is at least a numastat proc file.
grep . /sys/devices/system/node/node*/numastat
/sys/devices/system/node/node0/numastat:numa_hit 5958586
/sys/devices/system/node/node0/numastat:numa_miss 0
/sys/devices/system/node/node0/numastat:numa_foreign 0
/sys/devices/system/node/node0/numastat:interleave_hit 4191
/sys/devices/system/node/node0/numastat:local_node 5885189
/sys/devices/system/node/node0/numastat:other_node 73397
/sys/devices/system/node/node1/numastat:numa_hit 488922
/sys/devices/system/node/node1/numastat:numa_miss 0
/sys/devices/system/node/node1/numastat:numa_foreign 0
/sys/devices/system/node/node1/numastat:interleave_hit 4187
/sys/devices/system/node/node1/numastat:local_node 386741
/sys/devices/system/node/node1/numastat:other_node 102181
>> modified it a little bit:
>> ~# while [ true ]; do ps -eo
>> user,pid,tid,class,rtprio,ni,pri,psr,pcpu,vsz,rss,pmem,stat,wchan:28,cmd
>> | grep scp | grep -v grep; sleep 1; done
>>
>> root 12409 12409 TS - 0 19 0 59.8 42136 1724 0.0 Ss
>> poll_schedule_timeout scp -t /tmp/
>
> It's mostly doing poll() waits. There must be some dependency on
> something other to make progress. Would you post the full ps output
> for all tasks, and even better, run
complete ps output:
http://pastebin.com/raw.php?i=b948svzN
> echo t> /proc/sysrq-trigger
sadly i wa sonly able to grab the output in this crazy format:
http://pastebin.com/raw.php?i=MBXvvyH1
Hope that still helps.
Thanks Stefan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: slow performance on disk/network i/o full speed after drop_caches
From: Wu Fengguang @ 2011-08-26 3:03 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG
Cc: Pekka Enberg, LKML, linux-mm@kvack.org, Andrew Morton, Mel Gorman,
Jens Axboe, Linux Netdev List
In-Reply-To: <4E570AEB.1040703@profihost.ag>
On Fri, Aug 26, 2011 at 10:54:35AM +0800, Stefan Priebe - Profihost AG wrote:
> Hi Wu,
>
> > Ah you are running an older kernel that didn't show all the vmstat
> > numbers. But still it's revealing that node 0 is used heavily and node
> > 1 is almost idle. So I won't be surprised to see most free pages lie
> > in node 1.
> I'm running a 2.6.38 kernel.
>
> There is at least a numastat proc file.
Thanks. This shows that node0 is accessed 10x more than node1.
> grep . /sys/devices/system/node/node*/numastat
> /sys/devices/system/node/node0/numastat:numa_hit 5958586
> /sys/devices/system/node/node0/numastat:numa_miss 0
> /sys/devices/system/node/node0/numastat:numa_foreign 0
> /sys/devices/system/node/node0/numastat:interleave_hit 4191
> /sys/devices/system/node/node0/numastat:local_node 5885189
> /sys/devices/system/node/node0/numastat:other_node 73397
> /sys/devices/system/node/node1/numastat:numa_hit 488922
> /sys/devices/system/node/node1/numastat:numa_miss 0
> /sys/devices/system/node/node1/numastat:numa_foreign 0
> /sys/devices/system/node/node1/numastat:interleave_hit 4187
> /sys/devices/system/node/node1/numastat:local_node 386741
> /sys/devices/system/node/node1/numastat:other_node 102181
>
> >> modified it a little bit:
> >> ~# while [ true ]; do ps -eo
> >> user,pid,tid,class,rtprio,ni,pri,psr,pcpu,vsz,rss,pmem,stat,wchan:28,cmd
> >> | grep scp | grep -v grep; sleep 1; done
> >>
> >> root 12409 12409 TS - 0 19 0 59.8 42136 1724 0.0 Ss
> >> poll_schedule_timeout scp -t /tmp/
> >
> > It's mostly doing poll() waits. There must be some dependency on
> > something other to make progress. Would you post the full ps output
> > for all tasks, and even better, run
> complete ps output:
> http://pastebin.com/raw.php?i=b948svzN
In that log, scp happens to be in R state and also no other tasks in D
state. Would you retry in the hope of catching some stucked state?
> > echo t> /proc/sysrq-trigger
> sadly i wa sonly able to grab the output in this crazy format:
> http://pastebin.com/raw.php?i=MBXvvyH1
It's pretty readable dmesg, except that the data is incomplete and
there are nothing valuable in the uploaded portion..
Thanks,
Fengguang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: slow performance on disk/network i/o full speed after drop_caches
From: Stefan Priebe @ 2011-08-26 3:13 UTC (permalink / raw)
To: Wu Fengguang
Cc: Pekka Enberg, LKML, linux-mm@kvack.org, Andrew Morton, Mel Gorman,
Jens Axboe, Linux Netdev List
In-Reply-To: <20110826030313.GA24058@localhost>
>> There is at least a numastat proc file.
>
> Thanks. This shows that node0 is accessed 10x more than node1.
What can i do to prevent this or isn't this normal when a machine mostly idles so processes are mostly processed by cpu0.
>
>> complete ps output:
>> http://pastebin.com/raw.php?i=b948svzN
>
> In that log, scp happens to be in R state and also no other tasks in D
> state. Would you retry in the hope of catching some stucked state?
Sadly not as the sysrq trigger has rebootet the machine and it will now run fine for 1 or 2 days.
>
>>> echo t> /proc/sysrq-trigger
>> sadly i wa sonly able to grab the output in this crazy format:
>> http://pastebin.com/raw.php?i=MBXvvyH1
>
> It's pretty readable dmesg, except that the data is incomplete and
> there are nothing valuable in the uploaded portion..
That was everything i could grab through netconsole. Is there a better way?
Stefan
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: slow performance on disk/network i/o full speed after drop_caches
From: Wu Fengguang @ 2011-08-26 3:26 UTC (permalink / raw)
To: Stefan Priebe
Cc: Pekka Enberg, LKML, linux-mm@kvack.org, Andrew Morton, Mel Gorman,
Jens Axboe, Linux Netdev List
In-Reply-To: <D299D0AE-2F3C-42E2-9723-A3D7C0108C40@profihost.ag>
On Fri, Aug 26, 2011 at 11:13:07AM +0800, Stefan Priebe wrote:
>
> >> There is at least a numastat proc file.
> >
> > Thanks. This shows that node0 is accessed 10x more than node1.
>
> What can i do to prevent this or isn't this normal when a machine mostly idles so processes are mostly processed by cpu0.
Yes, that's normal. However it should explain why it's slow even when
there are lots of free pages _globally_.
> >
> >> complete ps output:
> >> http://pastebin.com/raw.php?i=b948svzN
> >
> > In that log, scp happens to be in R state and also no other tasks in D
> > state. Would you retry in the hope of catching some stucked state?
> Sadly not as the sysrq trigger has rebootet the machine and it will now run fine for 1 or 2 days.
Oops, sorry! It might be possible to reproduce the issue by manually
eating all of the memory with sparse file data:
truncate -s 1T 1T
cp 1T /dev/null
> >
> >>> echo t> /proc/sysrq-trigger
> >> sadly i wa sonly able to grab the output in this crazy format:
> >> http://pastebin.com/raw.php?i=MBXvvyH1
> >
> > It's pretty readable dmesg, except that the data is incomplete and
> > there are nothing valuable in the uploaded portion..
> That was everything i could grab through netconsole. Is there a better way?
netconsole is enough. The partial output should be due to the reboot...
Thanks,
Fengguang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: slow performance on disk/network i/o full speed after drop_caches
From: Zhu Yanhai @ 2011-08-26 3:30 UTC (permalink / raw)
To: Wu Fengguang
Cc: Stefan Priebe, Pekka Enberg, LKML, linux-mm@kvack.org,
Andrew Morton, Mel Gorman, Jens Axboe, Linux Netdev List
In-Reply-To: <20110826032601.GA26282@localhost>
Fengguang,
Maybe it's because zone_reclaim_mode? We often have received some reports that
scp or something like that is slow with no reason, and mostly it's due
to someone
enabled zone_reclaim_mode by mistake.
Stefan, is your zone_reclaim_mode enabled? try 'cat
/proc/sys/vm/zone_reclaim_mode',
and echo 0 to it to disable.
Thanks,
Zhu Yanhai
2011/8/26 Wu Fengguang <fengguang.wu@intel.com>:
> On Fri, Aug 26, 2011 at 11:13:07AM +0800, Stefan Priebe wrote:
>>
>> >> There is at least a numastat proc file.
>> >
>> > Thanks. This shows that node0 is accessed 10x more than node1.
>>
>> What can i do to prevent this or isn't this normal when a machine mostly idles so processes are mostly processed by cpu0.
>
> Yes, that's normal. However it should explain why it's slow even when
> there are lots of free pages _globally_.
>
>> >
>> >> complete ps output:
>> >> http://pastebin.com/raw.php?i=b948svzN
>> >
>> > In that log, scp happens to be in R state and also no other tasks in D
>> > state. Would you retry in the hope of catching some stucked state?
>> Sadly not as the sysrq trigger has rebootet the machine and it will now run fine for 1 or 2 days.
>
> Oops, sorry! It might be possible to reproduce the issue by manually
> eating all of the memory with sparse file data:
>
> truncate -s 1T 1T
> cp 1T /dev/null
>
>> >
>> >>> echo t> /proc/sysrq-trigger
>> >> sadly i wa sonly able to grab the output in this crazy format:
>> >> http://pastebin.com/raw.php?i=MBXvvyH1
>> >
>> > It's pretty readable dmesg, except that the data is incomplete and
>> > there are nothing valuable in the uploaded portion..
>> That was everything i could grab through netconsole. Is there a better way?
>
> netconsole is enough. The partial output should be due to the reboot...
>
> Thanks,
> Fengguang
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* linux-next: manual merge of the staging tree with the net tree
From: Stephen Rothwell @ 2011-08-26 3:47 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Jiri Pirko, David Miller, netdev,
Larry Finger
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/rtl8192e/r8192E_core.c between commit afc4b13df143 ("net:
remove use of ndo_set_multicast_list in drivers") from the net tree and
commit 09505184ec3d ("staging: rtl8192e: Remove files that are not used")
from the staging tree.
The latter removed the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: strange routing issue--packets stop getting forwarded for a live connection
From: Corey Hickey @ 2011-08-26 3:50 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Linux Netdev List
In-Reply-To: <alpine.LFD.2.00.1108211142180.1581@ja.ssi.bg>
On 2011-08-21 02:02, Julian Anastasov wrote:
>>>> 3. MTU size; 1500 on eth0 and 1406 on tun0. Bigger packets have been
>>>> transferred fine.
>>>
>>> Lower MTU, it can be PMTUD problem. At 04:50:24.112658
>>> I see 7801:9169 is 1420 bytes and no ICMP FRAG NEEDED is generated.
>>> May be these two regressions explain it:
>>>
>>> http://marc.info/?l=linux-netdev&m=131342172722536&w=2
>>>
>>> There are 2 fixes you can try or more recent kernel
>>> tree, for example 3.1-rc2 has the fixes.
>>
>> Many thanks for your reply--it looks like you're on to something. You
>> didn't specify which interface to lower the MTU on, so I tried them each
>> in turn, and found that lowering the MTU on the client machine to 1406
>> (matching tun0 on the router) did indeed solve the problem. That makes
>> sense in retrospect.
>
> I just wanted to note the difference in MTUs
> as a possible cause that triggers the problem. And after
> your confirmation I think the new/patched kernel should work
> without playing with MTUs.
I finally got a chance to test this, and the patched kernel works fine.
Thank you!
-Corey
^ permalink raw reply
* Re: [PATCH net-next-2.6] e1000: save skb counts in TX to avoid cache misses
From: Jeff Kirsher @ 2011-08-26 3:52 UTC (permalink / raw)
To: Dean Nelson; +Cc: netdev@vger.kernel.org, Andy Gospodarek
In-Reply-To: <20110826003923.4083.24862.email-sent-by-dnelson@localhost6.localdomain6>
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]
On Thu, 2011-08-25 at 17:39 -0700, Dean Nelson wrote:
> Virtual Machines with emulated e1000 network adapter running on
> Parallels'
> server were seeing kernel panics due to the e1000 driver dereferencing
> an
> unexpected NULL pointer retrieved from buffer_info->skb.
>
> The problem has been addressed for the e1000e driver, but not for the
> e1000.
> Since the two drivers share similar code in the affected area, a port
> of the
> following e1000e driver commit solves the issue for the e1000 driver:
>
> commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180
> Author: Tom Herbert <therbert@google.com>
> Date: Wed May 5 14:02:27 2010 +0000
>
> e1000e: save skb counts in TX to avoid cache misses
>
> In e1000_tx_map, precompute number of segements and bytecounts
> which
> are derived from fields in skb; these are stored in buffer_info.
> When
> cleaning tx in e1000_clean_tx_irq use the values in the associated
> buffer_info for statistics counting, this eliminates cache misses
> on skb fields.
>
>
> Signed-off-by: Dean Nelson <dnelson@redhat.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Looks fine.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: Greg KH @ 2011-08-26 4:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Jiri Pirko, David Miller, netdev,
Larry Finger
In-Reply-To: <20110826134705.0d5b6767777f0af2f8667731@canb.auug.org.au>
On Fri, Aug 26, 2011 at 01:47:05PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/rtl8192e/r8192E_core.c between commit afc4b13df143 ("net:
> remove use of ndo_set_multicast_list in drivers") from the net tree and
> commit 09505184ec3d ("staging: rtl8192e: Remove files that are not used")
> from the staging tree.
>
> The latter removed the file, so I did that.
Thanks, that should be the correct thing :)
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: Larry Finger @ 2011-08-26 5:35 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, linux-next, linux-kernel, Jiri Pirko,
David Miller, netdev
In-Reply-To: <20110826043357.GA17686@kroah.com>
On 08/25/2011 11:33 PM, Greg KH wrote:
> On Fri, Aug 26, 2011 at 01:47:05PM +1000, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> Today's linux-next merge of the staging tree got a conflict in
>> drivers/staging/rtl8192e/r8192E_core.c between commit afc4b13df143 ("net:
>> remove use of ndo_set_multicast_list in drivers") from the net tree and
>> commit 09505184ec3d ("staging: rtl8192e: Remove files that are not used")
>> from the staging tree.
>>
>> The latter removed the file, so I did that.
>
> Thanks, that should be the correct thing :)
I'm a little confused. The files deleted in 09505184ec3d are not used at all in
the new rtl8192e. The only way it makes sense is you did not have the new
version when the the error with r8192E_core.c occurred.
The error that was reported to me was
"drivers/staging/rtl8192e/rtl_core.c:2917:2: error: unknown field
'ndo_set_multicast_list' specified in initializer". The file rtl_core.c is
needed with the new version. Yes, the names are quite confusing, which is part
of the reason it took so long to delete the unused ones.
I have tested Stephan's patch and will send it to Greg with my SOB.
Larry
^ permalink raw reply
* [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: Mitsuo Hayasaka @ 2011-08-26 6:02 UTC (permalink / raw)
To: Patrick McHardy, David S. Miller, Eric Dumazet,
MichałMirosław
Cc: netdev, linux-kernel, yrl.pp-manager.tt, Mitsuo Hayasaka,
Patrick McHardy, David S. Miller, Eric Dumazet,
"MichałMirosław", Tom Herbert, Jesse Gross
There is a time-lag of IFF_RUNNING flag consistency between vlan and real
devices when the real devices are in problem such as link or cable broken.
This leads to a degradation of Availability such as a delay of failover in
HA systems using vlan since the detection of the problem at real device is
delayed.
Why this happens:
Network devices' flags can be checked using ioctl with SIOCGIFFLAGS. When
vlan technique is used, it checks the flags of vlan device, not real
device.
Patch:
This patch adds vlan-device check into dev_get_flags(). So, it can check
flags of the real device even if the vlan is used.
Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: Tom Herbert <therbert@google.com>
Cc: Jesse Gross <jesse@nicira.com>
---
include/linux/if_vlan.h | 2 +-
net/core/dev.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 44da482..4df4e6f 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -91,7 +91,7 @@ struct vlan_group {
struct rcu_head rcu;
};
-static inline int is_vlan_dev(struct net_device *dev)
+static inline int is_vlan_dev(const struct net_device *dev)
{
return dev->priv_flags & IFF_802_1Q_VLAN;
}
diff --git a/net/core/dev.c b/net/core/dev.c
index a4306f7..527e21b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4603,6 +4603,13 @@ unsigned dev_get_flags(const struct net_device *dev)
(dev->gflags & (IFF_PROMISC |
IFF_ALLMULTI));
+ /*
+ * If we're trying to get flags on a vlan device
+ * use the underlying physical device instead.
+ */
+ if (is_vlan_dev(dev))
+ dev = vlan_dev_real_dev(dev);
+
if (netif_running(dev)) {
if (netif_oper_up(dev))
flags |= IFF_RUNNING;
^ permalink raw reply related
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: Stephen Hemminger @ 2011-08-26 6:08 UTC (permalink / raw)
To: Mitsuo Hayasaka
Cc: Patrick McHardy, David S. Miller, Eric Dumazet,
MichałMirosław, Tom Herbert, Jesse Gross, herbert,
netdev, linux-kernel, yrl.pp-manager.tt
In-Reply-To: <20110826060257.5304.62723.stgit@ltc219.sdl.hitachi.co.jp>
On Fri, 26 Aug 2011 15:02:57 +0900
Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> wrote:
> There is a time-lag of IFF_RUNNING flag consistency between vlan and real
> devices when the real devices are in problem such as link or cable broken.
> This leads to a degradation of Availability such as a delay of failover in
> HA systems using vlan since the detection of the problem at real device is
> delayed.
>
> Why this happens:
> Network devices' flags can be checked using ioctl with SIOCGIFFLAGS. When
> vlan technique is used, it checks the flags of vlan device, not real
> device.
>
> Patch:
> This patch adds vlan-device check into dev_get_flags(). So, it can check
> flags of the real device even if the vlan is used.
>
> Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Jesse Gross <jesse@nicira.com>
I don't think this is the right way to solve the problem.
The flags are supposed to propagate back from real device to vlan
via network notifications.
Just doing this for ioctl is not enough, API's other than user space depend on this.
Also the user may have manually set different flags on vlan than on
the real device.
^ permalink raw reply
* Re: slow performance on disk/network i/o full speed after drop_caches
From: Stefan Priebe - Profihost AG @ 2011-08-26 6:18 UTC (permalink / raw)
To: Zhu Yanhai
Cc: Wu Fengguang, Pekka Enberg, LKML, linux-mm@kvack.org,
Andrew Morton, Mel Gorman, Jens Axboe, Linux Netdev List
In-Reply-To: <CAC8teKXqZktBK7+GbLgHn-2k+zjjf8uieRM_q_V7JK7ePAk9Lg@mail.gmail.com>
Yanhai,
> Stefan, is your zone_reclaim_mode enabled? try 'cat
> /proc/sys/vm/zone_reclaim_mode',
> and echo 0 to it to disable.
you're abssolutely corect zone_reclaim_mode is on - but why?
There must be some linux software which switches it on.
~# grep 'zone_reclaim_mode' /etc/sysctl.* -r -i
~#
also
~# grep 'zone_reclaim_mode' /etc/sysctl.* -r -i
~#
tells us nothing.
I've then read this:
"zone_reclaim_mode is set during bootup to 1 if it is determined that
pages from remote zones will cause a measurable performance reduction.
The page allocator will then reclaim easily reusable pages (those page
cache pages that are currently not used) before allocating off node pages."
Why does the kernel do that here in our case on these machines.
Stefan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] p54spi: add "spi:" prefix for stlc45xx modalias
From: Axel Lin @ 2011-08-26 6:34 UTC (permalink / raw)
To: linux-kernel
Cc: Christian Lamparter, John W. Linville, linux-wireless, netdev
Since commit e0626e38 (spi: prefix modalias with "spi:"),
the spi modalias is prefixed with "spi:".
This patch adds "spi:" prefix for modalias of stlc45xx.
Also move it to be group with other modalias.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/net/wireless/p54/p54spi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 6d9204fe..f18df82 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -41,7 +41,6 @@
#endif /* CONFIG_P54_SPI_DEFAULT_EEPROM */
MODULE_FIRMWARE("3826.arm");
-MODULE_ALIAS("stlc45xx");
/*
* gpios should be handled in board files and provided via platform data,
@@ -738,3 +737,4 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Christian Lamparter <chunkeey@web.de>");
MODULE_ALIAS("spi:cx3110x");
MODULE_ALIAS("spi:p54spi");
+MODULE_ALIAS("spi:stlc45xx");
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: Herbert Xu @ 2011-08-26 6:45 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Mitsuo Hayasaka, Patrick McHardy, David S. Miller, Eric Dumazet,
MichałMirosław, Tom Herbert, Jesse Gross, netdev,
linux-kernel, yrl.pp-manager.tt
In-Reply-To: <20110825230859.11b2b132@nehalam.ftrdhcpuser.net>
On Thu, Aug 25, 2011 at 11:08:59PM -0700, Stephen Hemminger wrote:
>
> Just doing this for ioctl is not enough, API's other than user space depend on this.
> Also the user may have manually set different flags on vlan than on
> the real device.
Right, anything that tests netif_carrier_ok directly on the VLAN
device will still be delayed.
Now I remember discussing this issue in Japan. However, I can't
recall the exact scenario in which the delay occured.
Is the issue with the link status going down on the real device,
or the real device coming up?
IIRC we already have mechanisms in place to ensure that down events
are not delayed by linkwatch. Of course it is possible that this
isn't working for some reason, or some other part of the system is
causing the delay.
So please clarify the scenario for us Hayasaka-san. Also please
let us know how you measured the delay.
Thanks,
--
Email: Herbert Xu <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
* [PATCH 0/2] ath: Reduce logging message code size
From: Joe Perches @ 2011-08-26 8:56 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, linux-kernel
Reduces size ~5KB in an allyesconfig.
Joe Perches (2):
ath: Make ath_dbg void not int
ath: Make ath_printk void not int and remove unused struct ath_common *
drivers/net/wireless/ath/ath.h | 48 +++++++++++++++++++-------------------
drivers/net/wireless/ath/main.c | 8 +-----
2 files changed, 26 insertions(+), 30 deletions(-)
--
1.7.6.405.gc1be0
^ permalink raw reply
* [PATCH 2/2] ath: Make ath_printk void not int and remove unused struct ath_common *
From: Joe Perches @ 2011-08-26 8:56 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <cover.1314347556.git.joe@perches.com>
Changing the return type and removing the unused argument from
ath_printk reduces code size.
Add an __always_unused struct ath_common * to the macros
that call ath_printk to avoid unused variable warnings.
$ size drivers/net/wireless/ath/built-in.o*
text data bss dec hex filename
1159859 16235 212000 1388094 152e3e drivers/net/wireless/ath/built-in.o.new
1164175 16235 212032 1392442 153f3a drivers/net/wireless/ath/built-in.o.old
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/ath/ath.h | 27 ++++++++++++++++-----------
drivers/net/wireless/ath/main.c | 8 ++------
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index a3f8505..9891fb6 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -178,24 +178,29 @@ bool ath_hw_keyreset(struct ath_common *common, u16 entry);
void ath_hw_cycle_counters_update(struct ath_common *common);
int32_t ath_hw_get_listen_time(struct ath_common *common);
-extern __attribute__((format (printf, 3, 4)))
-int ath_printk(const char *level, struct ath_common *common,
- const char *fmt, ...);
+extern __attribute__((format (printf, 2, 3)))
+void ath_printk(const char *level, const char *fmt, ...);
+
+#define _ath_printk(level, common, fmt, ...) \
+do { \
+ __always_unused struct ath_common *unused = common; \
+ ath_printk(level, fmt, ##__VA_ARGS__); \
+} while (0)
#define ath_emerg(common, fmt, ...) \
- ath_printk(KERN_EMERG, common, fmt, ##__VA_ARGS__)
+ _ath_printk(KERN_EMERG, common, fmt, ##__VA_ARGS__)
#define ath_alert(common, fmt, ...) \
- ath_printk(KERN_ALERT, common, fmt, ##__VA_ARGS__)
+ _ath_printk(KERN_ALERT, common, fmt, ##__VA_ARGS__)
#define ath_crit(common, fmt, ...) \
- ath_printk(KERN_CRIT, common, fmt, ##__VA_ARGS__)
+ _ath_printk(KERN_CRIT, common, fmt, ##__VA_ARGS__)
#define ath_err(common, fmt, ...) \
- ath_printk(KERN_ERR, common, fmt, ##__VA_ARGS__)
+ _ath_printk(KERN_ERR, common, fmt, ##__VA_ARGS__)
#define ath_warn(common, fmt, ...) \
- ath_printk(KERN_WARNING, common, fmt, ##__VA_ARGS__)
+ _ath_printk(KERN_WARNING, common, fmt, ##__VA_ARGS__)
#define ath_notice(common, fmt, ...) \
- ath_printk(KERN_NOTICE, common, fmt, ##__VA_ARGS__)
+ _ath_printk(KERN_NOTICE, common, fmt, ##__VA_ARGS__)
#define ath_info(common, fmt, ...) \
- ath_printk(KERN_INFO, common, fmt, ##__VA_ARGS__)
+ _ath_printk(KERN_INFO, common, fmt, ##__VA_ARGS__)
/**
* enum ath_debug_level - atheros wireless debug level
@@ -250,7 +255,7 @@ enum ATH_DEBUG {
#define ath_dbg(common, dbg_mask, fmt, ...) \
do { \
if ((common)->debug_mask & dbg_mask) \
- ath_printk(KERN_DEBUG, common, fmt, ##__VA_ARGS__); \
+ _ath_printk(KERN_DEBUG, common, fmt, ##__VA_ARGS__); \
} while (0)
#define ATH_DBG_WARN(foo, arg...) WARN(foo, arg)
diff --git a/drivers/net/wireless/ath/main.c b/drivers/net/wireless/ath/main.c
index c325202..d9218fe 100644
--- a/drivers/net/wireless/ath/main.c
+++ b/drivers/net/wireless/ath/main.c
@@ -57,22 +57,18 @@ struct sk_buff *ath_rxbuf_alloc(struct ath_common *common,
}
EXPORT_SYMBOL(ath_rxbuf_alloc);
-int ath_printk(const char *level, struct ath_common *common,
- const char *fmt, ...)
+void ath_printk(const char *level, const char *fmt, ...)
{
struct va_format vaf;
va_list args;
- int rtn;
va_start(args, fmt);
vaf.fmt = fmt;
vaf.va = &args;
- rtn = printk("%sath: %pV", level, &vaf);
+ printk("%sath: %pV", level, &vaf);
va_end(args);
-
- return rtn;
}
EXPORT_SYMBOL(ath_printk);
--
1.7.6.405.gc1be0
^ permalink raw reply related
* [PATCH 1/2] ath: Make ath_dbg void not int
From: Joe Perches @ 2011-08-26 8:56 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <cover.1314347556.git.joe@perches.com>
The return value is never used so make it void.
Reduces object size a tiny bit.
$ size drivers/net/wireless/ath/built-in.o*
text data bss dec hex filename
1164175 16235 212032 1392442 153f3a drivers/net/wireless/ath/built-in.o.new
1164819 16235 212032 1393086 1541be drivers/net/wireless/ath/built-in.o.old
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/ath/ath.h | 29 ++++++++++++-----------------
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index 17c4b56..a3f8505 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -178,8 +178,9 @@ bool ath_hw_keyreset(struct ath_common *common, u16 entry);
void ath_hw_cycle_counters_update(struct ath_common *common);
int32_t ath_hw_get_listen_time(struct ath_common *common);
-extern __attribute__ ((format (printf, 3, 4))) int
-ath_printk(const char *level, struct ath_common *common, const char *fmt, ...);
+extern __attribute__((format (printf, 3, 4)))
+int ath_printk(const char *level, struct ath_common *common,
+ const char *fmt, ...);
#define ath_emerg(common, fmt, ...) \
ath_printk(KERN_EMERG, common, fmt, ##__VA_ARGS__)
@@ -246,27 +247,21 @@ enum ATH_DEBUG {
#ifdef CONFIG_ATH_DEBUG
-#define ath_dbg(common, dbg_mask, fmt, ...) \
-({ \
- int rtn; \
- if ((common)->debug_mask & dbg_mask) \
- rtn = ath_printk(KERN_DEBUG, common, fmt, \
- ##__VA_ARGS__); \
- else \
- rtn = 0; \
- \
- rtn; \
-})
+#define ath_dbg(common, dbg_mask, fmt, ...) \
+do { \
+ if ((common)->debug_mask & dbg_mask) \
+ ath_printk(KERN_DEBUG, common, fmt, ##__VA_ARGS__); \
+} while (0)
+
#define ATH_DBG_WARN(foo, arg...) WARN(foo, arg)
#define ATH_DBG_WARN_ON_ONCE(foo) WARN_ON_ONCE(foo)
#else
-static inline __attribute__ ((format (printf, 3, 4))) int
-ath_dbg(struct ath_common *common, enum ATH_DEBUG dbg_mask,
- const char *fmt, ...)
+static inline __attribute__((format (printf, 3, 4)))
+void ath_dbg(struct ath_common *common, enum ATH_DEBUG dbg_mask,
+ const char *fmt, ...)
{
- return 0;
}
#define ATH_DBG_WARN(foo, arg...) do {} while (0)
#define ATH_DBG_WARN_ON_ONCE(foo) ({ \
--
1.7.6.405.gc1be0
^ permalink raw reply related
* 3.1.0-rc2: irq/112-eth0-Tx: page allocation failure: (w/frame pointers enabled)
From: Justin Piszcz @ 2011-08-26 12:14 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Alan Piszcz
Hello,
Why does this occur on a machine with 48GB of memory (used mainly as a router)
and backup server, is it a kernel bug?
top - 08:12:19 up 8 days, 21 min, 73 users, load average: 0.05, 0.10, 0.15
Tasks: 604 total, 1 running, 603 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.4%us, 1.0%sy, 0.1%ni, 97.0%id, 0.4%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 49556624k total, 49038776k used, 517848k free, 619836k buffers
Swap: 2097148k total, 489076k used, 1608072k free, 36790936k cached
Kernel messages:
[687946.708409] irq/112-eth0-Tx: page allocation failure: order:1, mode:0x20
[687946.711519] Pid: 18665, comm: irq/112-eth0-Tx Not tainted 3.1.0-rc2 #1
[687946.714289] Call Trace:
[687946.716759] <IRQ> [<ffffffff8108673e>] warn_alloc_failed+0xee/0x140
[687946.719998] [<ffffffff8108970c>] __alloc_pages_nodemask+0x54c/0x770
[687946.722422] [<ffffffff810b8d8d>] kmem_getpages+0x5d/0x160
[687946.724869] [<ffffffff810b9f4e>] fallback_alloc+0x1be/0x1d0
[687946.727044] [<ffffffff810b9c2e>] ? cache_grow+0x26e/0x290
[687946.729379] [<ffffffff810b9cdc>] ____cache_alloc_node+0x8c/0x140
[687946.731666] [<ffffffff810ba413>] kmem_cache_alloc+0xa3/0xf0
[687946.733784] [<ffffffff814b3bec>] sk_prot_alloc.isra.40+0x3c/0x180
[687946.735996] [<ffffffff814b3dc9>] sk_clone+0x19/0x2d0
[687946.738418] [<ffffffff81508453>] inet_csk_clone+0x13/0xb0
[687946.740798] [<ffffffff81520144>] tcp_create_openreq_child+0x24/0x490
[687946.743286] [<ffffffff8151d307>] tcp_v4_syn_recv_sock+0x47/0x270
[687946.746065] [<ffffffff8151ff46>] tcp_check_req+0x2d6/0x4b0
[687946.748966] [<ffffffff8151d1ba>] tcp_v4_do_rcv+0x1aa/0x2b0
[687946.751572] [<ffffffff8151f704>] tcp_v4_rcv+0x5d4/0x8d0
[687946.754272] [<ffffffff814fe5e5>] ip_local_deliver_finish+0xc5/0x200
[687946.756948] [<ffffffff814fe8d8>] ip_local_deliver+0x88/0x90
[687946.759554] [<ffffffff814fe331>] ip_rcv_finish+0x121/0x310
[687946.762137] [<ffffffff814feace>] ip_rcv+0x1ee/0x2b0
[687946.764603] [<ffffffff8158fa66>] ? packet_rcv_spkt+0x136/0x180
[687946.767380] [<ffffffff814c2572>] __netif_receive_skb+0x4b2/0x5a0
[687946.769913] [<ffffffff814c2848>] netif_receive_skb+0x78/0x80
[687946.772275] [<ffffffff814c2cd8>] ? dev_gro_receive+0x1b8/0x2c0
[687946.775044] [<ffffffff814c33c8>] napi_skb_finish+0x48/0x60
[687946.777626] [<ffffffff814c348d>] napi_gro_receive+0xad/0xc0
[687946.780175] [<ffffffff8141b8f7>] igb_poll+0x707/0xd60
[687946.782682] [<ffffffff812ed7e4>] ? timerqueue_add+0x74/0xc0
[687946.785204] [<ffffffff8102ece0>] ? enqueue_task_rt+0x150/0x280
[687946.787789] [<ffffffff814c2a99>] net_rx_action+0x109/0x190
[687946.790282] [<ffffffff8102dead>] ? enqueue_task+0x3d/0x80
[687946.792884] [<ffffffff8103d1c8>] __do_softirq+0x98/0x120
[687946.795446] [<ffffffff81071680>] ? irq_thread_fn+0x50/0x50
[687946.798037] [<ffffffff815d1f6c>] call_softirq+0x1c/0x30
[687946.800530] <EOI> [<ffffffff81003abd>] do_softirq+0x4d/0x80
[687946.803066] [<ffffffff8103cf3c>] local_bh_enable+0x8c/0xa0
[687946.805471] [<ffffffff810716be>] irq_forced_thread_fn+0x3e/0x50
[687946.807945] [<ffffffff810715a7>] irq_thread+0x157/0x1e0
[687946.810228] [<ffffffff81071450>] ? irq_finalize_oneshot+0x120/0x120
[687946.812385] [<ffffffff81052277>] kthread+0x87/0x90
[687946.814488] [<ffffffff815d1e74>] kernel_thread_helper+0x4/0x10
[687946.816581] [<ffffffff810521f0>] ? kthread_worker_fn+0x130/0x130
[687946.819500] [<ffffffff815d1e70>] ? gs_change+0xb/0xb
[687946.821890] Mem-Info:
[687946.824226] Node 0 DMA per-cpu:
[687946.826667] CPU 0: hi: 0, btch: 1 usd: 0
[687946.829035] CPU 1: hi: 0, btch: 1 usd: 0
[687946.831210] CPU 2: hi: 0, btch: 1 usd: 0
[687946.833331] CPU 3: hi: 0, btch: 1 usd: 0
[687946.835359] CPU 4: hi: 0, btch: 1 usd: 0
[687946.837274] CPU 5: hi: 0, btch: 1 usd: 0
[687946.839086] CPU 6: hi: 0, btch: 1 usd: 0
[687946.839088] CPU 7: hi: 0, btch: 1 usd: 0
[687946.839089] CPU 8: hi: 0, btch: 1 usd: 0
[687946.839090] CPU 9: hi: 0, btch: 1 usd: 0
[687946.839093] CPU 10: hi: 0, btch: 1 usd: 0
[687946.839095] CPU 11: hi: 0, btch: 1 usd: 0
[687946.839128] CPU 12: hi: 0, btch: 1 usd: 0
[687946.839129] CPU 13: hi: 0, btch: 1 usd: 0
[687946.839131] CPU 14: hi: 0, btch: 1 usd: 0
[687946.839132] CPU 15: hi: 0, btch: 1 usd: 0
[687946.839134] CPU 16: hi: 0, btch: 1 usd: 0
[687946.839135] CPU 17: hi: 0, btch: 1 usd: 0
[687946.839136] CPU 18: hi: 0, btch: 1 usd: 0
[687946.839138] CPU 19: hi: 0, btch: 1 usd: 0
[687946.839139] CPU 20: hi: 0, btch: 1 usd: 0
[687946.839141] CPU 21: hi: 0, btch: 1 usd: 0
[687946.839142] CPU 22: hi: 0, btch: 1 usd: 0
[687946.839143] CPU 23: hi: 0, btch: 1 usd: 0
[687946.839144] Node 0 DMA32 per-cpu:
[687946.839146] CPU 0: hi: 186, btch: 31 usd: 104
[687946.839147] CPU 1: hi: 186, btch: 31 usd: 183
[687946.839149] CPU 2: hi: 186, btch: 31 usd: 35
[687946.839150] CPU 3: hi: 186, btch: 31 usd: 189
[687946.839152] CPU 4: hi: 186, btch: 31 usd: 26
[687946.839153] CPU 5: hi: 186, btch: 31 usd: 171
[687946.839154] CPU 6: hi: 186, btch: 31 usd: 7
[687946.839156] CPU 7: hi: 186, btch: 31 usd: 151
[687946.839157] CPU 8: hi: 186, btch: 31 usd: 24
[687946.839158] CPU 9: hi: 186, btch: 31 usd: 159
[687946.839160] CPU 10: hi: 186, btch: 31 usd: 0
[687946.839161] CPU 11: hi: 186, btch: 31 usd: 0
[687946.839162] CPU 12: hi: 186, btch: 31 usd: 161
[687946.839164] CPU 13: hi: 186, btch: 31 usd: 166
[687946.839165] CPU 14: hi: 186, btch: 31 usd: 162
[687946.839166] CPU 15: hi: 186, btch: 31 usd: 166
[687946.839168] CPU 16: hi: 186, btch: 31 usd: 60
[687946.839169] CPU 17: hi: 186, btch: 31 usd: 160
[687946.839170] CPU 18: hi: 186, btch: 31 usd: 1
[687946.839172] CPU 19: hi: 186, btch: 31 usd: 0
[687946.839173] CPU 20: hi: 186, btch: 31 usd: 0
[687946.839174] CPU 21: hi: 186, btch: 31 usd: 127
[687946.839176] CPU 22: hi: 186, btch: 31 usd: 0
[687946.839177] CPU 23: hi: 186, btch: 31 usd: 185
[687946.839178] Node 0 Normal per-cpu:
[687946.839179] CPU 0: hi: 186, btch: 31 usd: 7
[687946.839181] CPU 1: hi: 186, btch: 31 usd: 149
[687946.839182] CPU 2: hi: 186, btch: 31 usd: 22
[687946.839183] CPU 3: hi: 186, btch: 31 usd: 117
[687946.839185] CPU 4: hi: 186, btch: 31 usd: 101
[687946.839186] CPU 5: hi: 186, btch: 31 usd: 171
[687946.839188] CPU 6: hi: 186, btch: 31 usd: 56
[687946.839189] CPU 7: hi: 186, btch: 31 usd: 95
[687946.839190] CPU 8: hi: 186, btch: 31 usd: 51
[687946.839192] CPU 9: hi: 186, btch: 31 usd: 157
[687946.839193] CPU 10: hi: 186, btch: 31 usd: 0
[687946.839195] CPU 11: hi: 186, btch: 31 usd: 13
[687946.839196] CPU 12: hi: 186, btch: 31 usd: 33
[687946.839197] CPU 13: hi: 186, btch: 31 usd: 168
[687946.839199] CPU 14: hi: 186, btch: 31 usd: 176
[687946.839200] CPU 15: hi: 186, btch: 31 usd: 156
[687946.839202] CPU 16: hi: 186, btch: 31 usd: 124
[687946.839203] CPU 17: hi: 186, btch: 31 usd: 38
[687946.839204] CPU 18: hi: 186, btch: 31 usd: 22
[687946.839206] CPU 19: hi: 186, btch: 31 usd: 103
[687946.839207] CPU 20: hi: 186, btch: 31 usd: 32
[687946.839209] CPU 21: hi: 186, btch: 31 usd: 185
[687946.839210] CPU 22: hi: 186, btch: 31 usd: 48
[687946.839211] CPU 23: hi: 186, btch: 31 usd: 145
[687946.839213] Node 1 Normal per-cpu:
[687946.839214] CPU 0: hi: 186, btch: 31 usd: 93
[687946.839216] CPU 1: hi: 186, btch: 31 usd: 77
[687946.839217] CPU 2: hi: 186, btch: 31 usd: 40
[687946.839218] CPU 3: hi: 186, btch: 31 usd: 165
[687946.839220] CPU 4: hi: 186, btch: 31 usd: 4
[687946.839221] CPU 5: hi: 186, btch: 31 usd: 180
[687946.839222] CPU 6: hi: 186, btch: 31 usd: 29
[687946.839224] CPU 7: hi: 186, btch: 31 usd: 83
[687946.839225] CPU 8: hi: 186, btch: 31 usd: 78
[687946.839227] CPU 9: hi: 186, btch: 31 usd: 163
[687946.839228] CPU 10: hi: 186, btch: 31 usd: 171
[687946.839230] CPU 11: hi: 186, btch: 31 usd: 167
[687946.839231] CPU 12: hi: 186, btch: 31 usd: 21
[687946.839232] CPU 13: hi: 186, btch: 31 usd: 27
[687946.839234] CPU 14: hi: 186, btch: 31 usd: 30
[687946.839235] CPU 15: hi: 186, btch: 31 usd: 180
[687946.839236] CPU 16: hi: 186, btch: 31 usd: 4
[687946.839238] CPU 17: hi: 186, btch: 31 usd: 17
[687946.839239] CPU 18: hi: 186, btch: 31 usd: 83
[687946.839241] CPU 19: hi: 186, btch: 31 usd: 126
[687946.839242] CPU 20: hi: 186, btch: 31 usd: 161
[687946.839244] CPU 21: hi: 186, btch: 31 usd: 157
[687946.839245] CPU 22: hi: 186, btch: 31 usd: 172
[687946.839246] CPU 23: hi: 186, btch: 31 usd: 113
[687946.839250] active_anon:2415853 inactive_anon:207634 isolated_anon:0
[687946.839251] active_file:4112085 inactive_file:4489987 isolated_file:33
[687946.839252] unevictable:0 dirty:4489 writeback:0 unstable:0
[687946.839253] free:137513 slab_reclaimable:852856 slab_unreclaimable:39114
[687946.839254] mapped:15723 shmem:5214 pagetables:15849 bounce:0
[687946.839255] Node 0 DMA free:15896kB min:56kB low:68kB high:84kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15672kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[687946.839262] lowmem_reserve[]: 0 2991 24201 24201
[687946.839264] Node 0 DMA32 free:133556kB min:11124kB low:13904kB high:16684kB active_anon:509940kB inactive_anon:138796kB active_file:732776kB inactive_file:1063388kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3063520kB mlocked:0kB dirty:152kB writeback:0kB mapped:1472kB shmem:120kB slab_reclaimable:435724kB slab_unreclaimable:8988kB kernel_stack:320kB pagetables:1132kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[687946.839272] lowmem_reserve[]: 0 0 21210 21210
[687946.839274] Node 0 Normal free:215052kB min:78884kB low:98604kB high:118324kB active_anon:4096588kB inactive_anon:322760kB active_file:7572688kB inactive_file:7578964kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:21719040kB mlocked:0kB dirty:12488kB writeback:0kB mapped:29660kB shmem:15064kB slab_reclaimable:1546068kB slab_unreclaimable:78700kB kernel_stack:3480kB pagetables:35252kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[687946.839282] lowmem_reserve[]: 0 0 0 0
[687946.839283] Node 1 Normal free:185548kB min:90152kB low:112688kB high:135228kB active_anon:5056884kB inactive_anon:368980kB active_file:8142876kB inactive_file:9317596kB unevictable:0kB isolated(anon):0kB isolated(file):132kB present:24821760kB mlocked:0kB dirty:5316kB writeback:0kB mapped:31760kB shmem:5672kB slab_reclaimable:1429632kB slab_unreclaimable:68768kB kernel_stack:2648kB pagetables:27012kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[687946.839292] lowmem_reserve[]: 0 0 0 0
[687946.839294] Node 0 DMA: 0*4kB 1*8kB 1*16kB 0*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15896kB
[687946.839299] Node 0 DMA32: 31847*4kB 718*8kB 8*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 133260kB
[687946.839304] Node 0 Normal: 38479*4kB 5294*8kB 1090*16kB 11*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 214060kB
[687946.839309] Node 1 Normal: 29327*4kB 5080*8kB 910*16kB 102*32kB 19*64kB 11*128kB 26*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 185052kB
[687946.839314] 8618791 total pagecache pages
[687946.839315] 11459 pages in swap cache
[687946.839317] Swap cache stats: add 258693, delete 247234, find 26065392/26080490
[687946.839318] Free swap = 1628596kB
[687946.839319] Total swap = 2097148kB
[687947.017273] 12582896 pages RAM
[687947.020203] 193740 pages reserved
[687947.023090] 3702079 pages shared
[687947.025938] 8692980 pages non-shared
[687949.743902] irq/112-eth0-Tx: page allocation failure: order:1, mode:0x20
[687949.746909] Pid: 18665, comm: irq/112-eth0-Tx Not tainted 3.1.0-rc2 #1
[687949.749718] Call Trace:
[687949.752521] <IRQ> [<ffffffff8108673e>] warn_alloc_failed+0xee/0x140
[687949.755407] [<ffffffff8108970c>] __alloc_pages_nodemask+0x54c/0x770
[687949.758276] [<ffffffff810b8d8d>] kmem_getpages+0x5d/0x160
[687949.761157] [<ffffffff810b9f4e>] fallback_alloc+0x1be/0x1d0
[687949.764182] [<ffffffff810b9c2e>] ? cache_grow+0x26e/0x290
[687949.767350] [<ffffffff810b9cdc>] ____cache_alloc_node+0x8c/0x140
[687949.770514] [<ffffffff810ba413>] kmem_cache_alloc+0xa3/0xf0
[687949.773699] [<ffffffff814b3bec>] sk_prot_alloc.isra.40+0x3c/0x180
[687949.776947] [<ffffffff814b3dc9>] sk_clone+0x19/0x2d0
[687949.780172] [<ffffffff81508453>] inet_csk_clone+0x13/0xb0
[687949.783425] [<ffffffff81520144>] tcp_create_openreq_child+0x24/0x490
[687949.786686] [<ffffffff8151d307>] tcp_v4_syn_recv_sock+0x47/0x270
[687949.789977] [<ffffffff8151ff46>] tcp_check_req+0x2d6/0x4b0
[687949.793264] [<ffffffff8151d1ba>] tcp_v4_do_rcv+0x1aa/0x2b0
[687949.796565] [<ffffffff8151f704>] tcp_v4_rcv+0x5d4/0x8d0
[687949.799867] [<ffffffff814fe5e5>] ip_local_deliver_finish+0xc5/0x200
[687949.803162] [<ffffffff814fe8d8>] ip_local_deliver+0x88/0x90
[687949.806463] [<ffffffff814fe331>] ip_rcv_finish+0x121/0x310
[687949.809779] [<ffffffff814feace>] ip_rcv+0x1ee/0x2b0
[687949.813105] [<ffffffff8158fa66>] ? packet_rcv_spkt+0x136/0x180
[687949.816446] [<ffffffff814c2572>] __netif_receive_skb+0x4b2/0x5a0
[687949.819794] [<ffffffff814c2848>] netif_receive_skb+0x78/0x80
[687949.823157] [<ffffffff814c2cd8>] ? dev_gro_receive+0x1b8/0x2c0
[687949.826529] [<ffffffff814c33c8>] napi_skb_finish+0x48/0x60
[687949.829918] [<ffffffff814c348d>] napi_gro_receive+0xad/0xc0
[687949.833315] [<ffffffff8141b8f7>] igb_poll+0x707/0xd60
[687949.833324] [<ffffffff8101db39>] ? physflat_send_IPI_mask+0x9/0x10
[687949.833330] [<ffffffff8102ece0>] ? enqueue_task_rt+0x150/0x280
[687949.833338] [<ffffffff814c2a99>] net_rx_action+0x109/0x190
[687949.833342] [<ffffffff8102dead>] ? enqueue_task+0x3d/0x80
[687949.833348] [<ffffffff8103d1c8>] __do_softirq+0x98/0x120
[687949.833353] [<ffffffff81071680>] ? irq_thread_fn+0x50/0x50
[687949.833359] [<ffffffff815d1f6c>] call_softirq+0x1c/0x30
[687949.833361] <EOI> [<ffffffff81003abd>] do_softirq+0x4d/0x80
[687949.833369] [<ffffffff8103cf3c>] local_bh_enable+0x8c/0xa0
[687949.833372] [<ffffffff810716be>] irq_forced_thread_fn+0x3e/0x50
[687949.833375] [<ffffffff810715a7>] irq_thread+0x157/0x1e0
[687949.833379] [<ffffffff81071450>] ? irq_finalize_oneshot+0x120/0x120
[687949.833384] [<ffffffff81052277>] kthread+0x87/0x90
[687949.833388] [<ffffffff815d1e74>] kernel_thread_helper+0x4/0x10
[687949.833392] [<ffffffff810521f0>] ? kthread_worker_fn+0x130/0x130
[687949.833395] [<ffffffff815d1e70>] ? gs_change+0xb/0xb
[687949.833398] Mem-Info:
[687949.833400] Node 0 DMA per-cpu:
[687949.833402] CPU 0: hi: 0, btch: 1 usd: 0
[687949.833405] CPU 1: hi: 0, btch: 1 usd: 0
[687949.833407] CPU 2: hi: 0, btch: 1 usd: 0
[687949.833409] CPU 3: hi: 0, btch: 1 usd: 0
[687949.833411] CPU 4: hi: 0, btch: 1 usd: 0
[687949.833413] CPU 5: hi: 0, btch: 1 usd: 0
[687949.833415] CPU 6: hi: 0, btch: 1 usd: 0
[687949.833417] CPU 7: hi: 0, btch: 1 usd: 0
[687949.833419] CPU 8: hi: 0, btch: 1 usd: 0
[687949.833421] CPU 9: hi: 0, btch: 1 usd: 0
[687949.833423] CPU 10: hi: 0, btch: 1 usd: 0
[687949.833425] CPU 11: hi: 0, btch: 1 usd: 0
[687949.833427] CPU 12: hi: 0, btch: 1 usd: 0
[687949.833429] CPU 13: hi: 0, btch: 1 usd: 0
[687949.833432] CPU 14: hi: 0, btch: 1 usd: 0
[687949.833434] CPU 15: hi: 0, btch: 1 usd: 0
[687949.833436] CPU 16: hi: 0, btch: 1 usd: 0
[687949.833438] CPU 17: hi: 0, btch: 1 usd: 0
[687949.833440] CPU 18: hi: 0, btch: 1 usd: 0
[687949.833442] CPU 19: hi: 0, btch: 1 usd: 0
[687949.833444] CPU 20: hi: 0, btch: 1 usd: 0
[687949.833446] CPU 21: hi: 0, btch: 1 usd: 0
[687949.833448] CPU 22: hi: 0, btch: 1 usd: 0
[687949.833450] CPU 23: hi: 0, btch: 1 usd: 0
[687949.833451] Node 0 DMA32 per-cpu:
[687949.833454] CPU 0: hi: 186, btch: 31 usd: 31
[687949.833456] CPU 1: hi: 186, btch: 31 usd: 177
[687949.833458] CPU 2: hi: 186, btch: 31 usd: 44
[687949.833460] CPU 3: hi: 186, btch: 31 usd: 186
[687949.833462] CPU 4: hi: 186, btch: 31 usd: 26
[687949.833465] CPU 5: hi: 186, btch: 31 usd: 161
[687949.833467] CPU 6: hi: 186, btch: 31 usd: 19
[687949.833469] CPU 7: hi: 186, btch: 31 usd: 120
[687949.833471] CPU 8: hi: 186, btch: 31 usd: 24
[687949.833473] CPU 9: hi: 186, btch: 31 usd: 129
[687949.833475] CPU 10: hi: 186, btch: 31 usd: 0
[687949.833477] CPU 11: hi: 186, btch: 31 usd: 0
[687949.833479] CPU 12: hi: 186, btch: 31 usd: 159
[687949.833481] CPU 13: hi: 186, btch: 31 usd: 170
[687949.833483] CPU 14: hi: 186, btch: 31 usd: 181
[687949.833485] CPU 15: hi: 186, btch: 31 usd: 166
[687949.833488] CPU 16: hi: 186, btch: 31 usd: 60
[687949.833490] CPU 17: hi: 186, btch: 31 usd: 160
[687949.833492] CPU 18: hi: 186, btch: 31 usd: 1
[687949.833494] CPU 19: hi: 186, btch: 31 usd: 0
[687949.833496] CPU 20: hi: 186, btch: 31 usd: 0
[687949.833498] CPU 21: hi: 186, btch: 31 usd: 127
[687949.833500] CPU 22: hi: 186, btch: 31 usd: 0
[687949.833502] CPU 23: hi: 186, btch: 31 usd: 185
[687949.833503] Node 0 Normal per-cpu:
[687949.833505] CPU 0: hi: 186, btch: 31 usd: 43
[687949.833508] CPU 1: hi: 186, btch: 31 usd: 81
[687949.833510] CPU 2: hi: 186, btch: 31 usd: 51
[687949.833512] CPU 3: hi: 186, btch: 31 usd: 114
[687949.833514] CPU 4: hi: 186, btch: 31 usd: 95
[687949.833516] CPU 5: hi: 186, btch: 31 usd: 154
[687949.833518] CPU 6: hi: 186, btch: 31 usd: 108
[687949.833520] CPU 7: hi: 186, btch: 31 usd: 69
[687949.833522] CPU 8: hi: 186, btch: 31 usd: 22
[687949.833524] CPU 9: hi: 186, btch: 31 usd: 181
[687949.833526] CPU 10: hi: 186, btch: 31 usd: 174
[687949.833528] CPU 11: hi: 186, btch: 31 usd: 0
[687949.833530] CPU 12: hi: 186, btch: 31 usd: 157
[687949.833532] CPU 13: hi: 186, btch: 31 usd: 157
[687949.833534] CPU 14: hi: 186, btch: 31 usd: 110
[687949.833536] CPU 15: hi: 186, btch: 31 usd: 164
[687949.833538] CPU 16: hi: 186, btch: 31 usd: 114
[687949.833541] CPU 17: hi: 186, btch: 31 usd: 38
[687949.833543] CPU 18: hi: 186, btch: 31 usd: 0
[687949.833545] CPU 19: hi: 186, btch: 31 usd: 72
[687949.833547] CPU 20: hi: 186, btch: 31 usd: 1
[687949.833549] CPU 21: hi: 186, btch: 31 usd: 164
[687949.833551] CPU 22: hi: 186, btch: 31 usd: 55
[687949.833553] CPU 23: hi: 186, btch: 31 usd: 118
[687949.833554] Node 1 Normal per-cpu:
[687949.833557] CPU 0: hi: 186, btch: 31 usd: 64
[687949.833559] CPU 1: hi: 186, btch: 31 usd: 125
[687949.833561] CPU 2: hi: 186, btch: 31 usd: 56
[687949.833563] CPU 3: hi: 186, btch: 31 usd: 148
[687949.833565] CPU 4: hi: 186, btch: 31 usd: 0
[687949.833567] CPU 5: hi: 186, btch: 31 usd: 149
[687949.833569] CPU 6: hi: 186, btch: 31 usd: 151
[687949.833571] CPU 7: hi: 186, btch: 31 usd: 79
[687949.833573] CPU 8: hi: 186, btch: 31 usd: 61
[687949.833575] CPU 9: hi: 186, btch: 31 usd: 183
[687949.833577] CPU 10: hi: 186, btch: 31 usd: 171
[687949.833579] CPU 11: hi: 186, btch: 31 usd: 167
[687949.833581] CPU 12: hi: 186, btch: 31 usd: 174
[687949.833584] CPU 13: hi: 186, btch: 31 usd: 171
[687949.833586] CPU 14: hi: 186, btch: 31 usd: 158
[687949.833588] CPU 15: hi: 186, btch: 31 usd: 149
[687949.833590] CPU 16: hi: 186, btch: 31 usd: 6
[687949.833592] CPU 17: hi: 186, btch: 31 usd: 17
[687949.833594] CPU 18: hi: 186, btch: 31 usd: 82
[687949.833596] CPU 19: hi: 186, btch: 31 usd: 111
[687949.833598] CPU 20: hi: 186, btch: 31 usd: 159
[687949.833600] CPU 21: hi: 186, btch: 31 usd: 157
[687949.833602] CPU 22: hi: 186, btch: 31 usd: 160
[687949.833604] CPU 23: hi: 186, btch: 31 usd: 74
[687949.833610] active_anon:2415858 inactive_anon:207589 isolated_anon:0
[687949.833611] active_file:4112461 inactive_file:4495431 isolated_file:0
[687949.833612] unevictable:0 dirty:5362 writeback:0 unstable:0
[687949.833614] free:135634 slab_reclaimable:847992 slab_unreclaimable:39054
[687949.833615] mapped:15726 shmem:5214 pagetables:15849 bounce:0
[687949.833617] Node 0 DMA free:15896kB min:56kB low:68kB high:84kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15672kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[687949.833627] lowmem_reserve[]: 0 2991 24201 24201
[687949.833631] Node 0 DMA32 free:121756kB min:11124kB low:13904kB high:16684kB active_anon:509940kB inactive_anon:138796kB active_file:732776kB inactive_file:1077800kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3063520kB mlocked:0kB dirty:384kB writeback:0kB mapped:1472kB shmem:120kB slab_reclaimable:435700kB slab_unreclaimable:9008kB kernel_stack:320kB pagetables:1132kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[687949.833643] lowmem_reserve[]: 0 0 21210 21210
[687949.833645] Node 0 Normal free:178800kB min:78884kB low:98604kB high:118324kB active_anon:4096596kB inactive_anon:322580kB active_file:7573100kB inactive_file:7623984kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:21719040kB mlocked:0kB dirty:13852kB writeback:0kB mapped:29672kB shmem:15064kB slab_reclaimable:1532288kB slab_unreclaimable:78968kB kernel_stack:3480kB pagetables:35252kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[687949.833657] lowmem_reserve[]: 0 0 0 0
[687949.833660] Node 1 Normal free:226084kB min:90152kB low:112688kB high:135228kB active_anon:5056896kB inactive_anon:368980kB active_file:8143968kB inactive_file:9279940kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:24821760kB mlocked:0kB dirty:7212kB writeback:0kB mapped:31760kB shmem:5672kB slab_reclaimable:1423980kB slab_unreclaimable:68240kB kernel_stack:2648kB pagetables:27012kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[687949.833672] lowmem_reserve[]: 0 0 0 0
[687949.833674] Node 0 DMA: 0*4kB 1*8kB 1*16kB 0*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15896kB
[687949.833682] Node 0 DMA32: 28319*4kB 870*8kB 95*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 121756kB
[687949.833689] Node 0 Normal: 29680*4kB 4095*8kB 1649*16kB 27*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 178728kB
[687949.833697] Node 1 Normal: 39478*4kB 6538*8kB 637*16kB 111*32kB 9*64kB 7*128kB 4*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 226456kB
[687949.833704] 8624516 total pagecache pages
[687949.833706] 11462 pages in swap cache
[687949.833708] Swap cache stats: add 258724, delete 247262, find 26065393/26080492
[687949.833710] Free swap = 1628508kB
[687949.833711] Total swap = 2097148kB
[687950.051707] 12582896 pages RAM
[687950.054637] 193740 pages reserved
[687950.057542] 3675896 pages shared
[687950.060450] 8720032 pages non-shared
Justin.
^ permalink raw reply
* Re: [PATCH] iptables/man: IPv6 TOS mangling fix was backported to 2.6.35-longterm too
From: Jan Engelhardt @ 2011-08-26 13:16 UTC (permalink / raw)
To: Fernando Luis Vazquez Cao
Cc: Patrick McHardy, Netfilter Developer Mailing List,
Linux Networking Developer Mailing List
In-Reply-To: <1314154554.1878.7.camel@nausicaa>
On Wednesday 2011-08-24 04:55, Fernando Luis Vazquez Cao wrote:
>Fernando Luis Vázquez Cao wrote:
>> Update man page accordingly.
>>
>> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
>> ---
>>
>> -longterm releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug
>> -whereby IPv6 TOS mangling does not behave as documented and differs from the
>> -IPv4 version. The TOS mask indicates the bits one wants to zero out, so it needs
>> -to be inverted before applying it to the original TOS field. However, the
>> +longterm releases 2.6.32 (>=.42), 2.6.33 (>=.15), and 2.6.35 (>=.14), there is
>> +a bug whereby IPv6 TOS mangling does not behave as documented and differs from
>> +the IPv4 version. The TOS mask indicates the bits one wants to zero out, so it
>> +needs to be inverted before applying it to the original TOS field. However, the
>> aformentioned kernels forgo the inversion which breaks --set-tos and its
>> mnemonics.
>
>Ping?
Patch picked up now.
^ permalink raw reply
* Re: [PATCH] p54spi: add "spi:" prefix for stlc45xx modalias
From: Christian Lamparter @ 2011-08-26 14:51 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, John W. Linville, linux-wireless, netdev
In-Reply-To: <1314340499.25655.1.camel@phoenix>
On Friday, August 26, 2011 08:34:59 AM Axel Lin wrote:
> Since commit e0626e38 (spi: prefix modalias with "spi:"),
> the spi modalias is prefixed with "spi:".
>
> This patch adds "spi:" prefix for modalias of stlc45xx.
> Also move it to be group with other modalias.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
sure, can't say no.
Acked-By: Christian Lamparter <chunkeey@googlemail.com>
^ permalink raw reply
* Re: [PATCH net-next v2 05/10] headers, net: Define struct __kernel_sockaddr, replacing struct sockaddr
From: David Miller @ 2011-08-26 15:08 UTC (permalink / raw)
To: ben; +Cc: netdev
In-Reply-To: <1314247456.27179.122.camel@deadeye>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Thu, 25 Aug 2011 05:44:15 +0100
> Commit 9c501935a3cdcf6b1d35aaee3aa11c7a7051a305 ('net: Support
> inclusion of <linux/socket.h> before <sys/socket.h>') removed the
> definition of struct sockaddr for userland.
>
> But we still have several headers using struct sockaddr, and we
> shouldn't make them include <sys/socket.h> as that risks recursive
> inclusion in future. Define and use an identical struct
> __kernel_sockaddr instead.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
...
>
> -/*
> - * 1003.1g requires sa_family_t and that sa_data is char.
> - */
> +#define sockaddr __kernel_sockaddr
This cure is worse than the disease.
Now any application that includes sys/socket.h one way or another is
now going to get a real hard build failure since __kernel_sockaddr
will effectively get redefined.
There is no reason sys/socket.h and our headers cannot co-exist and
this is the whole reason we're going through all of this pain to use
the __kernel_foo types in our networking datastructures which are
exposed to userspace.
^ 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