Kok, Auke wrote:
> Kok, Auke wrote:
>> Andrew Morton wrote:
>>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>>>&g
Kok, Auke wrote:
> Andrew Morton wrote:
>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]>
>> wrote:
>>
>>> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>>>
>>> [ 8803.850634] ACPI: Prep
Andrew Morton wrote:
> On Sun, 17 Feb 2008 13:20:59 + "Daniel J Blueman" <[EMAIL PROTECTED]>
> wrote:
>
>> I'm still hitting this with e1000e on 2.6.25-rc2, 10 times again.
are you sure? I don't think that's the case and you're seeing e1000 dumps
here...
>> It's clearly non-fatal, but then
Andrew Morton wrote:
> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
>
>> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>>
>> [ 8803.850634] ACPI: Preparing to enter system sleep state S3
>> [ 8803.853141] Suspending console(s)
>> [ 8805.28
Miklos Szeredi wrote:
>> the register dump looks OK as far as I can see. Since initialization
>> works OK and the adapter seems to be setup OK reading from the
>> register dump, I'm not sure at all what is going on.
>>
>> can you try manually ifup-ing the device and running tcpdump? do you
>> see p
Miklos Szeredi wrote:
>> OK. can you download, install and run `ethregs -i eth0` (from
>> e1000.sf.net) and send me the output? I'll compare with a known
>> working t60 I have here and see if anything shows up.
>
> OK, attached.
>
>> Also, post me the dmesg from after the adapter fails to load
>>
Miklos Szeredi wrote:
>>> - network doesn't always come up at first try (e1000e). On 2.6.24
>>>e1000e doesn't seem to work at all, so I use e1000, but that has
>>>other problems.
>
> It does seem to be using MSI interrupts:
>
>CPU0 CPU1
> 0:2994380 1 I
Kok, Auke wrote:
> Miklos Szeredi wrote:
>> - network doesn't always come up at first try (e1000e). On 2.6.24
>>e1000e doesn't seem to work at all, so I use e1000, but that has
>>other problems.
>
> Andy Gospodarek pointed out a possible problem with
Miklos Szeredi wrote:
> - network doesn't always come up at first try (e1000e). On 2.6.24
>e1000e doesn't seem to work at all, so I use e1000, but that has
>other problems.
Andy Gospodarek pointed out a possible problem with e1000e if you are not using
MSI interrupts (e.g. booting with p
[EMAIL PROTECTED] wrote:
> The patch titled
> drivers/net/e1000: Use FIELD_SIZEOF
> has been added to the -mm tree. Its filename is
> drivers-net-e1000-use-field_sizeof.patch
>
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a
Prakash Punnoor wrote:
> On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
>> Hi,
>>
>> Is it a known problem?
>> Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
>> E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
>> e1000e).
your card wi
Julia Lawall wrote:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
> that matches its definition.
thanks for the (3) patches, I'll make sure they get merged.
Cheers,
Auke
>
> The modification was made using the followin
Ray Lee wrote:
> On Feb 9, 2008 1:51 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> Martin Rogge wrote:
>>> On Saturday 09 February 2008 11:07:26 Martin Rogge wrote:
>>>> Hi,
>>>>
>>>> I am not so familiar with the various mailing lists and
Martin Rogge wrote:
> On Saturday 09 February 2008 11:07:26 Martin Rogge wrote:
>> Hi,
>>
>> I am not so familiar with the various mailing lists and missed out on
>> [EMAIL PROTECTED] the first time. Please cc me on any
>> replies.
>>
>> I am looking for help with either making the e1000e driver wo
Pavel Machek wrote:
> On Thu 2008-02-07 14:32:16, Kok, Auke wrote:
>> Pavel Machek wrote:
>>> Hi!
>>>
>>>>> I have the famous e1000 latency problems:
>>>>>
>>>>> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9
Pavel Machek wrote:
> Hi!
>
>>> I have the famous e1000 latency problems:
>>>
>>> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms
>>> 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms
>>> 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms
>>> 64 bytes from
Max Krasnyansky wrote:
>
> Kok, Auke wrote:
>> Max Krasnyansky wrote:
>>> Kok, Auke wrote:
>>>> Max Krasnyansky wrote:
>>>>> So you don't think it's related to the interrupt coalescing by any chance
>>>>> ?
&g
Pavel Machek wrote:
> Hi!
>
> I have the famous e1000 latency problems:
>
> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms
> 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms
> 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms
> 64 bytes from 195.113.31.
Max Krasnyansky wrote:
> Kok, Auke wrote:
>> Max Krasnyansky wrote:
>>> So you don't think it's related to the interrupt coalescing by any chance ?
>>> I'd suggest to try and disable the coalescing and see if it makes any
>>> difference.
>&
Max Krasnyansky wrote:
> Pavel Machek wrote:
>> Hi!
>>
>> I have the famous e1000 latency problems:
>>
>> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms
>> 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms
>> 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1
Rafael J. Wysocki wrote:
> On Wednesday, 6 of February 2008, Pavel Machek wrote:
>> On Tue 2008-02-05 16:22:55, Kok, Auke wrote:
>>> ?? ??? wrote:
>>>>>>>> I've patched my kernel with the PCIe ASPM and after setting
>>>>&g
?? ??? wrote:
> I've patched my kernel with the PCIe ASPM and after setting
> echo powersave > /sys/module/pcie_aspm/parameters/policy
>
> I started to experience random hangs of my laptop.
> Hardware info:
> Thinkpad x60s 1704-5UG
the x60's chipset doesn't
Greg KH wrote:
> On Tue, Feb 05, 2008 at 10:46:23AM -0800, Arjan van de Ven wrote:
>> On Tue, 5 Feb 2008 18:40:04 +0100
>> ?? <[EMAIL PROTECTED]> wrote:
>>
>>> I've patched my kernel with the PCIe ASPM and after setting
>>> echo powersave > /sys/module/pcie_aspm/pa
Adrian Bunk wrote:
> This patch makes the needlessly global e1000_dump_eeprom() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
yes, thanks, I'll push it to Jeff.
Auke
>
> ---
> b5fd924a1388d4aaa94cf05e42e317c2b1fb5748
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e10
Adrian Bunk wrote:
> This patch makes the needlessly global reg_pattern_test_array() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
stephen hemminger already pointed this out to me... I'll certainly push this
upstream, thanks Adrian!
Auke
>
> ---
> ed72e457f06311390d9a9e51a00c9049
Andreas Mohr wrote:
> Hi,
>
> On Tue, Jan 29, 2008 at 03:09:25PM -0800, Kok, Auke wrote:
>> Andreas Mohr wrote:
>>> Perhaps it's useful to file a bug/patch
>>> on http://sourceforge.net/projects/e1000/ ? Perhaps -mm testing?
>> I wanted to push this
Jeff Garzik wrote:
> Linus Torvalds wrote:
>>
>> On Tue, 29 Jan 2008, Randy Dunlap wrote:
>>> Andrew was concerned about this when the driver was in -mm.
>>> He asked for a patch that would set E1000E to same value as E1000
>>> and I supplied that. Auke acked it IIRC. Other people vetoed it. :(
Jiri Slaby wrote:
> Patch against netdev-2.6 follows.
> --
> writeX functions are not permitted on iomap-ped space change to iowriteX,
> also pci_unmap pci_map-ped space on exit (instead of iounmap).
>
> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> ---
> drivers/net/e100.c |8
> 1
Andreas Mohr wrote:
> Hi,
>
> On Tue, Jan 01, 2008 at 09:09:08PM +0100, Andreas Mohr wrote:
>> Thanks for your quick reply!
>>
>> OK, here's part 1, the MII-less support stuff.
>> (preliminary posting, for review only)
>>
>> Note that these diffs apply to 2.6.24-rc6-mm1 without much trouble,
>> th
Jiri Slaby wrote:
> On 01/28/2008 11:31 PM, Kok, Auke wrote:
>> Andrew Morton wrote:
>>> Please resend when convenient. Maybe more luodly or something, I dunno.
>>
>> just repost to me and Jeff and I'll pick it up this week if Jeff does
>> not.
>
>
Pavel Machek wrote:
> Hi!
>
>> v3->v2, fixed the issues Matthew Wilcox raised.
>>
>> PCI Express ASPM defines a protocol for PCI Express components in the D0
>> state to reduce Link power by placing their Links into a low power state
>> and instructing the other end of the Link to do likewise. Thi
Andrew Morton wrote:
> On Fri, 18 Jan 2008 14:38:51 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>> Jiri Slaby wrote:
>>> readX functions are not permitted on iomap-ped space change to ioreadX,
>>> also pci_unmap pci_map-ped space on exit (instead of iounmap).
>>>
>>> Signed-off-by: Jiri Slaby <
Rick Jones wrote:
>> 1) Interrupts are being processed on both cpus:
>>
>> [EMAIL PROTECTED]:/root> cat /proc/interrupts
>>CPU0 CPU1
>> 30:17037564530785 U3-MPIC Level eth0
>
> IIRC none of the e1000 driven cards are multi-queue
the pci-express variants are, but th
Chris Friesen wrote:
> Kok, Auke wrote:
>
>> You're using 2.6.10... you can always replace the e1000 module with the
>> out-of-tree version from e1000.sf.net, this might help a bit - the
>> version in the
>> 2.6.10 kernel is very very old.
>
> Do you have
Chris Friesen wrote:
> Hi all,
>
> I've got an issue that's popped up with a deployed system running
> 2.6.10. I'm looking for some help figuring out why incoming network
> packets aren't being processed fast enough.
>
> After a recent userspace app change, we've started seeing packets being
> d
[EMAIL PROTECTED] wrote:
> I am running 2.6.23 kernel on a DUAL core and QUAD core i386 boxes and
> after everyboot, when the ethernet traffic starts i get this warning.
>
> All the ports in the system are e1000 and i am using the kernel e1000
> driver.
[added netdev to the Cc:]
can you repro th
Shaohua Li wrote:
> On Thu, 2008-01-03 at 11:33 -0800, Kok, Auke wrote:
>> Shaohua Li wrote:
>>> PCI Express ASPM defines a protocol for PCI Express components in the D0
>>> state to reduce Link power by placing their Links into a low power state
>>> and instruc
Shaohua Li wrote:
> PCI Express ASPM defines a protocol for PCI Express components in the D0
> state to reduce Link power by placing their Links into a low power state
> and instructing the other end of the Link to do likewise. This
> capability allows hardware-autonomous, dynamic Link power reduct
Andreas Mohr wrote:
> Hi all,
>
> I was mildly annoyed when rebooting my _headless_ internet gateway after a
> hotplug -> udev migration and witnessing it not coming up again,
> which turned out to be due to an eepro100 / e100 loading conflict
> since eepro100 supported both of my Intel-based netw
pradeep pradeep wrote:
> Hi,
> I want to support a new PCI based VGA card in
> linux. I want to know what is the VGA driver stack in
> the Linux. Can any one help me where to start.
Assuming you're not talking about a VGA grabber card here...
Graphics/ X drivers are mostly in userspace except
Stephen Hemminger wrote:
> On Thu, 20 Dec 2007 15:36:13 -0500
> "Parag Warudkar" <[EMAIL PROTECTED]> wrote:
>
>> On Dec 20, 2007 3:04 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
I think it is reasonable for Network driver watchdogs to use a
deferrable timer - if the machine is 100% I
Arjan van de Ven wrote:
>
My interpretation of the api is:
* round_jiffies() - timer wants to wakeup but isn't precise
about when so schedule
on next second when system will wake up anyway;
e.g why meetings are usually sc
Parag Warudkar wrote:
> On Dec 20, 2007 12:05 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> I can't even apply this patch and the e1000 one... not only is it whitespace
>> damaged it is also not properly formatted as patch at all. If you want me to
>> take
>>
Stephen Hemminger wrote:
> On Thu, 20 Dec 2007 17:29:23 +
>
>> -Original Message-
>> From: Stephen Hemminger <[EMAIL PROTECTED]>
>>
>> Date: Thu, 20 Dec 2007 09:16:03
>> To:[EMAIL PROTECTED]
>> Cc:[EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org
>> Subject: Re:
Parag Warudkar wrote:
>
> Reduce wakeups from idle per second.
>
> Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
>
> --- linux-2.6/drivers/net/e1000e/netdev.c2007-12-07
> 10:04:39.0 -0500
> +++ linux-2.6-work/drivers/net/e1000e/netdev.c2007-12-18
> 20:45:59.0 -0500
>
Parag Warudkar wrote:
> On Dec 19, 2007 4:38 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> Parag Warudkar wrote:
>>> On 12/19/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> why would this patch reduce wakeups even more than round_jiffies()? Does it
>> make
>
Parag Warudkar wrote:
> On 12/19/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
> [snip]
>
>> I can't possibly see any benefit from this other than that you just add up
>> to a
>> whole second to the initialization cycle, which is bad.
>>
> Well, Ok b
Parag Warudkar wrote:
>
> Use deferrable timer for watchdog. Reduces wakeups from idle per second.
no, we don't want this. We already allow the re-scheduling of the watchdog to be
round_jiffies() modified so that it coincides with other interrupts.
but at load time we don't want the timer to be
Parag Warudkar wrote:
>
> Reduce wakeups from idle per second.
>
> Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
>
> --- linux-2.6/drivers/net/e1000e/netdev.c2007-12-07
> 10:04:39.0 -0500
> +++ linux-2.6-work/drivers/net/e1000e/netdev.c2007-12-18
> 20:45:59.0 -0500
>
Ivan Kokshaysky wrote:
> Check that the e100 is in the D0 power state. If it's not, it won't
> respond to MMIO accesses and we end up with master-abort machine
> checks on some platforms.
>
> Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
what kind of platform actually is doing this? It almos
David Miller wrote:
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 09:13:54 -0500
>
>> If the netif_running() check is indeed required to make a device break
>> out of napi polling and respond to an ifconfig down, then I think the
>> netif_running() check should be moved up i
David Miller wrote:
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> Date: Wed, 12 Dec 2007 12:29:23 -0500
>
>> Is the netif_running() check even required?
>
> No, it is not.
>
> When a device is brought down, one of the first things
> that happens is that we wait for all pending NAPI polls
> to co
[EMAIL PROTECTED] wrote:
> The patch titled
> e1000e: make E1000E default to the same kconfig setting as E1000
> has been added to the -mm tree. Its filename is
> e1000e-make-e1000e-default-to-the-same-kconfig-setting-as-e1000.patch
>
> *** Remember to use Documentation/SubmitChecklist
Andrew Morton wrote:
> On Tue, 11 Dec 2007 13:26:58 -0800
> "Kok, Auke" <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[EMAIL PROTECTED]> wrote:
>>>
>>>>> -
Kok, Auke wrote:
> Andrew Morton wrote:
>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[EMAIL PROTECTED]> wrote:
>>
>>>> - Lots of device IDs have been removed from the e1000 driver and moved
>>>> over
>>>> to e1000e. S
Andrew Morton wrote:
> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[EMAIL PROTECTED]> wrote:
>
>>>
>>> - Lots of device IDs have been removed from the e1000 driver and moved
>>> over
>>> to e1000e. So if your e1000 stops working, you forgot to set
>>> CONFIG_E1000E.
>>>
>>>
>> Wouldn't it
Roel Kluin wrote:
> drivers/net/e1000/e1000_ethtool.c:113:
> #define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN
>
> drivers/net/e1000e/ethtool.c:106:
> #define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN
>
> E1000_TEST_LEN*ETH_GSTRING_LEN will expand to
> sizeo
Roel Kluin wrote:
> drivers/net/e1000/e1000_ethtool.c:113:
> #define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN
>
> drivers/net/e1000e/ethtool.c:106:
> #define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN
>
> E1000_TEST_LEN*ETH_GSTRING_LEN will expand to
> sizeo
Lukas Hejtmanek wrote:
> On Mon, Nov 26, 2007 at 03:26:08PM -0800, Kok, Auke wrote:
>> The fix for this has been to grant more time for the hardware to recover
>> from this busy state. I'll make sure to check if the upstream drivers are OK
>> in this regard.
>>
>
Lukas Hejtmanek wrote:
> Hello,
>
> I have laptop thinkpad T61 with 82566MM Gigabit Network Connection (rev 03)
> (8086:1049). I have kernel 2.6.24-rc3. E1000E driver does not work (the card
> is not detected although it is PCI-E), with E1000 driver, it works mostly OK
> unless I force speed to 10
Jeff Garzik wrote:
> 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/insecu
Joe Perches wrote:
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> ---
> drivers/net/ixgbe/ixgbe_common.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_common.c
> b/drivers/net/ixgbe/ixgbe_common.c
> index 512e3b2..b7e50bc 100644
> ---
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>> Kok, Auke wrote:
>>>> Patrick McHardy wrote:
>>>>
>>>>> I already posted a patch for this, not sure what happened to it.
>>>>> Auke, any news on mergin
Denys Vlasenko wrote:
> On Wednesday 14 November 2007 00:27, Adrian Bunk wrote:
>> You missed the following in my email:
>> "we slowly scare them away due to the many bug reports without any
>> reaction."
>>
>> The problem is that bug reports take time. If you go away from easy
>> things like comp
Joonwoo Park wrote:
> 2007/11/14, Kok, Auke <[EMAIL PROTECTED]>:
>> Patrick McHardy wrote:
>>> Kok, Auke wrote:
>>>> Patrick McHardy wrote:
>>>>
>>>>> I already posted a patch for this, not sure what happened to it.
>>>&g
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>
>>> I already posted a patch for this, not sure what happened to it.
>>> Auke, any news on merging the secondary unicast address support?
>>
>> I dropped the ball on that one. Care
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>
>>> I already posted a patch for this, not sure what happened to it.
>>> Auke, any news on merging the secondary unicast address support?
>>
>> I dropped the ball on that one. Care
Patrick McHardy wrote:
> Herbert Xu wrote:
>> On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which cas
Willy Tarreau wrote:
> On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
>> From: Willy Tarreau <[EMAIL PROTECTED]>
>> Date: Tue, 13 Nov 2007 00:15:16 +0100
>>
>>> I can say that sometimes you'd like to be aware that one of your
>>> VLANs is wrong and you'd simply like to sniff the wire
Chris Friesen wrote:
> David Miller wrote:
>
>> When you select VLAN, you by definition are asking for non-VLAN
>> traffic to be elided. It is like plugging the ethernet cable
>> into one switch or another.
>
> For max functionality it seems like the raw eth device should show
> everything on th
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Joonwoo Park wrote:
>>> IMHO even though netdevice is in the promiscuous mode, we should receive
>>> all of ingress packets.
>>> This disable the vlan filtering feature when a vlan hw accel configured
>>
Joonwoo Park wrote:
> IMHO even though netdevice is in the promiscuous mode, we should receive all
> of ingress packets.
> This disable the vlan filtering feature when a vlan hw accel configured e1000
> device goes into promiscuous mode.
> This make packets visible to sniffers though it's not vla
David Miller wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 22:20:30 -0400
>
>> David Miller wrote:
>>> From: Jeff Garzik <[EMAIL PROTECTED]>
>>> Date: Tue, 23 Oct 2007 21:03:36 -0400
>>>
I'm wondering if there is a way to avoid adding
if (!is_valid_ether
Jeff Garzik wrote:
> Bill Davidsen wrote:
>> Adrian Bunk wrote:
>>> This patch contains the planned removal of the eepro100 driver.
>>>
>> Are the e100 people satisfied that e100 now handles all known cases? I
>
> Nope. There are still e100 work outstanding that means we cannot kill
> eepro100.
David Miller wrote:
> From: Dave Jones <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 17:20:26 -0400
>
>> Indeed. This is a common enough problem that not including it causes
>> more pain than its worth. I have two affected boxes myself that I
>> actually thought the hardware was dead before I trie
Dave Jones wrote:
> On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
>
> > > In any case, this patch should not be merged. We often send it around to
> users to
> > > debug their issue in case it involves eeproms, but merging it will just
> conceal
> > > the real issue and all of
Jeff Garzik wrote:
> Kok, Auke wrote:
>> Adam Jackson wrote:
>>> On Tue, 2007-10-23 at 09:18 -0700, Kok, Auke wrote:
>>>> Adam Jackson wrote:
>>>>> When the EEPROM gets corrupted, you can fix it with ethtool, but
>>>>> only if
>>>
Adam Jackson wrote:
> On Tue, 2007-10-23 at 09:18 -0700, Kok, Auke wrote:
>> Adam Jackson wrote:
>>> When the EEPROM gets corrupted, you can fix it with ethtool, but only if
>>> the module loads and creates a network device. But, without this option,
>>> if
Adam Jackson wrote:
> When the EEPROM gets corrupted, you can fix it with ethtool, but only if
> the module loads and creates a network device. But, without this option,
> if the EEPROM is corrupted, the driver will not create a network device.
>
> Signed-off-by: Adam Jackson <[EMAIL PROTECTED]>
Lennart Sorensen wrote:
> On Fri, Oct 12, 2007 at 01:46:33PM -0700, Kok, Auke wrote:
>> I would assume that that is true for all PHY's - if there is no link to keep
>> the
>> carrier active on I would think that the power consumption is nominal across
>> the
>
Dmitry Torokhov wrote:
> On 10/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, 16 Oct 2007, Matthew Garrett wrote:
It still doesn't mean it belongs inside the stream of data for the
keyboard,
maskerading as a key press.
>>> But it *is* a key press!
>> To get somewhat
Adrian Bunk wrote:
> You want to check for the value, not for the address.
>
> Spotted by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> --- a/drivers/net/e1000e/ethtool.c
> +++ b/drivers/net/e1000e/ethtool.c
> @@ -1451,11 +1451,11 @@ static int e1000_loopback
[EMAIL PROTECTED] wrote:
> On Fri, 12 Oct 2007 09:35:15 PDT, "Kok, Auke" said:
>
>>> How much power does a non-connected NIC consume, and can you save power
>>> by forcing 10 MBit until a link is detected (doubling negotiation time)?
>> no, the PHY cons
Vitaliy Gusev wrote:
> On the 28 September 2007 03:13 Greg KH, wrote:
>> On Thu, Sep 27, 2007 at 11:36:32AM -0700, Kok, Auke wrote:
>>> Ivan Kokshaysky wrote:
>>>> On Wed, Sep 26, 2007 at 03:20:40PM -0700, Jesse Barnes wrote:
>>>>> Ivan, your con
Bodo Eggert wrote:
> Kok, Auke <[EMAIL PROTECTED]> wrote:
>> K.Prasad wrote:
>
>>> Without the side-effect of experiencing a link-flap when switching to a
>>> lower-speed (with its toll in terms of down-time for auto-negotiation,
>>> STP, etc), t
Mark Gross wrote:
> On Tue, Oct 09, 2007 at 11:41:17AM -0700, Kok, Auke wrote:
>> Lennart Sorensen wrote:
>>> On Mon, Oct 08, 2007 at 03:31:51PM -0700, Kok, Auke wrote:
>>>> you most certainly want to do this in userspace I think.
>>>>
>>>> On
K.Prasad wrote:
> On Wed, 10 Oct 2007 00:11:17 +0530, Kok, Auke <[EMAIL PROTECTED]>
> wrote:
>
>> Lennart Sorensen wrote:
>>> On Mon, Oct 08, 2007 at 03:31:51PM -0700, Kok, Auke wrote:
>>>> you most certainly want to do this in userspace I think.
>>
Lennart Sorensen wrote:
> On Mon, Oct 08, 2007 at 03:31:51PM -0700, Kok, Auke wrote:
>> you most certainly want to do this in userspace I think.
>>
>> One of the biggest problems is that link negotiation can take a significant
>> amount
>> of time, well ove
Pavel Machek wrote:
> Hi!
>
> I've found that gbit vs. 100mbit power consumption difference is about
> 1W -- pretty significant. (Maybe powertop should include it in the
> tips section? :).
>
> Energy Star people insist that machines should switch down to 100mbit
> when network is idle, and I gue
maximilian attems wrote:
> Linux tau 2.6.23-rc8-mm2-686 #1 SMP Wed Oct 3 23:56:32 CEST 2007 i686
> GNU/Linux
>
> eth0 renamed to eth1
> sysfs: duplicate filename 'eth1' can not be created
> WARNING: at fs/sysfs/dir.c:433 sysfs_add_one()
> [] dump_trace+0x68/0x1d5
> [] show_trace_log_lvl+0x18/0x2
[EMAIL PROTECTED] wrote:
> The patch titled
> eepro100: Avoid potential NULL pointer deref in speedo_init_rx_ring()
> has been removed from the -mm tree. Its filename was
> eepro100-avoid-potential-null-pointer-deref-in-speedo_init_rx_ring.patch
>
> This patch was dropped because an upd
Ivan Kokshaysky wrote:
> On Wed, Sep 26, 2007 at 03:20:40PM -0700, Jesse Barnes wrote:
>> Ivan, your concern is about disabling things like interrupt controllers
>> and power management chips during probe right? You're right that doing
>> that could cause problems if we get and interrupt or PMU
Erez Zadok wrote:
> Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
> ---
> fs/unionfs/copyup.c | 102 +-
> 1 files changed, 51 insertions(+), 51 deletions(-)
>
> diff --git a/fs/unionfs/copyup.c b/fs/unionfs/copyup.c
> index 23ac4c8..e3c5f15 100644
John Duthie wrote:
> I'm having a few Problems with a NEW PC
>
> Spec is:
> Intel DQ35JOE Mainboard
>
> The Integrated NIC is not found by kernel 2.6.23-rc6 or 2.6.22.1
> Am I missing an option in there ??
support for that nic has not yet been released as a -rc or stable kernel release
> The I
Dan Williams wrote:
On Thu, 2007-09-13 at 01:30 -0400, Jeff Garzik wrote:
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/atl1/atl1_main.c | 19 +++
d
[EMAIL PROTECTED] wrote:
The patch titled
git-net-broke-ixgbe
has been added to the -mm tree. Its filename is
git-net-broke-ixgbe.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to
Adrian Bunk wrote:
This patch contains the planned removal of the eepro100 driver.
Signed-off-by: Adrian Bunk
you lost your e-mail address? :)
---
This patch has been sent on:
- 14 Aug 2007
- 29 Jul 2007
currently we won't have e100 fixed up for ARM in 2.6.23, so removing this for
2.6.2
Joe Perches wrote:
On Wed, 2007-08-15 at 19:19 -0700, Kok, Auke wrote:
Joe Perches wrote:
On Wed, 2007-08-15 at 19:58 -0400, Dave Jones wrote:
There's more than a few of these (not inspected).
$ egrep -r --include=*.c "\bif[[:space:]]*\([^\)]*\)[[:space:]]*\;" *
arch/sh/boar
Joe Perches wrote:
On Wed, 2007-08-15 at 19:58 -0400, Dave Jones wrote:
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c
index 3330917..0ed02b7 100644
--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw
Rick Jones wrote:
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Fri, 10 Aug 2007 15:40:02 -0700
For GSO on output, is there a generic fallback for any driver that
does not specifically implement GSO?
Absolutely, in fact that's mainly what it's there for.
I don't think ther
1 - 100 of 201 matches
Mail list logo
