Hi e1000e-devel;
Steven (cc-ed) noticed an imbalance in semaphore put/get for
82573-based NICs. Don't we need something like the following
(untested) patch?
From: Steven La
Acked-by: Arthur Kepner
---
diff --git a/drivers/net/ethernet/intel/e1000e/82571.c
b/drivers/net/ethernet/intel/e
(Resending - the previous version was against our local
tree, not the upstream tree.)
If an e1000e interface is brought down, and subsequently
'print_hang_task' is run we'll dereference a NULL 'buffer_info'
pointer and crash with something like this:
Mar 19 13:20:27 BUG: unable to handle ke
Hi e1000-devel;
I sent a patch (same subject line as this mail) last Friday
to both e1000-devel, and netdev.
Could you have a look at it, and give it an ack, or nak?
Thanks.
--
Arthur
--
Symantec Endpoint Protec
During shutdown it's possible for __dev_close() (which holds
rtnl_lock) to clear the __LINK_STATE_START bit, and for ixgbe
to then read that bit (without holding rtnl_lock), and then
not fail to free irqs, etc. The result is a crash like this:
[ cut here ]
kernel BUG a
On Fri, Jan 25, 2013 at 08:25:17PM +, Ronciak, John wrote:
> This could be BIOS configuration as well. Check the BIOS version as Tushar
> says but also look at how you have the device/slot configured in the BIOS.
>
The "probe of :07:00.0 failed with error -2" is seen
with only a few sy
On Fri, Jan 25, 2013 at 08:25:17PM +, Ronciak, John wrote:
> This could be BIOS configuration as well. Check the BIOS version as Tushar
> says but also look at how you have the device/slot configured in the BIOS.
>
Will double check on bios version and get back to you both.
But would you
We have seen some instances where the pci probe of a 82574
is failing like this:
e1000e :07:00.0: PCI INT A -> GSI 46 (level, low) -> IRQ 46
e1000e :07:00.0: setting latency timer to 64
alloc irq_desc for 92 on node 0
alloc kstat_irqs on node 0
e1000e :07:00.0: irq 92 for MSI/MSI-
Ping!
Any info about this one?
--
Arthur
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on
On Fri, Nov 16, 2012 at 04:27:25PM -0800, Jesse Brandeburg wrote:
> On Fri, 16 Nov 2012 14:58:13 -0800 akepner wrote:
>
> > With e1000e (versions 1.2.20, and 2.1.4) we've noticed that the
> > ethtool selftest fails with a miscompare when the interface is
> > up
With e1000e (versions 1.2.20, and 2.1.4) we've noticed that the
ethtool selftest fails with a miscompare when the interface is
up, but succeeds when it's down:
[admin@oak-sh317 ~]# ifconfig lan0_0 up
[admin@oak-sh317 ~]# ethtool -t lan0_0
The test result is FAIL
The test extra info:
Register t
On Thu, Jul 12, 2012 at 11:21:46AM -0700, Alexander Duyck wrote:
> .
> It seems like it might be some sort of memory corruption. In order to
> get into that state the DD bit has to be set for the descriptor and the
> skb would have to be NULL.
>
> What part is it you are running this on? Is
Using the 3.7.21 version of the ixgbe driver we can reliably
produce a crash with this signature:
BUG: unable to handle kernel NULL pointer dereference at 006c
IP: [] ixgbe_poll+0x9df/0x1710 [ixgbe]
PGD 814c7b067 PUD 8074dd067 PMD 0
Oops: [#1] SMP
last sysfs file: /sys/device
12 matches
Mail list logo