On Sat, Oct 12, 2013 at 1:26 AM, Skidmore, Donald C
wrote:
>> -Original Message-
>> From: Greg KH [mailto:gre...@linuxfoundation.org]
>> Sent: Friday, October 11, 2013 9:12 AM
>> To: Bjorn Helgaas
>> Cc: ethan.zhao; linux-ker...@vger.kernel.org; Skidmore, Donald C; e1000-
>> de...@lists.so
On Tue, Sep 10, 2013 at 3:04 PM, Bjorn Helgaas wrote:
> [+cc Thomas, e1000e driver folks, linux-pci, lkml]
>
> On Mon, Jul 15, 2013 at 2:31 AM, wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=60555
>>
>> Bug ID: 60555
>>Summary: Some amount of ifconfig cause load av
On 13-10-11 04:41 AM, Alexander Gordeev wrote:
> On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote:
>> Just to help us all understand "the loop" issue..
>>
>> Here's an example of driver code which uses the existing MSI-X interfaces,
>> for a device which can work with either 16, 8, 4, 2, o
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, October 11, 2013 9:12 AM
> To: Bjorn Helgaas
> Cc: ethan.zhao; linux-ker...@vger.kernel.org; Skidmore, Donald C; e1000-
> de...@lists.sourceforge.net
> Subject: Re: [PATCH] drivers/base/core.c: always o
OK. I'll file an internal bug on this.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565
-Original Message-
From: Petr Cervenka [mailto:gr...@centrum.cz]
Sent: Friday, October 11, 2013 6:30 AM
To: Fujinaka, Todd
On Fri, Oct 11, 2013 at 10:08:09AM -0600, Bjorn Helgaas wrote:
> [+cc Don, e1000-devel]
>
> On Fri, Oct 11, 2013 at 9:35 AM, Greg KH wrote:
> > On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
> >> From: "ethan.zhao"
> >>
> >> While loading ixgbevf driver,every vf detected will be out
[+cc Don, e1000-devel]
On Fri, Oct 11, 2013 at 9:35 AM, Greg KH wrote:
> On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
>> From: "ethan.zhao"
>>
>> While loading ixgbevf driver,every vf detected will be output as the
>> same name 'eth4':
>>
>> ixgbevf: Intel(R) 10 Gigabit PCI Expre
Hello John,
> Hello,
>
> Why would you have an unprogrammed i210 device/NIC? Did something happen
> to the system the device or NIC was in?
No, this is how the chip is sold. ID 0x8086 0x1531 , unprogrammed.
> What type of system is the i210
> in?
Freescale i.MX6 , Designware 1-lane PCIe contr
Hello,
Why would you have an unprogrammed i210 device/NIC? Did something happen to
the system the device or NIC was in? What type of system is the i210 in?
Since you are asking for an eepromARMtool I'm assuming that the i210 is in some
sort of ARM system. Is that correct? Where did the sys
Hello.
I must apologize, because it is not easy to fill internal buffers of network
adapter with unplugged cable. Normal network communication* probably doesn't
reach the driver under such circumstances. Netconsole must be bypassing that
somehow.
(*I tried RAW Ethernet packets.)
Petr
Hello,
I found this thread [1]. I have precisely the same problem (i210 0x8086:0x1531
with unprogrammed NVM connected to i.MX6 PCIe). The only difference is I'm
working with mainline kernel (next/3.12-rc).
Is it correct to assume this i210 cannot operate without programmed iNVM? Where
can I ob
Just to help us all understand "the loop" issue..
Here's an example of driver code which uses the existing MSI-X interfaces,
for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt.
This is from a new driver I'm working on right now:
static int xx_alloc_msix_irqs (struct xx_dev
On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote:
> Just to help us all understand "the loop" issue..
>
> Here's an example of driver code which uses the existing MSI-X interfaces,
> for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt.
> This is from a new driver I'm
13 matches
Mail list logo
