linux.kernel - 26 new messages in 17 topics - digest
linux.kernel
http://groups.google.com/group/linux.kernel?hl=en
linux.kernel@googlegroups.com
Today's topics:
* Cpufreq: Make governor data on nonboot cpus across system suspend/resume - 4
messages, 3 authors
http://groups.google.com/group/linux.kernel/t/8cd1f356eda2a3b0?hl=en
* xen drivers fail to link on ARM with v3.12-9888-gf63c482 - 2 messages, 1
author
http://groups.google.com/group/linux.kernel/t/2b72ccf2ec8c82da?hl=en
* : REGRESSION: "*ERROR* Timed out waiting for forcewake old ack to clear" - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/463ef67d8af2a4ae?hl=en
* ARM: fix /proc/$PID/stack to work on SMP - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5998a790ce0f13fe?hl=en
* perf tip: fails to convert comm - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5eff5c722c706d30?hl=en
* cpufreq: suspend/resume governors with PM notifiers - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/14055e77b2ea6480?hl=en
* Kernel 3.4.57: "tg3 0000:01:00.0: eth0: transmit timed out, resetting" - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/3f5e74e211bfbf83?hl=en
* bonding/bond_main: Apply ACCESS_ONCE() to avoid sparse false positive - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/702c74b758c475e5?hl=en
* power: Change device_wakeup_enable() to check for null dev_name(dev) - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/63d037cc27ffc12e?hl=en
* documentation: Update circular buffer for load-acquire/store-release - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/9d3de39c23ef46a9?hl=en
* i2c: Fallback to of_node of parent - 4 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d93b3f894c3e5685?hl=en
* vmstat: On demand vmstat workers V3 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f9b1502cc1b5f270?hl=en
* autofs4: allow autofs to work outside the initial PID namespace - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/97091a536b47b942?hl=en
* ASoC: omap: mcbsp, mcpdm, dmic: raw read and write endian fix - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/61c361b93c246cfd?hl=en
* sound fixes for 3.13-rc1 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/55ae5a33d87f1caf?hl=en
* Command line related cleanups - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f284ec730d289d67?hl=en
* panic: setup panic_timeout early - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b9ad085825bd3729?hl=en
==============================================================================
TOPIC: Cpufreq: Make governor data on nonboot cpus across system suspend/
resume
http://groups.google.com/group/linux.kernel/t/8cd1f356eda2a3b0?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Nov 16 2013 7:00 am
From: Viresh Kumar
On 16 November 2013 20:11, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Saturday, November 16, 2013 11:59:59 AM Lan Tianyu wrote:
>> Defaultly, all cpus use ondemand governor after bootup. Change one
>> non-boot cpu's governor to conservative,
>
> Well, why would anyone want to do that? Just out of curiosity ...
People may want to use different group/cluster/socket of CPUs differently,
with different kind of policies. Maybe performance governor for boot cpu
and ondemand for others.
This bug would also be there for big LITTLE where we want to have
separate set of tunables for big and LITTLE clusters for the same type
of governor.
> So this is acpi-cpufreq, right?
Probably yes, I saw something similar somewhere.. But this is driver
independent..
> The patch looks basically OK to me, but ->
We wouldn't need this patch if my other patch (where I am disabling
governors in suspend/resume goes in, in any form)..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 4 ==
Date: Sat, Nov 16 2013 7:00 am
From: "Rafael J. Wysocki"
On Saturday, November 16, 2013 03:41:10 PM Rafael J. Wysocki wrote:
[...]
> > >> @@ -1822,6 +1822,9 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
> > >> ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
> > >> module_put(policy->governor->owner);
> > >>
> > >> + if ((event == CPUFREQ_GOV_POLICY_INIT) && ret == -EALREADY)
> > >> + ret = 0;
> > >> +
>
> -> I'd prefer this check to be combined with the one done to determine whether
> or not we need to do the module_put(). Something like
>
> if (event == CPUFREQ_GOV_POLICY_EXIT && ret) {
Obviously, that should be:
if (event == CPUFREQ_GOV_POLICY_INIT && ret) {
> module_put(policy->governor->owner);
> if (ret == -EALREADY)
> return 0;
> } else if (event == CPUFREQ_GOV_POLICY_EXIT && !ret) {
> module_put(policy->governor->owner);
> }
Sorry for the confusion.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 3 of 4 ==
Date: Sat, Nov 16 2013 7:30 am
From: Lan Tianyu
On 11/16/2013 10:41 PM, Rafael J. Wysocki wrote:
> On Saturday, November 16, 2013 11:59:59 AM Lan Tianyu wrote:
>> On 11/16/2013 08:38 AM, Rafael J. Wysocki wrote:
>>> On Friday, November 15, 2013 04:15:34 PM Lan Tianyu wrote:
>>>> Currently, governor of nonboot cpus will be put to EXIT when system suspend.
>>>> Since all these cpus will be unplugged and the governor usage_count decreases
>>>> to zero. The governor data and its sysfs interfaces will be freed or released.
>>>> This makes user config of these governors loss during suspend and resume.
>>>
>>> First off, do we have a pointer to a bug report related to that?
>>>
>>
>> No, I found this bug when I tried to resolve other similar bug.
>> https://bugzilla.kernel.org/show_bug.cgi?id=63081. I still have no idea
>> about bug 63081 and asked reporter to try this patch.
>>
>>> Second, what does need to be done to reproduce this problem?
>>>
>>
>> Defaultly, all cpus use ondemand governor after bootup. Change one
>> non-boot cpu's governor to conservative,
>
> Well, why would anyone want to do that? Just out of curiosity ...
Just use this way to produce the issue. But on the laptop, I think
fewer people will do the same thing. Just like Viresh said, this also
will affect the systems of governor per policy.
>
>> modify conservative config via sysfs interface and then do system suspend.
>> After resume, the config of conservative is reset. On my machine, all cpus
>> have owen policy.
>
> So this is acpi-cpufreq, right?
>
Yes, it's acpi-cpufreq driver.
> The patch looks basically OK to me, but ->
>
>>>> This doesn't happen on the governor covering boot cpu because it isn't
>>>> unplugged during system suspend.
>>>>
>>>> To fix this issue, skipping governor exit during system suspend and check
>>>> policy governor data to determine whether the governor is really needed
>>>> to be initialized when do init. If not, return EALREADY to indicate the
>>>> governor has been initialized and should do nothing. __cpufreq_governor()
>>>> convert EALREADY to 0 as return value for INIT event since governor is
>>>> still under INIT state and can do START operation.
>>>>
>>>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>>>> ---
>>>> Fix some typos
>>>>
>>>> drivers/cpufreq/cpufreq.c | 5 ++++-
>>>> drivers/cpufreq/cpufreq_governor.c | 13 ++++++++++++-
>>>> 2 files changed, 16 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>>> index 02d534d..38f2e4a 100644
>>>> --- a/drivers/cpufreq/cpufreq.c
>>>> +++ b/drivers/cpufreq/cpufreq.c
>>>> @@ -1239,7 +1239,7 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
>>>>
>>>> /* If cpu is last user of policy, free policy */
>>>> if (cpus == 1) {
>>>> - if (has_target()) {
>>>> + if (has_target() && !frozen) {
>>>> ret = __cpufreq_governor(policy,
>>>> CPUFREQ_GOV_POLICY_EXIT);
>>>> if (ret) {
>>>> @@ -1822,6 +1822,9 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
>>>> ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
>>>> module_put(policy->governor->owner);
>>>>
>>>> + if ((event == CPUFREQ_GOV_POLICY_INIT) && ret == -EALREADY)
>>>> + ret = 0;
>>>> +
>
> -> I'd prefer this check to be combined with the one done to determine whether
> or not we need to do the module_put(). Something like
>
> if (event == CPUFREQ_GOV_POLICY_EXIT && ret) {
> module_put(policy->governor->owner);
> if (ret == -EALREADY)
> return 0;
> } else if (event == CPUFREQ_GOV_POLICY_EXIT && !ret) {
> module_put(policy->governor->owner);
> }
>
Ok. I will update soon.
> Thanks!
>
>>>> return ret;
>>>> }
>>>>
>>>> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
>>>> index 0806c31..ddb93af 100644
>>>> --- a/drivers/cpufreq/cpufreq_governor.c
>>>> +++ b/drivers/cpufreq/cpufreq_governor.c
>>>> @@ -204,9 +204,20 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>>>>
>>>> switch (event) {
>>>> case CPUFREQ_GOV_POLICY_INIT:
>>>> + /*
>>>> + * In order to keep governor data across suspend/resume,
>>>> + * Governor doesn't exit when suspend and will be
>>>> + * reinitialized when resume. Here check policy governor
>>>> + * data to determine whether the governor has been exited.
>>>> + * If not, return EALREADY.
>>>> + */
>>>> if (have_governor_per_policy()) {
>>>> - WARN_ON(dbs_data);
>>>> + if (dbs_data)
>>>> + return -EALREADY;
>>>> } else if (dbs_data) {
>>>> + if (policy->governor_data == dbs_data)
>>>> + return -EALREADY;
>>>> +
>>>> dbs_data->usage_count++;
>>>> policy->governor_data = dbs_data;
>>>> return 0;
>>>>
>>
>>
>>
--
Best Regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 4 of 4 ==
Date: Sat, Nov 16 2013 7:40 am
From: Lan Tianyu
Currently, governor of nonboot cpus will be put to EXIT when system suspend.
Since all these cpus will be unplugged and the governor usage_count decreases
to zero. The governor data and its sysfs interfaces will be freed or released.
This makes user config of these governors loss during suspend and resume.
This doesn't happen on the governor covering boot cpu because it isn't
unplugged during system suspend.
To fix this issue, skipping governor exit during system suspend and check
policy governor data to determine whether the governor is really needed
to be initialized when do init. If not, return EALREADY to indicate the
governor has been initialized and should do nothing. __cpufreq_governor()
convert EALREADY to 0 as return value for INIT event since governor is
still under INIT state and can do START operation.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
---
Change since v1:
Change coding style.
drivers/cpufreq/cpufreq.c | 10 +++++++---
drivers/cpufreq/cpufreq_governor.c | 13 ++++++++++++-
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..73ad593 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1239,7 +1239,7 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
- if (has_target()) {
+ if (has_target() && !frozen) {
ret = __cpufreq_governor(policy,
CPUFREQ_GOV_POLICY_EXIT);
if (ret) {
@@ -1818,9 +1818,13 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
mutex_unlock(&cpufreq_governor_lock);
}
- if (((event == CPUFREQ_GOV_POLICY_INIT) && ret) ||
- ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
+ if ((event == CPUFREQ_GOV_POLICY_INIT) && ret) {
+ module_put(policy->governor->owner);
+ if (ret == -EALREADY)
+ return 0;
+ } else if ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret) {
module_put(policy->governor->owner);
+ }
return ret;
}
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 0806c31..ddb93af 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -204,9 +204,20 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
switch (event) {
case CPUFREQ_GOV_POLICY_INIT:
+ /*
+ * In order to keep governor data across suspend/resume,
+ * Governor doesn't exit when suspend and will be
+ * reinitialized when resume. Here check policy governor
+ * data to determine whether the governor has been exited.
+ * If not, return EALREADY.
+ */
if (have_governor_per_policy()) {
- WARN_ON(dbs_data);
+ if (dbs_data)
+ return -EALREADY;
} else if (dbs_data) {
+ if (policy->governor_data == dbs_data)
+ return -EALREADY;
+
dbs_data->usage_count++;
policy->governor_data = dbs_data;
return 0;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: xen drivers fail to link on ARM with v3.12-9888-gf63c482
http://groups.google.com/group/linux.kernel/t/2b72ccf2ec8c82da?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Nov 16 2013 7:00 am
From: Josh Boyer
Hi All,
The xen-gntalloc, xen-netfront, xen-blkfront, and xen-netback drivers
fail to link on ARM today with the following error:
ERROR: "phys_to_mach" [drivers/xen/xen-gntalloc.ko] undefined!
ERROR: "phys_to_mach" [drivers/net/xen-netfront.ko] undefined!
ERROR: "phys_to_mach" [drivers/net/xen-netback/xen-netback.ko] undefined!
ERROR: "phys_to_mach" [drivers/block/xen-blkfront.ko] undefined!
This is with Linus' tree as of this morning.
I'm guessing this is because the mfn_to_pfn and pfn_to_mfn functions
are inlined and reference phys_to_mach directly, and that isn't
exported to modules. Thoughts?
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Sat, Nov 16 2013 8:40 am
From: Josh Boyer
On Sat, Nov 16, 2013 at 9:56 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> Hi All,
>
> The xen-gntalloc, xen-netfront, xen-blkfront, and xen-netback drivers
> fail to link on ARM today with the following error:
>
> ERROR: "phys_to_mach" [drivers/xen/xen-gntalloc.ko] undefined!
> ERROR: "phys_to_mach" [drivers/net/xen-netfront.ko] undefined!
> ERROR: "phys_to_mach" [drivers/net/xen-netback/xen-netback.ko] undefined!
> ERROR: "phys_to_mach" [drivers/block/xen-blkfront.ko] undefined!
>
> This is with Linus' tree as of this morning.
>
> I'm guessing this is because the mfn_to_pfn and pfn_to_mfn functions
> are inlined and reference phys_to_mach directly, and that isn't
> exported to modules. Thoughts?
The patch below seems to fix this, but I'm not sure it's the desired
approach. I added the export for mach_to_phys just in case.
josh
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index 23732cd..7772fa8 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -27,7 +27,9 @@ struct xen_p2m_entry {
rwlock_t p2m_lock;
struct rb_root phys_to_mach = RB_ROOT;
+EXPORT_SYMBOL_GPL(phys_to_mach);
static struct rb_root mach_to_phys = RB_ROOT;
+EXPORT_SYMBOL_GPL(mach_to_phys);
static int xen_add_phys_to_mach_entry(struct xen_p2m_entry *new)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: : REGRESSION: "*ERROR* Timed out waiting for forcewake old ack to clear
"
http://groups.google.com/group/linux.kernel/t/463ef67d8af2a4ae?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 7:00 am
From: Daniel Vetter
On Sat, Nov 16, 2013 at 3:39 PM, Jörg Otte <jrg.otte@gmail.com> wrote:
> 2013/11/16 Daniel Vetter <daniel.vetter@ffwll.ch>:
>> On Sat, Nov 16, 2013 at 12:28 PM, Jörg Otte <jrg.otte@gmail.com> wrote:
>>> On startup I get the following error display on the console:
>>> "*ERROR* Timed out waiting for forcewake old ack to clear"
>>>
>>> I already reported this error a year ago at the time of v3.7
>>> ( see https://lkml.org/lkml/2012/11/27/355)
>>> which was fixed later on.
>>>
>>> Now this error is back again. Kernel 3.12.0-09888-gf63c48
>>
>> Please boot with drm.debug=0xe, reproduce the issue and then attach
>> the complete dmesg (including all the boot message, so if it takes a
>> while to reproduce please grab an boot dmesg, too).
>>
>> Also adding the right mailing lists, see MAINTAINERS.
>>
>> Thanks, Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> Thanks, Jörg
Yeah, we've broken the early uncore sanitize stuff again :( I'll send
out a patch asap.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: ARM: fix /proc/$PID/stack to work on SMP
http://groups.google.com/group/linux.kernel/t/5998a790ce0f13fe?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 7:20 am
From: Russell King - ARM Linux
On Sat, Nov 16, 2013 at 10:58:44PM +0800, ivan lam wrote:
> In arm, we can't get stack info of the other tasks via
> /proc/$PID/stack file. for example:
>
> # sleep 1000 &
> # ps -ef | grep sleep
> 536 0 0:00 sleep 1000
> 538 0 0:00 grep sleep
> # cat /proc/536/stack
> [<ffffffff>] 0xffffffff
>
> If a thread was scheduled out, this proc should provide
> useful backtrace for debug. Try to unwind the stack based
> on the previous scheduled out register file whatever a
> thread is in Running state or not.
>
> After this fix, result as:
>
> # cat /proc/536/stack
> [<8003f018>] hrtimer_nanosleep+0x8c/0x108
> [<8003f134>] SyS_nanosleep+0xa0/0xb0
> [<8000e220>] ret_fast_syscall+0x0/0x30
> [<ffffffff>] 0xffffffff
>
> If a thread is Running on the oher CPUs, the result is not accurate,
> but this is acceptable. This behaviors are same as x86 and arm64 arch.
As we have people running around trying to add additional checks to
the unwinder to stop it going wrong, I've no plans to apply any patch
like this until we're more sure that it won't open up the possibility
for any user process to crash the kernel. That in itself is a massive
security issue because its an effective DoS attack.
Moreover, your emailer has totally screwed the patch, so it's impossible
to apply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: perf tip: fails to convert comm
http://groups.google.com/group/linux.kernel/t/5eff5c722c706d30?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 7:20 am
From: David Ahern
On 11/15/13, 6:02 PM, Frederic Weisbecker wrote:
> On Fri, Nov 15, 2013 at 09:29:51AM -0700, David Ahern wrote:
>> HI Frederic:
>>
>> On 11/13/13, 11:03 AM, Frederic Weisbecker wrote:
>>>
>>> I see. I can reproduce, I'll check and see what happens. It would be nice if
>>> we could have an option to dump internal perf events like comm events as well
>>> in the perf script stream.
>>
>> Any progress on a solution? This is a regression in 3.13.
>
> So the problem is that when a thread overrides its default ":%pid" comm, we forget
> to tag the thread comm as overriden. Hence, this overriden comm is not inherited on
> future forks.
>
> So here is a fix. Tell me if you see more issue, I'll cook a proper changelog and
> resend if everyting looks good.
That works for me. Thank you.
Tested-by: David Ahern <dsahern@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: cpufreq: suspend/resume governors with PM notifiers
http://groups.google.com/group/linux.kernel/t/14055e77b2ea6480?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 7:20 am
From: Viresh Kumar
On 16 November 2013 19:59, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> Well, disabling it for the whole duration of suspend/resume and/or hibernation
> may not be the right approach entirely, unless we force the pax perf of the
s/pax/max ?
> boot CPU at least in addition to that. Otherwise the latency of suspend and
> the subsequent resume will depend on what perf level the CPUs where before
> disabling the governors, which is not desirable at al.
Well that is pretty much doable.
>> And these are the notifications that we send:
>> - PM_HIBERNATION_PREPARE
>> - PM_POST_HIBERNATION
>> - PM_RESTORE_PREPARE
>> - PM_POST_RESTORE
>>
>> If I am not wrong I need to stop governors on PM_HIBERNATION_PREPARE and need to
>> start them back on: PM_POST_HIBERNATION (I am a bit confused with this one. Does
>> this POST_HIBERNATION one happens at the end of going into hibernation? or after
>> booting back? I need a notifier at the end of restore)..
>
> You'd need both PM_POST_HIBERNATION and PM_POST_RESTORE, but I wouldn't really
> like cpufreq governors to be disabled throughout the whole hibernation.
So PM_POST_HIBERNATION is called just before shutting off the system? And
PM_POST_RESTORE is called after system is resumed from saved image?
> Actually, we use CPU offline/online during system suspend/resume to avoid
> having to do stuff like this from PM notifiers.
I didn't get the logic behind this one..
> So I'd like the original problem to be addressed in a different way.
Hmm..
> PS
> The sisk.pl address will start bouncing shortly, so please replace it with
> rjw@rjwysocki.net in your address book.
Okay...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: Kernel 3.4.57: "tg3 0000:01:00.0: eth0: transmit timed out, resetting"
http://groups.google.com/group/linux.kernel/t/3f5e74e211bfbf83?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 7:20 am
From: Bjorn Helgaas
[+cc Nithin, Michael, netdev]
On Sat, Nov 16, 2013 at 7:01 AM, Urban Loesch <bind@enas.net> wrote:
> Hi,
>
> I'm running a DELL PER620 with kernel 3.4.57 an Broadcom quad-port gbit
> adapter BCM5720. 15min load-average is about 4-8.
>
> After 13 days of uptime today the machine becomes unresponsible. But after a
> couple of minutes it becomes responsible again and was rebooted (sysctl
> paremter for kernel.panic = 1) automatically. the machine is acting a
> webserver fo about 3000 virtualhosts.
>
> After searching the lofiles on remote my syslog server I found the following
> messages regarding eth0:
>
> 2013-11-16 11:43:38 [1505491.196172] tg3 0000:01:00.0: eth0: transmit timed
> out, resetting
> 2013-11-16 11:43:38 [1505491.815002] INFO: rcu_bh detected stalls on
> CPUs/tasks:
> 2013-11-16 11:43:38 [1505491.815009] 16: (1 GPs behind)
> idle=1fd/140000000000000/0
> 2013-11-16 11:43:38 [1505491.815012] (detected by 6, t=6002 jiffies)
> 2013-11-16 11:43:38 [1505491.815014] INFO: Stall ended before state dump
> start
> 2013-11-16 11:43:38 [1505492.450611] tg3 0000:01:00.0: eth0: 0x00000000:
> 0x165f14e4, 0x00100406, 0x02000000, 0x00800010
> 2013-11-16 11:43:38 [1505492.450614] tg3 0000:01:00.0: eth0: 0x00000010:
> 0xd57a000c, 0x00000000, 0xd57b000c, 0x00000000
> 2013-11-16 11:43:38 [1505492.450615] tg3 0000:01:00.0: eth0: 0x00000020:
> 0xd57c000c, 0x00000000, 0x00000000, 0x1f5b1028
> 2013-11-16 11:43:38 [1505492.450617] tg3 0000:01:00.0: eth0: 0x00000030:
> 0xd8800000, 0x00000048, 0x00000000, 0x0000010f
> 2013-11-16 11:43:38 [1505492.450619] tg3 0000:01:00.0: eth0: 0x00000040:
> 0x00000000, 0x3f000000, 0xc8035001, 0x64002008
> 2013-11-16 11:43:38 [1505492.450621] tg3 0000:01:00.0: eth0: 0x00000050:
> 0x818c5803, 0x78000000, 0x0086a005, 0x00000000
> 2013-11-16 11:43:38 [1505492.450623] tg3 0000:01:00.0: eth0: 0x00000060:
> 0x00000000, 0x00000000, 0xf0000298, 0x00380081
> 2013-11-16 11:43:38 [1505492.450624] tg3 0000:01:00.0: eth0: 0x00000070:
> 0x000710b0, 0xffcb28fa, 0x0001421c, 0x00000000
> 2013-11-16 11:43:38 [1505492.450626] tg3 0000:01:00.0: eth0: 0x00000080:
> 0x00000001, 0x00000002, 0x00000000, 0x000001d2
> 2013-11-16 11:43:38 [1505492.450628] tg3 0000:01:00.0: eth0: 0x00000090:
> 0x00000000, 0x00000000, 0x00000000, 0x000006a1
> 2013-11-16 11:43:38 [1505492.450629] tg3 0000:01:00.0: eth0: 0x000000a0:
> 0x8010ac11, 0x00000004, 0x00001004, 0x00020010
> 2013-11-16 11:43:38 [1505492.450631] tg3 0000:01:00.0: eth0: 0x000000b0:
> 0x10008d81, 0x0010242e, 0x0004cc22, 0x10120040
> 2013-11-16 11:43:38 [1505492.450633] tg3 0000:01:00.0: eth0: 0x000000d0:
> 0x0000001f, 0x00000006, 0x00000000, 0x00000001
> 2013-11-16 11:43:38 [1505492.450635] tg3 0000:01:00.0: eth0: 0x000000f0:
> 0x00000000, 0x05720000, 0x00000000, 0xbec733be
> 2013-11-16 11:43:38 [1505492.450637] tg3 0000:01:00.0: eth0: 0x00000100:
> 0x13c10001, 0x00000000, 0x00018000, 0x000e7030
> 2013-11-16 11:43:38 [1505492.450638] tg3 0000:01:00.0: eth0: 0x00000110:
> 0x00002000, 0x000031c0, 0x000000a0, 0x00000000
> 2013-11-16 11:43:38 [1505492.450640] tg3 0000:01:00.0: eth0: 0x00000130:
> 0x00000000, 0x00000000, 0x00000000, 0x15010003
> 2013-11-16 11:43:38 [1505492.450642] tg3 0000:01:00.0: eth0: 0x00000140:
> 0x1c3f67fa, 0x000090b1, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450643] tg3 0000:01:00.0: eth0: 0x00000150:
> 0x16010004, 0x00000000, 0x0007811b, 0x00000001
> 2013-11-16 11:43:38 [1505492.450645] tg3 0000:01:00.0: eth0: 0x00000160:
> 0x00010002, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450647] tg3 0000:01:00.0: eth0: 0x00000170:
> 0x00000000, 0x800000ff, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450648] tg3 0000:01:00.0: eth0: 0x00000200:
> 0x00000000, 0x3f000000, 0x00000000, 0xfb000000
> 2013-11-16 11:43:38 [1505492.450650] tg3 0000:01:00.0: eth0: 0x00000210:
> 0x00000000, 0x0d000000, 0x00000000, 0xa7000000
> 2013-11-16 11:43:38 [1505492.450652] tg3 0000:01:00.0: eth0: 0x00000220:
> 0x00000000, 0x00000001, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450653] tg3 0000:01:00.0: eth0: 0x00000260:
> 0x00000000, 0x00000000, 0x00000000, 0x000006a1
> 2013-11-16 11:43:38 [1505492.450655] tg3 0000:01:00.0: eth0: 0x00000280:
> 0x00000000, 0x000001d2, 0x00000000, 0x00000d73
> 2013-11-16 11:43:38 [1505492.450657] tg3 0000:01:00.0: eth0: 0x00000290:
> 0x00000000, 0x000004df, 0x00000000, 0x000001b5
> 2013-11-16 11:43:38 [1505492.450659] tg3 0000:01:00.0: eth0: 0x00000300:
> 0x0000010d, 0x000001df, 0x000000bb, 0x00000035
> 2013-11-16 11:43:38 [1505492.450660] tg3 0000:01:00.0: eth0: 0x00000400:
> 0x18e04808, 0x00400000, 0x00001000, 0x00000880
> 2013-11-16 11:43:38 [1505492.450662] tg3 0000:01:00.0: eth0: 0x00000410:
> 0x000090b1, 0x1c3f67fa, 0x000090b1, 0x1c3f67fa
> 2013-11-16 11:43:38 [1505492.450664] tg3 0000:01:00.0: eth0: 0x00000420:
> 0x000090b1, 0x1c3f67fa, 0x000090b1, 0x1c3f67fa
> 2013-11-16 11:43:38 [1505492.450666] tg3 0000:01:00.0: eth0: 0x00000430:
> 0x00000400, 0x00000000, 0x000002f4, 0x000005f2
> 2013-11-16 11:43:38 [1505492.450667] tg3 0000:01:00.0: eth0: 0x00000440:
> 0x00000000, 0x00000000, 0x00000000, 0x04384400
> 2013-11-16 11:43:38 [1505492.450669] tg3 0000:01:00.0: eth0: 0x00000450:
> 0x00000001, 0x00008000, 0x00000000, 0x00000102
> 2013-11-16 11:43:38 [1505492.450671] tg3 0000:01:00.0: eth0: 0x00000460:
> 0x00000008, 0x00002620, 0x01ff0002, 0x00000000
> 2013-11-16 11:43:38 [1505492.450672] tg3 0000:01:00.0: eth0: 0x00000470:
> 0x80000200, 0x00c10000, 0x01000000, 0xc0000000
> 2013-11-16 11:43:38 [1505492.450674] tg3 0000:01:00.0: eth0: 0x00000480:
> 0x42000000, 0x7fffffff, 0x06000004, 0x7fffffff
> 2013-11-16 11:43:38 [1505492.450676] tg3 0000:01:00.0: eth0: 0x00000500:
> 0x00000008, 0x00000002, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450677] tg3 0000:01:00.0: eth0: 0x00000540:
> 0x0000e0db, 0x551fe086, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450679] tg3 0000:01:00.0: eth0: 0x00000590:
> 0x00e00000, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450681] tg3 0000:01:00.0: eth0: 0x000005b0:
> 0x00000000, 0x00000008, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450682] tg3 0000:01:00.0: eth0: 0x000005c0:
> 0x52ad2878, 0x40ae6aee, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450684] tg3 0000:01:00.0: eth0: 0x00000600:
> 0xffffffff, 0x00f80011, 0x00000000, 0x00001f04
> 2013-11-16 11:43:38 [1505492.450686] tg3 0000:01:00.0: eth0: 0x00000610:
> 0xffffffff, 0x00000000, 0x07c00004, 0x00000000
> 2013-11-16 11:43:38 [1505492.450687] tg3 0000:01:00.0: eth0: 0x00000620:
> 0x00000040, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450689] tg3 0000:01:00.0: eth0: 0x00000630:
> 0x01230123, 0x01230123, 0x01230123, 0x01230123
> 2013-11-16 11:43:38 [1505492.450691] tg3 0000:01:00.0: eth0: 0x00000640:
> 0x01230123, 0x01230123, 0x01230123, 0x01230123
> 2013-11-16 11:43:38 [1505492.450693] tg3 0000:01:00.0: eth0: 0x00000650:
> 0x01230123, 0x01230123, 0x01230123, 0x01230123
> 2013-11-16 11:43:38 [1505492.450694] tg3 0000:01:00.0: eth0: 0x00000660:
> 0x01230123, 0x01230123, 0x01230123, 0x01230123
> 2013-11-16 11:43:38 [1505492.450696] tg3 0000:01:00.0: eth0: 0x00000670:
> 0x5f865437, 0xe4ac62cc, 0x50103a45, 0x36621985
> 2013-11-16 11:43:38 [1505492.450698] tg3 0000:01:00.0: eth0: 0x00000680:
> 0xbf14c0e8, 0x1bc27a1e, 0x84f4b556, 0x094ea6fe
> 2013-11-16 11:43:38 [1505492.450699] tg3 0000:01:00.0: eth0: 0x00000690:
> 0x7dda01e7, 0xc04d7481, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450701] tg3 0000:01:00.0: eth0: 0x000006c0:
> 0x00000000, 0x00000000, 0x04000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450703] tg3 0000:01:00.0: eth0: 0x000006d0:
> 0x00000001, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450705] tg3 0000:01:00.0: eth0: 0x00000800:
> 0x000008a6, 0xffffffff, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450706] tg3 0000:01:00.0: eth0: 0x00000810:
> 0x00000000, 0xffffffff, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450708] tg3 0000:01:00.0: eth0: 0x00000820:
> 0x00000000, 0x00000000, 0xffffffff, 0x00000000
> 2013-11-16 11:43:38 [1505492.450710] tg3 0000:01:00.0: eth0: 0x00000830:
> 0x00000000, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-16 11:43:38 [1505492.450711] tg3 0000:01:00.0: eth0: 0x00000840:
> 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-16 11:43:38 [1505492.450713] tg3 0000:01:00.0: eth0: 0x00000850:
> 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-16 11:43:38 [1505492.450715] tg3 0000:01:00.0: eth0: 0x00000860:
> 0xffffffff, 0xffffffff, 0xffffffff, 0x00000009
> 2013-11-16 11:43:38 [1505492.450716] tg3 0000:01:00.0: eth0: 0x00000880:
> 0x00000963, 0x019454f2, 0x00000000, 0x0000000a
> 2013-11-16 11:43:38 [1505492.450718] tg3 0000:01:00.0: eth0: 0x000008f0:
> 0x00000001, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450720] tg3 0000:01:00.0: eth0: 0x00000900:
> 0x00006c19, 0xffffffff, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450721] tg3 0000:01:00.0: eth0: 0x00000910:
> 0x00000000, 0xffffffff, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450723] tg3 0000:01:00.0: eth0: 0x00000920:
> 0x00000000, 0x00000000, 0xffffffff, 0x00000000
> 2013-11-16 11:43:38 [1505492.450725] tg3 0000:01:00.0: eth0: 0x00000930:
> 0x00000000, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-16 11:43:38 [1505492.450726] tg3 0000:01:00.0: eth0: 0x00000940:
> 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-16 11:43:38 [1505492.450728] tg3 0000:01:00.0: eth0: 0x00000950:
> 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-16 11:43:38 [1505492.450730] tg3 0000:01:00.0: eth0: 0x00000960:
> 0xffffffff, 0xffffffff, 0xffffffff, 0x00000071
> 2013-11-16 11:43:38 [1505492.450732] tg3 0000:01:00.0: eth0: 0x00000980:
> 0x00005e7f, 0x00000000, 0x00000000, 0x00000097
> 2013-11-16 11:43:38 [1505492.450733] tg3 0000:01:00.0: eth0: 0x00000990:
> 0x00000003, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450735] tg3 0000:01:00.0: eth0: 0x00000a00:
> 0xf428f606, 0x1613e7b3, 0x00000004, 0x00000000
> 2013-11-16 11:43:38 [1505492.450737] tg3 0000:01:00.0: eth0: 0x00000a20:
> 0x51b3edd8, 0x13a2f3e5, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450738] tg3 0000:01:00.0: eth0: 0x00000a40:
> 0x1bb17940, 0x1353913e, 0x00000002, 0x000000bb
> 2013-11-16 11:43:38 [1505492.450740] tg3 0000:01:00.0: eth0: 0x00000a60:
> 0xb79007bb, 0x13f86e55, 0x00000006, 0x00000000
> 2013-11-16 11:43:38 [1505492.450742] tg3 0000:01:00.0: eth0: 0x00000c00:
> 0x0000000a, 0x00000000, 0x00000003, 0x00000001
> 2013-11-16 11:43:38 [1505492.450743] tg3 0000:01:00.0: eth0: 0x00000c10:
> 0x00000000, 0x00000000, 0x00000000, 0x00f20000
> 2013-11-16 11:43:38 [1505492.450745] tg3 0000:01:00.0: eth0: 0x00000c80:
> 0x50438596, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450747] tg3 0000:01:00.0: eth0: 0x00000ce0:
> 0xf2cfb402, 0x0000000b, 0x000000f2, 0x00040028
> 2013-11-16 11:43:38 [1505492.450748] tg3 0000:01:00.0: eth0: 0x00000cf0:
> 0x00000000, 0x5000005f, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450750] tg3 0000:01:00.0: eth0: 0x00001000:
> 0x00000002, 0x00000000, 0xa000c4c6, 0x00000000
> 2013-11-16 11:43:38 [1505492.450752] tg3 0000:01:00.0: eth0: 0x00001010:
> 0x01df1df1, 0x0000c4c6, 0x00000000, 0x00000000
> 2013-11-16 11:43:38 [1505492.450754] tg3 0000:01:00.0: eth0: 0x00001400:
> 0x00000006, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450755] tg3 0000:01:00.0: eth0: 0x00001440:
> 0x000001df, 0x0000010d, 0x00000035, 0x000000bb
> 2013-11-16 11:43:39 [1505492.450757] tg3 0000:01:00.0: eth0: 0x00001480:
> 0x00002211, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450759] tg3 0000:01:00.0: eth0: 0x00001800:
> 0x00000036, 0x00000000, 0x000001df, 0x0000010d
> 2013-11-16 11:43:39 [1505492.450760] tg3 0000:01:00.0: eth0: 0x00001810:
> 0x00000035, 0x000000bb, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450762] tg3 0000:01:00.0: eth0: 0x00001830:
> 0x00000000, 0x00000000, 0x00000000, 0xf8354000
> 2013-11-16 11:43:39 [1505492.450764] tg3 0000:01:00.0: eth0: 0x00001840:
> 0xf82f8000, 0x00000017, 0x00000202, 0xc0000000
> 2013-11-16 11:43:39 [1505492.450766] tg3 0000:01:00.0: eth0: 0x00001850:
> 0x0000001f, 0x00000000, 0x000041e0, 0x010d01df
> 2013-11-16 11:43:39 [1505492.450767] tg3 0000:01:00.0: eth0: 0x00001860:
> 0x0100d200, 0x00000000, 0xf8355de0, 0x00000017
> 2013-11-16 11:43:39 [1505492.450769] tg3 0000:01:00.0: eth0: 0x00001c00:
> 0x00000002, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450771] tg3 0000:01:00.0: eth0: 0x00002000:
> 0x00000002, 0x00000010, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450773] tg3 0000:01:00.0: eth0: 0x00002010:
> 0x00000181, 0x00000001, 0x00780003, 0x00000000
> 2013-11-16 11:43:39 [1505492.450775] tg3 0000:01:00.0: eth0: 0x00002100:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450776] tg3 0000:01:00.0: eth0: 0x00002110:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450778] tg3 0000:01:00.0: eth0: 0x00002120:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450780] tg3 0000:01:00.0: eth0: 0x00002130:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450781] tg3 0000:01:00.0: eth0: 0x00002140:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450783] tg3 0000:01:00.0: eth0: 0x00002150:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450784] tg3 0000:01:00.0: eth0: 0x00002160:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450786] tg3 0000:01:00.0: eth0: 0x00002170:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450788] tg3 0000:01:00.0: eth0: 0x00002180:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450789] tg3 0000:01:00.0: eth0: 0x00002190:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450791] tg3 0000:01:00.0: eth0: 0x000021a0:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450793] tg3 0000:01:00.0: eth0: 0x000021b0:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450794] tg3 0000:01:00.0: eth0: 0x000021c0:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450796] tg3 0000:01:00.0: eth0: 0x000021d0:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450798] tg3 0000:01:00.0: eth0: 0x000021e0:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450799] tg3 0000:01:00.0: eth0: 0x000021f0:
> 0x000e1710, 0x000e1710, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450801] tg3 0000:01:00.0: eth0: 0x00002200:
> 0x3d943ab4, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450803] tg3 0000:01:00.0: eth0: 0x00002250:
> 0x00004e57, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450804] tg3 0000:01:00.0: eth0: 0x00002400:
> 0x00010012, 0x00000000, 0x00240001, 0x00000000
> 2013-11-16 11:43:39 [1505492.450806] tg3 0000:01:00.0: eth0: 0x00002410:
> 0x0000000f, 0x00005d00, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450808] tg3 0000:01:00.0: eth0: 0x00002440:
> 0x00000000, 0x00000000, 0x00000002, 0x00044400
> 2013-11-16 11:43:39 [1505492.450809] tg3 0000:01:00.0: eth0: 0x00002450:
> 0x00000017, 0xf6bb0000, 0x08001800, 0x00040000
> 2013-11-16 11:43:39 [1505492.450811] tg3 0000:01:00.0: eth0: 0x00002470:
> 0x00000000, 0x00000684, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450813] tg3 0000:01:00.0: eth0: 0x00002500:
> 0x00000000, 0x00000000, 0x00000002, 0x00044800
> 2013-11-16 11:43:39 [1505492.450815] tg3 0000:01:00.0: eth0: 0x00002510:
> 0x00000000, 0x00000000, 0x00000002, 0x00040400
> 2013-11-16 11:43:39 [1505492.450816] tg3 0000:01:00.0: eth0: 0x00002520:
> 0x00000000, 0x00000000, 0x00000002, 0x00044c00
> 2013-11-16 11:43:39 [1505492.450818] tg3 0000:01:00.0: eth0: 0x00002530:
> 0x00000000, 0x00000000, 0x00000002, 0x00040800
> 2013-11-16 11:43:39 [1505492.450819] tg3 0000:01:00.0: eth0: 0x00002540:
> 0x00000000, 0x00000000, 0x00000002, 0x00045000
> 2013-11-16 11:43:39 [1505492.450821] tg3 0000:01:00.0: eth0: 0x00002550:
> 0x00000000, 0x00000000, 0x00000002, 0x00040c00
> 2013-11-16 11:43:39 [1505492.450823] tg3 0000:01:00.0: eth0: 0x00002560:
> 0x00000000, 0x00000000, 0x00000002, 0x00045400
> 2013-11-16 11:43:39 [1505492.450824] tg3 0000:01:00.0: eth0: 0x00002570:
> 0x00000000, 0x00000000, 0x00000002, 0x00041000
> 2013-11-16 11:43:39 [1505492.450826] tg3 0000:01:00.0: eth0: 0x00002580:
> 0x00000000, 0x00000000, 0x00000002, 0x00045800
> 2013-11-16 11:43:39 [1505492.450828] tg3 0000:01:00.0: eth0: 0x00002590:
> 0x00000000, 0x00000000, 0x00000002, 0x00041400
> 2013-11-16 11:43:39 [1505492.450829] tg3 0000:01:00.0: eth0: 0x000025a0:
> 0x00000000, 0x00000000, 0x00000002, 0x00045c00
> 2013-11-16 11:43:39 [1505492.450831] tg3 0000:01:00.0: eth0: 0x000025b0:
> 0x00000000, 0x00000000, 0x00000002, 0x00041800
> 2013-11-16 11:43:39 [1505492.450833] tg3 0000:01:00.0: eth0: 0x000025c0:
> 0x00000000, 0x00000000, 0x00000002, 0x00046000
> 2013-11-16 11:43:39 [1505492.450834] tg3 0000:01:00.0: eth0: 0x000025d0:
> 0x00000000, 0x00000000, 0x00000002, 0x00041c00
> 2013-11-16 11:43:39 [1505492.450836] tg3 0000:01:00.0: eth0: 0x000025e0:
> 0x00000000, 0x00000000, 0x00000002, 0x00046400
> 2013-11-16 11:43:39 [1505492.450838] tg3 0000:01:00.0: eth0: 0x000025f0:
> 0x00000000, 0x00000000, 0x00000002, 0x00042000
> 2013-11-16 11:43:39 [1505492.450839] tg3 0000:01:00.0: eth0: 0x00002600:
> 0x00000000, 0x00000000, 0x00000002, 0x00046800
> 2013-11-16 11:43:39 [1505492.450841] tg3 0000:01:00.0: eth0: 0x00002610:
> 0x00000000, 0x00000000, 0x00000002, 0x00042400
> 2013-11-16 11:43:39 [1505492.450843] tg3 0000:01:00.0: eth0: 0x00002620:
> 0x00000000, 0x00000000, 0x00000002, 0x00046c00
> 2013-11-16 11:43:39 [1505492.450844] tg3 0000:01:00.0: eth0: 0x00002630:
> 0x00000000, 0x00000000, 0x00000002, 0x00042800
> 2013-11-16 11:43:39 [1505492.450846] tg3 0000:01:00.0: eth0: 0x00002640:
> 0x00000000, 0x00000000, 0x00000002, 0x00047000
> 2013-11-16 11:43:39 [1505492.450848] tg3 0000:01:00.0: eth0: 0x00002650:
> 0x00000000, 0x00000000, 0x00000002, 0x00042c00
> 2013-11-16 11:43:39 [1505492.450849] tg3 0000:01:00.0: eth0: 0x00002660:
> 0x00000000, 0x00000000, 0x00000002, 0x00047400
> 2013-11-16 11:43:39 [1505492.450851] tg3 0000:01:00.0: eth0: 0x00002670:
> 0x00000000, 0x00000000, 0x00000002, 0x00043000
> 2013-11-16 11:43:39 [1505492.450852] tg3 0000:01:00.0: eth0: 0x00002680:
> 0x00000000, 0x00000000, 0x00000002, 0x00047800
> 2013-11-16 11:43:39 [1505492.450854] tg3 0000:01:00.0: eth0: 0x00002690:
> 0x00000000, 0x00000000, 0x00000002, 0x00043400
> 2013-11-16 11:43:39 [1505492.450856] tg3 0000:01:00.0: eth0: 0x000026a0:
> 0x00000000, 0x00000000, 0x00000002, 0x00047c00
> 2013-11-16 11:43:39 [1505492.450857] tg3 0000:01:00.0: eth0: 0x000026b0:
> 0x00000000, 0x00000000, 0x00000002, 0x00043800
> 2013-11-16 11:43:39 [1505492.450859] tg3 0000:01:00.0: eth0: 0x000026c0:
> 0x00000000, 0x00000000, 0x00000002, 0x00048000
> 2013-11-16 11:43:39 [1505492.450861] tg3 0000:01:00.0: eth0: 0x000026d0:
> 0x00000000, 0x00000000, 0x00000002, 0x00043c00
> 2013-11-16 11:43:39 [1505492.450862] tg3 0000:01:00.0: eth0: 0x000026e0:
> 0x00000000, 0x00000000, 0x00000002, 0x00048400
> 2013-11-16 11:43:39 [1505492.450864] tg3 0000:01:00.0: eth0: 0x000026f0:
> 0x00000000, 0x00000000, 0x00000002, 0x00044000
> 2013-11-16 11:43:39 [1505492.450866] tg3 0000:01:00.0: eth0: 0x00002800:
> 0x00000006, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450868] tg3 0000:01:00.0: eth0: 0x00002c00:
> 0x00000006, 0x00000000, 0x00000000, 0x00000699
> 2013-11-16 11:43:39 [1505492.450869] tg3 0000:01:00.0: eth0: 0x00002c10:
> 0x00000000, 0x00000000, 0x00000019, 0x0000000c
> 2013-11-16 11:43:39 [1505492.450871] tg3 0000:01:00.0: eth0: 0x00002c20:
> 0x00000002, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450873] tg3 0000:01:00.0: eth0: 0x00002d00:
> 0x00000080, 0x00000040, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450874] tg3 0000:01:00.0: eth0: 0x00003000:
> 0x00000006, 0x00000000, 0x00000000, 0x00000699
> 2013-11-16 11:43:39 [1505492.450876] tg3 0000:01:00.0: eth0: 0x00003400:
> 0x00000004, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450878] tg3 0000:01:00.0: eth0: 0x00003600:
> 0x00004600, 0x00170000, 0x00110000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450880] tg3 0000:01:00.0: eth0: 0x00003610:
> 0x00170000, 0x00000000, 0x00130000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450881] tg3 0000:01:00.0: eth0: 0x00003620:
> 0x00110011, 0x00000000, 0x00000000, 0x00032080
> 2013-11-16 11:43:39 [1505492.450883] tg3 0000:01:00.0: eth0: 0x00003630:
> 0x00800000, 0x87748774, 0x02c01000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450885] tg3 0000:01:00.0: eth0: 0x00003640:
> 0x00000000, 0x00000000, 0x00000020, 0x00000019
> 2013-11-16 11:43:39 [1505492.450886] tg3 0000:01:00.0: eth0: 0x00003650:
> 0x00000171, 0x000f03ff, 0x05720000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450888] tg3 0000:01:00.0: eth0: 0x00003660:
> 0x00000000, 0x00000000, 0x02000000, 0x00000202
> 2013-11-16 11:43:39 [1505492.450890] tg3 0000:01:00.0: eth0: 0x00003670:
> 0x00000000, 0xfeffffe3, 0x00000000, 0x00000020
> 2013-11-16 11:43:39 [1505492.450891] tg3 0000:01:00.0: eth0: 0x00003680:
> 0x30018010, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450893] tg3 0000:01:00.0: eth0: 0x000036a0:
> 0x000001a0, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450895] tg3 0000:01:00.0: eth0: 0x000036b0:
> 0x0010034c, 0x07ff07ff, 0x07ff07ff, 0x01000004
> 2013-11-16 11:43:39 [1505492.450896] tg3 0000:01:00.0: eth0: 0x000036c0:
> 0xffffffff, 0x00000000, 0x00000000, 0x8c58c9dc
> 2013-11-16 11:43:39 [1505492.450898] tg3 0000:01:00.0: eth0: 0x000036d0:
> 0x0000019d, 0x00000000, 0x00000000, 0x000048ef
> 2013-11-16 11:43:39 [1505492.450900] tg3 0000:01:00.0: eth0: 0x000036f0:
> 0x00000000, 0x00000000, 0x00000000, 0x00010801
> 2013-11-16 11:43:39 [1505492.450902] tg3 0000:01:00.0: eth0: 0x00003800:
> 0x00000001, 0x00000000, 0x0000000e, 0x0516028b
> 2013-11-16 11:43:39 [1505492.450903] tg3 0000:01:00.0: eth0: 0x00003810:
> 0x0000002f, 0x000000ba, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450905] tg3 0000:01:00.0: eth0: 0x00003c00:
> 0x00000306, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450907] tg3 0000:01:00.0: eth0: 0x00003c30:
> 0x00000000, 0x00000000, 0x00000017, 0xfa561000
> 2013-11-16 11:43:39 [1505492.450908] tg3 0000:01:00.0: eth0: 0x00003c40:
> 0x00000000, 0x00000b00, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450910] tg3 0000:01:00.0: eth0: 0x00003c50:
> 0x00000000, 0x00000699, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450912] tg3 0000:01:00.0: eth0: 0x00003c80:
> 0x000001d6, 0x00000d76, 0x000004e6, 0x00000267
> 2013-11-16 11:43:39 [1505492.450913] tg3 0000:01:00.0: eth0: 0x00003cc0:
> 0x000001ea, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450915] tg3 0000:01:00.0: eth0: 0x00003cd0:
> 0x00000000, 0x0000000f, 0x00000000, 0x00000000
> 2013-11-16 11:43:39 [1505492.450917] tg3 0000:01:00.0: eth0: 0x00003d00:
> 0x00000017, 0xf7fe1000, 0x00000017, 0xf73b8000
> 2013-11-16 11:43:39 [1505492.450918] tg3 0000:01:00.0: eth0: 0x00003d10:
> 0x00000017, 0xf7079000, 0x00000017, 0xf900c000
> 2013-11-16 11:43:39 [1505492.450920] tg3 0000:01:00.0: eth0: 0x00003d80:
> 0x00000014, 0x00000048, 0x00000005, 0x00000035
> 2013-11-16 11:43:39 [1505492.450922] tg3 0000:01:00.0: eth0: 0x00003d90:
> 0x00000005, 0x00000005, 0x00000014, 0x00000048
> 2013-11-16 11:43:39 [1505492.450924] tg3 0000:01:00.0: eth0: 0x00003da0:
> 0x00000005, 0x00000035, 0x00000005, 0x00000005
> 2013-11-16 11:43:40 [1505492.450925] tg3 0000:01:00.0: eth0: 0x00003db0:
> 0x00000014, 0x00000048, 0x00000005, 0x00000035
> 2013-11-16 11:43:40 [1505492.450927] tg3 0000:01:00.0: eth0: 0x00003dc0:
> 0x00000005, 0x00000005, 0x00000014, 0x00000048
> 2013-11-16 11:43:40 [1505492.450929] tg3 0000:01:00.0: eth0: 0x00003dd0:
> 0x00000005, 0x00000035, 0x00000005, 0x00000005
> 2013-11-16 11:43:40 [1505492.450930] tg3 0000:01:00.0: eth0: 0x00003f00:
> 0x00000000, 0x0000010d, 0x00000035, 0x000000bb
> 2013-11-16 11:43:40 [1505492.450932] tg3 0000:01:00.0: eth0: 0x00003fc0:
> 0x001e87b9, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.450934] tg3 0000:01:00.0: eth0: 0x00004000:
> 0x00000002, 0x00000000, 0x0012140b, 0x00143a42
> 2013-11-16 11:43:40 [1505492.450936] tg3 0000:01:00.0: eth0: 0x00004010:
> 0x00000000, 0x00201012, 0x00000490, 0x02005422
> 2013-11-16 11:43:40 [1505492.450937] tg3 0000:01:00.0: eth0: 0x00004020:
> 0x00000000, 0x00000000, 0x00000010, 0x00000000
> 2013-11-16 11:43:40 [1505492.450939] tg3 0000:01:00.0: eth0: 0x00004030:
> 0x00000010, 0x00806510, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.450940] tg3 0000:01:00.0: eth0: 0x00004040:
> 0x00000000, 0x00000000, 0x01085220, 0x00000000
> 2013-11-16 11:43:40 [1505492.450942] tg3 0000:01:00.0: eth0: 0x00004050:
> 0x00000000, 0x00000000, 0x0033a010, 0x004d7002
> 2013-11-16 11:43:40 [1505492.450944] tg3 0000:01:00.0: eth0: 0x00004060:
> 0x004e3000, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.450946] tg3 0000:01:00.0: eth0: 0x00004400:
> 0x00000016, 0x00000000, 0x00010000, 0x0000a000
> 2013-11-16 11:43:40 [1505492.450947] tg3 0000:01:00.0: eth0: 0x00004410:
> 0x00000000, 0x0000002a, 0x000000a0, 0x00000000
> 2013-11-16 11:43:40 [1505492.450949] tg3 0000:01:00.0: eth0: 0x00004420:
> 0x0000003d, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.450951] tg3 0000:01:00.0: eth0: 0x00004440:
> 0x00000000, 0x00000000, 0x00000000, 0x00000804
> 2013-11-16 11:43:40 [1505492.450952] tg3 0000:01:00.0: eth0: 0x00004450:
> 0x00100538, 0x013b0003, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.450954] tg3 0000:01:00.0: eth0: 0x00004800:
> 0x380303fe, 0x00000000, 0x00000000, 0x00000120
> 2013-11-16 11:43:40 [1505492.450956] tg3 0000:01:00.0: eth0: 0x00004810:
> 0x00000000, 0x0000000a, 0x00689c74, 0x00001514
> 2013-11-16 11:43:40 [1505492.450958] tg3 0000:01:00.0: eth0: 0x00004820:
> 0x000000e3, 0x00000000, 0xf0330000, 0x22ee9ae8
> 2013-11-16 11:43:40 [1505492.450959] tg3 0000:01:00.0: eth0: 0x00004830:
> 0x00000000, 0x000002b4, 0x000002b4, 0x00000000
> 2013-11-16 11:43:40 [1505492.450961] tg3 0000:01:00.0: eth0: 0x00004840:
> 0x00e18278, 0x00e18278, 0x000e2200, 0xe3426024
> 2013-11-16 11:43:40 [1505492.450963] tg3 0000:01:00.0: eth0: 0x00004850:
> 0x21cb6453, 0x702305ea, 0xd7d6d7d6, 0x00000000
> 2013-11-16 11:43:40 [1505492.450964] tg3 0000:01:00.0: eth0: 0x00004860:
> 0x000000e3, 0x11283020, 0x00100800, 0xf3000008
> 2013-11-16 11:43:40 [1505492.450966] tg3 0000:01:00.0: eth0: 0x00004870:
> 0x05ea0080, 0x003e1820, 0x003e1820, 0x00000000
> 2013-11-16 11:43:40 [1505492.450968] tg3 0000:01:00.0: eth0: 0x00004880:
> 0x0000e0db, 0x551fe086, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.450970] tg3 0000:01:00.0: eth0: 0x00004900:
> 0x28190404, 0x00305407, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.450971] tg3 0000:01:00.0: eth0: 0x00004910:
> 0x000f001c, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.450973] tg3 0000:01:00.0: eth0: 0x00004a00:
> 0x180303fe, 0x00100000, 0x00100010, 0x963b0000
> 2013-11-16 11:43:40 [1505492.450975] tg3 0000:01:00.0: eth0: 0x00004a10:
> 0xf8355e60, 0x008ca924, 0x00100012, 0x00000000
> 2013-11-16 11:43:40 [1505492.450976] tg3 0000:01:00.0: eth0: 0x00004a20:
> 0x00000000, 0x00000010, 0xf02c0000, 0xf8355ea0
> 2013-11-16 11:43:40 [1505492.450978] tg3 0000:01:00.0: eth0: 0x00004a30:
> 0x00000000, 0x00000032, 0x00000032, 0x00000000
> 2013-11-16 11:43:40 [1505492.450980] tg3 0000:01:00.0: eth0: 0x00004a40:
> 0xf8355e50, 0xf8355e60, 0xf8355e70, 0xf8355e40
> 2013-11-16 11:43:40 [1505492.450981] tg3 0000:01:00.0: eth0: 0x00004a50:
> 0x00100010, 0x00100010, 0x00100010, 0x00100010
> 2013-11-16 11:43:40 [1505492.450983] tg3 0000:01:00.0: eth0: 0x00004a70:
> 0x28190404, 0x00305407, 0x000f001c, 0x00000000
> 2013-11-16 11:43:40 [1505492.450985] tg3 0000:01:00.0: eth0: 0x00004b00:
> 0x180303fe, 0x00f30003, 0x30000000, 0x00f30120
> 2013-11-16 11:43:40 [1505492.450987] tg3 0000:01:00.0: eth0: 0x00004b10:
> 0x00f20040, 0x00f00003, 0x00f3dc78, 0x00000010
> 2013-11-16 11:43:40 [1505492.450988] tg3 0000:01:00.0: eth0: 0x00004b20:
> 0x00000003, 0x02000000, 0xd6aa1001, 0x0ff300f8
> 2013-11-16 11:43:40 [1505492.450990] tg3 0000:01:00.0: eth0: 0x00004b30:
> 0xd6aa1401, 0x0ff300f8, 0xd6aa0801, 0x0ff200f8
> 2013-11-16 11:43:40 [1505492.450992] tg3 0000:01:00.0: eth0: 0x00004b40:
> 0xd6aa0c01, 0x0ff000f8, 0x0101d7d7, 0x60603535
> 2013-11-16 11:43:40 [1505492.450994] tg3 0000:01:00.0: eth0: 0x00004b50:
> 0xf0330000, 0xd6aa10f8, 0xaf100000, 0x03000002
> 2013-11-16 11:43:40 [1505492.450996] tg3 0000:01:00.0: eth0: 0x00004b60:
> 0xf0330000, 0xd6aa14f8, 0xaf100000, 0x400001ea
> 2013-11-16 11:43:40 [1505492.450997] tg3 0000:01:00.0: eth0: 0x00004b70:
> 0xf0330000, 0xd6aa08f8, 0xaf100000, 0x000000ff
> 2013-11-16 11:43:40 [1505492.450999] tg3 0000:01:00.0: eth0: 0x00004b80:
> 0x00000003, 0x11283020, 0x00100800, 0xf3000008
> 2013-11-16 11:43:40 [1505492.451001] tg3 0000:01:00.0: eth0: 0x00004b90:
> 0x05ea0080, 0x28190404, 0x00305407, 0x000f001c
> 2013-11-16 11:43:40 [1505492.451003] tg3 0000:01:00.0: eth0: 0x00004ba0:
> 0x00f00092, 0x00000003, 0x11283020, 0x000f001c
> 2013-11-16 11:43:40 [1505492.451004] tg3 0000:01:00.0: eth0: 0x00004bb0:
> 0xd6aa0001, 0xd6aa0401, 0xf2cfd001, 0xf2cfb401
> 2013-11-16 11:43:40 [1505492.451006] tg3 0000:01:00.0: eth0: 0x00004bc0:
> 0xd6aa1002, 0xd6aa1402, 0xd6aa0802, 0xd6aa0c02
> 2013-11-16 11:43:40 [1505492.451008] tg3 0000:01:00.0: eth0: 0x00004bd0:
> 0xd6aa0002, 0xd6aa0402, 0xf2cfd002, 0xf2cfb402
> 2013-11-16 11:43:40 [1505492.451009] tg3 0000:01:00.0: eth0: 0x00004be0:
> 0x00f300f3, 0x00f000f2, 0x00f300f2, 0x00f000f1
> 2013-11-16 11:43:40 [1505492.451011] tg3 0000:01:00.0: eth0: 0x00004bf0:
> 0xf0330000, 0xd6aa0cf8, 0xaf0f0000, 0x0000ffff
> 2013-11-16 11:43:40 [1505492.451013] tg3 0000:01:00.0: eth0: 0x00004c00:
> 0x200003fe, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451014] tg3 0000:01:00.0: eth0: 0x00004c10:
> 0x0000003f, 0x00000000, 0x00000006, 0x00000000
> 2013-11-16 11:43:40 [1505492.451016] tg3 0000:01:00.0: eth0: 0x00004c20:
> 0x00000000, 0x00000000, 0x00000000, 0x00000006
> 2013-11-16 11:43:40 [1505492.451018] tg3 0000:01:00.0: eth0: 0x00004c30:
> 0x00000000, 0x035d8000, 0x00108000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451020] tg3 0000:01:00.0: eth0: 0x00004c40:
> 0x00000020, 0x00000000, 0x001d0020, 0x00140020
> 2013-11-16 11:43:40 [1505492.451021] tg3 0000:01:00.0: eth0: 0x00004c50:
> 0xe5d751d5, 0x001d5266, 0x674e6d76, 0x63193f3f
> 2013-11-16 11:43:40 [1505492.451023] tg3 0000:01:00.0: eth0: 0x00004c60:
> 0x00000020, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451025] tg3 0000:01:00.0: eth0: 0x00005000:
> 0x00009800, 0x80004000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451026] tg3 0000:01:00.0: eth0: 0x00005010:
> 0x00000000, 0x00000000, 0x00000000, 0x08001fc0
> 2013-11-16 11:43:40 [1505492.451028] tg3 0000:01:00.0: eth0: 0x00005020:
> 0x00021f02, 0x00000000, 0x00000000, 0x40000020
> 2013-11-16 11:43:40 [1505492.451030] tg3 0000:01:00.0: eth0: 0x00005030:
> 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451031] tg3 0000:01:00.0: eth0: 0x00005040:
> 0x00000000, 0x00000000, 0x080019d2, 0x00000000
> 2013-11-16 11:43:40 [1505492.451033] tg3 0000:01:00.0: eth0: 0x00005080:
> 0x00009800, 0x80004000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451035] tg3 0000:01:00.0: eth0: 0x00005090:
> 0x00000000, 0x00000000, 0x00000000, 0x0800185c
> 2013-11-16 11:43:40 [1505492.451036] tg3 0000:01:00.0: eth0: 0x000050a0:
> 0xafa40014, 0x00000000, 0x00000000, 0x40000020
> 2013-11-16 11:43:40 [1505492.451038] tg3 0000:01:00.0: eth0: 0x000050b0:
> 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451040] tg3 0000:01:00.0: eth0: 0x000050c0:
> 0x00000000, 0x00000000, 0x08000088, 0x00000000
> 2013-11-16 11:43:40 [1505492.451042] tg3 0000:01:00.0: eth0: 0x00005100:
> 0x00009800, 0x80000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451043] tg3 0000:01:00.0: eth0: 0x00005110:
> 0x00000000, 0x00000000, 0x00000000, 0x08002ca0
> 2013-11-16 11:43:40 [1505492.451045] tg3 0000:01:00.0: eth0: 0x00005120:
> 0x30420001, 0x00000000, 0x00000000, 0x40000020
> 2013-11-16 11:43:40 [1505492.451047] tg3 0000:01:00.0: eth0: 0x00005130:
> 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451048] tg3 0000:01:00.0: eth0: 0x00005140:
> 0x00000000, 0x00000000, 0x0800203c, 0x00000000
> 2013-11-16 11:43:40 [1505492.451050] tg3 0000:01:00.0: eth0: 0x00005180:
> 0x00009800, 0x80004000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451052] tg3 0000:01:00.0: eth0: 0x00005190:
> 0x00000000, 0x00000000, 0x00000000, 0x08001fac
> 2013-11-16 11:43:40 [1505492.451053] tg3 0000:01:00.0: eth0: 0x000051a0:
> 0x2404000f, 0x00000000, 0x00000000, 0x40000020
> 2013-11-16 11:43:40 [1505492.451055] tg3 0000:01:00.0: eth0: 0x000051b0:
> 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451057] tg3 0000:01:00.0: eth0: 0x000051c0:
> 0x00000000, 0x00000000, 0x080019d2, 0x00000000
> 2013-11-16 11:43:40 [1505492.451058] tg3 0000:01:00.0: eth0: 0x00005200:
> 0x00000000, 0x0b9604fa, 0x06000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451060] tg3 0000:01:00.0: eth0: 0x00005210:
> 0xc0000000, 0xc0000000, 0x00000000, 0x0b9604fa
> 2013-11-16 11:43:40 [1505492.451062] tg3 0000:01:00.0: eth0: 0x00005220:
> 0x06000000, 0x00000000, 0x00000000, 0xc0000000
> 2013-11-16 11:43:40 [1505492.451064] tg3 0000:01:00.0: eth0: 0x00005230:
> 0x00000000, 0x0b9604fa, 0x06000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451066] tg3 0000:01:00.0: eth0: 0x00005240:
> 0x00000000, 0x00000000, 0x00000000, 0x0b9604fa
> 2013-11-16 11:43:40 [1505492.451067] tg3 0000:01:00.0: eth0: 0x00005250:
> 0x06000000, 0x00000000, 0xc0000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451069] tg3 0000:01:00.0: eth0: 0x00005260:
> 0x00000000, 0x0b9604fa, 0x06000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451071] tg3 0000:01:00.0: eth0: 0x00005270:
> 0xc0000000, 0xc0000000, 0x00000000, 0x0b9604fa
> 2013-11-16 11:43:40 [1505492.451073] tg3 0000:01:00.0: eth0: 0x00005280:
> 0x00009800, 0x80000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451074] tg3 0000:01:00.0: eth0: 0x00005290:
> 0x00000000, 0x00000000, 0x00000000, 0x08002ca0
> 2013-11-16 11:43:40 [1505492.451076] tg3 0000:01:00.0: eth0: 0x000052a0:
> 0x30420001, 0x00000000, 0x00000000, 0x40000020
> 2013-11-16 11:43:40 [1505492.451078] tg3 0000:01:00.0: eth0: 0x000052b0:
> 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451079] tg3 0000:01:00.0: eth0: 0x000052c0:
> 0x00000000, 0x00000000, 0x0800203c, 0x00000000
> 2013-11-16 11:43:40 [1505492.451081] tg3 0000:01:00.0: eth0: 0x00005300:
> 0x00009800, 0x80004000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451083] tg3 0000:01:00.0: eth0: 0x00005310:
> 0x00000000, 0x00000000, 0x00000000, 0x08001fac
> 2013-11-16 11:43:40 [1505492.451084] tg3 0000:01:00.0: eth0: 0x00005320:
> 0x2404000f, 0x00000000, 0x00000000, 0x40000020
> 2013-11-16 11:43:40 [1505492.451086] tg3 0000:01:00.0: eth0: 0x00005330:
> 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451088] tg3 0000:01:00.0: eth0: 0x00005340:
> 0x00000000, 0x00000000, 0x080019d2, 0x00000000
> 2013-11-16 11:43:40 [1505492.451089] tg3 0000:01:00.0: eth0: 0x00005380:
> 0x00009800, 0x80004000, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451091] tg3 0000:01:00.0: eth0: 0x00005390:
> 0x00000000, 0x00000000, 0x00000000, 0x0800185c
> 2013-11-16 11:43:40 [1505492.451093] tg3 0000:01:00.0: eth0: 0x000053a0:
> 0xafa40014, 0x00000000, 0x00000000, 0x40000020
> 2013-11-16 11:43:40 [1505492.451094] tg3 0000:01:00.0: eth0: 0x000053b0:
> 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> 2013-11-16 11:43:40 [1505492.451096] tg3 0000:01:00.0: eth0: 0x000053c0:
> 0x00000000, 0x00000000, 0x08000088, 0x00000000
> 2013-11-16 11:43:41 [1505492.451098] tg3 0000:01:00.0: eth0: 0x00005800:
> 0x3f000000, 0x3f000000, 0x00000001, 0x00000000
> 2013-11-16 11:43:41 [1505492.451099] tg3 0000:01:00.0: eth0: 0x00005810:
> 0x10000000, 0x00000000, 0xae000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451101] tg3 0000:01:00.0: eth0: 0x00005820:
> 0x00000001, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451103] tg3 0000:01:00.0: eth0: 0x00005860:
> 0x00000000, 0x00000000, 0x000006a1, 0x000006a1
> 2013-11-16 11:43:41 [1505492.451104] tg3 0000:01:00.0: eth0: 0x00005880:
> 0x000001d2, 0x000001d2, 0x00000d76, 0x00000d76
> 2013-11-16 11:43:41 [1505492.451106] tg3 0000:01:00.0: eth0: 0x00005890:
> 0x000004e6, 0x000004e6, 0x000001b5, 0x000001b5
> 2013-11-16 11:43:41 [1505492.451108] tg3 0000:01:00.0: eth0: 0x00005900:
> 0x000001ea, 0x000001ea, 0x0000010d, 0x00000035
> 2013-11-16 11:43:41 [1505492.451110] tg3 0000:01:00.0: eth0: 0x00005910:
> 0x000000bb, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451111] tg3 0000:01:00.0: eth0: 0x00005980:
> 0x000001ea, 0x0000010d, 0x00000035, 0x000000bb
> 2013-11-16 11:43:41 [1505492.451113] tg3 0000:01:00.0: eth0: 0x00005a00:
> 0x000f601f, 0x00000000, 0x00010000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451115] tg3 0000:01:00.0: eth0: 0x00006000:
> 0x00010082, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451117] tg3 0000:01:00.0: eth0: 0x00006400:
> 0x00000000, 0x00000000, 0x00010891, 0xc0000000
> 2013-11-16 11:43:41 [1505492.451118] tg3 0000:01:00.0: eth0: 0x00006410:
> 0x0a000064, 0x0a000064, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451120] tg3 0000:01:00.0: eth0: 0x00006420:
> 0x00000000, 0x00000000, 0x00000000, 0x818c0000
> 2013-11-16 11:43:41 [1505492.451122] tg3 0000:01:00.0: eth0: 0x00006430:
> 0x78000000, 0x14e4165f, 0x1f5b1028, 0x00020000
> 2013-11-16 11:43:41 [1505492.451123] tg3 0000:01:00.0: eth0: 0x00006440:
> 0x0000304f, 0x000002e4, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451125] tg3 0000:01:00.0: eth0: 0x000064c0:
> 0x00000010, 0x00000004, 0x00001004, 0x00000000
> 2013-11-16 11:43:41 [1505492.451127] tg3 0000:01:00.0: eth0: 0x000064d0:
> 0x00000000, 0x10008d81, 0x00000000, 0x00315e22
> 2013-11-16 11:43:41 [1505492.451129] tg3 0000:01:00.0: eth0: 0x000064e0:
> 0x00000031, 0x0000001f, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451130] tg3 0000:01:00.0: eth0: 0x000064f0:
> 0x00000002, 0x00000031, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451132] tg3 0000:01:00.0: eth0: 0x00006500:
> 0x01e10003, 0x1c3f67fa, 0x000090b1, 0x00000003
> 2013-11-16 11:43:41 [1505492.451134] tg3 0000:01:00.0: eth0: 0x00006510:
> 0x0007811b, 0x00058116, 0x00046113, 0x00000000
> 2013-11-16 11:43:41 [1505492.451136] tg3 0000:01:00.0: eth0: 0x00006550:
> 0x00000001, 0x02800000, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451138] tg3 0000:01:00.0: eth0: 0x000065f0:
> 0x00000000, 0x00000109, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451139] tg3 0000:01:00.0: eth0: 0x00006800:
> 0x14130034, 0x20099082, 0x01029208, 0xfade98a5
> 2013-11-16 11:43:41 [1505492.451141] tg3 0000:01:00.0: eth0: 0x00006810:
> 0x21020000, 0xffffffff, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451143] tg3 0000:01:00.0: eth0: 0x00006830:
> 0xffffffff, 0xffffffff, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451144] tg3 0000:01:00.0: eth0: 0x00006840:
> 0x00000000, 0x00000001, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451146] tg3 0000:01:00.0: eth0: 0x00006890:
> 0x00000000, 0x88003800, 0x00000000, 0x04102040
> 2013-11-16 11:43:41 [1505492.451148] tg3 0000:01:00.0: eth0: 0x000068a0:
> 0x00000020, 0x00000001, 0x03ff03ff, 0x00000000
> 2013-11-16 11:43:41 [1505492.451149] tg3 0000:01:00.0: eth0: 0x000068b0:
> 0xe0011514, 0x00000000, 0x00000000, 0x00000000
> 2013-11-16 11:43:41 [1505492.451151] tg3 0000:01:00.0: eth0: 0x000068e0:
> 0x00000000, 0x00000000, 0x00000000, 0x00050b08
> 2013-11-16 11:43:41 [1505492.451153] tg3 0000:01:00.0: eth0: 0x000068f0:
> 0x00ff000e, 0x00ff0000, 0x00000000, 0x04444444
> 2013-11-16 11:43:41 [1505492.451154] tg3 0000:01:00.0: eth0: 0x00006920:
> 0x00000000, 0x00000000, 0x00000001, 0x00000000
> 2013-11-16 11:43:41 [1505492.451156] tg3 0000:01:00.0: eth0: 0x00007000:
> 0x00000008, 0x00000000, 0x00000000, 0x00004868
> 2013-11-16 11:43:41 [1505492.451158] tg3 0000:01:00.0: eth0: 0x00007010:
> 0x1a5876c2, 0x01c08073, 0x00d70081, 0x03008200
> 2013-11-16 11:43:41 [1505492.451160] tg3 0000:01:00.0: eth0: 0x00007020:
> 0x00000000, 0x00000000, 0x00000406, 0x10004000
> 2013-11-16 11:43:41 [1505492.451161] tg3 0000:01:00.0: eth0: 0x00007030:
> 0x000e0000, 0x0000486c, 0x00170030, 0x00000000
> 2013-11-16 11:43:41 [1505492.451165] tg3 0000:01:00.0: eth0: 0: Host status
> block [00000004:0000003f:(0000:02e5:0000):(0000:0000)]
> 2013-11-16 11:43:41 [1505492.451167] tg3 0000:01:00.0: eth0: 0: NAPI info
> [0000003f:0000003f:(0000:0000:01ff):0000:(06a1:0000:0000:0000)]
> 2013-11-16 11:43:41 [1505492.451169] tg3 0000:01:00.0: eth0: 1: Host status
> block [00000001:00000033:(0000:0000:0000):(01d6:0013)]
> 2013-11-16 11:43:41 [1505492.451171] tg3 0000:01:00.0: eth0: 1: NAPI info
> [000000fb:000000fb:(0013:01df:01ff):01d2:(01d2:01d2:0000:0000)]
> 2013-11-16 11:43:41 [1505492.451173] tg3 0000:01:00.0: eth0: 2: Host status
> block [00000001:00000010:(0d76:0000:0000):(0000:010d)]
> 2013-11-16 11:43:41 [1505492.451176] tg3 0000:01:00.0: eth0: 2: NAPI info
> [00000010:00000010:(010d:010d:01ff):0d76:(0576:0573:0000:0000)]
> 2013-11-16 11:43:41 [1505492.451178] tg3 0000:01:00.0: eth0: 3: Host status
> block [00000001:000000ae:(0000:0000:0000):(0000:0035)]
> 2013-11-16 11:43:41 [1505492.451180] tg3 0000:01:00.0: eth0: 3: NAPI info
> [000000ae:000000ae:(0035:0035:01ff):04e6:(04e6:04df:0000:0000)]
> 2013-11-16 11:43:41 [1505492.451182] tg3 0000:01:00.0: eth0: 4: Host status
> block [00000001:000000b2:(0000:0000:0267):(0000:00bb)]
> 2013-11-16 11:43:41 [1505492.451184] tg3 0000:01:00.0: eth0: 4: NAPI info
> [000000cd:000000cd:(00bb:0062:01ff):01b5:(01b5:01b5:0000:0000)]
> 2013-11-16 11:43:41 [1505492.457748] tg3 0000:01:00.0: eth0: The system may
> be re-ordering memory-mapped I/O cycles to the network device, attempting to
> recover. Please report the problem to the driver maintainer and include
> system chipset information.
> 2013-11-16 11:43:41 [1505492.490118] tg3 0000:01:00.0: eth0: Link is down
> 2013-11-16 11:43:41 [1505498.044676] tg3 0000:01:00.0: eth0: Link is up at
> 1000 Mbps, full duplex
> 2013-11-16 11:43:41 [1505498.044678] tg3 0000:01:00.0: eth0: Flow control
> is off for TX and off for RX
> 2013-11-16 11:43:41 [1505498.044680] tg3 0000:01:00.0: eth0: EEE is
> disabled
>
> Further information:
> Current output of "ethtool -k eth0":
> rx-checksumming: on
> tx-checksumming: on
> tx-checksum-ipv4: on
> tx-checksum-ip-generic: off [fixed]
> tx-checksum-ipv6: on
> tx-checksum-fcoe-crc: off [fixed]
> tx-checksum-sctp: off [fixed]
> scatter-gather: on
> tx-scatter-gather: on
> tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off
> tx-tcp-ecn-segmentation: off
> tx-tcp6-segmentation: off
> udp-fragmentation-offload: off [fixed]
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: on
> tx-vlan-offload: on
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: on
> rx-vlan-filter: off [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: off [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: off [fixed]
> fcoe-mtu: off [fixed]
> tx-nocache-copy: on
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
>
> Current output of "lscpi -vvvv" for eth0:
> 01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit
> Ethernet PCIe
> Subsystem: Dell Device 1f5b
> 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 B routed to IRQ 38
> Region 0: Memory at d57d0000 (64-bit, prefetchable) [size=64K]
> Region 2: Memory at d57e0000 (64-bit, prefetchable) [size=64K]
> Region 4: Memory at d57f0000 (64-bit, prefetchable) [size=64K]
> Expansion ROM at d5700000 [disabled] [size=256K]
> Capabilities: [48] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data
> Product Name: Broadcom NetXtreme Gigabit Ethernet
> Read-only fields:
> [PN] Part number: BCM95720
> [MN] Manufacture ID: 31 30 32 38
> [V0] Vendor specific: FFV7.4.8
> [V1] Vendor specific: DSV1028VPDR.VER1.0
> [V2] Vendor specific: NPY2
> [V3] Vendor specific: PMT1
> [V4] Vendor specific: NMVBroadcom Corp
> [V5] Vendor specific: DTINIC
> [V6] Vendor specific: DCM1001008d452101008d45
> [RV] Reserved: checksum good, 235 byte(s) reserved
> End
> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> Address: 0000000000000000 Data: 0000
> Capabilities: [a0] MSI-X: Enable+ Count=17 Masked-
> Vector table: BAR=4 offset=00000000
> PBA: BAR=4 offset=00001000
> Capabilities: [ac] Express (v2) Endpoint, MSI 00
> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us,
> L1 <64us
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
> DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+
> Unsupported+
> RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop-
> FLReset-
> MaxPayload 256 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+
> TransPend-
> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM L0s L1, Latency
> L0 <1us, L1 <2us
> ClockPM+ Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
> CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
> DevCtl2: Completion Timeout: 65ms to 210ms, 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,
> EqualizationComplete-, EqualizationPhase1-
> EqualizationPhase2-, EqualizationPhase3-,
> LinkEqualizationRequest-
> 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: [13c v1] Device Serial Number 00-00-90-b1-1c-3f-67-fb
> Capabilities: [150 v1] Power Budgeting <?>
> Capabilities: [160 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-
> Kernel driver in use: tg3
>
>
> Can you please get me some help how to solve the problem?
> If you need more information please let me know.
>
> For answer please Cc me, as I'm not a member of lkml.
>
> Many thanks and regards
> Urban Loesch
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: bonding/bond_main: Apply ACCESS_ONCE() to avoid sparse false positive
http://groups.google.com/group/linux.kernel/t/702c74b758c475e5?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 7:30 am
From: "Paul E. McKenney"
On Sat, Nov 16, 2013 at 12:32:16PM +0800, Ding Tianhong wrote:
> 于 2013/11/16 8:40, Paul E. McKenney 写道:
> > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> >
> > The sparse checking for rcu_assign_pointer() was recently upgraded
> > to reject non-__kernel address spaces. This also rejects __rcu,
> > which is almost always the right thing to do. However, the uses in
> > bond_change_active_slave() and __bond_release_one() are legitimate:
> > They are assigning a pointer to an element from an RCU-protected list
> > (or a NULL pointer), and all elements of this list are already visible
> > to caller.
> >
> > This commit therefore silences these false positives either by laundering
> > the pointers using ACCESS_ONCE() as suggested by Eric Dumazet and Josh
> > Triplett, or by using RCU_INIT_POINTER() for NULL pointer assignments.
>
> I think it is fit for net-next.
Thank you!
If this is queued there, I would be happy to drop it from my tree.
There are no dependencies on anything in my tree.
Thanx, Paul
> > Reported-by: kbuild test robot <fengguang.wu@intel.com>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Cc: Stephen Hemminger <stephen@networkplumber.org>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: bridge@lists.linux-foundation.org
> > Cc: netdev@vger.kernel.org
> > ---
> > drivers/net/bonding/bond_main.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> > index 72df399c4ab3..bbd7fd3e46fe 100644
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/drivers/net/bonding/bond_main.c
> > @@ -890,7 +890,8 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
> > if (new_active)
> > bond_set_slave_active_flags(new_active);
> > } else {
> > - rcu_assign_pointer(bond->curr_active_slave, new_active);
> > + /* Both --rcu and visible, so ACCESS_ONCE() is OK. */
> > + ACCESS_ONCE(bond->curr_active_slave) = new_active;
> > }
> >
> > if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) {
> > @@ -1801,7 +1802,7 @@ static int __bond_release_one(struct net_device *bond_dev,
> > }
> >
> > if (all) {
> > - rcu_assign_pointer(bond->curr_active_slave, NULL);
> > + RCU_INIT_POINTER(bond->curr_active_slave, NULL);
> > } else if (oldcurrent == slave) {
> > /*
> > * Note that we hold RTNL over this sequence, so there
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: power: Change device_wakeup_enable() to check for null dev_name(dev)
http://groups.google.com/group/linux.kernel/t/63d037cc27ffc12e?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 7:30 am
From: Shuah Khan
On 11/15/2013 05:25 PM, Greg KH wrote:
> On Fri, Nov 15, 2013 at 05:16:31PM -0700, Shuah Khan wrote:
>> On 11/15/2013 05:21 PM, Rafael J. Wysocki wrote:
>>> On Friday, November 15, 2013 05:03:57 PM Shuah Khan wrote:
>>>> device_wakeup_enable() uses dev_name(dev) as the wakeup source name.
>>>> When it gets called with a device with its name not yet set, ws structure
>>>> with ws->name = NULL gets created.
>>>>
>>>> When kernel is booted with wakeup_source_activate enabled, it will panic
>>>> when the trace point code tries to derefernces ws->name.
>>>>
>>>> Change device_wakeup_enable() to check for dev_name(dev) null condition
>>>> and return -EINVAL to avoid panics when device_wakeup_enable() gets called
>>>> before device is fully initialized with its name.
>> return -EINVAL;
>>>
>>> Can you please use WARN_ON(!dev_name(dev)) here? While I agree that it is a
>>> bad idea to crash the kernel because dev has no name, that indicates a driver
>>> bug that shouldn't be too easy to ignore.
>>>
>>> Thanks!
>>>
>>
>> Right. ok I will re-cut the patch with WARN_ON and send it. fyi I did
>> send fix for the driver (power_supply) as well.
>>
>> http://www.kernelhub.org/?msg=362354&p=2
>
> Why is a driver calling kobject_set_name() instead of device_set_name()?
>
> Yes, it's really the same thing deep down, but drivers should never care
> about a kobject, just 'struct device'. Well, even then it usually
> should care about it's type of 'struct device' but that's a different
> issue...
>
> Anyway, not saying your patch is wrong at all, just for the future if
> people are looking for code cleanups...
>
Use of kobject_set_name() did look odd to me. I will fix that for this
driver by re-doing the patch while I am it. About the power_supply
patch, stable needs fixing as well, and I will have to backport once he
fix goes into the mainline.
http://www.kernelhub.org/?msg=362354&p=2 as is doesn't apply to 3.10 and
3.11
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: documentation: Update circular buffer for load-acquire/store-release
http://groups.google.com/group/linux.kernel/t/9d3de39c23ef46a9?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Nov 16 2013 7:50 am
From: "Paul E. McKenney"
On Sat, Nov 16, 2013 at 11:58:45AM +0000, David Howells wrote:
> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>
> > - /* read index before reading contents at that index */
>
> > - smp_mb(); /* finish reading descriptor before incrementing tail */
>
> I'd rather you didn't remove these comments (assuming they're correct) as
> they're pointing out the point of the example.
Ah, good point! I have added them back just before the smp_load_acquire()
and smp_store_release(), as shown below. Does that work?
Thanx, Paul
------------------------------------------------------------------------
diff --git a/Documentation/circular-buffers.txt b/Documentation/circular-buffers.txt
index 15e54ff50018..88951b179262 100644
--- a/Documentation/circular-buffers.txt
+++ b/Documentation/circular-buffers.txt
@@ -200,6 +200,7 @@ The consumer will look something like this:
spin_lock(&consumer_lock);
+ /* Read index before reading contents at that index. */
unsigned long head = smp_load_acquire(buffer->head);
unsigned long tail = buffer->tail;
@@ -210,6 +211,7 @@ The consumer will look something like this:
consume_item(item);
+ /* Finish reading descriptor before incrementing tail. */
smp_store_release(buffer->tail,
(tail + 1) & (buffer->size - 1));
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Sat, Nov 16 2013 8:10 am
From: Peter Zijlstra
On Fri, Nov 15, 2013 at 04:10:30PM -0800, Paul E. McKenney wrote:
> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>
> This commit replaces full barriers by targeted use of load-acquire and
> store-release.
I guess I'd better hurry up merging the patches that introduce these
thingies someplace :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: i2c: Fallback to of_node of parent
http://groups.google.com/group/linux.kernel/t/d93b3f894c3e5685?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Nov 16 2013 7:50 am
From: Florian Meier
Many busses (e.g. tegra, omap, bcm2835)
need to set the of_node of the adapter
device to the one of the parent device, i.e.
adap->dev.of_node = pdev->dev.of_node;
As suggested by Stephen Warren, this could also
be done in the i2c core and it is a common mistake
to forget this line:
I2C: BCM2835: Linking platform nodes to adapter nodes
i2c: Fix device tree binding for i2c-cbus-gpio
Signed-off-by: Florian Meier <florian.meier@koalo.de>
Suggested-by: Stephen Warren <swarren@wwwdotorg.org>
---
drivers/i2c/i2c-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 430c001..c8e33a5 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1310,6 +1310,9 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
struct device *dev = &adapter->dev;
int id;
+ if (!dev->of_node && dev->parent)
+ dev->of_node = dev->parent->of_node;
+
if (dev->of_node) {
id = of_alias_get_id(dev->of_node, "i2c");
if (id >= 0) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 4 ==
Date: Sat, Nov 16 2013 8:10 am
From: Wolfram Sang
> + if (!dev->of_node && dev->parent)
> + dev->of_node = dev->parent->of_node;
> +
That is not enough. Current drivers could then have the assignment
removed and even more important, this behaviour should be documented.
Regards,
Wolfram
== 3 of 4 ==
Date: Sat, Nov 16 2013 8:20 am
From: Florian Meier
Ok, I will try to find all relevant lines.
Where is the best place to document this?
Greetings,
Florian
2013/11/16 Wolfram Sang <wsa@the-dreams.de>:
>
>> + if (!dev->of_node && dev->parent)
>> + dev->of_node = dev->parent->of_node;
>> +
>
> That is not enough. Current drivers could then have the assignment
> removed and even more important, this behaviour should be documented.
>
> Regards,
>
> Wolfram
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 4 of 4 ==
Date: Sat, Nov 16 2013 9:00 am
From: Florian Meier
I have looked through all bus drivers and in most
cases they have a corresponding line that could be removed.
Although, this patch would break i2c-powermac, because it
relies on the fact that of_node stays NULL.
Any idea how to handle that?
Greetings,
Florian
On 16.11.2013 17:11, Florian Meier wrote:
> Ok, I will try to find all relevant lines.
> Where is the best place to document this?
>
> Greetings,
> Florian
>
> 2013/11/16 Wolfram Sang <wsa@the-dreams.de>:
>>
>>> + if (!dev->of_node && dev->parent)
>>> + dev->of_node = dev->parent->of_node;
>>> +
>>
>> That is not enough. Current drivers could then have the assignment
>> removed and even more important, this behaviour should be documented.
>>
>> Regards,
>>
>> Wolfram
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: vmstat: On demand vmstat workers V3
http://groups.google.com/group/linux.kernel/t/f9b1502cc1b5f270?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 7:50 am
From: Frederic Weisbecker
On Thu, Oct 03, 2013 at 05:40:40PM +0000, Christoph Lameter wrote:
> V2->V3:
> - Introduce a new tick_get_housekeeping_cpu() function. Not sure
> if that is exactly what we want but it is a start. Thomas?
Not really. Thomas suggested an infrastructure to move CPU-local periodic
jobs handling to be offlined to set of remote housekeeping CPU.
This could be potentially useful for many kind of stats relying on
periodic updates, the scheduler tick being a candidate (I have yet to
check if we can really apply that in practice though).
Now the problem is that vmstats updates use pure local lockless
operations. It may be possible to offline this update to remote CPUs
but then we need to convert vmstats updates to use locks. Which is
potentially costly. Unless we can find some clever lockless update
scheme. Do you think this can be possible?
See below for more detailed review:
[...]
>
> /*
> @@ -1213,12 +1229,15 @@ static const struct file_operations proc
> #ifdef CONFIG_SMP
> static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
> int sysctl_stat_interval __read_mostly = HZ;
> +static struct cpumask *monitored_cpus;
>
> static void vmstat_update(struct work_struct *w)
> {
> - refresh_cpu_vm_stats();
> - schedule_delayed_work(&__get_cpu_var(vmstat_work),
> - round_jiffies_relative(sysctl_stat_interval));
> + if (refresh_cpu_vm_stats())
> + schedule_delayed_work(this_cpu_ptr(&vmstat_work),
> + round_jiffies_relative(sysctl_stat_interval));
> + else
> + cpumask_set_cpu(smp_processor_id(), monitored_cpus);
That looks racy against other CPUs that may set their own bit and also
against the shepherd that clears processed monitored CPUs.
That seem to matter because a CPU could be simply entirely forgotten
by vmstat and never processed again.
> }
>
> static void start_cpu_timer(int cpu)
> @@ -1226,7 +1245,70 @@ static void start_cpu_timer(int cpu)
> struct delayed_work *work = &per_cpu(vmstat_work, cpu);
>
> INIT_DEFERRABLE_WORK(work, vmstat_update);
> - schedule_delayed_work_on(cpu, work, __round_jiffies_relative(HZ, cpu));
> + schedule_delayed_work_on(cpu, work,
> + __round_jiffies_relative(sysctl_stat_interval, cpu));
> +}
> +
> +/*
> + * Check if the diffs for a certain cpu indicate that
> + * an update is needed.
> + */
> +static bool need_update(int cpu)
> +{
> + struct zone *zone;
> +
> + for_each_populated_zone(zone) {
> + struct per_cpu_pageset *p = per_cpu_ptr(zone->pageset, cpu);
> +
> + /*
> + * The fast way of checking if there are any vmstat diffs.
> + * This works because the diffs are byte sized items.
> + */
> + if (memchr_inv(p->vm_stat_diff, 0, NR_VM_ZONE_STAT_ITEMS))
> + return true;
> + }
> + return false;
> +}
> +
> +static void vmstat_shepherd(struct work_struct *w)
> +{
> + int cpu;
> + int s = tick_get_housekeeping_cpu();
> + struct delayed_work *d = per_cpu_ptr(&vmstat_work, s);
> +
> + refresh_cpu_vm_stats();
> +
> + for_each_cpu(cpu, monitored_cpus)
> + if (need_update(cpu)) {
> + cpumask_clear_cpu(cpu, monitored_cpus);
> + start_cpu_timer(cpu);
> + }
> +
> + if (s != smp_processor_id()) {
> + /* Timekeeping was moved. Move the shepherd worker */
> + cpumask_set_cpu(smp_processor_id(), monitored_cpus);
> + cpumask_clear_cpu(s, monitored_cpus);
> + cancel_delayed_work_sync(d);
> + INIT_DEFERRABLE_WORK(d, vmstat_shepherd);
> + }
> +
> + schedule_delayed_work_on(s, d,
> + __round_jiffies_relative(sysctl_stat_interval, s));
Note that on dynticks idle (CONFIG_NO_HZ_IDLE=y), the timekeeper CPU can change quickly and often.
I can imagine a nasty race there: CPU 0 is the timekeeper. It schedules the
vmstat sherpherd work in 2 seconds. But CPU 0 goes to sleep for a big while
and some other CPU takes the timekeeping duty. The shepherd timer won't be
processed until CPU 0 wakes up although we may have CPUs to monitor.
CONFIG_NO_HZ_FULL may work incidentally because CPU 0 is the only timekeeper there
but this is a temporary limitation. Expect the timekeeper to be dynamic in the future
under that config.
> +
> +}
> +
> +static void __init start_shepherd_timer(void)
> +{
> + int cpu = tick_get_housekeeping_cpu();
> + struct delayed_work *d = per_cpu_ptr(&vmstat_work, cpu);
> +
> + INIT_DEFERRABLE_WORK(d, vmstat_shepherd);
> + monitored_cpus = kmalloc(BITS_TO_LONGS(nr_cpu_ids) * sizeof(long),
> + GFP_KERNEL);
> + cpumask_copy(monitored_cpus, cpu_online_mask);
> + cpumask_clear_cpu(cpu, monitored_cpus);
> + schedule_delayed_work_on(cpu, d,
> + __round_jiffies_relative(sysctl_stat_interval, cpu));
> }
So another issue with the whole design of this patch, outside its races, is that
a CPU can run full dynticks, do some quick system call at some point and thus
make the shepherd disturb it after it goes back in userland in full dynticks.
So such a system that dynamically schedules timers on demand is enough if we
want to _minimize_ timers. But what we want is a strong guarantee that the
CPU won't be disturbed at least while it runs in userland, right?
I mean, we are not only interested in optimizations but also in guarantees if
we have an extreme workload that strongly depends on the CPU not beeing disturbed
at all. I know that some people in realtime want that. And I thought it's also
what your want, may be I misunderstood your usecase?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: autofs4: allow autofs to work outside the initial PID namespace
http://groups.google.com/group/linux.kernel/t/97091a536b47b942?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 8:10 am
From: Oleg Nesterov
On 11/15, Andrew Morton wrote:
>
> Enable autofs4 to work in a "container". oz_pgrp is converted from pid_t
> to struct pid and this is stored at mount time based on the "pgrp=" option
> or if the option is missing then the current pgrp.
I don't understand this code, so I am probably wrong. And this is minor
anyway, but...
> @@ -357,7 +358,17 @@ static int autofs_dev_ioctl_setpipefd(st
> mutex_unlock(&sbi->wq_mutex);
> return -EBUSY;
> } else {
> - struct file *pipe = fget(pipefd);
> + struct file *pipe;
> +
> + new_pid = get_task_pid(current, PIDTYPE_PGID);
> +
> + if (ns_of_pid(new_pid) != ns_of_pid(sbi->oz_pgrp)) {
> + AUTOFS_WARN("Not allowed to change PID namespace");
> + err = -EINVAL;
> + goto out;
> + }
> +
> + pipe = fget(pipefd);
> if (!pipe) {
> err = -EBADF;
> goto out;
> @@ -367,12 +378,13 @@ static int autofs_dev_ioctl_setpipefd(st
> fput(pipe);
> goto out;
> }
> - sbi->oz_pgrp = task_pgrp_nr(current);
> + swap(sbi->oz_pgrp, new_pid);
> sbi->pipefd = pipefd;
> sbi->pipe = pipe;
> sbi->catatonic = 0;
> }
> out:
> + put_pid(new_pid);
This looks suspicious, put_pid() can actually kfree the old sbi->oz_pgrp
swapped above. IOW, this assumes we can't race with any user of ->oz_pgrp.
For example,
> @@ -80,7 +83,7 @@ static int autofs4_show_options(struct s
> if (!gid_eq(root_inode->i_gid, GLOBAL_ROOT_GID))
> seq_printf(m, ",gid=%u",
> from_kgid_munged(&init_user_ns, root_inode->i_gid));
> - seq_printf(m, ",pgrp=%d", sbi->oz_pgrp);
> + seq_printf(m, ",pgrp=%d", pid_vnr(sbi->oz_pgrp));
Can't this race with autofs_dev_ioctl_setpipefd() above?
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: ASoC: omap: mcbsp, mcpdm, dmic: raw read and write endian fix
http://groups.google.com/group/linux.kernel/t/61c361b93c246cfd?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Nov 16 2013 8:50 am
From: Jarkko Nikula
On 11/16/2013 02:01 AM, Taras Kondratiuk wrote:
> From: Victor Kamensky <victor.kamensky@linaro.org>
>
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> need to use read[lw]_relaxed and write[lw]_relaxed functions.
> If the first simply reads/writes register, the second will byteswap
> it if host operates in BE mode.
>
> Changes are trivial sed like replacement of __raw_xxx functions
> with xxx_relaxed variant.
>
> Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
> ---
> sound/soc/omap/mcbsp.c | 12 ++++++------
> sound/soc/omap/omap-dmic.c | 4 ++--
> sound/soc/omap/omap-mcpdm.c | 4 ++--
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
Looks ok to me by looking at the _relaxed definitions in
arch/arm/include/asm/io.h.
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Sat, Nov 16 2013 9:30 am
From: Takashi Iwai
At Sat, 16 Nov 2013 18:09:51 +0200,
Jarkko Nikula wrote:
>
> On 11/16/2013 02:01 AM, Taras Kondratiuk wrote:
> > From: Victor Kamensky <victor.kamensky@linaro.org>
> >
> > All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> > Need to use endian neutral functions to read/write h/w registers.
> > I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> > need to use read[lw]_relaxed and write[lw]_relaxed functions.
> > If the first simply reads/writes register, the second will byteswap
> > it if host operates in BE mode.
> >
> > Changes are trivial sed like replacement of __raw_xxx functions
> > with xxx_relaxed variant.
> >
> > Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
> > Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
> > ---
> > sound/soc/omap/mcbsp.c | 12 ++++++------
> > sound/soc/omap/omap-dmic.c | 4 ++--
> > sound/soc/omap/omap-mcpdm.c | 4 ++--
> > 3 files changed, 10 insertions(+), 10 deletions(-)
> >
> Looks ok to me by looking at the _relaxed definitions in
> arch/arm/include/asm/io.h.
>
> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
>
What's the reason to use _relaxed version in all places?
I understand this patch is to fix the endianess, so this can be
applied as is, as long as the original code works. But, still in
general, I wonder how the concurrency is guaranteed by this driver
code...
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: sound fixes for 3.13-rc1
http://groups.google.com/group/linux.kernel/t/55ae5a33d87f1caf?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 9:30 am
From: Takashi Iwai
Linus,
please pull sound fixes for v3.13-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-fix-3.13-rc1
The topmost commit is abfe69dd2e313d0c8226ca4a12329e3d829cfd7c
----------------------------------------------------------------
sound fixes for 3.13-rc1
Two peaks in diffstat are for the audio EQ init of IDT codecs and the
EMU2004 usb mixer addition, both of which are pretty device-specific,
so safe to apply. The rest are a bunch of small fixes, most of them
are regression fixes.
----------------------------------------------------------------
Anssi Hannula (5):
ALSA: hda - hdmi: Use TFx channel positions instead of FxH
ALSA: usb: Fix wrong mapping of RLC and RRC channels
ALSA: hda - hdmi: Add error-checking to some codec reads
ALSA: hda - hdmi: Skip out-of-range latency values in AMD ELD generator
ALSA: hda - hdmi: Fix wrong baseline length in ATI/AMD generated ELD
Brian Austin (1):
ASoC: cs42l52: Correct MIC CTL mask
Charles Keepax (1):
ASoC: wm8997: Correct typo in ISRC mux routes
Dan Carpenter (2):
ALSA: snd-aoa: two copy and paste bugs
ALSA: isa: not allocating enough space
David Henningsson (1):
ALSA: hda - Fix Line Out automute on Realtek multifunction jacks
Nicolin Chen (1):
ASoC: wm8962: Turn on regcache_cache_only before disabling regulator
Oskar Schirmer (1):
ASoC: fsl: imx-pcm-fiq: omit fiq counter to avoid harm in unbalanced situations
Richard Fitzgerald (2):
ALSA: compress_core: don't return -EBADFD from poll if paused
ASoC: arizona: Fix typo in name of EQ coefficient controls
Takashi Iwai (9):
ALSA: hda - Control SPDIF out pin on MacBookPro 11,2
ALSA: msnd: Avoid duplicated driver name
ALSA: hda - Check keep_eapd_on before inv_eapd
ALSA: hda - Don't turn off EAPD for headphone on Lenovo N100
ALSA: hda - Control EAPD for Master volume on Lenovo N100
ALSA: hda - Don't clear the power state at snd_hda_codec_reset()
ASoC: blackfin: Fix missing break
ALSA: pcsp: Fix the order of input device unregistration
ALSA: jack: Unregister input device at disconnection
Vasily Khoruzhick (1):
ALSA: usb-audio: add front jack channel selector for EMU0204
Vitaliy Kulikov (1):
ALSA: hda - load EQ params into IDT codec on HP bNB13 systems
Wei Yongjun (1):
ALSA: sparc: fix missing unlock on error in snd_cs4231_playback_prepare()
---
sound/aoa/fabrics/layout.c | 4 +-
sound/core/compress_offload.c | 3 +-
sound/core/jack.c | 19 +-
sound/drivers/pcsp/pcsp.c | 2 +-
sound/isa/msnd/msnd_pinnacle.c | 4 +-
sound/isa/wavefront/wavefront_synth.c | 2 +-
sound/pci/hda/hda_codec.c | 3 -
sound/pci/hda/hda_eld.c | 37 ++-
sound/pci/hda/hda_generic.c | 4 +-
sound/pci/hda/patch_analog.c | 33 ++-
sound/pci/hda/patch_cirrus.c | 56 +++-
sound/pci/hda/patch_hdmi.c | 11 +-
sound/pci/hda/patch_realtek.c | 4 +-
sound/pci/hda/patch_sigmatel.c | 532 +++++++++++++++++++++++++++++++++-
sound/soc/blackfin/bf5xx-i2s.c | 1 +
sound/soc/codecs/cs42l52.h | 2 +-
sound/soc/codecs/wm5102.c | 8 +-
sound/soc/codecs/wm5110.c | 8 +-
sound/soc/codecs/wm8962.c | 2 +
sound/soc/codecs/wm8997.c | 10 +-
sound/soc/fsl/imx-pcm-fiq.c | 29 +-
sound/sparc/cs4231.c | 11 +-
sound/usb/mixer_quirks.c | 90 ++++++
sound/usb/stream.c | 4 +-
24 files changed, 803 insertions(+), 76 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: Command line related cleanups
http://groups.google.com/group/linux.kernel/t/f284ec730d289d67?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 9:40 am
From: Felipe Contreras
Hi,
These became apparent in the review process of a new command line parameter.
Felipe Contreras (5):
kstrtox: remove redundant cleanup
cmdline: fix style issues
cmdline: declare exported symbols immediately
kstrtox: remove redundant casts
params: improve standard definitions
kernel/params.c | 25 +++++++++----------------
lib/cmdline.c | 14 ++++++--------
lib/kstrtox.c | 17 ++++++++---------
3 files changed, 23 insertions(+), 33 deletions(-)
--
1.8.4.2+fc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: panic: setup panic_timeout early
http://groups.google.com/group/linux.kernel/t/b9ad085825bd3729?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 16 2013 9:50 am
From: Ingo Molnar
* Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Fri, Nov 15, 2013 at 2:15 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Fri, Nov 15, 2013 at 12:10 PM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> >>
> >> I haven't seen a single complaint about this commit message, so I
> >> don't see what is your point.
> >
> > My point is that I have sixteen pointless messages in my mbox,
> > half of which are due to just your argumentative nature.
>
> This is clearly not the point you were making, but I won't argue
> why.
That was exactly the point Linus was making.
Anyway, the fact that you are argumentative even with Linus gives me
little hope that you will improve your communication patterns with
_me_, so I'm personally done arguing with you.
> You don't want to argue? Then don't argue. Apply the patch. [...]
*Plonk*.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
You received this message because you are subscribed to the Google Groups "linux.kernel"
group.
To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en
To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
posted by twitter @ 5:21 PM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home