* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: J. Bruce Fields @ 2011-11-29 16:42 UTC (permalink / raw)
To: Trond Myklebust
Cc: Peng Tao, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1322584830.4174.16.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
> I mean that I'm perfectly entitled to do
>
> 'modprobe -r blocklayoutdriver'
>
> and when I do that, then I expect blkmapd to close the rpc pipe and wait
> for a new one to be created just like rpc.idmapd and rpc.gssd do when I
> remove the nfs and sunrpc modules.
The rpc pipefs mount doesn't hold a reference on the sunrpc module?
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Eric Dumazet @ 2011-11-29 16:46 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1111281825200.25622@pokey.mtv.corp.google.com>
Le lundi 28 novembre 2011 à 18:32 -0800, Tom Herbert a écrit :
> Changes from last version:
> - Fixed obj leak in netdev_queue_add_kobject (suggested by shemminger)
> - Change dql to use unsigned int (32 bit) values (suggested by eric)
> - Added adj_limit field to dql structure. This computed as
> limit + num_completed. In dql_avail this is used to determine
> availability with one less arithmetic op.
> - Use UINT_MAX for limit constants.
> - Change netdev_sent_queue to not have a number of packets argument,
> one packet is assumed. (suggested by shemminger)
> - Added more detail about locking requirements for dql
> - Moves netdev->state field to written fields part of netdev structure
> - Fixed function prototypes in dql.h.
>
> ----
>
> This patch series implements byte queue limits (bql) for NIC TX queues.
>
> Byte queue limits are a mechanism to limit the size of the transmit
> hardware queue on a NIC by number of bytes. The goal of these byte
> limits is too reduce latency (HOL blocking) caused by excessive queuing
> in hardware (aka buffer bloat) without sacrificing throughput.
>
> Hardware queuing limits are typically specified in terms of a number
> hardware descriptors, each of which has a variable size. The variability
> of the size of individual queued items can have a very wide range. For
> instance with the e1000 NIC the size could range from 64 bytes to 4K
> (with TSO enabled). This variability makes it next to impossible to
> choose a single queue limit that prevents starvation and provides lowest
> possible latency.
>
> The objective of byte queue limits is to set the limit to be the
> minimum needed to prevent starvation between successive transmissions to
> the hardware. The latency between two transmissions can be variable in a
> system. It is dependent on interrupt frequency, NAPI polling latencies,
> scheduling of the queuing discipline, lock contention, etc. Therefore we
> propose that byte queue limits should be dynamic and change in
> accordance with networking stack latencies a system encounters. BQL
> should not need to take the underlying link speed as input, it should
> automatically adjust to whatever the speed is (even if that in itself is
> dynamic).
>
> Patches to implement this:
> - Dynamic queue limits (dql) library. This provides the general
> queuing algorithm.
> - netdev changes that use dlq to support byte queue limits.
> - Support in drivers for byte queue limits.
>
> The effects of BQL are demonstrated in the benchmark results below.
>
> --- High priority versus low priority traffic:
>
> In this test 100 netperf TCP_STREAMs were started to saturate the link.
> A single instance of a netperf TCP_RR was run with high priority set.
> Queuing discipline in pfifo_fast, NIC is e1000 with TX ring size set to
> 1024. tps for the high priority RR is listed.
>
> No BQL, tso on: 3000-3200K bytes in queue: 36 tps
> BQL, tso on: 156-194K bytes in queue, 535 tps
> No BQL, tso off: 453-454K bytes int queue, 234 tps
> BQL, tso off: 66K bytes in queue, 914 tps
>
> --- Various RR sizes
>
> These tests were done running 200 stream of netperf RR tests. The
> results demonstrate the reduction in queuing and also illustrates
> the overhead due to BQL (in small RR sizes).
>
> 140000 rr size
> BQL: 80-215K bytes in queue, 856 tps, 3.26%
> No BQL: 2700-2930K bytes in queue, 854 tps, 3.71% cpu
>
> 14000 rr size
> BQL: 25-55K bytes in queue, 8500 tps
> No BQL: 1500-1622K bytes in queue, 8523 tps, 4.53% cpu
>
> 1400 rr size
> BQL: 20-38K in queue bytes in queue, 86582 tps, 7.38% cpu
> No BQL: 29-117K 85738 tps, 7.67% cpu
>
> 140 rr size
> BQL: 1-10K bytes in queue, 320540 tps, 34.6% cpu
> No BQL: 1-13K bytes in queue, 323158, 37.16% cpu
>
> 1 rr size
> BQL: 0-3K in queue, 338811 tps, 41.41% cpu
> No BQL: 0-3K in queue, 339947 42.36% cpu
>
> So the amount of queuing in the NIC can be reduced up to 90% or more.
> Accordingly, the latency for high priority packets in the prescence
> of low priority bulk throughput traffic can be reduced by 90% or more.
>
> Since BQL accounting is in the transmit path for every packet, and the
> function to recompute the byte limit is run once per transmit
> completion-- there will be some overhead in using BQL. So far, Ive see
> the overhead to be in the range of 1-3% for CPU utilization and maximum
> pps.
I did sucessful tests with tg3 (I'll provide the patch for bnx2 shortly)
Some details probably can be polished, but I believe your v4 is ready
for inclusion.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks !
^ permalink raw reply
* RE: [PATCH v4 0/10] bql: Byte Queue Limits
From: David Laight @ 2011-11-29 17:06 UTC (permalink / raw)
To: Dave Taht, Eric Dumazet; +Cc: John Fastabend, Tom Herbert, davem, netdev
In-Reply-To: <CAA93jw7+KyX=7DC88hKisgaFtzn9vgLsBfUWOGhSHHPadw97Cg@mail.gmail.com>
...
> We spent all that engineering time making TCP go fast and minimized
the
> hardware impact of that - why not spend a little more time - in the
> next generation of hw/sw - making TCP work *better* on the network?
One problem I've seen is that a lot of the 'make TCP go fast'
changes have been focused on bulk transfer over long(ish) latency
links - typical for ftp and http downloads.
Interactive (command+response) works moderately, but async
data requests suffer badly.
Typically these connections will have Nagle disabled (because
you can't stand the repeated timeouts), and may be between
very local systems so the RTT is efectively zero and packet
loss unexpected.
Under these conditions the 'slow start' and 'delayed acks'
conspire against you.
What is more, if you have a high request rate there is little
that can be done to merge tx packets, even the sender is
willing to let some data be queued until (say) the next 1ms
clock tick.
I have seen 30000 packets/sec on a single tcp connection!
(The sender doesn't know there is another message to send.)
The sender was a dual, running 'while :; do :; done'
reduced the packet count considerably!
David
^ permalink raw reply
* ipv4: broadcast sometimes leaves wrong interface (since commit e066008b38ca9ace1b6de8dbbac8ed460640791d)
From: Jeroen van Ingen @ 2011-11-29 16:44 UTC (permalink / raw)
To: netdev
Hi,
We're having an issue on our Linux PPTP servers. After the first PPTP
client is connected, locally generated broadcast packets go out the ppp0
interface while the routing rules should select eth0.
Some details were already mentioned on the linux-kernel list, see eg
http://lkml.indiana.edu/hypermail/linux/kernel/1111.2/00290.html for
reference.
Finally we were able to narrow it down to one specific commit:
e066008b38ca9ace1b6de8dbbac8ed460640791d ("ipv4: Fix __ip_dev_find() to
use ifa_local instead of ifa_address."). With all recent kernels (tested
up to 3.2.0rc3) we observe this issue and it's solved by reverting this
single patch.
This is the first time we've had to debug a kernel issue. Any advice on
how to proceed would be very welcome. If it's not possible to have this
patch reverted in the kernel, hopefully someone can explain how to work
around this behavior.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
^ permalink raw reply
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Trond Myklebust @ 2011-11-29 17:19 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Peng Tao, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111129164252.GA19528-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Tue, 2011-11-29 at 11:42 -0500, J. Bruce Fields wrote:
> On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
> > I mean that I'm perfectly entitled to do
> >
> > 'modprobe -r blocklayoutdriver'
> >
> > and when I do that, then I expect blkmapd to close the rpc pipe and wait
> > for a new one to be created just like rpc.idmapd and rpc.gssd do when I
> > remove the nfs and sunrpc modules.
>
> The rpc pipefs mount doesn't hold a reference on the sunrpc module?
I stand corrected: the mount does hold a reference to the sunrpc
module.
However nothing holds a reference to the blocklayoutdriver module, so
the main point that the "blocklayout" pipe can disappear from underneath
the blkmapd stands.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode
From: Ben Hutchings @ 2011-11-29 17:19 UTC (permalink / raw)
To: Greg Rose
Cc: Roopa Prabhu, netdev@vger.kernel.org, davem@davemloft.net,
chrisw@redhat.com, sri@us.ibm.com, dragos.tatulea@gmail.com,
kvm@vger.kernel.org, arnd@arndb.de, mst@redhat.com,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <1322584544.2684.20.camel@bwh-desktop>
On Tue, 2011-11-29 at 16:35 +0000, Ben Hutchings wrote:
> On Mon, 2011-11-21 at 09:41 -0800, Greg Rose wrote:
> > On 11/18/2011 9:40 AM, Ben Hutchings wrote:
> [...]
> > > What concerns me is that this seems to be a workaround rather than a fix
> > > for over-use of promiscuous mode, and it changes the semantics of
> > > filtering modes in ways that haven't been well-specified.
> >
> > I feel the opposite is true. It allows a known set of receive filters
> > so that you don't have to use promiscuous mode, which cuts down on
> > overhead from processing packets the upper layer stack isn't really
> > interested in.
> >
> > >
> > > What if there's a software bridge between two net devices corresponding
> > > to separate physical ports, so that they really need to be promiscuous?
> > > What if the administrator runs tcpdump and really wants the (PF) net
> > > device to be promiscuous?
> >
> > I don't believe there is anything in this patch set that removes
> > promiscuous mode operation as it is commonly used. Perhaps I've missed
> > something.
> [...]
>
> Maybe I missed something!
>
> Let's be clear on what our models are for filtering. At the moment we
> have MAC filters set through ndo_set_rx_mode and VF filters set through
> ndo_set_vf_{mac,vlan}.
>
> Ignoring anti-spoofing for the moment, should the currently defined
> filters look like this (a):
>
> TX ^ | RX
> | v
> +------------------+---+-----------------+
> | | ++------------+ |
> | | |RX MAC filter| |
> | | ++------------+ |
> | | |match |
> | ^ v |
> | | ++------------+ |
> | | |RX VF filters| |
> | | +-------+-----+ |
> | /|\ no /|\ |
> | | | \ match/ | |match 2 |
> | | ^ \ / v | |
> | | | \ /match| |
> | | \ \/ 1/ | |
> | | \ /\ / | |
> | ^ \/ \/ v |
> | | /\ /\ | |
> | | / || \ | |
> | | / || \ | |
> | | / || \ | |
> | || || || |
> +----------------++-----++-----++--------+
> || || ||
> PF VF 1 VF 2
>
> or like this (b):
>
> TX ^ | RX
> | v
> +------------------+---+-----------------+
> | | ++------------+ |
> | | |RX VF filters| |
> | | ++--------+---+ |
> | | no|match /| |
> | ^ v | | |
> | | +-+----+ | | |
> | | |RX MAC| | | |
> | | |filter| | | |
> | | +------+ | | |
> | | |match | | |
> | /|\ | | | |
> | | | \ | match| |match 2 |
> | | ^ \/ 1 v | |
> | | | /\ | | |
> | | \/ \ / | |
> | | /\ \ / | |
> | ^ / \ \/ v |
> | || \ /\ | |
> | || || \ | |
> | || || \ | |
> | || || \ | |
> | || || || |
> +----------------++-----++-----++--------+
> || || ||
> PF VF 1 VF 2
>
> I think the current model is (a); do you agree?
>
> So is the proposed new model something like this (c):
Corrected diagram:
TX ^ | RX
| v
+------------------+---+-----------------+
| | ++------------+ |
| | |RX MAC filter| |
| ^ ++------------+ |
| | |match |
| no match| v |
| +----------------+ ++------------+ |
| |loopback filters| |RX VF filters| |
| +---------+-----++ +-------+-----+ |
| /|\ /|\ match /|\ |
| v | `-+>+-+-.2 / | | |
| \ \ | |m \ \ / | | |
| match 0\ `-+-+.a \ \ / v | |
| \ | | \t \ X / | |
| \ | \ \c X \ / | |
| \| \ \h \ X | |
| \ \/\1 X \ v |
| || /\ |/ \ \ | |
| |v / || \ \| |
| || / ^| \ | |
| ||/ |v || |
| || || || |
+----------------++-----++-----++--------+
|| || ||
PF VF 1 VF 2
> (I've labelled the new filters as loopback filters here, and I'm still
> leaving out anti-spoofing.)
>
> If not, please explain what the new model *is*.
>
> Ben.
>
--
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.
^ permalink raw reply
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: J. Bruce Fields @ 2011-11-29 17:27 UTC (permalink / raw)
To: Trond Myklebust
Cc: Peng Tao, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1322587165.4174.20.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
On Tue, Nov 29, 2011 at 12:19:25PM -0500, Trond Myklebust wrote:
> On Tue, 2011-11-29 at 11:42 -0500, J. Bruce Fields wrote:
> > On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
> > > I mean that I'm perfectly entitled to do
> > >
> > > 'modprobe -r blocklayoutdriver'
> > >
> > > and when I do that, then I expect blkmapd to close the rpc pipe and wait
> > > for a new one to be created just like rpc.idmapd and rpc.gssd do when I
> > > remove the nfs and sunrpc modules.
> >
> > The rpc pipefs mount doesn't hold a reference on the sunrpc module?
>
> I stand corrected: the mount does hold a reference to the sunrpc
> module.
> However nothing holds a reference to the blocklayoutdriver module, so
> the main point that the "blocklayout" pipe can disappear from underneath
> the blkmapd stands.
OK, that makes sense.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 02/10] net: Add queue state xoff flag for stack
From: David Miller @ 2011-11-29 17:27 UTC (permalink / raw)
To: jhs, hadi; +Cc: therbert, netdev
In-Reply-To: <1322572371.2090.1.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Tue, 29 Nov 2011 08:12:51 -0500
> On Mon, 2011-11-28 at 18:32 -0800, Tom Herbert wrote:
>>
>> enum netdev_queue_state_t {
>> - __QUEUE_STATE_XOFF,
>> + __QUEUE_STATE_DRV_XOFF,
>> + __QUEUE_STATE_STACK_XOFF,
>> __QUEUE_STATE_FROZEN,
>
> QUEUE_STATE_DRV_XOFF seems to be a rename of __QUEUE_STATE_XOFF
> no issues there.
> Is inserting __QUEUE_STATE_STACK_XOFF going to cause any issues?
> Typically, you should insert new things at the end.
I doubt the ordering matters here, and any such dependency is a bug.
:-)
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Rick Jones @ 2011-11-29 17:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dave Taht, Tom Herbert, davem, netdev
In-Reply-To: <1322550138.2970.70.camel@edumazet-laptop>
On 11/28/2011 11:02 PM, Eric Dumazet wrote:
> Le mardi 29 novembre 2011 à 05:23 +0100, Dave Taht a écrit :
>>> In this test 100 netperf TCP_STREAMs were started to saturate the link.
>>> A single instance of a netperf TCP_RR was run with high priority set.
>>> Queuing discipline in pfifo_fast, NIC is e1000 with TX ring size set to
>>> 1024. tps for the high priority RR is listed.
>>>
>>> No BQL, tso on: 3000-3200K bytes in queue: 36 tps
>>> BQL, tso on: 156-194K bytes in queue, 535 tps
>>
>>> No BQL, tso off: 453-454K bytes int queue, 234 tps
>>> BQL, tso off: 66K bytes in queue, 914 tps
>>
>>
>> Jeeze. Under what circumstances is tso a win? I've always
>> had great trouble with it, as some e1000 cards do it rather badly.
It is a win when one is sending bulk(ish) data and wish to avoid the
trips up and down the protocol stack to save CPU cycles.
TSO is sometimes called "poor man's Jumbo Frames" as it seeks to
achieve the same goal - fewer trips down the protocol stack per KB of
data transferred.
>> I assume these are while running at GigE speeds?
>>
>> What of 100Mbit? 10GigE? (I will duplicate your tests
>> at 100Mbit, but as for 10gigE...)
>>
>
> TSO on means a low priority 65Kbytes packet can be in TX ring right
> before the high priority packet. If you cant afford the delay, you lose.
>
> There is no mystery here.
>
> If you want low latencies :
> - TSO must be disabled so that packets are at most one ethernet frame.
> - You adjust BQL limit to small value
> - You even can lower MTU to get even more better latencies.
>
> If you want good throughput from your [10]GigE and low cpu cost, TSO
> should be enabled.
Outbound throughput. If you want good inbound throughput you want GRO/LRO.
> If you want to be smart, you could have a dynamic behavior :
>
> Let TSO on as long as no high priority low latency producer is running
> (if low latency packets are locally generated)
I'd probably leave that to the administrator rather than try to clutter
things with additional logic.
*If* I were to add additional logic, I might have an interface
communicate its "maximum TSO size" up the stack in a manner to too
dissimilar from MTU. That way one can control just how much time a
TSO'd segment would consume.
rick jones
^ permalink raw reply
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Peng Tao @ 2011-11-29 17:30 UTC (permalink / raw)
To: Trond Myklebust
Cc: J. Bruce Fields, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1322587165.4174.20.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
On Wed, Nov 30, 2011 at 1:19 AM, Trond Myklebust
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, 2011-11-29 at 11:42 -0500, J. Bruce Fields wrote:
>> On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
>> > I mean that I'm perfectly entitled to do
>> >
>> > 'modprobe -r blocklayoutdriver'
>> >
>> > and when I do that, then I expect blkmapd to close the rpc pipe and wait
>> > for a new one to be created just like rpc.idmapd and rpc.gssd do when I
>> > remove the nfs and sunrpc modules.
>>
>> The rpc pipefs mount doesn't hold a reference on the sunrpc module?
>
> I stand corrected: the mount does hold a reference to the sunrpc
> module.
> However nothing holds a reference to the blocklayoutdriver module, so
> the main point that the "blocklayout" pipe can disappear from underneath
> the blkmapd stands.
Thanks for the explanation and I agree it can cause problem if user
reload blocklayout module. I will look into a fix to blkmapd.
Best,
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: David Miller @ 2011-11-29 17:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, netdev
In-Reply-To: <1322585184.2465.36.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 17:46:24 +0100
> I did sucessful tests with tg3 (I'll provide the patch for bnx2 shortly)
>
> Some details probably can be polished, but I believe your v4 is ready
> for inclusion.
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Agreed, all applied to net-next, thanks!
Tom, please keep an eye out for regression or suggestion reports.
Thanks again.
^ permalink raw reply
* Re: [RFC] sky2: add bql support
From: David Miller @ 2011-11-29 17:47 UTC (permalink / raw)
To: shemminger; +Cc: therbert, netdev
In-Reply-To: <20111128201907.6d31d4c3@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 28 Nov 2011 20:19:07 -0800
> Just for testing, here is how to add BQL support to sky2
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Let me know when you have a final version of this, thanks.
^ permalink raw reply
* Re: [patch] net/netlabel: copy and paste bug in netlbl_cfg_unlbl_map_add()
From: Paul Moore @ 2011-11-29 17:47 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, netdev, kernel-janitors
In-Reply-To: <20111124071820.GB14122@elgon.mountain>
On Thursday, November 24, 2011 10:18:20 AM Dan Carpenter wrote:
> This was copy and pasted from the IPv4 code. We're calling the
> ip4 version of that function and map4 is NULL.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index 8ed67dcc..3735297 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -162,8 +162,8 @@ int netlbl_cfg_unlbl_map_add(const char *domain,
> map6->list.addr.s6_addr32[3] &= mask6->s6_addr32[3];
> map6->list.mask = *mask6;
> map6->list.valid = 1;
> - ret_val = netlbl_af4list_add(&map4->list,
> - &addrmap->list4);
> + ret_val = netlbl_af6list_add(&map6->list,
> + &addrmap->list6);
> if (ret_val != 0)
> goto cfg_unlbl_map_add_failure;
> break;
Thanks for fixing this. I actually stumbled across this just last week while
working on the CALIPSO stuff and queued up a patch but didn't get a chance to
verify it before Thanksgiving - you just saved me the effort :)
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: RCU'ed dst_get_neighbour()
From: Eric Dumazet @ 2011-11-29 18:01 UTC (permalink / raw)
To: Marc Aurele La France; +Cc: netdev
In-Reply-To: <alpine.WNT.2.00.1111291027320.1036@TSI>
Le mardi 29 novembre 2011 à 10:44 -0700, Marc Aurele La France a écrit :
> Hi.
>
> Commit (1) seems to imply that all dst_get_neighbour() references now need
> to be wrapped with rcu_read_lock()/rcu_read_unlock() sequences. See (2)
> for one such proposed change.
>
> In the case I have here (ipoib), this commit results in ...
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> include/net/dst.h:91 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 1
> 4 locks held by kworker/3:1/630:
> #0: (ib_cm){.+.+.+}, at: [<ffffffff81055735>]
> process_one_work+0x1ab/0x4f9
> #1: ((&(&work->work)->work)){+.+.+.}, at: [<ffffffff81055735>]
> process_one_work+0x1ab/0x4f9
> #2: (rcu_read_lock_bh){.+....}, at: [<ffffffff81388216>]
> dev_queue_xmit+0x0/0x5ae
> #3: (_xmit_INFINIBAND){+.-...}, at: [<ffffffff8139eecc>]
> sch_direct_xmit+0x4d/0x22b
>
> stack backtrace:
> Pid: 630, comm: kworker/3:1 Not tainted 3.1.3-smp #1
> Call Trace:
> [<ffffffff8106c385>] lockdep_rcu_dereference+0x9b/0xa4
> [<ffffffff81351cda>] ipoib_start_xmit+0xf4/0x36f
> [<ffffffff81384215>] dev_hard_start_xmit+0x2a7/0x54f
> [<ffffffff8139eeef>] sch_direct_xmit+0x70/0x22b
> [<ffffffff8138851f>] dev_queue_xmit+0x309/0x5ae
> [<ffffffff81388216>] ? napi_gro_receive+0xb3/0xb3
> [<ffffffff813582d3>] ipoib_cm_rep_handler+0x208/0x248
> [<ffffffff81433e16>] ? _raw_spin_unlock_irqrestore+0x3d/0x5b
> [<ffffffff8135a912>] ipoib_cm_tx_handler+0x95/0x27f
> [<ffffffff8106d183>] ? __trace_hardirqs_on_caller+0x41/0x65
> [<ffffffff81327b29>] cm_process_work+0x26/0xbc
> [<ffffffff81328d74>] cm_rep_handler+0x274/0x2ae
> [<ffffffff81329582>] cm_work_handler+0x41/0x91
> [<ffffffff8105582c>] process_one_work+0x2a2/0x4f9
> [<ffffffff81055735>] ? process_one_work+0x1ab/0x4f9
> [<ffffffff810580c6>] ? worker_thread+0x4a/0x1ca
> [<ffffffff81329541>] ? cm_req_handler+0x355/0x355
> [<ffffffff81058175>] worker_thread+0xf9/0x1ca
> [<ffffffff8105807c>] ? gcwq_mayday_timeout+0x77/0x77
> [<ffffffff8105bfa3>] kthread+0x86/0x8e
> [<ffffffff81436b34>] kernel_thread_helper+0x4/0x10
> [<ffffffff8143425d>] ? retint_restore_args+0xe/0xe
> [<ffffffff8105bf1d>] ? kthread_stop+0x1cd/0x1cd
> [<ffffffff81436b30>] ? gs_change+0xb/0xb
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> include/net/dst.h:91 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 1
> 2 locks held by kworker/u:2/748:
> #0: ((name)){.+.+.+}, at: [<ffffffff81055735>]
> process_one_work+0x1ab/0x4f9
> #1: ((&port_priv->work)){+.+.+.}, at: [<ffffffff81055735>]
> process_one_work+0x1ab/0x4f9
>
> stack backtrace:
> Pid: 748, comm: kworker/u:2 Not tainted 3.1.3-smp #1
> Call Trace:
> [<ffffffff8106c385>] lockdep_rcu_dereference+0x9b/0xa4
> [<ffffffff81354e68>] ipoib_mcast_join_finish+0x362/0x48a
> [<ffffffff81355481>] ipoib_mcast_sendonly_join_complete+0x3b/0x174
> [<ffffffff813246b3>] mcast_work_handler+0xba/0x182
> [<ffffffff813248aa>] join_handler+0xe6/0xee
> [<ffffffff81322af1>] ib_sa_mcmember_rec_callback+0x51/0x5c
> [<ffffffff8132289c>] recv_handler+0x44/0x50
> [<ffffffff8131efca>] ib_mad_complete_recv+0xc3/0x125
> [<ffffffff8131debe>] ? find_mad_agent+0x13a/0x149
> [<ffffffff8131f30a>] ib_mad_recv_done_handler+0x2de/0x326
> [<ffffffff8131f3b0>] ib_mad_completion_handler+0x5e/0x91
> [<ffffffff8105582c>] process_one_work+0x2a2/0x4f9
> [<ffffffff81055735>] ? process_one_work+0x1ab/0x4f9
> [<ffffffff810580c6>] ? worker_thread+0x4a/0x1ca
> [<ffffffff8131f352>] ? ib_mad_recv_done_handler+0x326/0x326
> [<ffffffff81058175>] worker_thread+0xf9/0x1ca
> [<ffffffff8105807c>] ? gcwq_mayday_timeout+0x77/0x77
> [<ffffffff8105bfa3>] kthread+0x86/0x8e
> [<ffffffff81436b34>] kernel_thread_helper+0x4/0x10
> [<ffffffff8143425d>] ? retint_restore_args+0xe/0xe
> [<ffffffff8105bf1d>] ? kthread_stop+0x1cd/0x1cd
> [<ffffffff81436b30>] ? gs_change+0xb/0xb
>
> Comments/flames?
>
> Thanks.
>
> Marc.
>
> PS: Please reply-to-all as I am not subscribed to netdev.
>
> (1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f2c31e32b378a6653f8de606149d963baf11d7d3
> (2) http://www.spinics.net/lists/netdev/msg179639.html
>
> +----------------------------------+----------------------------------+
> | Marc Aurele La France | work: 1-780-492-9310 |
> | Academic Information and | fax: 1-780-492-1729 |
> | Communications Technologies | email: tsi@ualberta.ca |
> | 352 General Services Building +----------------------------------+
> | University of Alberta | |
> | Edmonton, Alberta | Standard disclaimers apply |
> | T6G 2H1 | |
> | CANADA | |
> +----------------------------------+----------------------------------+
Thanks for the report Marc, I'll take a look asap.
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Konrad Rzeszutek Wilk @ 2011-11-29 18:04 UTC (permalink / raw)
To: Rafael J. Wysocki, tglx, mingo, hpa, x86, borislav.petkov
Cc: Linux SCSI List, Florian Mickler, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI, Linux ACPI,
Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
In-Reply-To: <20111122135412.GA29905@phenom.dumpdata.com>
On Tue, Nov 22, 2011 at 08:54:12AM -0500, Konrad Rzeszutek Wilk wrote:
> > Subject : Regression in 3.1 causes Xen to use wrong idle routine
> > Submitter : Stefan Bader <stefan.bader@canonical.com>
> > Date : 2011-10-26 10:24
> > Message-ID : 4EA7DFD1.9060608@canonical.com
> > References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
>
> The patch mentioned in http://mid.gmane.org/20111115144004.GE22675@phenom.dumpdata.com
> should do it. But the patch needs an Ack from ACPI/x86 folks.
This patch (mentioned in the URL above) fixes the issue. Could it be
applied to the x86 tree for 3.2 or get an Ack, please?
>From 4f10ec7a7b9ff24657696aa98f25bcecde247373 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 21 Nov 2011 18:02:02 -0500
Subject: [PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.
This patch:
commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown <len.brown@intel.com>
Date: Fri Apr 1 18:28:35 2011 -0400
cpuidle: replace xen access to x86 pm_idle and default_idle
..scribble on pm_idle and access default_idle,
have it simply disable_cpuidle() so acpi_idle will not load and
architecture default HLT will be used.
idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
and acpi_idle_call to not set pm_idle (which is excellent). But the
amd_e400_idle and mwait_idle can still setup pm_idle which we really
do not want. In case of mwait_idle we can hit some instances where:
Brought up 2 CPUs
invalid opcode: 0000 [#1] SMP
CPU 1
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
RIP: e030:[<ffffffff81015d1d>] [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
RSP: e02b:ffff8801d28ddf10 EFLAGS: 00010082
RAX: ffff8801d28dc010 RBX: ffff8801d28ddfd8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
RBP: ffff8801d28ddf10 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000001 R11: ffff8801d28ddfd8 R12: ffffffff81b590d0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8801dff81000(0000) knlGS:0000000000000000
CS: e033 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000
Process swapper (pid: 0, threadinfo ffff8801d28dc000, task ffff8801d28cae60)
Stack:
ffff8801d28ddf40 ffffffff8100e2ed ffff8801dff8e390 c136dfe72feab515
0000000000000000 0000000000000000 ffff8801d28ddf50 ffffffff8149ee78
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
[<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
RIP [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
RSP <ffff8801d28ddf10>
RH BZ #739499 and Ubuntu #881076
In case of amd_e400_idle we don't get so spectacular crashes, but
we do end up making an MSR which is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.
Lets make pm_idle be default_idle to take care of that.
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/x86/include/asm/system.h | 1 +
arch/x86/kernel/process.c | 8 ++++++++
arch/x86/xen/setup.c | 2 +-
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2d2f01c 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
void default_idle(void);
+bool set_pm_idle_to_default(void);
void stop_this_cpu(void *dummy);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1f7f8c8..336b299 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -404,6 +404,14 @@ void default_idle(void)
EXPORT_SYMBOL(default_idle);
#endif
+bool set_pm_idle_to_default()
+{
+ if (!pm_idle) {
+ pm_idle = default_idle;
+ return true;
+ }
+ return false;
+}
void stop_this_cpu(void *dummy)
{
local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..7506181 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
#endif
disable_cpuidle();
boot_option_idle_override = IDLE_HALT;
-
+ WARN_ON(!set_pm_idle_to_default());
fiddle_vdso();
}
--
1.7.7.3
^ permalink raw reply related
* RE: [PATCH] staging: hv: move hv_netvsc out of staging area
From: Haiyang Zhang @ 2011-11-29 18:05 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, NetDev
In-Reply-To: <20111129151638.GB24688@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Tuesday, November 29, 2011 10:17 AM
> To: Haiyang Zhang
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; NetDev
> Subject: Re: [PATCH] staging: hv: move hv_netvsc out of staging area
> > I have rebased the previous patch on the latest staging-next branch,
> > and re-submitting it now. In another email, the same patch was
> > submitted without using the "-M" flag, in case anyone wants to read
> > the unchanged code in the patch body.
>
> This one was fine, now applied, thanks.
Thank you!
- Haiyang
^ permalink raw reply
* RCU'ed dst_get_neighbour()
From: Marc Aurele La France @ 2011-11-29 17:44 UTC (permalink / raw)
To: netdev, eric.dumazet
Hi.
Commit (1) seems to imply that all dst_get_neighbour() references now need
to be wrapped with rcu_read_lock()/rcu_read_unlock() sequences. See (2)
for one such proposed change.
In the case I have here (ipoib), this commit results in ...
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/net/dst.h:91 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
4 locks held by kworker/3:1/630:
#0: (ib_cm){.+.+.+}, at: [<ffffffff81055735>]
process_one_work+0x1ab/0x4f9
#1: ((&(&work->work)->work)){+.+.+.}, at: [<ffffffff81055735>]
process_one_work+0x1ab/0x4f9
#2: (rcu_read_lock_bh){.+....}, at: [<ffffffff81388216>]
dev_queue_xmit+0x0/0x5ae
#3: (_xmit_INFINIBAND){+.-...}, at: [<ffffffff8139eecc>]
sch_direct_xmit+0x4d/0x22b
stack backtrace:
Pid: 630, comm: kworker/3:1 Not tainted 3.1.3-smp #1
Call Trace:
[<ffffffff8106c385>] lockdep_rcu_dereference+0x9b/0xa4
[<ffffffff81351cda>] ipoib_start_xmit+0xf4/0x36f
[<ffffffff81384215>] dev_hard_start_xmit+0x2a7/0x54f
[<ffffffff8139eeef>] sch_direct_xmit+0x70/0x22b
[<ffffffff8138851f>] dev_queue_xmit+0x309/0x5ae
[<ffffffff81388216>] ? napi_gro_receive+0xb3/0xb3
[<ffffffff813582d3>] ipoib_cm_rep_handler+0x208/0x248
[<ffffffff81433e16>] ? _raw_spin_unlock_irqrestore+0x3d/0x5b
[<ffffffff8135a912>] ipoib_cm_tx_handler+0x95/0x27f
[<ffffffff8106d183>] ? __trace_hardirqs_on_caller+0x41/0x65
[<ffffffff81327b29>] cm_process_work+0x26/0xbc
[<ffffffff81328d74>] cm_rep_handler+0x274/0x2ae
[<ffffffff81329582>] cm_work_handler+0x41/0x91
[<ffffffff8105582c>] process_one_work+0x2a2/0x4f9
[<ffffffff81055735>] ? process_one_work+0x1ab/0x4f9
[<ffffffff810580c6>] ? worker_thread+0x4a/0x1ca
[<ffffffff81329541>] ? cm_req_handler+0x355/0x355
[<ffffffff81058175>] worker_thread+0xf9/0x1ca
[<ffffffff8105807c>] ? gcwq_mayday_timeout+0x77/0x77
[<ffffffff8105bfa3>] kthread+0x86/0x8e
[<ffffffff81436b34>] kernel_thread_helper+0x4/0x10
[<ffffffff8143425d>] ? retint_restore_args+0xe/0xe
[<ffffffff8105bf1d>] ? kthread_stop+0x1cd/0x1cd
[<ffffffff81436b30>] ? gs_change+0xb/0xb
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/net/dst.h:91 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
2 locks held by kworker/u:2/748:
#0: ((name)){.+.+.+}, at: [<ffffffff81055735>]
process_one_work+0x1ab/0x4f9
#1: ((&port_priv->work)){+.+.+.}, at: [<ffffffff81055735>]
process_one_work+0x1ab/0x4f9
stack backtrace:
Pid: 748, comm: kworker/u:2 Not tainted 3.1.3-smp #1
Call Trace:
[<ffffffff8106c385>] lockdep_rcu_dereference+0x9b/0xa4
[<ffffffff81354e68>] ipoib_mcast_join_finish+0x362/0x48a
[<ffffffff81355481>] ipoib_mcast_sendonly_join_complete+0x3b/0x174
[<ffffffff813246b3>] mcast_work_handler+0xba/0x182
[<ffffffff813248aa>] join_handler+0xe6/0xee
[<ffffffff81322af1>] ib_sa_mcmember_rec_callback+0x51/0x5c
[<ffffffff8132289c>] recv_handler+0x44/0x50
[<ffffffff8131efca>] ib_mad_complete_recv+0xc3/0x125
[<ffffffff8131debe>] ? find_mad_agent+0x13a/0x149
[<ffffffff8131f30a>] ib_mad_recv_done_handler+0x2de/0x326
[<ffffffff8131f3b0>] ib_mad_completion_handler+0x5e/0x91
[<ffffffff8105582c>] process_one_work+0x2a2/0x4f9
[<ffffffff81055735>] ? process_one_work+0x1ab/0x4f9
[<ffffffff810580c6>] ? worker_thread+0x4a/0x1ca
[<ffffffff8131f352>] ? ib_mad_recv_done_handler+0x326/0x326
[<ffffffff81058175>] worker_thread+0xf9/0x1ca
[<ffffffff8105807c>] ? gcwq_mayday_timeout+0x77/0x77
[<ffffffff8105bfa3>] kthread+0x86/0x8e
[<ffffffff81436b34>] kernel_thread_helper+0x4/0x10
[<ffffffff8143425d>] ? retint_restore_args+0xe/0xe
[<ffffffff8105bf1d>] ? kthread_stop+0x1cd/0x1cd
[<ffffffff81436b30>] ? gs_change+0xb/0xb
Comments/flames?
Thanks.
Marc.
PS: Please reply-to-all as I am not subscribed to netdev.
(1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f2c31e32b378a6653f8de606149d963baf11d7d3
(2) http://www.spinics.net/lists/netdev/msg179639.html
+----------------------------------+----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and | fax: 1-780-492-1729 |
| Communications Technologies | email: tsi@ualberta.ca |
| 352 General Services Building +----------------------------------+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply |
| T6G 2H1 | |
| CANADA | |
+----------------------------------+----------------------------------+
^ permalink raw reply
* Re: [PATCH net-next] flow_dissector: use a 64bit load/store
From: David Miller @ 2011-11-29 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322548235.2970.57.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 07:30:35 +0100
> [PATCH net-next] flow_dissector: use a 64bit load/store
>
> gcc compiler is smart enough to use a single load/store if we
> memcpy(dptr, sptr, 8) on x86_64, regardless of
> CONFIG_CC_OPTIMIZE_FOR_SIZE
>
> In IP header, daddr immediately follows saddr, this wont change in the
> future. We only need to make sure our flow_keys (src,dst) fields wont
> break the rule.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid frag allocation for small frames
From: David Miller @ 2011-11-29 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, subramanian.vijay
In-Reply-To: <1322556107.2970.82.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 09:41:47 +0100
> tcp_sendmsg() uses select_size() helper to choose skb head size when a
> new skb must be allocated.
>
> If GSO is enabled for the socket, current strategy is to force all
> payload data to be outside of headroom, in PAGE fragments.
>
> This strategy is not welcome for small packets, wasting memory.
>
> Experiments show that best results are obtained when using 2048 bytes
> for skb head (This includes the skb overhead and various headers)
>
> This patch provides better len/truesize ratios for packets sent to
> loopback device, and reduce memory needs for in-flight loopback packets,
> particularly on arches with big pages.
>
> If a sender sends many 1-byte packets to an unresponsive application,
> receiver rmem_alloc will grow faster and will stop queuing these packets
> sooner, or will collapse its receive queue to free excess memory.
>
> netperf -t TCP_RR results are improved by ~4 %, and many workloads are
> improved as well (tbench, mysql...)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sch_sfq: use skb_flow_dissect()
From: David Miller @ 2011-11-29 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322574045.2465.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 14:40:45 +0100
> Instead of using a custom flow dissector, use skb_flow_dissect() and
> benefit from tunnelling support.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sch_choke: use skb_flow_dissect()
From: David Miller @ 2011-11-29 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322576535.2465.8.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 15:22:15 +0100
> Instead of using a custom flow dissector, use skb_flow_dissect() and
> benefit from tunnelling support.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Tom Herbert @ 2011-11-29 18:31 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20111129.124715.163094087536706067.davem@davemloft.net>
On Tue, Nov 29, 2011 at 9:47 AM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 29 Nov 2011 17:46:24 +0100
>
>> I did sucessful tests with tg3 (I'll provide the patch for bnx2 shortly)
>>
>> Some details probably can be polished, but I believe your v4 is ready
>> for inclusion.
>>
>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Agreed, all applied to net-next, thanks!
>
> Tom, please keep an eye out for regression or suggestion reports.
>
Will do. I am well aware of how invasive this is in the data path ;-)
I'll add a doc describing BQL also.
By the way, the way to disable BQL at runtime is the 'echo max >
/sys/class/net/eth<n>/queues/tx-<m>/byte_queue_limits/limit_min
> Thanks again.
>
Thanks Dave, Eric, Dave Taht, and everyone for reviewing this.
Tom
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Borislav Petkov @ 2011-11-29 18:34 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Rafael J. Wysocki, tglx, mingo, hpa, x86,
Linux Kernel Mailing List, Linux SCSI List, Linux ACPI,
Network Development, Linux Wireless List, DRI, Florian Mickler,
Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki, deepthi
In-Reply-To: <20111129180414.GA11459@phenom.dumpdata.com>
On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> This patch:
>
> commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> Author: Len Brown <len.brown@intel.com>
> Date: Fri Apr 1 18:28:35 2011 -0400
>
> cpuidle: replace xen access to x86 pm_idle and default_idle
>
> ..scribble on pm_idle and access default_idle,
> have it simply disable_cpuidle() so acpi_idle will not load and
> architecture default HLT will be used.
>
> idea was to have one call - disable_cpuidle() which would make
> pm_idle not be molested by other code. It disallows cpuidle_idle_call
> and acpi_idle_call to not set pm_idle (which is excellent). But the
what is acpi_idle_call, I can't find it anywhere.
> amd_e400_idle and mwait_idle can still setup pm_idle which we really
> do not want.
This is not the case: rather select_idle_routine()/idle_setup() sets
pm_idle.
[..]
> +bool set_pm_idle_to_default()
> +{
> + if (!pm_idle) {
> + pm_idle = default_idle;
> + return true;
> + }
> + return false;
> +}
I don't understand what you're trying to achieve here? Do you want
default_idle to be always the pm_idle for xen or what is the deal here?
If yes, then simply do:
bool set_pm_idle_to_default(void) // remember to add "void" for no function args
{
bool ret = !!pm_idle;
pm_idle = default_idle;
return ret;
}
...
> void stop_this_cpu(void *dummy)
> {
> local_irq_disable();
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 46d6d21..7506181 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
> #endif
> disable_cpuidle();
> boot_option_idle_override = IDLE_HALT;
> -
> + WARN_ON(!set_pm_idle_to_default());
and then do
WARN_ON(set_pm_idle_to_default());
instead of having arbitrary confusing logic. This way you can warn
whether something else set pm_idle already. Or?
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* Lockups with r8169 driver (Was: Hangs with Linux 3.2.0-rc3)
From: Lucas Stach @ 2011-11-29 18:35 UTC (permalink / raw)
To: Borislav Petkov, Francois Romieu; +Cc: LKML, Netdev
In-Reply-To: <20111129154352.GC13958@x1.osrc.amd.com>
[-- Attachment #1: Type: text/plain, Size: 4286 bytes --]
Hi Boris,
Am Dienstag, den 29.11.2011, 16:43 +0100 schrieb Borislav Petkov:
> On Tue, Nov 29, 2011 at 09:06:55AM +0100, Borislav Petkov wrote:
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] WARNING: at kernel/watchdog.c:241 watchdog_overflow_callback+0x9b/0xa6()
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] Hardware name: GA-970A-UD3
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] Watchdog detected hard LOCKUP on cpu 0
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_a
md kvm uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] Pid: 0, comm: swapper Not tainted 3.2.0-rc3+ #39
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] Call Trace:
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] <NMI> [<ffffffff81050c5a>] warn_slowpath_common+0x83/0x9b
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81050d15>] warn_slowpath_fmt+0x46/0x48
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81015204>] ? native_sched_clock+0x34/0x36
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810a7abb>] watchdog_overflow_callback+0x9b/0xa6
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810d28c5>] __perf_event_overflow+0x100/0x17f
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff8107055b>] ? local_clock+0x27/0x2f
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810d0cb6>] ? perf_event_update_userpage+0xf/0xa3
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810d2f2e>] perf_event_overflow+0x14/0x16
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff8101c22a>] x86_pmu_handle_irq+0xbe/0xf9
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814aa5ee>] perf_event_nmi_handler+0x19/0x1b
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814a9f77>] nmi_handle+0x42/0x67
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814aa028>] do_nmi+0x8c/0x26f
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814a9830>] nmi+0x20/0x30
> > > Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffffa023bf55>] ? rtl8169_interrupt+0x268/0x2a4 [r8169]
>
> Btw,
>
> this looks like the box hanged itself after getting an net IRQ over your
> r8169 which reminds me of this other issue being debugged on lkml in
> conjunction with r8169:
>
> http://marc.info/?l=linux-kernel&m=132225246211817&w=2
Thanks for the pointer, this helped a lot.
It seems the lockup is triggered by the r6169 driver. I can reproduce it
with rc2 also. With AMD IOMMU enabled I get the following in dmesg just
before the lockup:
"AMD-Vi: Event logged [IO_PAGE_FAULT device=03:00.0 domain=0x0018 address=0x0000000000003000 flags=0x0050]"
where device=03:00.0 is my r8169 ethernet adapter. So it seems the
hardware tries to dma to a location it's not supposed to dma to.
Dropping Andreas Herrmann from cc as this is clearly not Bulldozer
related. Instead adding netdev and r8169 maintainer. For completeness I
will reattach the whole crashdump and lspci -vv for the ethernet device.
I will try the last patch mentioned in the linked thread and report
back.
Thanks,
Lucas
>
> Can you try reproducing the issue without having network traffic. Also,
> according to the thread above, 3.1 kernel is also affected so it could
> make sense for you go back to 3.0 and see whether it happens with it
> too.
>
> HTH.
>
[-- Attachment #2: crash --]
[-- Type: text/plain, Size: 44506 bytes --]
Nov 29 00:22:04 tellur kernel: [13936.370598] WARNING: at kernel/watchdog.c:241 watchdog_overflow_callback+0x9b/0xa6()
Nov 29 00:22:04 tellur kernel: [13936.370598] Hardware name: GA-970A-UD3
Nov 29 00:22:04 tellur kernel: [13936.370598] Watchdog detected hard LOCKUP on cpu 0
Nov 29 00:22:04 tellur kernel: [13936.370598] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:04 tellur kernel: [13936.370598] Pid: 0, comm: swapper Not tainted 3.2.0-rc3+ #39
Nov 29 00:22:04 tellur kernel: [13936.370598] Call Trace:
Nov 29 00:22:04 tellur kernel: [13936.370598] <NMI> [<ffffffff81050c5a>] warn_slowpath_common+0x83/0x9b
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81050d15>] warn_slowpath_fmt+0x46/0x48
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81015204>] ? native_sched_clock+0x34/0x36
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810a7abb>] watchdog_overflow_callback+0x9b/0xa6
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810d28c5>] __perf_event_overflow+0x100/0x17f
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff8107055b>] ? local_clock+0x27/0x2f
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810d0cb6>] ? perf_event_update_userpage+0xf/0xa3
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810d2f2e>] perf_event_overflow+0x14/0x16
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff8101c22a>] x86_pmu_handle_irq+0xbe/0xf9
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814aa5ee>] perf_event_nmi_handler+0x19/0x1b
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814a9f77>] nmi_handle+0x42/0x67
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814aa028>] do_nmi+0x8c/0x26f
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814a9830>] nmi+0x20/0x30
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffffa023bf55>] ? rtl8169_interrupt+0x268/0x2a4 [r8169]
Nov 29 00:22:04 tellur kernel: [13936.370598] <<EOE>> <IRQ> [<ffffffff81014de7>] ? read_tsc+0x9/0x19
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810a841d>] handle_irq_event_percpu+0x5f/0x193
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810a858c>] handle_irq_event+0x3b/0x57
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810293ac>] ? ack_apic_edge+0x24/0x28
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff810aad4e>] handle_edge_irq+0xa6/0xcc
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81010a95>] handle_irq+0x88/0x8e
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814b214d>] do_IRQ+0x4d/0xa5
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff814a92ae>] common_interrupt+0x6e/0x6e
Nov 29 00:22:04 tellur kernel: [13936.370598] <EOI> [<ffffffff8102f369>] ? native_safe_halt+0xb/0xd
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff812afe54>] acpi_safe_halt+0x2a/0x43
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff812afe8d>] acpi_idle_do_entry+0x20/0x30
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff812b030e>] acpi_idle_enter_c1+0x62/0xbf
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81487a9e>] rest_init+0x72/0x74
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81b67b6c>] start_kernel+0x3ab/0x3b8
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81b672c4>] x86_64_start_reservations+0xaf/0xb3
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81b67140>] ? early_idt_handlers+0x140/0x140
Nov 29 00:22:04 tellur kernel: [13936.370598] [<ffffffff81b673ca>] x86_64_start_kernel+0x102/0x111
Nov 29 00:22:04 tellur kernel: [13936.370598] ---[ end trace d8087f6327f1e63a ]---
Nov 29 00:22:53 tellur kernel: [13986.409015] INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 1, t=60002 jiffies)
Nov 29 00:22:53 tellur kernel: [13986.409020] sending NMI to all CPUs:
Nov 29 00:22:53 tellur kernel: [13986.409023] NMI backtrace for cpu 1
Nov 29 00:22:53 tellur kernel: [13986.409025] CPU 1
Nov 29 00:22:53 tellur kernel: [13986.409027] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:53 tellur kernel: [13986.409099]
Nov 29 00:22:53 tellur kernel: [13986.409102] Pid: 0, comm: kworker/0:0 Tainted: G W 3.2.0-rc3+ #39 Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3
Nov 29 00:22:53 tellur kernel: [13986.409107] RIP: 0010:[<ffffffff812444cc>] [<ffffffff812444cc>] __const_udelay+0x1/0x2e
Nov 29 00:22:53 tellur kernel: [13986.409114] RSP: 0018:ffff88042ec43dd8 EFLAGS: 00000046
Nov 29 00:22:53 tellur kernel: [13986.409116] RAX: 0000000000000000 RBX: 0000000000002710 RCX: 0000000000000040
Nov 29 00:22:53 tellur kernel: [13986.409118] RDX: 0000000000000001 RSI: 0000000000000100 RDI: 0000000000418958
Nov 29 00:22:53 tellur kernel: [13986.409120] RBP: ffff88042ec43df8 R08: 0000000000000002 R09: 0000ffff00066c0a
Nov 29 00:22:53 tellur kernel: [13986.409123] R10: 0000ffff00066c0a R11: 0000000000000000 R12: ffffffff81a2e880
Nov 29 00:22:53 tellur kernel: [13986.409125] R13: ffffffff81a2e980 R14: 0000000000000001 R15: ffffffff81a2f980
Nov 29 00:22:53 tellur kernel: [13986.409128] FS: 00007f7c157d2880(0000) GS:ffff88042ec40000(0000) knlGS:0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409130] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 00:22:53 tellur kernel: [13986.409133] CR2: 00000000006e81d8 CR3: 00000003f2cbb000 CR4: 00000000000406e0
Nov 29 00:22:53 tellur kernel: [13986.409135] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409138] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 00:22:53 tellur kernel: [13986.409140] Process kworker/0:0 (pid: 0, threadinfo ffff880414536000, task ffff880414539710)
Nov 29 00:22:53 tellur kernel: [13986.409144] Stack:
Nov 29 00:22:53 tellur kernel: [13986.409146] ffff88042ec43df8 ffffffff81027c3d 0000000000000000 ffff88042ec4ea80
Nov 29 00:22:53 tellur kernel: [13986.409151] ffff88042ec43e48 ffffffff810adcd8 0000000000000000 ffffffff81a2f980
Nov 29 00:22:53 tellur kernel: [13986.409155] ffff88042ec43e28 0000000000000001 0000000000000000 0000000000000001
Nov 29 00:22:53 tellur kernel: [13986.409160] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409162] <IRQ>
Nov 29 00:22:53 tellur kernel: [13986.409167] [<ffffffff81027c3d>] ? arch_trigger_all_cpu_backtrace+0x76/0x89
Nov 29 00:22:53 tellur kernel: [13986.409171] [<ffffffff810adcd8>] __rcu_pending+0x22d/0x354
Nov 29 00:22:53 tellur kernel: [13986.409175] [<ffffffff810ae1c0>] rcu_check_callbacks+0x9b/0xd9
Nov 29 00:22:53 tellur kernel: [13986.409179] [<ffffffff8105d862>] update_process_times+0x3f/0x76
Nov 29 00:22:53 tellur kernel: [13986.409183] [<ffffffff81078f06>] tick_sched_timer+0x75/0x9f
Nov 29 00:22:53 tellur kernel: [13986.409186] [<ffffffff8106e86f>] __run_hrtimer+0xbc/0x145
Nov 29 00:22:53 tellur kernel: [13986.409190] [<ffffffff81078e91>] ? tick_nohz_handler+0xde/0xde
Nov 29 00:22:53 tellur kernel: [13986.409193] [<ffffffff8106ef70>] hrtimer_interrupt+0xe0/0x19d
Nov 29 00:22:53 tellur kernel: [13986.409197] [<ffffffff814b221c>] smp_apic_timer_interrupt+0x77/0x8a
Nov 29 00:22:53 tellur kernel: [13986.409202] [<ffffffff814b011e>] apic_timer_interrupt+0x6e/0x80
Nov 29 00:22:53 tellur kernel: [13986.409204] <EOI>
Nov 29 00:22:53 tellur kernel: [13986.409207] [<ffffffff81014de7>] ? read_tsc+0x9/0x19
Nov 29 00:22:53 tellur kernel: [13986.409211] [<ffffffff812af523>] ? arch_local_irq_enable+0x8/0xd
Nov 29 00:22:53 tellur kernel: [13986.409215] [<ffffffff81070635>] ? sched_clock_idle_wakeup_event+0x17/0x1a
Nov 29 00:22:53 tellur kernel: [13986.409219] [<ffffffff812b026a>] acpi_idle_enter_simple+0xd3/0x115
Nov 29 00:22:53 tellur kernel: [13986.409223] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409227] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409232] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409234] Code: 0e 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 ff c8 75 fb 48 ff c8 5d c3 55 48 89 e5 66 66 66 66 90 ff 15 2f 8c 81 00 5d c3 55
Nov 29 00:22:53 tellur kernel: [13986.409275] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409277] <IRQ> [<ffffffff81027c3d>] ? arch_trigger_all_cpu_backtrace+0x76/0x89
Nov 29 00:22:53 tellur kernel: [13986.409283] [<ffffffff810adcd8>] __rcu_pending+0x22d/0x354
Nov 29 00:22:53 tellur kernel: [13986.409287] [<ffffffff810ae1c0>] rcu_check_callbacks+0x9b/0xd9
Nov 29 00:22:53 tellur kernel: [13986.409290] [<ffffffff8105d862>] update_process_times+0x3f/0x76
Nov 29 00:22:53 tellur kernel: [13986.409293] [<ffffffff81078f06>] tick_sched_timer+0x75/0x9f
Nov 29 00:22:53 tellur kernel: [13986.409296] [<ffffffff8106e86f>] __run_hrtimer+0xbc/0x145
Nov 29 00:22:53 tellur kernel: [13986.409300] [<ffffffff81078e91>] ? tick_nohz_handler+0xde/0xde
Nov 29 00:22:53 tellur kernel: [13986.409303] [<ffffffff8106ef70>] hrtimer_interrupt+0xe0/0x19d
Nov 29 00:22:53 tellur kernel: [13986.409307] [<ffffffff814b221c>] smp_apic_timer_interrupt+0x77/0x8a
Nov 29 00:22:53 tellur kernel: [13986.409310] [<ffffffff814b011e>] apic_timer_interrupt+0x6e/0x80
Nov 29 00:22:53 tellur kernel: [13986.409312] <EOI> [<ffffffff81014de7>] ? read_tsc+0x9/0x19
Nov 29 00:22:53 tellur kernel: [13986.409317] [<ffffffff812af523>] ? arch_local_irq_enable+0x8/0xd
Nov 29 00:22:53 tellur kernel: [13986.409321] [<ffffffff81070635>] ? sched_clock_idle_wakeup_event+0x17/0x1a
Nov 29 00:22:53 tellur kernel: [13986.409324] [<ffffffff812b026a>] acpi_idle_enter_simple+0xd3/0x115
Nov 29 00:22:53 tellur kernel: [13986.409328] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409331] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409335] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13936.370598] NMI backtrace for cpu 0
Nov 29 00:22:53 tellur kernel: [13936.370598] CPU 0
Nov 29 00:22:53 tellur kernel: [13936.370598] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:53 tellur kernel: [13936.370598]
Nov 29 00:22:53 tellur kernel: [13936.370598] Pid: 0, comm: swapper Tainted: G W 3.2.0-rc3+ #39 Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3
Nov 29 00:22:53 tellur kernel: [13936.370598] RIP: 0010:[<ffffffffa023bf55>] [<ffffffffa023bf55>] rtl8169_interrupt+0x268/0x2a4 [r8169]
Nov 29 00:22:53 tellur kernel: [13936.370598] RSP: 0018:ffff88042ec03e68 EFLAGS: 00000006
Nov 29 00:22:53 tellur kernel: [13936.370598] RAX: 0000000000000050 RBX: ffff8803f6188000 RCX: ffff88042ec13f90
Nov 29 00:22:53 tellur kernel: [13936.370598] RDX: 0000000000000000 RSI: ffff88042ec13f90 RDI: 0000000000000092
Nov 29 00:22:53 tellur kernel: [13936.370598] RBP: ffff88042ec03eb8 R08: ffff88042ec13f90 R09: 000000000000002d
Nov 29 00:22:53 tellur kernel: [13936.370598] R10: ffff8803ef3a5c40 R11: ffff8804144fae68 R12: 0000000000000040
Nov 29 00:22:53 tellur kernel: [13936.370598] R13: ffffc9001273e000 R14: ffffc9001273e03e R15: ffff8803f6188780
Nov 29 00:22:53 tellur kernel: [13936.370598] FS: 00007f137bda29c0(0000) GS:ffff88042ec00000(0000) knlGS:0000000000000000
Nov 29 00:22:53 tellur kernel: [13936.370598] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 00:22:53 tellur kernel: [13936.370598] CR2: 00007f1369168000 CR3: 00000003f46e8000 CR4: 00000000000406f0
Nov 29 00:22:53 tellur kernel: [13936.370598] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 00:22:53 tellur kernel: [13936.370598] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 00:22:53 tellur kernel: [13936.370598] Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a0d020)
Nov 29 00:22:53 tellur kernel: [13936.370598] Stack:
Nov 29 00:22:53 tellur kernel: [13936.370598] ffff8803f6188798 0000004081014d65 ffff88042ec03e88 ffffffff81014de7
Nov 29 00:22:53 tellur kernel: [13936.370598] ffff88042ec03e98 ffff880404ebf580 ffff88040e9b3e00 000000000000002b
Nov 29 00:22:53 tellur kernel: [13936.370598] 0000000000000000 125a8b380294c398 ffff88042ec03f08 ffffffff810a841d
Nov 29 00:22:53 tellur kernel: [13936.370598] Call Trace:
Nov 29 00:22:53 tellur kernel: [13936.370598] <IRQ>
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81014de7>] ? read_tsc+0x9/0x19
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff810a841d>] handle_irq_event_percpu+0x5f/0x193
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff810a858c>] handle_irq_event+0x3b/0x57
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff810293ac>] ? ack_apic_edge+0x24/0x28
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff810aad4e>] handle_edge_irq+0xa6/0xcc
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81010a95>] handle_irq+0x88/0x8e
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff814b214d>] do_IRQ+0x4d/0xa5
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff814a92ae>] common_interrupt+0x6e/0x6e
Nov 29 00:22:53 tellur kernel: [13936.370598] <EOI>
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff8102f369>] ? native_safe_halt+0xb/0xd
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff812afe54>] acpi_safe_halt+0x2a/0x43
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff812afe8d>] acpi_idle_do_entry+0x20/0x30
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff812b030e>] acpi_idle_enter_c1+0x62/0xbf
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81487a9e>] rest_init+0x72/0x74
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81b67b6c>] start_kernel+0x3ab/0x3b8
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81b672c4>] x86_64_start_reservations+0xaf/0xb3
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81b67140>] ? early_idt_handlers+0x140/0x140
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81b673ca>] x86_64_start_kernel+0x102/0x111
Nov 29 00:22:53 tellur kernel: [13936.370598] Code: 48 c7 c6 69 e5 23 a0 48 89 df 31 c0 e8 74 3d 1b e1 83 7d bc 00 41 0f b7 c4 74 08 41 83 cc 10 41 0f b7 c4 66 41 89 06 66 45 8b 26 <b8> 01 00 00 00 45 0f b7 e4 41 81 fc ff ff 00 00 74 10 45 85 e4
Nov 29 00:22:53 tellur kernel: [13936.370598] Call Trace:
Nov 29 00:22:53 tellur kernel: [13936.370598] <IRQ> [<ffffffff81014de7>] ? read_tsc+0x9/0x19
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff810a841d>] handle_irq_event_percpu+0x5f/0x193
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff810a858c>] handle_irq_event+0x3b/0x57
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff810293ac>] ? ack_apic_edge+0x24/0x28
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff810aad4e>] handle_edge_irq+0xa6/0xcc
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81010a95>] handle_irq+0x88/0x8e
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff814b214d>] do_IRQ+0x4d/0xa5
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff814a92ae>] common_interrupt+0x6e/0x6e
Nov 29 00:22:53 tellur kernel: [13936.370598] <EOI> [<ffffffff8102f369>] ? native_safe_halt+0xb/0xd
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff812afe54>] acpi_safe_halt+0x2a/0x43
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff812afe8d>] acpi_idle_do_entry+0x20/0x30
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff812b030e>] acpi_idle_enter_c1+0x62/0xbf
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81487a9e>] rest_init+0x72/0x74
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81b67b6c>] start_kernel+0x3ab/0x3b8
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81b672c4>] x86_64_start_reservations+0xaf/0xb3
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81b67140>] ? early_idt_handlers+0x140/0x140
Nov 29 00:22:53 tellur kernel: [13936.370598] [<ffffffff81b673ca>] x86_64_start_kernel+0x102/0x111
Nov 29 00:22:53 tellur kernel: [13986.409076] NMI backtrace for cpu 5
Nov 29 00:22:53 tellur kernel: [13986.409076] CPU 5
Nov 29 00:22:53 tellur kernel: [13986.409076] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:53 tellur kernel: [13986.409076]
Nov 29 00:22:53 tellur kernel: [13986.409076] Pid: 0, comm: kworker/0:1 Tainted: G W 3.2.0-rc3+ #39 Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3
Nov 29 00:22:53 tellur kernel: [13986.409076] RIP: 0010:[<ffffffff812afe93>] [<ffffffff812afe93>] acpi_idle_do_entry+0x26/0x30
Nov 29 00:22:53 tellur kernel: [13986.409076] RSP: 0018:ffff8804145bfe68 EFLAGS: 00000093
Nov 29 00:22:53 tellur kernel: [13986.409076] RAX: 00000cb876e2ac00 RBX: ffff88040edf4260 RCX: 00000cb876e2a476
Nov 29 00:22:53 tellur kernel: [13986.409076] RDX: 0000000000000841 RSI: 00000000000007d6 RDI: ffff88040edf4260
Nov 29 00:22:53 tellur kernel: [13986.409076] RBP: ffff8804145bfe68 R08: 0000000000000064 R09: 0000000000000389
Nov 29 00:22:53 tellur kernel: [13986.409076] R10: 00007fc830f4a820 R11: 0000000000000202 R12: 0000000000000002
Nov 29 00:22:53 tellur kernel: [13986.409076] R13: ffff88040edf4000 R14: ffff88040edf4020 R15: 125a8b45fe8f1164
Nov 29 00:22:53 tellur kernel: [13986.409076] FS: 00007fc830f4b700(0000) GS:ffff88042ed40000(0000) knlGS:0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409076] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 00:22:53 tellur kernel: [13986.409076] CR2: 00007fefe4e16000 CR3: 0000000001a05000 CR4: 00000000000406e0
Nov 29 00:22:53 tellur kernel: [13986.409076] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409076] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 00:22:53 tellur kernel: [13986.409076] Process kworker/0:1 (pid: 0, threadinfo ffff8804145be000, task ffff8804145c1710)
Nov 29 00:22:53 tellur kernel: [13986.409076] Stack:
Nov 29 00:22:53 tellur kernel: [13986.409076] ffff8804145bfea8 ffffffff812b0241 00007fc830f4a820 ffff88040edf4020
Nov 29 00:22:53 tellur kernel: [13986.409076] ffffffff81a63ae0 00000000fffffff0 0000000000000002 ffffffff81a63b90
Nov 29 00:22:53 tellur kernel: [13986.409076] ffff8804145bfef8 ffffffff813c1e7b ffff8804145bffd8 0000000581b48ee0
Nov 29 00:22:53 tellur kernel: [13986.409076] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409076] Code: ff ff 04 5d c3 55 48 89 e5 66 66 66 66 90 8a 47 08 3c 01 75 07 e8 07 5d d7 ff eb 17 3c 02 75 07 e8 9d ff ff ff eb 0c 8b 57 04 ec
Nov 29 00:22:53 tellur kernel: [13986.409076] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409076] NMI backtrace for cpu 4
Nov 29 00:22:53 tellur kernel: [13986.409076] CPU 4
Nov 29 00:22:53 tellur kernel: [13986.409076] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:53 tellur kernel: [13986.409076]
Nov 29 00:22:53 tellur kernel: [13986.409076] Pid: 0, comm: kworker/0:1 Tainted: G W 3.2.0-rc3+ #39 Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3
Nov 29 00:22:53 tellur kernel: [13986.409076] RIP: 0010:[<ffffffff812afe93>] [<ffffffff812afe93>] acpi_idle_do_entry+0x26/0x30
Nov 29 00:22:53 tellur kernel: [13986.409076] RSP: 0018:ffff8804145a5e68 EFLAGS: 00000093
Nov 29 00:22:53 tellur kernel: [13986.409076] RAX: 00000cb876e2ac00 RBX: ffff88040edf3a60 RCX: 00000cb876e2a472
Nov 29 00:22:53 tellur kernel: [13986.409076] RDX: 0000000000000841 RSI: 00000000000007be RDI: ffff88040edf3a60
Nov 29 00:22:53 tellur kernel: [13986.409076] RBP: ffff8804145a5e68 R08: 0000000000000064 R09: 0000000000000389
Nov 29 00:22:53 tellur kernel: [13986.409076] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002
Nov 29 00:22:53 tellur kernel: [13986.409076] R13: ffff88040edf3800 R14: ffff88040edf3820 R15: 125a8b45fe8f1155
Nov 29 00:22:53 tellur kernel: [13986.409076] FS: 00007f8a62e47700(0000) GS:ffff88042ed00000(0000) knlGS:0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409076] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 00:22:53 tellur kernel: [13986.409076] CR2: 00007f8a5815b000 CR3: 00000003ee023000 CR4: 00000000000406e0
Nov 29 00:22:53 tellur kernel: [13986.409076] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409076] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 00:22:53 tellur kernel: [13986.409076] Process kworker/0:1 (pid: 0, threadinfo ffff8804145a4000, task ffff8804145a9710)
Nov 29 00:22:53 tellur kernel: [13986.409076] Stack:
Nov 29 00:22:53 tellur kernel: [13986.409076] ffff8804145a5ea8 ffffffff812b0241 0000000000000000 ffff88040edf3820
Nov 29 00:22:53 tellur kernel: [13986.409076] ffffffff81a63ae0 00000000fffffff0 0000000000000002 ffffffff81a63b90
Nov 29 00:22:53 tellur kernel: [13986.409076] ffff8804145a5ef8 ffffffff813c1e7b ffff8804145a5fd8 0000000481b48ee0
Nov 29 00:22:53 tellur kernel: [13986.409076] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409076] Code: ff ff 04 5d c3 55 48 89 e5 66 66 66 66 90 8a 47 08 3c 01 75 07 e8 07 5d d7 ff eb 17 3c 02 75 07 e8 9d ff ff ff eb 0c 8b 57 04 ec
Nov 29 00:22:53 tellur kernel: [13986.409076] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409076] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409080] NMI backtrace for cpu 6
Nov 29 00:22:53 tellur kernel: [13986.409080] CPU 6
Nov 29 00:22:53 tellur kernel: [13986.409080] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:53 tellur kernel: [13986.409080]
Nov 29 00:22:53 tellur kernel: [13986.409080] Pid: 0, comm: kworker/0:1 Tainted: G W 3.2.0-rc3+ #39 Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3
Nov 29 00:22:53 tellur kernel: [13986.409080] RIP: 0010:[<ffffffff812afe93>] [<ffffffff812afe93>] acpi_idle_do_entry+0x26/0x30
Nov 29 00:22:53 tellur kernel: [13986.409080] RSP: 0018:ffff8804145e5e68 EFLAGS: 00000093
Nov 29 00:22:53 tellur kernel: [13986.409080] RAX: 00000cb876e2c600 RBX: ffff88040edf4a60 RCX: 00000cb876e2c168
Nov 29 00:22:53 tellur kernel: [13986.409080] RDX: 0000000000000841 RSI: 00000000000004b6 RDI: ffff88040edf4a60
Nov 29 00:22:53 tellur kernel: [13986.409080] RBP: ffff8804145e5e68 R08: 0000000000000064 R09: 0000000000000389
Nov 29 00:22:53 tellur kernel: [13986.409080] R10: 0000000000000a6f R11: 0000000000000000 R12: 0000000000000002
Nov 29 00:22:53 tellur kernel: [13986.409080] R13: ffff88040edf4800 R14: ffff88040edf4820 R15: 125a8b45fe8f2b48
Nov 29 00:22:53 tellur kernel: [13986.409080] FS: 00007fdef1f589c0(0000) GS:ffff88042ed80000(0000) knlGS:0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409080] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 00:22:53 tellur kernel: [13986.409080] CR2: 00007fc8441981a8 CR3: 00000003a06db000 CR4: 00000000000406e0
Nov 29 00:22:53 tellur kernel: [13986.409080] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409080] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 00:22:53 tellur kernel: [13986.409080] Process kworker/0:1 (pid: 0, threadinfo ffff8804145e4000, task ffff8804145e9710)
Nov 29 00:22:53 tellur kernel: [13986.409080] Stack:
Nov 29 00:22:53 tellur kernel: [13986.409080] ffff8804145e5ea8 ffffffff812b0241 0000000000000a6f ffff88040edf4820
Nov 29 00:22:53 tellur kernel: [13986.409080] ffffffff81a63ae0 00000000fffffff0 0000000000000002 ffffffff81a63b90
Nov 29 00:22:53 tellur kernel: [13986.409080] ffff8804145e5ef8 ffffffff813c1e7b ffff8804145e5fd8 0000000681b48ee0
Nov 29 00:22:53 tellur kernel: [13986.409080] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409080] Code: ff ff 04 5d c3 55 48 89 e5 66 66 66 66 90 8a 47 08 3c 01 75 07 e8 07 5d d7 ff eb 17 3c 02 75 07 e8 9d ff ff ff eb 0c 8b 57 04 ec
Nov 29 00:22:53 tellur kernel: [13986.409080] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409080] NMI backtrace for cpu 7
Nov 29 00:22:53 tellur kernel: [13986.409080] CPU 7
Nov 29 00:22:53 tellur kernel: [13986.409080] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:53 tellur kernel: [13986.409080]
Nov 29 00:22:53 tellur kernel: [13986.409080] Pid: 0, comm: kworker/0:1 Tainted: G W 3.2.0-rc3+ #39 Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3
Nov 29 00:22:53 tellur kernel: [13986.409080] RIP: 0010:[<ffffffff812afe93>] [<ffffffff812afe93>] acpi_idle_do_entry+0x26/0x30
Nov 29 00:22:53 tellur kernel: [13986.409080] RSP: 0018:ffff880414621e68 EFLAGS: 00000093
Nov 29 00:22:53 tellur kernel: [13986.409080] RAX: 00000cb876e2bc00 RBX: ffff88040edf5260 RCX: 00000cb876e2b484
Nov 29 00:22:53 tellur kernel: [13986.409080] RDX: 0000000000000841 RSI: 00000000000007bd RDI: ffff88040edf5260
Nov 29 00:22:53 tellur kernel: [13986.409080] RBP: ffff880414621e68 R08: 0000000000000064 R09: 0000000000000389
Nov 29 00:22:53 tellur kernel: [13986.409080] R10: 00007fc84014bd40 R11: 0000000000000202 R12: 0000000000000002
Nov 29 00:22:53 tellur kernel: [13986.409080] R13: ffff88040edf5000 R14: ffff88040edf5020 R15: 125a8b45fe8f2160
Nov 29 00:22:53 tellur kernel: [13986.409080] FS: 00007fc84014c700(0000) GS:ffff88042edc0000(0000) knlGS:0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409080] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 00:22:53 tellur kernel: [13986.409080] CR2: 00007f3f7dc9ec4c CR3: 00000003ef51c000 CR4: 00000000000406e0
Nov 29 00:22:53 tellur kernel: [13986.409080] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409080] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 00:22:53 tellur kernel: [13986.409080] Process kworker/0:1 (pid: 0, threadinfo ffff880414620000, task ffff8804145f9710)
Nov 29 00:22:53 tellur kernel: [13986.409080] Stack:
Nov 29 00:22:53 tellur kernel: [13986.409080] ffff880414621ea8 ffffffff812b0241 00007fc84014bd40 ffff88040edf5020
Nov 29 00:22:53 tellur kernel: [13986.409080] ffffffff81a63ae0 00000000fffffff0 0000000000000002 ffffffff81a63b90
Nov 29 00:22:53 tellur kernel: [13986.409080] ffff880414621ef8 ffffffff813c1e7b ffff880414621fd8 0000000781b48ee0
Nov 29 00:22:53 tellur kernel: [13986.409080] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409080] Code: ff ff 04 5d c3 55 48 89 e5 66 66 66 66 90 8a 47 08 3c 01 75 07 e8 07 5d d7 ff eb 17 3c 02 75 07 e8 9d ff ff ff eb 0c 8b 57 04 ec
Nov 29 00:22:53 tellur kernel: [13986.409080] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409080] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409081] NMI backtrace for cpu 2
Nov 29 00:22:53 tellur kernel: [13986.409081] CPU 2
Nov 29 00:22:53 tellur kernel: [13986.409081] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:53 tellur kernel: [13986.409081]
Nov 29 00:22:53 tellur kernel: [13986.409081] Pid: 0, comm: kworker/0:1 Tainted: G W 3.2.0-rc3+ #39 Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3
Nov 29 00:22:53 tellur kernel: [13986.409081] RIP: 0010:[<ffffffff812afe93>] [<ffffffff812afe93>] acpi_idle_do_entry+0x26/0x30
Nov 29 00:22:53 tellur kernel: [13986.409081] RSP: 0018:ffff880414579e68 EFLAGS: 00000093
Nov 29 00:22:53 tellur kernel: [13986.409081] RAX: 00000cb876e2c100 RBX: ffff88040edf2a60 RCX: 00000cb876e2b9c6
Nov 29 00:22:53 tellur kernel: [13986.409081] RDX: 0000000000000841 RSI: 00000000000007db RDI: ffff88040edf2a60
Nov 29 00:22:53 tellur kernel: [13986.409081] RBP: ffff880414579e68 R08: 0000000000000064 R09: 0000000000000382
Nov 29 00:22:53 tellur kernel: [13986.409081] R10: 0000000000000001 R11: 0000000000000293 R12: 0000000000000002
Nov 29 00:22:53 tellur kernel: [13986.409081] R13: ffff88040edf2800 R14: ffff88040edf2820 R15: 125a8b45fe8f26be
Nov 29 00:22:53 tellur kernel: [13986.409081] FS: 00007fded085f700(0000) GS:ffff88042ec80000(0000) knlGS:0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409081] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 00:22:53 tellur kernel: [13986.409081] CR2: 00007fb17c005078 CR3: 00000003a06db000 CR4: 00000000000406e0
Nov 29 00:22:53 tellur kernel: [13986.409081] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409081] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 00:22:53 tellur kernel: [13986.409081] Process kworker/0:1 (pid: 0, threadinfo ffff880414578000, task ffff880414551710)
Nov 29 00:22:53 tellur kernel: [13986.409081] Stack:
Nov 29 00:22:53 tellur kernel: [13986.409081] ffff880414579ea8 ffffffff812b0241 0000000000000001 ffff88040edf2820
Nov 29 00:22:53 tellur kernel: [13986.409081] ffffffff81a63ae0 00000000fffffff0 0000000000000002 ffffffff81a63b90
Nov 29 00:22:53 tellur kernel: [13986.409081] ffff880414579ef8 ffffffff813c1e7b ffff880414579fd8 0000000281b48ee0
Nov 29 00:22:53 tellur kernel: [13986.409081] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409081] Code: ff ff 04 5d c3 55 48 89 e5 66 66 66 66 90 8a 47 08 3c 01 75 07 e8 07 5d d7 ff eb 17 3c 02 75 07 e8 9d ff ff ff eb 0c 8b 57 04 ec
Nov 29 00:22:53 tellur kernel: [13986.409081] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409081] NMI backtrace for cpu 3
Nov 29 00:22:53 tellur kernel: [13986.409081] CPU 3
Nov 29 00:22:53 tellur kernel: [13986.409081] Modules linked in: tcp_lp ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun lockd bridge stp llc bluetooth rfkill it87 adt7475 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ir_lirc_codec lirc_dev ir_mce_kbd_decoder snd_timer snd ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ata_generic pata_acpi edac_core serio_raw soundcore joydev ir_rc5_decoder pata_atiixp ir_nec_decoder r8169 mii mceusb rc_core virtio_net edac_mce_amd sp5100_tco i2c_piix4 xhci_hcd fam15h_power pcspkr snd_page_alloc microcode k10temp virtio_ring virtio kvm_amd kvm
uinput sunrpc ipv6 usb_storage firewire_ohci uas firewire_core crc_itu_t nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi [last unloaded: scsi_wait_scan]
Nov 29 00:22:53 tellur kernel: [13986.409081]
Nov 29 00:22:53 tellur kernel: [13986.409081] Pid: 0, comm: kworker/0:1 Tainted: G W 3.2.0-rc3+ #39 Gigabyte Technology Co., Ltd. GA-970A-UD3/GA-970A-UD3
Nov 29 00:22:53 tellur kernel: [13986.409081] RIP: 0010:[<ffffffff812afe93>] [<ffffffff812afe93>] acpi_idle_do_entry+0x26/0x30
Nov 29 00:22:53 tellur kernel: [13986.409081] RSP: 0018:ffff88041458fe68 EFLAGS: 00000093
Nov 29 00:22:53 tellur kernel: [13986.409081] RAX: 00000cb876e2c100 RBX: ffff88040edf3260 RCX: 00000cb876e2b9da
Nov 29 00:22:53 tellur kernel: [13986.409081] RDX: 0000000000000841 RSI: 00000000000007f3 RDI: ffff88040edf3260
Nov 29 00:22:53 tellur kernel: [13986.409081] RBP: ffff88041458fe68 R08: 0000000000000064 R09: 0000000000000382
Nov 29 00:22:53 tellur kernel: [13986.409081] R10: 00007fc831f367a0 R11: 0000000000000202 R12: 0000000000000002
Nov 29 00:22:53 tellur kernel: [13986.409081] R13: ffff88040edf3000 R14: ffff88040edf3020 R15: 125a8b45fe8f26f3
Nov 29 00:22:53 tellur kernel: [13986.409081] FS: 00007fc831f37700(0000) GS:ffff88042ecc0000(0000) knlGS:0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409081] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 00:22:53 tellur kernel: [13986.409081] CR2: 00007f3f7dc9ec4c CR3: 0000000001a05000 CR4: 00000000000406e0
Nov 29 00:22:53 tellur kernel: [13986.409081] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 00:22:53 tellur kernel: [13986.409081] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 00:22:53 tellur kernel: [13986.409081] Process kworker/0:1 (pid: 0, threadinfo ffff88041458e000, task ffff880414591710)
Nov 29 00:22:53 tellur kernel: [13986.409081] Stack:
Nov 29 00:22:53 tellur kernel: [13986.409081] ffff88041458fea8 ffffffff812b0241 00007fc831f367a0 ffff88040edf3020
Nov 29 00:22:53 tellur kernel: [13986.409081] ffffffff81a63ae0 00000000fffffff0 0000000000000002 ffffffff81a63b90
Nov 29 00:22:53 tellur kernel: [13986.409081] ffff88041458fef8 ffffffff813c1e7b ffff88041458ffd8 0000000381b48ee0
Nov 29 00:22:53 tellur kernel: [13986.409081] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff81498652>] start_secondary+0x23f/0x241
Nov 29 00:22:53 tellur kernel: [13986.409081] Code: ff ff 04 5d c3 55 48 89 e5 66 66 66 66 90 8a 47 08 3c 01 75 07 e8 07 5d d7 ff eb 17 3c 02 75 07 e8 9d ff ff ff eb 0c 8b 57 04 ec
Nov 29 00:22:53 tellur kernel: [13986.409081] Call Trace:
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff812b0241>] acpi_idle_enter_simple+0xaa/0x115
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff813c1e7b>] cpuidle_idle_call+0xf8/0x189
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff8100e2e8>] cpu_idle+0xa9/0xf0
Nov 29 00:22:53 tellur kernel: [13986.409081] [<ffffffff81498652>] start_secondary+0x23f/0x241
[-- Attachment #3: lspci --]
[-- Type: text/plain, Size: 3256 bytes --]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
Subsystem: Giga-byte Technology GA-EP45-DS5 Motherboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 43
Region 0: I/O ports at ee00 [size=256]
Region 2: Memory at fdeff000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at fdef8000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0100c Data: 4179
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Unknown small resource type 00, will not decode more.
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 12-34-56-78-12-34-56-78
Kernel driver in use: r8169
Kernel modules: r8169
^ permalink raw reply
* [PATCH] can: Update logging style
From: Joe Perches @ 2011-11-29 18:54 UTC (permalink / raw)
To: Oliver Hartkopp, Urs Thuermann
Cc: David S. Miller, linux-can, netdev, linux-kernel
Use pr_fmt, pr_<level> and pr_<level>_ratelimited.
Coalesce format strings.
Signed-off-by: Joe Perches <joe@perches.com>
---
net/can/af_can.c | 31 ++++++++++++++-----------------
net/can/bcm.c | 14 ++++++++------
net/can/gw.c | 6 ++++--
net/can/proc.c | 8 ++++----
net/can/raw.c | 8 +++++---
5 files changed, 35 insertions(+), 32 deletions(-)
diff --git a/net/can/af_can.c b/net/can/af_can.c
index 0ce2ad0..c4f0da5 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -40,6 +40,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kmod.h>
@@ -62,8 +64,8 @@
#include "af_can.h"
-static __initdata const char banner[] = KERN_INFO
- "can: controller area network core (" CAN_VERSION_STRING ")\n";
+static __initdata const char banner[] =
+ "controller area network core (" CAN_VERSION_STRING ")";
MODULE_DESCRIPTION("Controller Area Network PF_CAN core");
MODULE_LICENSE("Dual BSD/GPL");
@@ -161,8 +163,8 @@ static int can_create(struct net *net, struct socket *sock, int protocol,
* return -EPROTONOSUPPORT
*/
if (err)
- printk_ratelimited(KERN_ERR "can: request_module "
- "(can-proto-%d) failed.\n", protocol);
+ pr_err_ratelimited("request_module (can-proto-%d) failed\n",
+ protocol);
cp = can_get_proto(protocol);
}
@@ -505,8 +507,7 @@ void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
d = find_dev_rcv_lists(dev);
if (!d) {
- printk(KERN_ERR "BUG: receive list not found for "
- "dev %s, id %03X, mask %03X\n",
+ pr_err("BUG: receive list not found for dev %s, id %03X, mask %03X\n",
DNAME(dev), can_id, mask);
goto out;
}
@@ -532,8 +533,7 @@ void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
*/
if (!next) {
- printk(KERN_ERR "BUG: receive list entry not found for "
- "dev %s, id %03X, mask %03X\n",
+ pr_err("BUG: receive list entry not found for dev %s, id %03X, mask %03X\n",
DNAME(dev), can_id, mask);
r = NULL;
goto out;
@@ -701,8 +701,7 @@ int can_proto_register(const struct can_proto *cp)
int err = 0;
if (proto < 0 || proto >= CAN_NPROTO) {
- printk(KERN_ERR "can: protocol number %d out of range\n",
- proto);
+ pr_err("protocol number %d out of range\n", proto);
return -EINVAL;
}
@@ -713,8 +712,7 @@ int can_proto_register(const struct can_proto *cp)
mutex_lock(&proto_tab_lock);
if (proto_tab[proto]) {
- printk(KERN_ERR "can: protocol %d already registered\n",
- proto);
+ pr_err("protocol %d already registered\n", proto);
err = -EBUSY;
} else
RCU_INIT_POINTER(proto_tab[proto], cp);
@@ -769,8 +767,7 @@ static int can_notifier(struct notifier_block *nb, unsigned long msg,
/* create new dev_rcv_lists for this device */
d = kzalloc(sizeof(*d), GFP_KERNEL);
if (!d) {
- printk(KERN_ERR
- "can: allocation of receive list failed\n");
+ pr_err("allocation of receive list failed\n");
return NOTIFY_DONE;
}
BUG_ON(dev->ml_priv);
@@ -790,8 +787,8 @@ static int can_notifier(struct notifier_block *nb, unsigned long msg,
dev->ml_priv = NULL;
}
} else
- printk(KERN_ERR "can: notifier: receive list not "
- "found for dev %s\n", dev->name);
+ pr_err("notifier: receive list not found for dev %s\n",
+ dev->name);
spin_unlock(&can_rcvlists_lock);
@@ -824,7 +821,7 @@ static struct notifier_block can_netdev_notifier __read_mostly = {
static __init int can_init(void)
{
- printk(banner);
+ pr_info("%s\n", banner);
memset(&can_rx_alldev_list, 0, sizeof(can_rx_alldev_list));
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 151b773..540c804 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -39,6 +39,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/init.h>
#include <linux/interrupt.h>
@@ -77,8 +79,8 @@
(CAN_SFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG))
#define CAN_BCM_VERSION CAN_VERSION
-static __initdata const char banner[] = KERN_INFO
- "can: broadcast manager protocol (rev " CAN_BCM_VERSION " t)\n";
+static __initdata const char banner[] =
+ "broadcast manager protocol (rev " CAN_BCM_VERSION " t)";
MODULE_DESCRIPTION("PF_CAN broadcast manager protocol");
MODULE_LICENSE("Dual BSD/GPL");
@@ -729,8 +731,8 @@ static void bcm_rx_unreg(struct net_device *dev, struct bcm_op *op)
/* mark as removed subscription */
op->rx_reg_dev = NULL;
} else
- printk(KERN_ERR "can-bcm: bcm_rx_unreg: registered device "
- "mismatch %p %p\n", op->rx_reg_dev, dev);
+ pr_err("%s: registered device mismatch %p %p\n",
+ __func__, op->rx_reg_dev, dev);
}
/*
@@ -1606,11 +1608,11 @@ static int __init bcm_module_init(void)
{
int err;
- printk(banner);
+ pr_info("%s\n", banner);
err = can_proto_register(&bcm_can_proto);
if (err < 0) {
- printk(KERN_ERR "can: registration of bcm protocol failed\n");
+ pr_err("registration of bcm protocol failed\n");
return err;
}
diff --git a/net/can/gw.c b/net/can/gw.c
index 3d79b12..e17253f 100644
--- a/net/can/gw.c
+++ b/net/can/gw.c
@@ -39,6 +39,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
@@ -59,7 +61,7 @@
#define CAN_GW_VERSION "20101209"
static __initdata const char banner[] =
- KERN_INFO "can: netlink gateway (rev " CAN_GW_VERSION ")\n";
+ "netlink gateway (rev " CAN_GW_VERSION ")";
MODULE_DESCRIPTION("PF_CAN netlink gateway");
MODULE_LICENSE("Dual BSD/GPL");
@@ -913,7 +915,7 @@ static int cgw_remove_job(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
static __init int cgw_module_init(void)
{
- printk(banner);
+ pr_info("%s\n", banner);
cgw_cache = kmem_cache_create("can_gw", sizeof(struct cgw_job),
0, 0, NULL);
diff --git a/net/can/proc.c b/net/can/proc.c
index ba873c3..c3aedf5 100644
--- a/net/can/proc.c
+++ b/net/can/proc.c
@@ -39,6 +39,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/proc_fs.h>
#include <linux/list.h>
@@ -118,8 +120,7 @@ static unsigned long calc_rate(unsigned long oldjif, unsigned long newjif,
/* see can_stat_update() - this should NEVER happen! */
if (count > (ULONG_MAX / HZ)) {
- printk(KERN_ERR "can: calc_rate: count exceeded! %ld\n",
- count);
+ pr_err("%s: count exceeded! %ld\n", __func__, count);
return 99999999;
}
@@ -475,8 +476,7 @@ void can_init_proc(void)
can_dir = proc_mkdir("can", init_net.proc_net);
if (!can_dir) {
- printk(KERN_INFO "can: failed to create /proc/net/can . "
- "CONFIG_PROC_FS missing?\n");
+ pr_info("failed to create /proc/net/can . CONFIG_PROC_FS missing?\n");
return;
}
diff --git a/net/can/raw.c b/net/can/raw.c
index cde1b4a..2875c55 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -39,6 +39,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/init.h>
#include <linux/uio.h>
@@ -56,7 +58,7 @@
#define CAN_RAW_VERSION CAN_VERSION
static __initdata const char banner[] =
- KERN_INFO "can: raw protocol (rev " CAN_RAW_VERSION ")\n";
+ "raw protocol (rev " CAN_RAW_VERSION ")";
MODULE_DESCRIPTION("PF_CAN raw protocol");
MODULE_LICENSE("Dual BSD/GPL");
@@ -783,11 +785,11 @@ static __init int raw_module_init(void)
{
int err;
- printk(banner);
+ pr_info("%s\n", banner);
err = can_proto_register(&raw_can_proto);
if (err < 0)
- printk(KERN_ERR "can: registration of raw protocol failed\n");
+ pr_err("registration of raw protocol failed\n");
return err;
}
--
1.7.6.405.gc1be0
^ 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