* Re: Udp packets received with improper length
From: Gerrit Renker @ 2011-12-03 2:32 UTC (permalink / raw)
To: David Miller; +Cc: fsmail, netdev
In-Reply-To: <20111201.141136.1615370877653045134.davem@davemloft.net>
Dave, -
| From: paul bilke <fsmail@conspiracy.net>
| Date: Mon, 28 Nov 2011 15:23:52 -0600
|
| > On 11/23/2011 2:14 PM, paul bilke wrote:
| >> We recently updated an embedded powerpc platform from 2.6.32 to 2.6.37. When deployed in the field devices with the new kernel have started receiving truncated UDP packets from their mates across noisy links. To test we wrote a simple client and
| >> server. The client sends 512 byte packets with a sequence number to the server listening on a UDP socket. On the client box we use netem to corrupt 100% of the packets sent(after transferring some data so arp cache is populated). The server then
| >> dumps the length received and the serial number from any packets that are received. Netem sometimes corrupts bits in the source MAC address so these packets arrive with valid UDP checksums and are delivered to the user application. With the
| >> server running on the 2.6.32 box we send a few million packets to it and only receive packets that are exactly 512 bytes long. When we do the same on the box running 2.6.37 we receive hundred of short packets, zero length and also 504 byte packets.
| >> When I use TCPdump on the box running 2.6.37 the truncate packets have valid checksums (Source MAC was corrupted by NETEM) and are of proper length (554 byte ethernet frame, 540 Byte IP portion and 520 byte UDP length) but the userland receives 504
| >> or 0 length in recvfrom. To see if this was just a powerpc related issue I repeated the test on x86 virtual machines. A vm running 2.6.18 (Centos 5) receives only 512 byte packets. On a vm running 2.6.40 (Fedora 15) I receive 512, 504 and 0 length
| >> packets.
| > <clip>
| >
| > Reverting commit 81d54ec8479a2c695760da81f05b5a9fb2dbe40a makes this problem disappear. The patch looks sane, the results are problematic.
|
| I think that commit is buggy. If we do a goto to "try_again", the length has already been
| truncated the first time around, so the calculation is not the same as what the original code
| calculates
|
| And indeed, checksum errors are how we can end up taking this code path.
|
| I'm reverting.
|
You are correct. What I had failed to see is the try_again case with multiple corruped datagrams. In this case the
code is not correct, len could already have been modified in the previous iteration. Reverting the commit is the
sanest option. Thank you.
Gerrit
^ permalink raw reply
* Re: pull request: batman-adv 2011-11-26
From: David Miller @ 2011-12-03 1:59 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
lindner_marek-LWAfsSFWpa4
In-Reply-To: <20111203015528.GB3148-E/2OGukznS5g9hUCZPvPmw@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Sat, 3 Dec 2011 02:55:29 +0100
> We first call pskb_may_pull() to pull the header only and then, under certain
> conditions, we linearise the whole skb to access it all. Should I use
> pskb_may_pull() even in this case?
Why would you need to access the whole thing?
There are only two types of possible accesses:
1) Header parsing --> use pskb_may_pull() as needed.
2) Copying the data to some other location, such as a user
buffer. Use skb_copy_datagram_iovec or similar which handle
fragmented SKBs just fine.
You should handle fragmented SKBs as much as possible, because
linearization is expensive and often amounts to a memory allocation
plus a copy if you linearize the whole thing.
^ permalink raw reply
* Re: pull request: batman-adv 2011-11-26
From: Antonio Quartulli @ 2011-12-03 1:55 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
lindner_marek-LWAfsSFWpa4
In-Reply-To: <20111202.125725.896787381527077500.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, Dec 02, 2011 at 12:57:25 -0500, David Miller wrote:
> From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
> Date: Fri, 2 Dec 2011 18:12:16 +0100
>
> > First of all I think you are referring to patch 08/10, in which I moved a
> > skb_linearise() operation.
> >
> > To be sure it is really needed, I backtracked the code flow and noted down any
> > eventual psbk_may_pull() (or any other linearisation operation). The result is:
> >
> > => in batman_skb_recv()
> > - pskb_may_pull(2)
> > => in recv_tt_query()
> > - pskb_may_pull(sizeof(header))
> > - skb_linearise()
> >
> > Actually it seems we haven't any useless linearisation.
> > Would you mind explain us where you actually found the problem, please?
> >
> > It might also be that I misunderstood your advice.
>
> You only need to call pskb_may_pull() on the parts of the packet you want to
> access directly to parse headers etc.
>
> If you use that interface properly, you never need to linearize, ever.
Sorry for being too generic: we actually invoke skb_linearise() because
we want to access the whole skb.
We first call pskb_may_pull() to pull the header only and then, under certain
conditions, we linearise the whole skb to access it all. Should I use
pskb_may_pull() even in this case?
Sorry for stealing you so much time on this issue, but I would like to fully
understand it in order to avoid any further mistake.
Thank you again.
Best Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
^ permalink raw reply
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Francois Romieu @ 2011-12-03 0:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: igorm, netdev, davem, Realtek linux nic maintainers
In-Reply-To: <1322836191.2762.3.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> :
[...]
> Also please CC maintainers of this driver to your submission.
>
> (I did this)
Thanks.
Frankly I would appreciate if people could wait a bit until fixes for
the current RxFIFOOverflow mess - and a bit more - are submitted. I just
need the week end for some sanity tested patches with a few different
nic.
Btw some code may be saved with an adequate ad-hoc {bytes/tx}_compl
struct and a few helpers acting on it as well as dev/dev->stats and
skb.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] datapath: Fix build breakage on kernel 2.6.40
From: Jesse Gross @ 2011-12-02 23:38 UTC (permalink / raw)
To: Zhi Yong Wu
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
aliguori-r/Jw6+rmf7HQT0dZR+AlfA, stefanha-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <CAEH94Li8gdMZnwSHG_xQj761uRxedRX2nUVmhFV4Kt_EDeuzYQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 1, 2011 at 6:25 PM, Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
> On Thu, Dec 1, 2011 at 5:55 AM, Jesse Gross <jesse@nicira.com> wrote:
>> On Wed, Nov 23, 2011 at 1:58 AM, Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
>>> diff --git a/datapath/linux/compat/include/linux/skbuff.h b/datapath/linux/compat/include/linux/skbuff.h
>>> index 311bfdb..22ba2e6 100644
>>> --- a/datapath/linux/compat/include/linux/skbuff.h
>>> +++ b/datapath/linux/compat/include/linux/skbuff.h
>>> @@ -239,7 +239,7 @@ static inline struct page *skb_frag_page(const skb_frag_t *frag)
>>> }
>>> #endif
>>>
>>> -#if LINUX_VERSION_CODE < KERNEL_VERSION(3,0,0)
>>> +#ifndef HAVE_SKB_RESET_MAC_LEN
>>
>> 2.6.40 is the early name for 3.0. Does it work if you just replace
>> the check with KERNEL_VERSION(2,6,40)?
> Yeah, it can work now, but i don't know if this issue exist on other
> old kernel version < 2.6.40.
Usually we just do these types of checks as we see examples of actual
backporting to avoid having hundreds of tests at configure time. In
this case, I think the issue is just a difference in how the same
kernel is numbered not backporting, so there isn't really a reason to
believe that this is a bigger problem.
> Should we send one updated patch for this based on your suggestion?
That would be great, thanks.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: Integration of Open vSwitch
From: Jesse Gross @ 2011-12-02 23:30 UTC (permalink / raw)
To: jhs-jkUAjuhPggJWk0Htik3J/w
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Chris Wright, Herbert Xu,
Eric Dumazet, netdev, John Fastabend, Stephen Hemminger,
David Miller
In-Reply-To: <1322658716.2243.12.camel@mojatatu>
On Wed, Nov 30, 2011 at 5:11 AM, jamal <hadi@cyberus.ca> wrote:
> On Tue, 2011-11-29 at 22:25 -0800, Jesse Gross wrote:
>> As I
>> mentioned before, I'd like to have a bit of a design discussion of
>> what it would look like if Open vSwitch were to use some of the
>> existing components (and really focus on just that). There were a
>> number of suggestions made about using parts of the bridge, tc,
>> netfilter, etc. and some of them overlap or conflict so I don't quite
>> have a coherent solution in mind. Would you guys mind walking through
>> what each of you envision it looking like?
>
> I'll try my TL;DR version:
> My opinion is the classifier action code needs refactoring. I have no
> doubt that it goes in as is it will eventually look like the one
> we already have. From the evolution of that code i can already see
> that is where it is going. I really dont see need to have two competing
> interfaces in that aspect. If you decide to go that way I will be
> happy to help review and make suggestions.
I completely agree with the desire to share code where there's overlap
and it makes sense (I was actually just working on some refactoring to
increase code reuse before this).
I think one of the key things to focus on is the userspace/kernel
interface since we'll have much less opportunity to significantly
change that over time. Getting both compatibility and performance is
something that we've worked on a fair amount and have arrived at a
solution that meets the needs of OVS (and probably only OVS) pretty
well. I think it's a nice model but keeping that while refactoring on
top of the tc layer seems challenging to do cleanly because the flow
information is needed by both the flow lookup and userspace
communication. Stringing that through generic code seems fairly
unappealing.
So I agree with you in principle and if you are right that things tend
to converge there should be more room for code reuse over time. Right
now though I would just focus on the high level bits.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH] infiniband: addr: Avoid unnecessary neigh lookup.
From: Roland Dreier @ 2011-12-02 23:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111202.145525.1679807360238725746.davem@davemloft.net>
> So if it's OK with you I'd like to merge this stuff directly in the
> net-next tree after getting your ACK on each patch.
Sure, that's fine, and for this particular patch:
Acked-by: Roland Dreier <roland@purestorage.com>
^ permalink raw reply
* Re: Integration of Open vSwitch
From: Jesse Gross @ 2011-12-02 23:08 UTC (permalink / raw)
To: Herbert Xu
Cc: jhs, netdev, dev, David Miller, Stephen Hemminger, Chris Wright,
John Fastabend, Eric Dumazet
In-Reply-To: <20111130070011.GA32630@gondor.apana.org.au>
On Tue, Nov 29, 2011 at 11:00 PM, Herbert Xu
<herbert@gondor.apana.org.au> wrote:
> The other factor I considered is scalability. The OVS code as is
> is not really friendly to SMP/NUMA scalability (but as Eric pointed,
> neither is the classifier/action layer). However, if this were to
> become a problem in future I'm sure we could extend either the
> interface as is (e.g., deploying multiqueue netlink sockets), or
> migrate to something else.
I agree that adding new flows is a weakness of the OVS model
(obviously it was a trade off) that has some room to be improved.
But, as you say, that's more of a long-term project that I think can
be done incrementally over time.
> So I don't really have any objections to this going into the tree.
Great, thanks for reviewing.
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Jerome Glisse @ 2011-12-02 23:04 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Christoph Lameter, Alex, Shi, Eric Dumazet,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel,
Pekka Enberg, linux-mm@kvack.org, Matt Mackall, tj, Alex Deucher
In-Reply-To: <20111124085040.GA1677@x4.trippels.de>
[-- Attachment #1: Type: text/plain, Size: 12970 bytes --]
On Thu, Nov 24, 2011 at 09:50:40AM +0100, Markus Trippelsdorf wrote:
> On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> >
> > > > FIX idr_layer_cache: Marking all objects used
> > >
> > > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > > exactly the same spot again. (CCing the drm list)
> >
> > Well this is looks like write after free.
> >
> > > =============================================================================
> > > BUG idr_layer_cache: Poison overwritten
> > > -----------------------------------------------------------------------------
> > > Object ffff8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > Object ffff8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > Object ffff8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > Object ffff8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > Object ffff880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> > > Object ffff880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> >
> > And its an integer sized write of 0. If you look at the struct definition
> > and lookup the offset you should be able to locate the field that
> > was modified.
>
> Here are two more BUGs that seem to point to the same bug:
>
> 1)
> ...
> Nov 21 18:30:30 x4 kernel: [drm] radeon: irq initialized.
> Nov 21 18:30:30 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
> Nov 21 18:30:30 x4 kernel: [drm] Loading RS780 Microcode
> Nov 21 18:30:30 x4 kernel: [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
> Nov 21 18:30:30 x4 kernel: radeon 0000:01:05.0: WB enabled
> Nov 21 18:30:30 x4 kernel: =============================================================================
> Nov 21 18:30:30 x4 kernel: BUG task_xstate: Not a valid slab page
> Nov 21 18:30:30 x4 kernel: -----------------------------------------------------------------------------
> Nov 21 18:30:30 x4 kernel:
> Nov 21 18:30:30 x4 kernel: INFO: Slab 0xffffea0000044300 objects=32767 used=65535 fp=0x (null) flags=0x0401
> Nov 21 18:30:30 x4 kernel: Pid: 9, comm: ksoftirqd/1 Not tainted 3.2.0-rc2-00274-g6fe4c6d-dirty #75
> Nov 21 18:30:30 x4 kernel: Call Trace:
> Nov 21 18:30:30 x4 kernel: [<ffffffff81101c1d>] slab_err+0x7d/0x90
> Nov 21 18:30:30 x4 kernel: [<ffffffff8103e29f>] ? dump_trace+0x16f/0x2e0
> Nov 21 18:30:30 x4 kernel: [<ffffffff81044764>] ? free_thread_xstate+0x24/0x40
> Nov 21 18:30:30 x4 kernel: [<ffffffff81044764>] ? free_thread_xstate+0x24/0x40
> Nov 21 18:30:30 x4 kernel: [<ffffffff81102566>] check_slab+0x96/0xc0
> Nov 21 18:30:30 x4 kernel: [<ffffffff814c5c29>] free_debug_processing+0x34/0x19c
> Nov 21 18:30:30 x4 kernel: [<ffffffff81101d9a>] ? set_track+0x5a/0x190
> Nov 21 18:30:30 x4 kernel: [<ffffffff8110cf2b>] ? sys_open+0x1b/0x20
> Nov 21 18:30:30 x4 kernel: [<ffffffff814c5e55>] __slab_free+0x33/0x2d0
> Nov 21 18:30:30 x4 kernel: [<ffffffff8110cf2b>] ? sys_open+0x1b/0x20
> Nov 21 18:30:30 x4 kernel: [<ffffffff81105134>] kmem_cache_free+0x104/0x120
> Nov 21 18:30:30 x4 kernel: [<ffffffff81044764>] free_thread_xstate+0x24/0x40
> Nov 21 18:30:30 x4 kernel: [<ffffffff81044794>] free_thread_info+0x14/0x30
> Nov 21 18:30:30 x4 kernel: [<ffffffff8106a4ff>] free_task+0x2f/0x50
> Nov 21 18:30:30 x4 kernel: [<ffffffff8106a5d0>] __put_task_struct+0xb0/0x110
> Nov 21 18:30:30 x4 kernel: [<ffffffff8106eb4b>] delayed_put_task_struct+0x3b/0xa0
> Nov 21 18:30:30 x4 kernel: [<ffffffff810aa01a>] __rcu_process_callbacks+0x12a/0x350
> Nov 21 18:30:30 x4 kernel: [<ffffffff810aa2a2>] rcu_process_callbacks+0x62/0x140
> Nov 21 18:30:30 x4 kernel: [<ffffffff81072e18>] __do_softirq+0xa8/0x200
> Nov 21 18:30:30 x4 kernel: [<ffffffff81073077>] run_ksoftirqd+0x107/0x210
> Nov 21 18:30:30 x4 kernel: [<ffffffff81072f70>] ? __do_softirq+0x200/0x200
> Nov 21 18:30:30 x4 kernel: [<ffffffff8108bb87>] kthread+0x87/0x90
> Nov 21 18:30:30 x4 kernel: [<ffffffff814cdcf4>] kernel_thread_helper+0x4/0x10
> Nov 21 18:30:30 x4 kernel: [<ffffffff8108bb00>] ? kthread_flush_work_fn+0x10/0x10
> Nov 21 18:30:30 x4 kernel: [<ffffffff814cdcf0>] ? gs_change+0xb/0xb
> Nov 21 18:30:30 x4 kernel: FIX task_xstate: Object at 0xffffffff8110cf2b not freed
> Nov 21 18:30:30 x4 kernel: [drm] ring test succeeded in 1 usecs
> Nov 21 18:30:30 x4 kernel: [drm] radeon: ib pool ready.
> Nov 21 18:30:30 x4 kernel: [drm] ib test succeeded in 0 usecs
> Nov 21 18:30:30 x4 kernel: [drm] Radeon Display Connectors
> Nov 21 18:30:30 x4 kernel: [drm] Connector 0
>
> 2)
> ...
> Nov 21 17:04:38 x4 kernel: fbcon: radeondrmfb (fb0) is primary device
> Nov 21 17:04:38 x4 kernel: Console: switching to colour frame buffer device 131x105
> Nov 21 17:04:38 x4 kernel: fb0: radeondrmfb frame buffer device
> Nov 21 17:04:38 x4 kernel: drm: registered panic notifier
> Nov 21 17:04:38 x4 kernel: [drm] Initialized radeon 2.11.0 20080528 for 0000:01:05.0 on minor 0
> Nov 21 17:04:38 x4 kernel: loop: module loaded
> Nov 21 17:04:38 x4 kernel: ahci 0000:00:11.0: version 3.0
> Nov 21 17:04:38 x4 kernel: ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> Nov 21 17:04:38 x4 kernel: ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
> Nov 21 17:04:38 x4 kernel: ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
> Nov 21 17:04:38 x4 kernel: scsi0 : ahci
> Nov 21 17:04:38 x4 kernel: scsi1 : ahci
> Nov 21 17:04:38 x4 kernel: =============================================================================
> Nov 21 17:04:38 x4 kernel: BUG task_struct: Poison overwritten
> Nov 21 17:04:38 x4 kernel: -----------------------------------------------------------------------------
> Nov 21 17:04:38 x4 kernel:
> Nov 21 17:04:38 x4 kernel: INFO: 0xffff880215c43800-0xffff880215c43803. First byte 0x0 instead of 0x6b
> Nov 21 17:04:38 x4 kernel: INFO: Allocated in copy_process+0xc4/0xf60 age=168 cpu=1 pid=5
> Nov 21 17:04:38 x4 kernel: __slab_alloc.constprop.70+0x1a4/0x1e0
> Nov 21 17:04:38 x4 kernel: kmem_cache_alloc+0x126/0x160
> Nov 21 17:04:38 x4 kernel: copy_process+0xc4/0xf60
> Nov 21 17:04:38 x4 kernel: do_fork+0x100/0x2b0
> Nov 21 17:04:38 x4 kernel: kernel_thread+0x6c/0x70
> Nov 21 17:04:38 x4 kernel: __call_usermodehelper+0x31/0xa0
> Nov 21 17:04:38 x4 kernel: process_one_work+0x11a/0x430
> Nov 21 17:04:38 x4 kernel: worker_thread+0x126/0x2d0
> Nov 21 17:04:38 x4 kernel: kthread+0x87/0x90
> Nov 21 17:04:38 x4 kernel: kernel_thread_helper+0x4/0x10
> Nov 21 17:04:38 x4 kernel: INFO: Freed in free_task+0x3e/0x50 age=156 cpu=2 pid=13
> Nov 21 17:04:38 x4 kernel: __slab_free+0x33/0x2d0
> Nov 21 17:04:38 x4 kernel: kmem_cache_free+0x104/0x120
> Nov 21 17:04:38 x4 kernel: free_task+0x3e/0x50
> Nov 21 17:04:38 x4 kernel: __put_task_struct+0xb0/0x110
> Nov 21 17:04:38 x4 kernel: delayed_put_task_struct+0x3b/0xa0
> Nov 21 17:04:38 x4 kernel: __rcu_process_callbacks+0x12a/0x350
> Nov 21 17:04:38 x4 kernel: rcu_process_callbacks+0x62/0x140
> Nov 21 17:04:38 x4 kernel: __do_softirq+0xa8/0x200
> Nov 21 17:04:38 x4 kernel: run_ksoftirqd+0x107/0x210
> Nov 21 17:04:38 x4 kernel: kthread+0x87/0x90
> Nov 21 17:04:38 x4 kernel: kernel_thread_helper+0x4/0x10
> Nov 21 17:04:38 x4 kernel: INFO: Slab 0xffffea0008571000 objects=17 used=17 fp=0x (null) flags=0x4000000000004080
> Nov 21 17:04:38 x4 kernel: INFO: Object 0xffff880215c432c0 @offset=12992 fp=0xffff880215c41d00
> Nov 21 17:04:38 x4 kernel:
> Nov 21 17:04:38 x4 kernel: Bytes b4 ffff880215c432b0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
> Nov 21 17:04:38 x4 kernel: Object ffff880215c432c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> ...
> Nov 21 17:04:38 x4 kernel: Object ffff880215c437f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c43890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Nov 21 17:04:38 x4 kernel: Object ffff880215c438a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
> Nov 21 17:04:38 x4 kernel: Redzone ffff880215c438b0: bb bb bb bb bb bb bb bb ........
> Nov 21 17:04:38 x4 kernel: Padding ffff880215c439f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
> Nov 21 17:04:38 x4 kernel: Pid: 5, comm: kworker/u:0 Not tainted 3.2.0-rc2-00274-g6fe4c6d #72
> Nov 21 17:04:38 x4 kernel: Call Trace:
> Nov 21 17:04:38 x4 kernel: [<ffffffff81101ca8>] ? print_section+0x38/0x40
> Nov 21 17:04:38 x4 kernel: [<ffffffff811021a3>] print_trailer+0xe3/0x150
> Nov 21 17:04:38 x4 kernel: [<ffffffff811023a0>] check_bytes_and_report+0xe0/0x100
> Nov 21 17:04:38 x4 kernel: [<ffffffff81103196>] check_object+0x1c6/0x240
> Nov 21 17:04:38 x4 kernel: [<ffffffff8106b034>] ? copy_process+0xc4/0xf60
> Nov 21 17:04:38 x4 kernel: [<ffffffff814c5bb3>] alloc_debug_processing+0x62/0xe4
> Nov 21 17:04:38 x4 kernel: [<ffffffff814c6461>] __slab_alloc.constprop.70+0x1a4/0x1e0
> Nov 21 17:04:38 x4 kernel: [<ffffffff8106b034>] ? copy_process+0xc4/0xf60
> Nov 21 17:04:38 x4 kernel: [<ffffffff814ca12a>] ? schedule+0x3a/0x50
> Nov 21 17:04:38 x4 kernel: [<ffffffff81104d66>] kmem_cache_alloc+0x126/0x160
> Nov 21 17:04:38 x4 kernel: [<ffffffff8106b034>] ? copy_process+0xc4/0xf60
> Nov 21 17:04:38 x4 kernel: [<ffffffff81065f18>] ? enqueue_task_fair+0xf8/0x140
> Nov 21 17:04:38 x4 kernel: [<ffffffff8106b034>] copy_process+0xc4/0xf60
> Nov 21 17:04:38 x4 kernel: [<ffffffff8106c000>] do_fork+0x100/0x2b0
> Nov 21 17:04:38 x4 kernel: [<ffffffff810920fd>] ? sched_clock_local+0x1d/0x90
> Nov 21 17:04:38 x4 kernel: [<ffffffff81044dec>] kernel_thread+0x6c/0x70
> Nov 21 17:04:38 x4 kernel: [<ffffffff81084430>] ? proc_cap_handler+0x180/0x180
> Nov 21 17:04:38 x4 kernel: [<ffffffff814cdd30>] ? gs_change+0xb/0xb
> Nov 21 17:04:38 x4 kernel: [<ffffffff810845a1>] __call_usermodehelper+0x31/0xa0
> Nov 21 17:04:38 x4 kernel: [<ffffffff810869ba>] process_one_work+0x11a/0x430
> Nov 21 17:04:38 x4 kernel: [<ffffffff81084570>] ? call_usermodehelper_freeinfo+0x30/0x30
> Nov 21 17:04:38 x4 kernel: [<ffffffff81087026>] worker_thread+0x126/0x2d0
> Nov 21 17:04:38 x4 kernel: [<ffffffff81086f00>] ? rescuer_thread+0x1f0/0x1f0
> Nov 21 17:04:38 x4 kernel: [<ffffffff8108bb87>] kthread+0x87/0x90
> Nov 21 17:04:38 x4 kernel: [<ffffffff814cdd34>] kernel_thread_helper+0x4/0x10
> Nov 21 17:04:38 x4 kernel: [<ffffffff8108bb00>] ? kthread_flush_work_fn+0x10/0x10
> Nov 21 17:04:38 x4 kernel: [<ffffffff814cdd30>] ? gs_change+0xb/0xb
> Nov 21 17:04:38 x4 kernel: FIX task_struct: Restoring 0xffff880215c43800-0xffff880215c43803=0x6b
> Nov 21 17:04:38 x4 kernel:
> Nov 21 17:04:38 x4 kernel: FIX task_struct: Marking all objects used
>
I really don't think that drm or radeon is guilty. I tried to reproduce
with rc3+ & rc4+ with slub or slab, did more then 20 kexec cycle with
same kernel parameter and no issue.
To confirm that radeon or drm is not to blame can you trigger the issue
by using nomodeset kernel option (your fb rotate option is then
useless). If with nomodeset you can trigger the issue can you then try
to trigger it with KMS enabled and with attached patch (real ugly printk
debuging)
Note that i walked over the drm mode init code and i believe the root
issue is that some code in the kernel do a double idr_remove/destroy
which trigger the idr slub/slab error. It just happen that radeon/drm
is call after the idr double free but is not the one guilty.
Note that i don't understand the idr code much, so my theory can be
completely wrong but attached patch might help to shed some light.
Cheers,
Jerome
[-- Attachment #2: 0001-UGLY-DEBUGING.patch --]
[-- Type: text/plain, Size: 3785 bytes --]
>From 4262819d046dacfb75ad2d639cb61c5b6985e159 Mon Sep 17 00:00:00 2001
From: Jerome Glisse <jglisse@redhat.com>
Date: Fri, 2 Dec 2011 17:50:02 -0500
Subject: [PATCH] UGLY DEBUGING
WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
---
drivers/gpu/drm/drm_crtc.c | 2 ++
drivers/gpu/drm/drm_pci.c | 2 ++
drivers/gpu/drm/drm_platform.c | 2 ++
lib/idr.c | 6 +++++-
mm/slab.c | 2 +-
5 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8323fc3..a1a0a69 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -242,6 +242,7 @@ again:
obj->id = new_id;
obj->type = obj_type;
+DRM_INFO("allocating idr %p %d idr %d\n", obj, obj_type, new_id);
return 0;
}
@@ -259,6 +260,7 @@ static void drm_mode_object_put(struct drm_device *dev,
struct drm_mode_object *object)
{
mutex_lock(&dev->mode_config.idr_mutex);
+DRM_INFO("remove idr %p %d idr %d\n", object, object->type, object->id);
idr_remove(&dev->mode_config.crtc_idr, object->id);
mutex_unlock(&dev->mode_config.idr_mutex);
}
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index d4d10b7..7932ebb 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -345,11 +345,13 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct pci_device_id *ent,
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
pci_set_drvdata(pdev, dev);
+printk(KERN_INFO "%s %d\n", __func__, __LINE__);
ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
if (ret)
goto err_g2;
}
+printk(KERN_INFO "%s %d\n", __func__, __LINE__);
if ((ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY)))
goto err_g3;
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index ae9db5e..3e7e401 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -65,11 +65,13 @@ int drm_get_platform_dev(struct platform_device *platdev,
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
dev_set_drvdata(&platdev->dev, dev);
+printk(KERN_INFO "%s %d\n", __func__, __LINE__);
ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
if (ret)
goto err_g1;
}
+printk(KERN_INFO "%s %d\n", __func__, __LINE__);
ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
if (ret)
goto err_g2;
diff --git a/lib/idr.c b/lib/idr.c
index ed055b2..22c3ec6 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -427,6 +427,7 @@ void idr_remove(struct idr *idp, int id)
* layers that fall into the freelist are those that have been
* preallocated.
*/
+printk(KERN_INFO "%s free idr %p\n", __func__, p);
kmem_cache_free(idr_layer_cache, p);
}
return;
@@ -489,6 +490,7 @@ void idr_destroy(struct idr *idp)
{
while (idp->id_free_cnt) {
struct idr_layer *p = get_from_free_list(idp);
+printk(KERN_INFO "%s free idr %p\n", __func__, p);
kmem_cache_free(idr_layer_cache, p);
}
}
@@ -841,8 +843,10 @@ int ida_get_new_above(struct ida *ida, int starting_id, int *p_id)
*/
if (ida->idr.id_free_cnt || ida->free_bitmap) {
struct idr_layer *p = get_from_free_list(&ida->idr);
- if (p)
+ if (p) {
+printk(KERN_INFO "%s free idr %p\n", __func__, p);
kmem_cache_free(idr_layer_cache, p);
+ }
}
return 0;
diff --git a/mm/slab.c b/mm/slab.c
index 708efe8..83864f9 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1926,7 +1926,7 @@ static void check_poison_obj(struct kmem_cache *cachep, void *objp)
/* Mismatch ! */
/* Print header */
if (lines == 0) {
- printk(KERN_ERR
+ WARN(1,
"Slab corruption: %s start=%p, len=%d\n",
cachep->name, realobj, size);
print_objinfo(cachep, objp, 0);
--
1.7.7.1
^ permalink raw reply related
* Re: [GIT PULL v2] Open vSwitch
From: Jesse Gross @ 2011-12-02 23:00 UTC (permalink / raw)
To: Herbert Xu
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Fischer, Anna,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org, David Miller
In-Reply-To: <20111201075237.GA12799-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Wed, Nov 30, 2011 at 11:52 PM, Herbert Xu
<herbert@gondor.apana.org.au> wrote:
> On Thu, Dec 01, 2011 at 04:24:18PM +0900, Simon Horman wrote:
>>
>> So while I agree that optimizing the hash is a good idea. I don't believe
>> it is a bottle-neck at this point. Though I could be convinced otherwise if
>> long collision chains could be constructed with relatively few flows.
>> Something I had not considered until I rad your email just now.
>
> It's not an optimisation issue, but a security one. If you leave
> a hash like this with a constant seed, an attacker would have an
> infinite amount of time to find collisions.
>
> Rehashing isn't all that difficult.
Yeah, I agree. We'll fix this for the next version of the patch series, thanks.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* RE: [PATCH] e1000e: Fix bug for e1000e interrupt default mode select.
From: Allan, Bruce W @ 2011-12-02 22:43 UTC (permalink / raw)
To: Ben Hutchings, Kumar Gala
Cc: Kirsher, Jeffrey T, Brandeburg, Jesse,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Prabhakar
In-Reply-To: <1322848522.2807.3.camel@bwh-desktop>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Ben Hutchings
>Sent: Friday, December 02, 2011 9:55 AM
>To: Kumar Gala
>Cc: Kirsher, Jeffrey T; Brandeburg, Jesse; e1000-devel@lists.sourceforge.net;
>netdev@vger.kernel.org; Prabhakar
>Subject: Re: [PATCH] e1000e: Fix bug for e1000e interrupt default mode select.
>
>On Fri, 2011-12-02 at 01:11 -0600, Kumar Gala wrote:
>> From: Prabhakar <prabhakar@freescale.com>
>>
>> If the kernel config does not have MSI enabled (CONFIG_PCI_MSI) the driver
>> should not default to MSI interrupt mode but legacy interrupt mode.
>
>It is supposed to automatically fall-back to legacy interrupt mode.
>Does that not work?
It should, and that was my argument (discussed internally) when a similar
patch was previously submitted. Different from the prior patch, this one
also changes the default message generated when the IntMode is specified
for one interface but not all. However, it's not quite right in that only
a small subset of the devices supported by e1000e have support for MSI-X in
the hardware. I have another patch queued up internally here at Intel that
changes the default IntMode based on not only kernel support of MSI/MSI-X
but also on feature support in hardware with additional comments for more
clarification. My patch should be pushed upstream soon.
>
>Also, are there really systems with PCI Express and no MSI support?
>
>Ben.
>
>> Signed-off-by: Jin Qing <b24347@freescale.com>
>> Signed-off-by: Prabhakar <prabhakar@freescale.com>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> drivers/net/ethernet/intel/e1000e/param.c | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/e1000e/param.c
>b/drivers/net/ethernet/intel/e1000e/param.c
>> index 20e93b0..18c35c6 100644
>> --- a/drivers/net/ethernet/intel/e1000e/param.c
>> +++ b/drivers/net/ethernet/intel/e1000e/param.c
>> @@ -388,8 +388,13 @@ void __devinit e1000e_check_options(struct e1000_adapter
>*adapter)
>> static struct e1000_option opt = {
>> .type = range_option,
>> .name = "Interrupt Mode",
>> +#ifdef CONFIG_PCI_MSI
>> .err = "defaulting to 2 (MSI-X)",
>> .def = E1000E_INT_MODE_MSIX,
>> +#else
>> + .err = "defaulting to 0 (Legacy)",
>> + .def = E1000E_INT_MODE_LEGACY,
>> +#endif
>> .arg = { .r = { .min = MIN_INTMODE,
>> .max = MAX_INTMODE } }
>> };
>
>--
>Ben Hutchings, Staff Engineer, Solarflare
>Not speaking for my employer; that's the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] sfc: Use kcalloc instead of kzalloc to allocate array
From: Thomas Meyer @ 2011-12-02 22:36 UTC (permalink / raw)
To: netdev, linux-kernel
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---
diff -u -p a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
--- a/drivers/net/ethernet/sfc/rx.c 2011-11-13 11:07:36.306977044 +0100
+++ b/drivers/net/ethernet/sfc/rx.c 2011-11-28 19:53:10.346917167 +0100
@@ -669,7 +669,7 @@ int efx_probe_rx_queue(struct efx_rx_que
rx_queue->ptr_mask);
/* Allocate RX buffers */
- rx_queue->buffer = kzalloc(entries * sizeof(*rx_queue->buffer),
+ rx_queue->buffer = kcalloc(entries, sizeof(*rx_queue->buffer),
GFP_KERNEL);
if (!rx_queue->buffer)
return -ENOMEM;
diff -u -p a/drivers/net/ethernet/sfc/selftest.c b/drivers/net/ethernet/sfc/selftest.c
--- a/drivers/net/ethernet/sfc/selftest.c 2011-11-13 11:07:36.306977044 +0100
+++ b/drivers/net/ethernet/sfc/selftest.c 2011-11-28 19:53:09.640237232 +0100
@@ -503,8 +503,8 @@ efx_test_loopback(struct efx_tx_queue *t
/* Determine how many packets to send */
state->packet_count = efx->txq_entries / 3;
state->packet_count = min(1 << (i << 2), state->packet_count);
- state->skbs = kzalloc(sizeof(state->skbs[0]) *
- state->packet_count, GFP_KERNEL);
+ state->skbs = kcalloc(state->packet_count,
+ sizeof(state->skbs[0]), GFP_KERNEL);
if (!state->skbs)
return -ENOMEM;
state->flush = false;
diff -u -p a/drivers/net/ethernet/sfc/tx.c b/drivers/net/ethernet/sfc/tx.c
--- a/drivers/net/ethernet/sfc/tx.c 2011-11-13 11:07:36.313643816 +0100
+++ b/drivers/net/ethernet/sfc/tx.c 2011-11-28 19:53:08.056874176 +0100
@@ -468,7 +468,7 @@ int efx_probe_tx_queue(struct efx_tx_que
tx_queue->queue, efx->txq_entries, tx_queue->ptr_mask);
/* Allocate software ring */
- tx_queue->buffer = kzalloc(entries * sizeof(*tx_queue->buffer),
+ tx_queue->buffer = kcalloc(entries, sizeof(*tx_queue->buffer),
GFP_KERNEL);
if (!tx_queue->buffer)
return -ENOMEM;
^ permalink raw reply
* [PATCH] ll_temac: Use kcalloc instead of kzalloc to allocate array
From: Thomas Meyer @ 2011-12-02 22:35 UTC (permalink / raw)
To: grant.likely, rob.herring, netdev, linux-kernel,
devicetree-discuss
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---
diff -u -p a/drivers/net/ethernet/xilinx/ll_temac_main.c b/drivers/net/ethernet/xilinx/ll_temac_main.c
--- a/drivers/net/ethernet/xilinx/ll_temac_main.c 2011-11-28 19:36:47.733440944 +0100
+++ b/drivers/net/ethernet/xilinx/ll_temac_main.c 2011-11-28 19:53:34.187365029 +0100
@@ -237,7 +237,7 @@ static int temac_dma_bd_init(struct net_
struct sk_buff *skb;
int i;
- lp->rx_skb = kzalloc(sizeof(*lp->rx_skb) * RX_BD_NUM, GFP_KERNEL);
+ lp->rx_skb = kcalloc(RX_BD_NUM, sizeof(*lp->rx_skb), GFP_KERNEL);
if (!lp->rx_skb) {
dev_err(&ndev->dev,
"can't allocate memory for DMA RX buffer\n");
^ permalink raw reply
* SYN attack, with FIN flag set
From: Denys Fedoryshchenko @ 2011-12-02 22:29 UTC (permalink / raw)
To: netdev
Hi
Recently i started to get SYN attacks, and managed them.
syncookies didn't helped, here is "perf report" info:
- 26.89% swapper [kernel.kallsyms] [k] _raw_spin_lock
- _raw_spin_lock
- 94.97% tcp_v4_rcv
ip_local_deliver_finish
ip_local_deliver
ip_rcv_finish
ip_rcv
__netif_receive_skb
process_backlog
net_rx_action
__do_softirq
call_softirq
do_softirq
+ irq_exit
But then i got attack that made server to choke and bypassed "--syn"
rule, and i was surprised, that stack are handling invalid combination
of flags, SYN+FIN.
Is it valid behaviour?
in tcp_input.c, tcp_rcv_state_process(), it just does check for rst (to
discard), but maybe packet with fin set should be discarded too?
From http://www.whitehats.ca/main/members/Seeker/seeker_tcp_header/
SYN FIN is probably the best known illegal combination. Remember that
SYN is used to start a connection, while FIN is used to end an existing
connection. It is nonsensical to perform both actions at the same time.
Many scanning tools use SYN FIN packets, because many intrusion
detection systems did not catch these in the past, although most do so
now. You can safely assume that any SYN FIN packets you see are
malicious.
---
System administrator
Denys Fedoryshchenko
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Igor Maravić @ 2011-12-02 21:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, Realtek linux nic maintainers, Francois Romieu,
Tom Herbert
In-Reply-To: <1322845932.2762.38.camel@edumazet-laptop>
>
> Reread what I said : "BQL must be lightweight"
>
> Not : "No lock should be used"
>
> OK ?
>
I'm out of ideas.
Do you think, if I remove netdev_reset_queue(tp->dev); from
rtl8169_init_ring_indexes,
and spin_locks, of course, that would be a good solution.
As far as I could see in marvell/sky2.c, sfc/tx.c and intel/e1000e/netdev.c
netdev_completed is called with out any lock.
Please correct me if I'm wrong.
BR
Igor
^ permalink raw reply
* [PATCH] ipv4: make sure RTO_ONLINK is saved in routing cache
From: Julian Anastasov @ 2011-12-02 21:39 UTC (permalink / raw)
To: netdev
__mkroute_output fails to work with the original tos
and uses value with stripped RTO_ONLINK bit. Make sure we put
the original TOS bits into rt_key_tos because it used to match
cached route.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/route.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 7047069..c546c4c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -111,7 +111,7 @@
#include <net/secure_seq.h>
#define RT_FL_TOS(oldflp4) \
- ((u32)(oldflp4->flowi4_tos & (IPTOS_RT_MASK | RTO_ONLINK)))
+ ((oldflp4)->flowi4_tos & (IPTOS_RT_MASK | RTO_ONLINK))
#define IP_MAX_MTU 0xFFF0
@@ -2435,11 +2435,11 @@ EXPORT_SYMBOL(ip_route_input_common);
static struct rtable *__mkroute_output(const struct fib_result *res,
const struct flowi4 *fl4,
__be32 orig_daddr, __be32 orig_saddr,
- int orig_oif, struct net_device *dev_out,
+ int orig_oif, __u8 orig_rtos,
+ struct net_device *dev_out,
unsigned int flags)
{
struct fib_info *fi = res->fi;
- u32 tos = RT_FL_TOS(fl4);
struct in_device *in_dev;
u16 type = res->type;
struct rtable *rth;
@@ -2490,7 +2490,7 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
rth->rt_genid = rt_genid(dev_net(dev_out));
rth->rt_flags = flags;
rth->rt_type = type;
- rth->rt_key_tos = tos;
+ rth->rt_key_tos = orig_rtos;
rth->rt_dst = fl4->daddr;
rth->rt_src = fl4->saddr;
rth->rt_route_iif = 0;
@@ -2540,7 +2540,7 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
static struct rtable *ip_route_output_slow(struct net *net, struct flowi4 *fl4)
{
struct net_device *dev_out = NULL;
- u32 tos = RT_FL_TOS(fl4);
+ __u8 tos = RT_FL_TOS(fl4);
unsigned int flags = 0;
struct fib_result res;
struct rtable *rth;
@@ -2716,7 +2716,7 @@ static struct rtable *ip_route_output_slow(struct net *net, struct flowi4 *fl4)
make_route:
rth = __mkroute_output(&res, fl4, orig_daddr, orig_saddr, orig_oif,
- dev_out, flags);
+ tos, dev_out, flags);
if (!IS_ERR(rth)) {
unsigned int hash;
--
1.7.3.4
^ permalink raw reply related
* Re: Bug in computing data_len in tcp_sendmsg?
From: David Miller @ 2011-12-02 21:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: subramanian.vijay, therbert, netdev
In-Reply-To: <1322858756.2762.68.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 02 Dec 2011 21:45:56 +0100
> Retransmits could transmits 3 bytes already ACKed, is it a big deal ?
Unfortunately this kind of adjustment doesn't work.
When we trim the head in response to ACK'd data, the stack assumes that
the first byte sitting at the front of the retransmit queue is ->snd_una.
So if you just back align the pull, and don't make amends for the setting
of ->snd_una, we'll retransmit the wrong bytes. The send queue will be
out of sync with the sequence number state of the socket.
This has implications for SACK tagging state bit in the transmit queue
as well.
In fact, this is a real dangerous road to go down, I think :-)
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-12-02 20:48 UTC (permalink / raw)
To: Jerome Glisse
Cc: Christoph Lameter, Alex, Shi, Dave Airlie, Eric Dumazet,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel,
Pekka Enberg, linux-mm@kvack.org, Matt Mackall, tj, Alex Deucher,
Robert Richter
In-Reply-To: <20111202200649.GA1603@x4.trippels.de>
On 2011.12.02 at 21:06 +0100, Markus Trippelsdorf wrote:
> On 2011.12.02 at 14:43 -0500, Jerome Glisse wrote:
> > On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
> > > On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
> > > > On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> > > > > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > > > >
> > > > > > > FIX idr_layer_cache: Marking all objects used
> > > > > >
> > > > > > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > > > > > exactly the same spot again. (CCing the drm list)
> > > > >
> > > > > Well this is looks like write after free.
> > > > >
> > > > > > =============================================================================
> > > > > > BUG idr_layer_cache: Poison overwritten
> > > > > > -----------------------------------------------------------------------------
> > > > > > Object ffff8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > > > Object ffff8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > > > Object ffff8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > > > Object ffff8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > > > Object ffff880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> > > > > > Object ffff880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > >
> > > > > And its an integer sized write of 0. If you look at the struct definition
> > > > > and lookup the offset you should be able to locate the field that
> > > > > was modified.
> > >
> > > It also happens with CONFIG_SLAB.
> > > (If someone wants to reproduce the issue, just run a kexec boot loop and
> > > the bug will occur after a few (~10) iterations.)
> > >
> >
> > Can you provide the kexec command line you are using and full kernel
> > log (mostly interested in kernel option).
>
> /usr/sbin/kexec -l "/usr/src/linux/arch/x86/boot/bzImage" --append="root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet"
> /usr/sbin/kexec -e
>
> (The loop happens after autologin in .zprofile:
> sleep 4 && sudo /etc/minit/ctrlaltdel/run
> (the last script kills, unmounts and then runs the two kexec commands
> above))
BTW I always see (mostly only on screen, sometimes in the logs):
[Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x10400, but the register is already in use for vector 0xf9 on another cpu
[Firmware Bug]: cpu 2, IBS interrupt offset 0 not available (MSRC001103A=0x0000000000000100)
[Firmware Bug]: using offset 1 for IBS interrupts
[Firmware Bug]: workaround enabled for IBS LVT offset
perf: AMD IBS detected (0x0000001f)
But I hope that it is only a harmless warning.
(perf Instruction-Based Sampling)
Robert?
--
Markus
--
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: Bug in computing data_len in tcp_sendmsg?
From: Eric Dumazet @ 2011-12-02 20:48 UTC (permalink / raw)
To: David Miller; +Cc: subramanian.vijay, therbert, netdev
In-Reply-To: <1322858756.2762.68.camel@edumazet-laptop>
Le vendredi 02 décembre 2011 à 21:45 +0100, Eric Dumazet a écrit :
> Le vendredi 02 décembre 2011 à 15:24 -0500, David Miller a écrit :
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Fri, 02 Dec 2011 21:22:49 +0100
> >
> > > Le vendredi 02 décembre 2011 à 13:40 -0500, David Miller a écrit :
> > >
> > >> Yes, for non-SG this always was technically possible.
> > >>
> > >
> > > Yes this can, I reproduced it very easily.
> > >
> > > I find this hard to believe...
> >
> > Grrr :-)
> >
> > Ok, I'll think about this some more.
>
> Maybe a quick fix would be to trim not len bytes but (len & ~3) bytes ?
>
> This avoid reallocations and complex code for a 'should never happen in
> normal circumstances'...
>
> Retransmits could transmits 3 bytes already ACKed, is it a big deal ?
>
> patch on top of linux/net tree :
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 63170e2..4e108c5 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1126,7 +1126,7 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
>
> /* If len == headlen, we avoid __skb_pull to preserve alignment. */
> if (unlikely(len < skb_headlen(skb)))
> - __skb_pull(skb, len);
> + __skb_pull(skb, len & ~3); /* preserve alignement of tcp/ip headers */
> else
> __pskb_trim_head(skb, len - skb_headlen(skb));
>
>
oops, thats the wrong version, here is it again :
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 63170e2..492b917 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1125,11 +1125,12 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
return -ENOMEM;
/* If len == headlen, we avoid __skb_pull to preserve alignment. */
- if (unlikely(len < skb_headlen(skb)))
+ if (unlikely(len < skb_headlen(skb))) {
+ len &= ~3;
__skb_pull(skb, len);
- else
+ } else {
__pskb_trim_head(skb, len - skb_headlen(skb));
-
+ }
TCP_SKB_CB(skb)->seq += len;
skb->ip_summed = CHECKSUM_PARTIAL;
^ permalink raw reply related
* Re: Bug in computing data_len in tcp_sendmsg?
From: Eric Dumazet @ 2011-12-02 20:45 UTC (permalink / raw)
To: David Miller; +Cc: subramanian.vijay, therbert, netdev
In-Reply-To: <20111202.152426.447759025066188323.davem@davemloft.net>
Le vendredi 02 décembre 2011 à 15:24 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 02 Dec 2011 21:22:49 +0100
>
> > Le vendredi 02 décembre 2011 à 13:40 -0500, David Miller a écrit :
> >
> >> Yes, for non-SG this always was technically possible.
> >>
> >
> > Yes this can, I reproduced it very easily.
> >
> > I find this hard to believe...
>
> Grrr :-)
>
> Ok, I'll think about this some more.
Maybe a quick fix would be to trim not len bytes but (len & ~3) bytes ?
This avoid reallocations and complex code for a 'should never happen in
normal circumstances'...
Retransmits could transmits 3 bytes already ACKed, is it a big deal ?
patch on top of linux/net tree :
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 63170e2..4e108c5 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1126,7 +1126,7 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
/* If len == headlen, we avoid __skb_pull to preserve alignment. */
if (unlikely(len < skb_headlen(skb)))
- __skb_pull(skb, len);
+ __skb_pull(skb, len & ~3); /* preserve alignement of tcp/ip headers */
else
__pskb_trim_head(skb, len - skb_headlen(skb));
^ permalink raw reply related
* Re: Bug in computing data_len in tcp_sendmsg?
From: David Miller @ 2011-12-02 20:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: subramanian.vijay, therbert, netdev
In-Reply-To: <1322857369.2762.63.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 02 Dec 2011 21:22:49 +0100
> Le vendredi 02 décembre 2011 à 13:40 -0500, David Miller a écrit :
>
>> Yes, for non-SG this always was technically possible.
>>
>
> Yes this can, I reproduced it very easily.
>
> I find this hard to believe...
Grrr :-)
Ok, I'll think about this some more.
^ permalink raw reply
* Re: Bug in computing data_len in tcp_sendmsg?
From: Eric Dumazet @ 2011-12-02 20:22 UTC (permalink / raw)
To: David Miller; +Cc: subramanian.vijay, therbert, netdev
In-Reply-To: <20111202.134040.638198723589712419.davem@davemloft.net>
Le vendredi 02 décembre 2011 à 13:40 -0500, David Miller a écrit :
> Yes, for non-SG this always was technically possible.
>
Yes this can, I reproduced it very easily.
I find this hard to believe...
[ 2179.697991] ------------[ cut here ]------------
[ 2179.698000] WARNING: at net/ipv4/tcp_output.c:850 tcp_transmit_skb+0x846/0x8f0()
[ 2179.698001] Hardware name: ProLiant BL460c G6
[ 2179.698011] Pid: 0, comm: swapper Tainted: G W 3.2.0-rc2+ #187
[ 2179.698012] Call Trace:
[ 2179.698014] <IRQ> [<ffffffff8104715f>] warn_slowpath_common+0x7f/0xc0
[ 2179.698020] [<ffffffff810471ba>] warn_slowpath_null+0x1a/0x20
[ 2179.698022] [<ffffffff815d8386>] tcp_transmit_skb+0x846/0x8f0
[ 2179.698025] [<ffffffff815d9621>] tcp_retransmit_skb+0x1a1/0x5f0
[ 2179.698027] [<ffffffff815daf5d>] tcp_retransmit_timer+0x1bd/0x640
[ 2179.698030] [<ffffffff815db578>] tcp_write_timer+0x198/0x200
[ 2179.698034] [<ffffffff810579bf>] run_timer_softirq+0x12f/0x3e0
[ 2179.698039] [<ffffffff81295924>] ? timerqueue_add+0x74/0xc0
[ 2179.698041] [<ffffffff815db3e0>] ? tcp_retransmit_timer+0x640/0x640
[ 2179.698045] [<ffffffff810753b5>] ? ktime_get+0x65/0xe0
[ 2179.698047] [<ffffffff8104e929>] __do_softirq+0xa9/0x240
[ 2179.698050] [<ffffffff81075b76>] ? do_timer+0x2b6/0x480
[ 2179.698053] [<ffffffff8106fb90>] ? hrtimer_interrupt+0x130/0x220
[ 2179.698057] [<ffffffff816d526c>] call_softirq+0x1c/0x30
[ 2179.698061] [<ffffffff81004115>] do_softirq+0x55/0x90
[ 2179.698063] [<ffffffff8104edde>] irq_exit+0x9e/0xc0
[ 2179.698066] [<ffffffff816d5a3e>] smp_apic_timer_interrupt+0x6e/0x99
[ 2179.698068] [<ffffffff816d3d8b>] apic_timer_interrupt+0x6b/0x70
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 58f69ac..92ce7c3 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -847,6 +847,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
/* Build TCP header and checksum it. */
th = tcp_hdr(skb);
+ WARN_ON((((unsigned long)th) & 3) != 0);
th->source = inet->inet_sport;
th->dest = inet->inet_dport;
th->seq = htonl(tcb->seq);
^ permalink raw reply related
* Hyvä Webmail Käyttäjä
From: Webmail Ylläpitäjä @ 2011-12-02 20:12 UTC (permalink / raw)
Hyvä Webmail Käyttäjä
Meillä on rajalliset mahdollisuudet tilapäisesti kaikki ominaisuudet
Herkkä kaikille webmailtilit. Voit palauttaa pääsy
Täytyy heti huomioon vastata tähän e-mail With Your
Käyttäjätunnus ja salasana. Käyttäjätunnus: () Password:
().
Koska suuri määrä roskapostia tai roskapostia saat joka päivä,
Päivitä kaikki sähköpostitilit roskapostisuodatin rajoittamaan ei-viestit
Kysyi turvallisuussyistä ja parantaa meidän uusi
Parannettuja ominaisuuksia sähköpostitilin / email jotta
He eivät koe palvelun keskeytystä.
Sinun tulee välittömästi vastata tähän sähköpostiin ja kirjoita nimi
Käyttäjätunnus ja salasana tila, joka antaa meille mahdollisuuden päivittää
Sähköpostitilin kunnolla.Vahvistus linkki lähetetään
Uudelleenkäytöstä aktivointi sähköpostitilisi, saat
vastaus
Kiitos ymmärrystä.
3xepyl Virhe 506: Varoitus Code
kiitos
Webmail ylläpitäjä
Tuki Copyright 2011.
foneettisesti ListenRead
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-12-02 20:06 UTC (permalink / raw)
To: Jerome Glisse
Cc: Christoph Lameter, Alex, Shi, Dave Airlie, Eric Dumazet,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel,
Pekka Enberg, linux-mm@kvack.org, Matt Mackall, tj, Alex Deucher
In-Reply-To: <20111202194309.GA12057@homer.localdomain>
On 2011.12.02 at 14:43 -0500, Jerome Glisse wrote:
> On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
> > On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
> > > On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> > > > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > > >
> > > > > > FIX idr_layer_cache: Marking all objects used
> > > > >
> > > > > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > > > > exactly the same spot again. (CCing the drm list)
> > > >
> > > > Well this is looks like write after free.
> > > >
> > > > > =============================================================================
> > > > > BUG idr_layer_cache: Poison overwritten
> > > > > -----------------------------------------------------------------------------
> > > > > Object ffff8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > > Object ffff8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > > Object ffff8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > > Object ffff8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > > > Object ffff880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> > > > > Object ffff880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > > >
> > > > And its an integer sized write of 0. If you look at the struct definition
> > > > and lookup the offset you should be able to locate the field that
> > > > was modified.
> >
> > It also happens with CONFIG_SLAB.
> > (If someone wants to reproduce the issue, just run a kexec boot loop and
> > the bug will occur after a few (~10) iterations.)
> >
>
> Can you provide the kexec command line you are using and full kernel
> log (mostly interested in kernel option).
/usr/sbin/kexec -l "/usr/src/linux/arch/x86/boot/bzImage" --append="root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet"
/usr/sbin/kexec -e
(The loop happens after autologin in .zprofile:
sleep 4 && sudo /etc/minit/ctrlaltdel/run
(the last script kills, unmounts and then runs the two kexec commands
above))
Linux version 3.2.0-rc4-00089-g621fc1e-dirty (markus@x4.trippels.de) (gcc version 4.6.3 20111202 (prerelease) (GCC) ) #134 SMP PREEMPT Fri Dec 2 11:06:20 CET 2011
Command line: root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet
KERNEL supported cpus:
AMD AuthenticAMD
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000100 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000dfe90000 (usable)
BIOS-e820: 00000000dfe90000 - 00000000dfea8000 (ACPI data)
BIOS-e820: 00000000dfea8000 - 00000000dfed0000 (ACPI NVS)
BIOS-e820: 00000000dfed0000 - 00000000dff00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000220000000 (usable)
NX (Execute Disable) protection: active
DMI present.
DMI: System manufacturer System Product Name/M4A78T-E, BIOS 3406 08/20/2010
e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
last_pfn = 0x220000 max_arch_pfn = 0x400000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
00000-9FFFF write-back
A0000-EFFFF uncachable
F0000-FFFFF write-protect
MTRR variable ranges enabled:
0 base 000000000000 mask FFFF80000000 write-back
1 base 000080000000 mask FFFFC0000000 write-back
2 base 0000C0000000 mask FFFFE0000000 write-back
3 base 0000F0000000 mask FFFFF8000000 write-combining
4 disabled
5 disabled
6 disabled
7 disabled
TOM2: 0000000220000000 aka 8704M
x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
last_pfn = 0xdfe90 max_arch_pfn = 0x400000000
initial memory mapped : 0 - 20000000
Base memory trampoline at [ffff88000009d000] 9d000 size 8192
Using GB pages for direct mapping
init_memory_mapping: 0000000000000000-00000000dfe90000
0000000000 - 00c0000000 page 1G
00c0000000 - 00dfe00000 page 2M
00dfe00000 - 00dfe90000 page 4k
kernel direct mapping tables up to dfe90000 @ 1fffd000-20000000
init_memory_mapping: 0000000100000000-0000000220000000
0100000000 - 0200000000 page 1G
0200000000 - 0220000000 page 2M
kernel direct mapping tables up to 220000000 @ dfe8e000-dfe90000
ACPI: RSDP 00000000000fb880 00024 (v02 ACPIAM)
ACPI: XSDT 00000000dfe90100 0005C (v01 082010 XSDT1403 20100820 MSFT 00000097)
ACPI: FACP 00000000dfe90290 000F4 (v03 082010 FACP1403 20100820 MSFT 00000097)
ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20110623/tbfadt-560)
ACPI: DSDT 00000000dfe90450 0E6FE (v01 A1152 A1152000 00000000 INTL 20060113)
ACPI: FACS 00000000dfea8000 00040
ACPI: APIC 00000000dfe90390 0007C (v01 082010 APIC1403 20100820 MSFT 00000097)
ACPI: MCFG 00000000dfe90410 0003C (v01 082010 OEMMCFG 20100820 MSFT 00000097)
ACPI: OEMB 00000000dfea8040 00072 (v01 082010 OEMB1403 20100820 MSFT 00000097)
ACPI: SRAT 00000000dfe9f450 000E8 (v01 AMD FAM_F_10 00000002 AMD 00000001)
ACPI: HPET 00000000dfe9f540 00038 (v01 082010 OEMHPET 20100820 MSFT 00000097)
ACPI: SSDT 00000000dfe9f580 0088C (v01 A M I POWERNOW 00000001 AMD 00000001)
ACPI: Local APIC address 0xfee00000
[ffffea0000000000-ffffea00087fffff] PMD -> [ffff880217600000-ffff88021f5fffff] on node 0
Zone PFN ranges:
DMA32 0x00000010 -> 0x00100000
Normal 0x00100000 -> 0x00220000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
0: 0x00000010 -> 0x0000009f
0: 0x00000100 -> 0x000dfe90
0: 0x00100000 -> 0x00220000
On node 0 totalpages: 2096671
DMA32 zone: 16384 pages used for memmap
DMA32 zone: 2 pages reserved
DMA32 zone: 900637 pages, LIFO batch:31
Normal zone: 18432 pages used for memmap
Normal zone: 1161216 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled)
ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 4, version 33, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8300 base: 0xfed00000
SMP: Allowing 4 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 40
Allocating PCI resources starting at dff00000 (gap: dff00000:20000000)
setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
PERCPU: Embedded 23 pages/cpu @ffff88021fc00000 s71680 r0 d22528 u524288
pcpu-alloc: s71680 r0 d22528 u524288 alloc=1*2097152
pcpu-alloc: [0] 0 1 2 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2061853
Kernel command line: root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Memory: 8167156k/8912896k available (4549k kernel code, 526212k absent, 219528k reserved, 4000k data, 420k init)
SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
Verbose stalled-CPUs detection is disabled.
NR_IRQS:4352 nr_irqs:712 16
Extended CMOS year: 2000
Console: colour VGA+ 80x25
console [tty0] enabled
hpet clockevent registered
Fast TSC calibration using PIT
Detected 3210.181 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 6420.36 BogoMIPS (lpj=3210181)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
tseg: 0000000000
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 6 MCE banks
using AMD E400 aware idle routine
Freeing SMP alternatives: 12k freed
ACPI: Core revision 20110623
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: AMD Phenom(tm) II X4 955 Processor stepping 02
Performance Events: AMD PMU driver.
... version: 0
... bit width: 48
... generic registers: 4
... value mask: 0000ffffffffffff
... max period: 00007fffffffffff
... fixed-purpose events: 0
... event mask: 000000000000000f
System has AMD C1E enabled
Switch to broadcast mode on CPU0
MCE: In-kernel MCE decoding enabled.
Booting Node 0, Processors #1
smpboot cpu 1: start_ip = 9d000
Switch to broadcast mode on CPU1
#2
smpboot cpu 2: start_ip = 9d000
Switch to broadcast mode on CPU2
#3 Ok.
smpboot cpu 3: start_ip = 9d000
Brought up 4 CPUs
Total of 4 processors activated (25685.44 BogoMIPS).
Switch to broadcast mode on CPU3
devtmpfs: initialized
NET: Registered protocol family 16
node 0 link 0: io port [1000, ffffff]
TOM: 00000000e0000000 aka 3584M
Fam 10h mmconf [e0000000, efffffff]
node 0 link 0: mmio [a0000, bffff]
node 0 link 0: mmio [e0000000, efffffff] ==> none
node 0 link 0: mmio [f0000000, fbcfffff]
node 0 link 0: mmio [fbd00000, fbefffff]
node 0 link 0: mmio [fbf00000, ffefffff]
TOM2: 0000000220000000 aka 8704M
bus: [00, 07] on node 0 link 0
bus: 00 index 0 [io 0x0000-0xffff]
bus: 00 index 1 [mem 0x000a0000-0x000bffff]
bus: 00 index 2 [mem 0xf0000000-0xffffffff]
bus: 00 index 3 [mem 0x220000000-0xfcffffffff]
Extended Config Space enabled on 1 nodes
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
PCI: Using configuration type 1 for extended access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: EC: Look up EC in DSDT
ACPI: Executed 3 blocks of module-level executable AML code
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7]
pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff]
pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff]
pci_root PNP0A03:00: host bridge window [mem 0xdff00000-0xdfffffff]
pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
pci 0000:00:00.0: [1022:9600] type 0 class 0x000600
pci 0000:00:01.0: [1022:9602] type 1 class 0x000604
pci 0000:00:06.0: [1022:9606] type 1 class 0x000604
pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
pci 0000:00:06.0: PME# disabled
pci 0000:00:11.0: [1002:4391] type 0 class 0x000106
pci 0000:00:11.0: reg 10: [io 0xc000-0xc007]
pci 0000:00:11.0: reg 14: [io 0xb000-0xb003]
pci 0000:00:11.0: reg 18: [io 0xa000-0xa007]
pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003]
pci 0000:00:11.0: reg 20: [io 0x8000-0x800f]
pci 0000:00:11.0: reg 24: [mem 0xfbcffc00-0xfbcfffff]
pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03
pci 0000:00:12.0: reg 10: [mem 0xfbcfd000-0xfbcfdfff]
pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03
pci 0000:00:12.1: reg 10: [mem 0xfbcfe000-0xfbcfefff]
pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03
pci 0000:00:12.2: reg 10: [mem 0xfbcff800-0xfbcff8ff]
pci 0000:00:12.2: supports D1 D2
pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
pci 0000:00:12.2: PME# disabled
pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03
pci 0000:00:13.0: reg 10: [mem 0xfbcfb000-0xfbcfbfff]
pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03
pci 0000:00:13.1: reg 10: [mem 0xfbcfc000-0xfbcfcfff]
pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03
pci 0000:00:13.2: reg 10: [mem 0xfbcff400-0xfbcff4ff]
pci 0000:00:13.2: supports D1 D2
pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
pci 0000:00:13.2: PME# disabled
pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05
pci 0000:00:14.1: [1002:439c] type 0 class 0x000101
pci 0000:00:14.1: reg 10: [io 0x0000-0x0007]
pci 0000:00:14.1: reg 14: [io 0x0000-0x0003]
pci 0000:00:14.1: reg 18: [io 0x0000-0x0007]
pci 0000:00:14.1: reg 1c: [io 0x0000-0x0003]
pci 0000:00:14.1: reg 20: [io 0xff00-0xff0f]
pci 0000:00:14.3: [1002:439d] type 0 class 0x000601
pci 0000:00:14.4: [1002:4384] type 1 class 0x000604
pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03
pci 0000:00:14.5: reg 10: [mem 0xfbcfa000-0xfbcfafff]
pci 0000:00:18.0: [1022:1200] type 0 class 0x000600
pci 0000:00:18.1: [1022:1201] type 0 class 0x000600
pci 0000:00:18.2: [1022:1202] type 0 class 0x000600
pci 0000:00:18.3: [1022:1203] type 0 class 0x000600
pci 0000:00:18.4: [1022:1204] type 0 class 0x000600
pci 0000:01:05.0: [1002:9614] type 0 class 0x000300
pci 0000:01:05.0: reg 10: [mem 0xf0000000-0xf7ffffff pref]
pci 0000:01:05.0: reg 14: [io 0xd000-0xd0ff]
pci 0000:01:05.0: reg 18: [mem 0xfbee0000-0xfbeeffff]
pci 0000:01:05.0: reg 24: [mem 0xfbd00000-0xfbdfffff]
pci 0000:01:05.0: supports D1 D2
pci 0000:01:05.1: [1002:960f] type 0 class 0x000403
pci 0000:01:05.1: reg 10: [mem 0xfbefc000-0xfbefffff]
pci 0000:01:05.1: supports D1 D2
pci 0000:00:01.0: PCI bridge to [bus 01-01]
pci 0000:00:01.0: bridge window [io 0xd000-0xdfff]
pci 0000:00:01.0: bridge window [mem 0xfbd00000-0xfbefffff]
pci 0000:00:01.0: bridge window [mem 0xf0000000-0xf7ffffff 64bit pref]
pci 0000:02:00.0: [1969:1026] type 0 class 0x000200
pci 0000:02:00.0: reg 10: [mem 0xfbfc0000-0xfbffffff 64bit]
pci 0000:02:00.0: reg 18: [io 0xec00-0xec7f]
pci 0000:02:00.0: PME# supported from D3hot D3cold
pci 0000:02:00.0: PME# disabled
pci 0000:00:06.0: PCI bridge to [bus 02-02]
pci 0000:00:06.0: bridge window [io 0xe000-0xefff]
pci 0000:00:06.0: bridge window [mem 0xfbf00000-0xfbffffff]
pci 0000:00:14.4: PCI bridge to [bus 03-03] (subtractive decode)
pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (subtractive decode)
pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (subtractive decode)
pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dffff] (subtractive decode)
pci 0000:00:14.4: bridge window [mem 0xdff00000-0xdfffffff] (subtractive decode)
pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfffff] (subtractive decode)
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE6._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
pci0000:00: Unable to request _OSC control (_OSC support mask: 0x19)
ACPI: PCI Interrupt Link [LNKA] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) *0, disabled.
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.24.
PCI: Using ACPI for IRQ routing
PCI: pci_cache_line_size set to 64 bytes
reserve RAM buffer: 000000000009fc00 - 000000000009ffff
reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
hpet0: 4 comparators, 32-bit 14.318180 MHz counter
Switching to clocksource hpet
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp 00:00: [bus 00-ff]
pnp 00:00: [io 0x0cf8-0x0cff]
pnp 00:00: [io 0x0000-0x0cf7 window]
pnp 00:00: [io 0x0d00-0xffff window]
pnp 00:00: [mem 0x000a0000-0x000bffff window]
pnp 00:00: [mem 0x000d0000-0x000dffff window]
pnp 00:00: [mem 0xdff00000-0xdfffffff window]
pnp 00:00: [mem 0xf0000000-0xfebfffff window]
pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled]
pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled]
system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:02: [dma 4]
pnp 00:02: [io 0x0000-0x000f]
pnp 00:02: [io 0x0081-0x0083]
pnp 00:02: [io 0x0087]
pnp 00:02: [io 0x0089-0x008b]
pnp 00:02: [io 0x008f]
pnp 00:02: [io 0x00c0-0x00df]
pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
pnp 00:03: [io 0x0070-0x0071]
pnp 00:03: [irq 8]
pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
pnp 00:04: [io 0x0061]
pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active)
pnp 00:05: [io 0x00f0-0x00ff]
pnp 00:05: [irq 13]
pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active)
pnp 00:06: [mem 0xfed00000-0xfed003ff]
pnp 00:06: Plug and Play ACPI device, IDs PNP0103 (active)
pnp 00:07: [io 0x0060]
pnp 00:07: [io 0x0064]
pnp 00:07: [mem 0xfec00000-0xfec00fff]
pnp 00:07: [mem 0xfee00000-0xfee00fff]
system 00:07: [mem 0xfec00000-0xfec00fff] could not be reserved
system 00:07: [mem 0xfee00000-0xfee00fff] has been reserved
system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:08: [io 0x0010-0x001f]
pnp 00:08: [io 0x0022-0x003f]
pnp 00:08: [io 0x0062-0x0063]
pnp 00:08: [io 0x0065-0x006f]
pnp 00:08: [io 0x0072-0x007f]
pnp 00:08: [io 0x0080]
pnp 00:08: [io 0x0084-0x0086]
pnp 00:08: [io 0x0088]
pnp 00:08: [io 0x008c-0x008e]
pnp 00:08: [io 0x0090-0x009f]
pnp 00:08: [io 0x00a2-0x00bf]
pnp 00:08: [io 0x00b1]
pnp 00:08: [io 0x00e0-0x00ef]
pnp 00:08: [io 0x04d0-0x04d1]
pnp 00:08: [io 0x040b]
pnp 00:08: [io 0x04d6]
pnp 00:08: [io 0x0c00-0x0c01]
pnp 00:08: [io 0x0c14]
pnp 00:08: [io 0x0c50-0x0c51]
pnp 00:08: [io 0x0c52]
pnp 00:08: [io 0x0c6c]
pnp 00:08: [io 0x0c6f]
pnp 00:08: [io 0x0cd0-0x0cd1]
pnp 00:08: [io 0x0cd2-0x0cd3]
pnp 00:08: [io 0x0cd4-0x0cd5]
pnp 00:08: [io 0x0cd6-0x0cd7]
pnp 00:08: [io 0x0cd8-0x0cdf]
pnp 00:08: [io 0x0b00-0x0b3f]
pnp 00:08: [io 0x0800-0x089f]
pnp 00:08: [io 0x0000-0xffffffffffffffff disabled]
pnp 00:08: [io 0x0b00-0x0b0f]
pnp 00:08: [io 0x0b20-0x0b3f]
pnp 00:08: [io 0x0900-0x090f]
pnp 00:08: [io 0x0910-0x091f]
pnp 00:08: [io 0xfe00-0xfefe]
pnp 00:08: [io 0x0060]
pnp 00:08: [io 0x0064]
pnp 00:08: [mem 0xdff00000-0xdfffffff]
pnp 00:08: [mem 0xffb80000-0xffbfffff]
pnp 00:08: [mem 0xfec10000-0xfec1001f]
system 00:08: [io 0x04d0-0x04d1] has been reserved
system 00:08: [io 0x040b] has been reserved
system 00:08: [io 0x04d6] has been reserved
system 00:08: [io 0x0c00-0x0c01] has been reserved
system 00:08: [io 0x0c14] has been reserved
system 00:08: [io 0x0c50-0x0c51] has been reserved
system 00:08: [io 0x0c52] has been reserved
system 00:08: [io 0x0c6c] has been reserved
system 00:08: [io 0x0c6f] has been reserved
system 00:08: [io 0x0cd0-0x0cd1] has been reserved
system 00:08: [io 0x0cd2-0x0cd3] has been reserved
system 00:08: [io 0x0cd4-0x0cd5] has been reserved
system 00:08: [io 0x0cd6-0x0cd7] has been reserved
system 00:08: [io 0x0cd8-0x0cdf] has been reserved
system 00:08: [io 0x0b00-0x0b3f] has been reserved
system 00:08: [io 0x0800-0x089f] has been reserved
system 00:08: [io 0x0b00-0x0b0f] has been reserved
system 00:08: [io 0x0b20-0x0b3f] has been reserved
system 00:08: [io 0x0900-0x090f] has been reserved
system 00:08: [io 0x0910-0x091f] has been reserved
system 00:08: [io 0xfe00-0xfefe] has been reserved
system 00:08: [mem 0xdff00000-0xdfffffff] has been reserved
system 00:08: [mem 0xffb80000-0xffbfffff] has been reserved
system 00:08: [mem 0xfec10000-0xfec1001f] has been reserved
system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:09: [io 0x0000-0xffffffffffffffff disabled]
pnp 00:09: [io 0x0230-0x023f]
pnp 00:09: [io 0x0290-0x029f]
pnp 00:09: [io 0x0f40-0x0f4f]
pnp 00:09: [io 0x0a30-0x0a3f]
system 00:09: [io 0x0230-0x023f] has been reserved
system 00:09: [io 0x0290-0x029f] has been reserved
system 00:09: [io 0x0f40-0x0f4f] has been reserved
system 00:09: [io 0x0a30-0x0a3f] has been reserved
system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:0a: [mem 0xe0000000-0xefffffff]
system 00:0a: [mem 0xe0000000-0xefffffff] has been reserved
system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:0b: [mem 0x00000000-0x0009ffff]
pnp 00:0b: [mem 0x000c0000-0x000cffff]
pnp 00:0b: [mem 0x000e0000-0x000fffff]
pnp 00:0b: [mem 0x00100000-0xdfefffff]
pnp 00:0b: [mem 0xfec00000-0xffffffff]
system 00:0b: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:0b: [mem 0x000c0000-0x000cffff] could not be reserved
system 00:0b: [mem 0x000e0000-0x000fffff] could not be reserved
system 00:0b: [mem 0x00100000-0xdfefffff] could not be reserved
system 00:0b: [mem 0xfec00000-0xffffffff] could not be reserved
system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
PCI: max bus depth: 1 pci_try_num: 2
pci 0000:00:01.0: PCI bridge to [bus 01-01]
pci 0000:00:01.0: bridge window [io 0xd000-0xdfff]
pci 0000:00:01.0: bridge window [mem 0xfbd00000-0xfbefffff]
pci 0000:00:01.0: bridge window [mem 0xf0000000-0xf7ffffff 64bit pref]
pci 0000:00:06.0: PCI bridge to [bus 02-02]
pci 0000:00:06.0: bridge window [io 0xe000-0xefff]
pci 0000:00:06.0: bridge window [mem 0xfbf00000-0xfbffffff]
pci 0000:00:14.4: PCI bridge to [bus 03-03]
pci 0000:00:06.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
pci 0000:00:06.0: setting latency timer to 64
pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7]
pci_bus 0000:00: resource 5 [io 0x0d00-0xffff]
pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff]
pci_bus 0000:00: resource 8 [mem 0xdff00000-0xdfffffff]
pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfebfffff]
pci_bus 0000:01: resource 0 [io 0xd000-0xdfff]
pci_bus 0000:01: resource 1 [mem 0xfbd00000-0xfbefffff]
pci_bus 0000:01: resource 2 [mem 0xf0000000-0xf7ffffff 64bit pref]
pci_bus 0000:02: resource 0 [io 0xe000-0xefff]
pci_bus 0000:02: resource 1 [mem 0xfbf00000-0xfbffffff]
pci_bus 0000:03: resource 4 [io 0x0000-0x0cf7]
pci_bus 0000:03: resource 5 [io 0x0d00-0xffff]
pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000bffff]
pci_bus 0000:03: resource 7 [mem 0x000d0000-0x000dffff]
pci_bus 0000:03: resource 8 [mem 0xdff00000-0xdfffffff]
pci_bus 0000:03: resource 9 [mem 0xf0000000-0xfebfffff]
NET: Registered protocol family 2
IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
UDP hash table entries: 4096 (order: 5, 131072 bytes)
UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
NET: Registered protocol family 1
pci 0000:00:01.0: MSI quirk detected; subordinate MSI disabled
pci 0000:01:05.0: Boot video device
PCI: CLS 64 bytes, default 64
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Placing 64MB software IO TLB between ffff8800dbe8e000 - ffff8800dfe8e000
software IO TLB at phys 0xdbe8e000 - 0xdfe8e000
kvm: Nested Virtualization enabled
kvm: Nested Paging enabled
perf: AMD IBS detected (0x0000001f)
SGI XFS with security attributes, large block/inode numbers, no debug enabled
msgmni has been set to 15951
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
ACPI: Power Button [PWRF]
ACPI: processor limited to max C-state 1
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
radeon 0000:01:05.0: setting latency timer to 64
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE0000
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone kernel: Available graphics memory: 4083584 kiB.
[TTM] Zone dma32: Available graphics memory: 2097152 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
radeon 0000:01:05.0: WB enabled
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] VGA
[drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm] Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm] DVI-D
[drm] HPD3
[drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm] Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF0000000
[drm] size 7299072
[drm] fb depth is 24
[drm] pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 131x105
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.12.0 20080528 for 0000:01:05.0 on minor 0
loop: module loaded
ahci 0000:00:11.0: version 3.0
ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
scsi4 : ahci
scsi5 : ahci
ata1: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffd00 irq 22
ata2: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffd80 irq 22
ata3: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffe00 irq 22
ata4: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffe80 irq 22
ata5: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcfff00 irq 22
ata6: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcfff80 irq 22
pata_atiixp 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
scsi6 : pata_atiixp
scsi7 : pata_atiixp
ata7: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
ata8: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15
ATL1E 0000:02:00.0: BAR 0: set to [mem 0xfbfc0000-0xfbffffff 64bit] (PCI address [0xfbfc0000-0xfbffffff])
ATL1E 0000:02:00.0: BAR 2: set to [io 0xec00-0xec7f] (PCI address [0xec00-0xec7f])
ATL1E 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ATL1E 0000:02:00.0: setting latency timer to 64
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ehci_hcd 0000:00:12.2: EHCI Host Controller
ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
QUIRK: Enable AMD PLL fix
ehci_hcd 0000:00:12.2: applying AMD SB600/SB700 USB freeze workaround
ehci_hcd 0000:00:12.2: debug port 1
ehci_hcd 0000:00:12.2: irq 17, io mem 0xfbcff800
ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
ehci_hcd 0000:00:13.2: EHCI Host Controller
ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
ehci_hcd 0000:00:13.2: applying AMD SB600/SB700 USB freeze workaround
ehci_hcd 0000:00:13.2: debug port 1
ehci_hcd 0000:00:13.2: irq 19, io mem 0xfbcff400
ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ohci_hcd 0000:00:12.0: OHCI Host Controller
ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:12.0: irq 16, io mem 0xfbcfd000
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ohci_hcd 0000:00:12.1: OHCI Host Controller
ohci_hcd 0000:00:12.1: new USB bus registered, assigned bus number 4
ohci_hcd 0000:00:12.1: irq 16, io mem 0xfbcfe000
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 3 ports detected
ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ohci_hcd 0000:00:13.0: OHCI Host Controller
ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5
ohci_hcd 0000:00:13.0: irq 18, io mem 0xfbcfb000
ata7.00: ATAPI: HL-DT-STDVD-RAM GH22NP20, 1.03, max UDMA/66
ata7.00: configured for UDMA/66
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 3 ports detected
ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ohci_hcd 0000:00:13.1: OHCI Host Controller
ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 6
ohci_hcd 0000:00:13.1: irq 18, io mem 0xfbcfc000
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 3 ports detected
ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ohci_hcd 0000:00:14.5: OHCI Host Controller
ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 7
ohci_hcd 0000:00:14.5: irq 18, io mem 0xfbcfa000
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
ata5: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
ata3.00: ATA-8: OCZ-VERTEX, 1.6, max UDMA/133
ata3.00: 62533296 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
ata1.00: ATA-8: ST1500DL003-9VT16L, CC32, max UDMA/133
ata1.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata2: SATA link down (SStatus 0 SControl 300)
ata3.00: configured for UDMA/133
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA ST1500DL003-9VT1 CC32 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 2:0:0:0: Direct-Access ATA OCZ-VERTEX 1.6 PQ: 0 ANSI: 5
sd 2:0:0:0: [sdb] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB)
sd 2:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1 sdb2
sd 2:0:0:0: [sdb] Attached SCSI disk
scsi 6:0:0:0: CD-ROM HL-DT-ST DVD-RAM GH22NP20 1.03 PQ: 0 ANSI: 5
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 2 ports detected
usbcore: registered new interface driver usblp
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
sda: unknown partition table
sd 0:0:0:0: [sda] Attached SCSI disk
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 6:0:0:0: Attached scsi CD-ROM sr0
sr 6:0:0:0: Attached scsi generic sg2 type 5
usb 4-1: new full-speed USB device number 2 using ohci_hcd
Refined TSC clocksource calibration: 3210.826 MHz.
Switching to clocksource tsc
usb 4-2: new full-speed USB device number 3 using ohci_hcd
usb 4-3: new low-speed USB device number 4 using ohci_hcd
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems
i8042: PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
rtc_cmos 00:03: RTC can wake from S4
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
i2c /dev entries driver
EDAC MC: Ver: 2.1.0
AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 0).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 1024MB 1: 1024MB
EDAC amd64: MC: 2: 1024MB 3: 1024MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 1024MB 1: 1024MB
EDAC amd64: MC: 2: 1024MB 3: 1024MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x4 syndromes.
EDAC amd64: MCT channel count: 2
EDAC amd64: CS0: Unbuffered DDR3 RAM
EDAC amd64: CS1: Unbuffered DDR3 RAM
EDAC amd64: CS2: Unbuffered DDR3 RAM
EDAC amd64: CS3: Unbuffered DDR3 RAM
EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 0000:00:18.2
EDAC PCI0: Giving out device to module 'amd64_edac' controller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED)
cpuidle: using governor ladder
cpuidle: using governor menu
input: C-Media USB Headphone Set as /devices/pci0000:00/0000:00:12.1/usb4/4-1/4-1:1.3/input/input2
generic-usb 0003:0D8C:000C.0001: input,hidraw0: USB HID v1.00 Device [C-Media USB Headphone Set ] on usb-0000:00:12.1-1/input3
logitech-djreceiver 0003:046D:C52B.0004: hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:12.1-2/input2
input: Logitech Unifying Device. Wireless PID:101b as /devices/pci0000:00/0000:00:12.1/usb4/4-2/4-2:1.2/0003:046D:C52B.0004/input/input3
logitech-djdevice 0003:046D:C52B.0006: input,hidraw2: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:101b] on usb-0000:00:12.1-2:1
input: HID 046a:0011 as /devices/pci0000:00/0000:00:12.1/usb4/4-3/4-3:1.0/input/input4
generic-usb 0003:046A:0011.0005: input,hidraw3: USB HID v1.10 Keyboard [HID 046a:0011] on usb-0000:00:12.1-3/input0
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver snd-usb-audio
ALSA device list:
#0: C-Media USB Headphone Set at usb-0000:00:12.1-1, full speed
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
ctnetlink v0.93: registering with nfnetlink.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 17
registered taskstats version 1
rtc_cmos 00:03: setting system clock to 2011-12-02 19:50:18 UTC (1322855418)
powernow-k8: Found 1 AMD Phenom(tm) II X4 955 Processor (4 cpu cores) (version 2.20.00)
powernow-k8: 0 : pstate 0 (3200 MHz)
powernow-k8: 1 : pstate 1 (2500 MHz)
powernow-k8: 2 : pstate 2 (2100 MHz)
powernow-k8: 3 : pstate 3 (800 MHz)
XFS (sdb2): Mounting Filesystem
XFS (sdb2): Ending clean mount
VFS: Mounted root (xfs filesystem) readonly on device 8:18.
devtmpfs: mounted
Freeing unused kernel memory: 420k freed
Write protecting the kernel read-only data: 8192k
Freeing unused kernel memory: 1584k freed
Freeing unused kernel memory: 400k freed
XFS (sda): Mounting Filesystem
XFS (sda): Ending clean mount
ATL1E 0000:02:00.0: irq 40 for MSI/MSI-X
ATL1E 0000:02:00.0: eth0: NIC Link is Up <100 Mbps Full Duplex>
ATL1E 0000:02:00.0: eth0: NIC Link is Up <100 Mbps Full Duplex>
udevd[868]: starting version 171
Adding 2097148k swap on /var/tmp/swap/swapfile. Priority:-1 extents:2 across:2634672k
--
Markus
--
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] net/hyperv: Fix the stop/wake queue mechanism
From: Haiyang Zhang @ 2011-12-02 19:56 UTC (permalink / raw)
To: haiyangz, kys, davem, gregkh, linux-kernel, netdev, devel
The ring buffer is only used to pass meta data for outbound packets. The
actual payload is accessed by DMA from the host. So the stop/wake queue
mechanism based on counting and comparing number of pages sent v.s. number
of pages in the ring buffer is wrong. Also, there is a race condition in
the stop/wake queue calls, which can stop xmit queue forever.
The new stop/wake queue mechanism is based on the actual bytes used by
outbound packets in the ring buffer. The check for number of outstanding
sends after stop queue prevents the race condition that can cause wake
queue happening earlier than stop queue.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reported-by: Long Li <longli@microsoft.com>
---
drivers/net/hyperv/netvsc.c | 14 +++++++++++---
drivers/net/hyperv/netvsc_drv.c | 24 +-----------------------
2 files changed, 12 insertions(+), 26 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 4a807e4..b6ac152 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -435,6 +435,9 @@ static void netvsc_send_completion(struct hv_device *device,
nvsc_packet->completion.send.send_completion_ctx);
atomic_dec(&net_device->num_outstanding_sends);
+
+ if (netif_queue_stopped(ndev))
+ netif_wake_queue(ndev);
} else {
netdev_err(ndev, "Unknown send completion packet type- "
"%d received!!\n", nvsp_packet->hdr.msg_type);
@@ -485,11 +488,16 @@ int netvsc_send(struct hv_device *device,
}
- if (ret != 0)
+ if (ret == 0) {
+ atomic_inc(&net_device->num_outstanding_sends);
+ } else if (ret == -EAGAIN) {
+ netif_stop_queue(ndev);
+ if (atomic_read(&net_device->num_outstanding_sends) < 1)
+ netif_wake_queue(ndev);
+ } else {
netdev_err(ndev, "Unable to send packet %p ret %d\n",
packet, ret);
- else
- atomic_inc(&net_device->num_outstanding_sends);
+ }
return ret;
}
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index b69c3a4..7da85eb 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -43,15 +43,10 @@
struct net_device_context {
/* point back to our device context */
struct hv_device *device_ctx;
- atomic_t avail;
struct delayed_work dwork;
};
-#define PACKET_PAGES_LOWATER 8
-/* Need this many pages to handle worst case fragmented packet */
-#define PACKET_PAGES_HIWATER (MAX_SKB_FRAGS + 2)
-
static int ring_size = 128;
module_param(ring_size, int, S_IRUGO);
MODULE_PARM_DESC(ring_size, "Ring buffer size (# of pages)");
@@ -144,18 +139,8 @@ static void netvsc_xmit_completion(void *context)
kfree(packet);
- if (skb) {
- struct net_device *net = skb->dev;
- struct net_device_context *net_device_ctx = netdev_priv(net);
- unsigned int num_pages = skb_shinfo(skb)->nr_frags + 2;
-
+ if (skb)
dev_kfree_skb_any(skb);
-
- atomic_add(num_pages, &net_device_ctx->avail);
- if (atomic_read(&net_device_ctx->avail) >=
- PACKET_PAGES_HIWATER)
- netif_wake_queue(net);
- }
}
static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
@@ -167,8 +152,6 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
/* Add 1 for skb->data and additional one for RNDIS */
num_pages = skb_shinfo(skb)->nr_frags + 1 + 1;
- if (num_pages > atomic_read(&net_device_ctx->avail))
- return NETDEV_TX_BUSY;
/* Allocate a netvsc packet based on # of frags. */
packet = kzalloc(sizeof(struct hv_netvsc_packet) +
@@ -218,10 +201,6 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
if (ret == 0) {
net->stats.tx_bytes += skb->len;
net->stats.tx_packets++;
-
- atomic_sub(num_pages, &net_device_ctx->avail);
- if (atomic_read(&net_device_ctx->avail) < PACKET_PAGES_LOWATER)
- netif_stop_queue(net);
} else {
/* we are shutting down or bus overloaded, just drop packet */
net->stats.tx_dropped++;
@@ -391,7 +370,6 @@ static int netvsc_probe(struct hv_device *dev,
net_device_ctx = netdev_priv(net);
net_device_ctx->device_ctx = dev;
- atomic_set(&net_device_ctx->avail, ring_size);
hv_set_drvdata(dev, net);
INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_send_garp);
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox