Frans Pop wrote:
> There is one thing I don't understand, but that may well be just me...
>
> From Linus' original patch:
>> +++ b/drivers/net/e1000/e1000_main.c
>> + INTEL_E1000_ETHERNET_DEVICE(0x108C),
>
> So, apparently support for 8086:108c was removed from the e1000
> driver.
When it w
Bill Fink wrote:
> a 2.6.15.4 kernel. The GigE NICs are Intel PRO/1000
> 82546EB_QUAD_COPPER,
> on a 64-bit/133-MHz PCI-X bus, using version 6.1.16-k2 of the e1000
> driver, and running with 9000-byte jumbo frames. The TCP congestion
> control is BIC.
Bill, FYI, there was a known issue with e10
On Sun, 19 May 2013, Or Gerlitz wrote:
> On Sun, May 19, 2013 at 1:25 PM, Eliezer Tamir
> wrote:
> > This is an updated version of the code we posted on February.
>
> Last time you've placed a copy of the patchset in the rfc branch of
> git://github.com/jbrandeb/lls.git - can you repost there V2
Joonwoo Park wrote:
> /* If no Tx and not enough Rx work done, exit the polling mode */
> if ((!tx_cleaned && (work_done == 0)) ||
>!netif_running(poll_dev)) {
> quit_polling:
> if (likely(adapter->itr_setting & 3))
> e1000_set_itr(adapter);
> netif_rx_co
Joonwoo Park wrote:
> 2007/12/12, Brandeburg, Jesse <[EMAIL PROTECTED]>:
>>
>> all drivers using NAPI in 2.6.24+ (NNAPI??) must return zero here,
>> after calling netif_rx_complete. netif_rx_complete plus work_done
>> != 0 causes a bug.
>>
>
> B
David Miller wrote:
> From: Robert Olsson <[EMAIL PROTECTED]>
> Date: Fri, 18 Jan 2008 14:00:57 +0100
>
>> I don't understand the idea with semaphore for enabling/disabling
>> irq's either the overall logic must safer/better without it.
>
> They must have had code paths where they didn't know i
Ian Wienand wrote:
> Hi,
>
> When rebooting today I got
>
> Will now restart.
> ACPI: PCI interrupt for device :00:03.0 disabled
> GSI 20 (level, low) -> CPU 1 (0x0100) vector 53 unregistered
> Destroying IRQ53 without calling free_irq
> WARNING: at
> /home/insecure/ianw/programs/git-kernel
[EMAIL PROTECTED] wrote:
> Quoting Frans Pop <[EMAIL PROTECTED]>:
>>> (Note this isn't the final correct patch we should apply. There is
>>> no reason why this revert back to the older ->poll() logic here
>>> should have any effect on the TX hang triggering...)
>>
>> s/no reason/no obvious reas
David Miller wrote:
> From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
> Date: Tue, 15 Jan 2008 13:53:43 -0800
>
>> The tx code has an "early exit" that tries to limit the amount of tx
>> packets handled in a single poll loop and requires napi or inte
Andrew Morton wrote:
> On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh"
> <[EMAIL PROTECTED]> wrote:
>
>>
>> The problem is
modprobe:2584 conflicting cache attribute 5000-50001000
uncached<->default
>>
>> Some address range here is being mapped with conflicting types.
>>
>+static void e100_shutdown(struct device *dev)
>+{
>+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
>+ struct net_device *netdev = pci_get_drvdata(pdev);
>+ struct nic *nic = netdev_priv(netdev);
>+
>+ pci_enable_wake(pdev, PCI_D0, nic->flags & (wol_magic |
>e1
added Linux-pci
Jesse Brandeburg wrote:
> On 1/16/07, Allen Parker <[EMAIL PROTECTED]> wrote:
>> Allen Parker wrote:
>>> I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
>>> under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier
>>> today I reported this to [EMAIL PROTE
John wrote:
> Jesse Brandeburg wrote:
>> What would you like to do? At this stage I would like e100 to work
>> better than it is, but I'm not sure what to do next.
>
> Hello everyone,
>
> I'm resurrecting this thread because it appears we'll need to support
> these motherboards for several month
Eric W. Biederman wrote:
> Len Brown <[EMAIL PROTECTED]> writes:
>
>> e1000 faults in 2.6.20-git, while 2.6.20 worked fine.
>>
>> System is a D875PBZ with LOM.
>>
>> clues?
>
> I'm guessing this is an old bug found by the following bit of
> debug coded added into since v2.6.20
>
> +#ifdef CONF
Roberto Nibali wrote:
>>> Sounds sane to me. My overall opinion on eepro100 removal is that
>>> we're not there yet. Rare problem cases remain where e100 fails
>>> but eepro100 works, and it's older drivers so its low priority for
>>> everybody.
>>>
>>> Needs to happen, though...
>>
>> It seem
15 matches
Mail list logo
