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
On Sun, 19 May 2013, Or Gerlitz wrote:
On Sun, May 19, 2013 at 1:25 PM, Eliezer Tamir
eliezer.ta...@linux.intel.com 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 -
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
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 e1000
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
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 was
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
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 if IRQs
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.
>>
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.
Somewhere the range was
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
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 interrupt
rescheduling based on the return value from
[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
[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 reason/ ? ;-)
The
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
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);
>
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);
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.
Brandeburg,
Don't we need to return non-zero work_done after
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
>
forwarding whole message for netdev to review
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
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
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 seems that several Tyan
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
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 CONFIG_DEBUG_SHIRQ
+
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
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 months to
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
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 PROTECTED], but
>+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 |
+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 |
30 matches
Mail list logo
