* [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
@ 2008-04-04 21:11 ` Kok, Auke
0 siblings, 0 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-04 21:11 UTC (permalink / raw
To: Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist
Cc: Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven
All,
>From kernel 2.6.26 onward all *PCI Express* device IDs previously
supported by e1000 will be moving to the e1000e driver. This includes
ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and
82571/2/3 chipset based adapters and variants.
If you have not already enabled CONFIG_E1000E make sure that you do so.
You can already do this with 2.6.25. From 2.6.26 on this change will be
required if you have such a device.
It is also worthwhile to note you will have to update your modprobe.conf
or equivalent file to point existing interfaces to the new driver.
For clarity, please note that all 8254x devices are only supported by
e1000, even if they are hidden behind a PCI Express bridge. They are
still regular PCI or PCI-X devices.
Intel will continue to support both e1000 and e1000e drivers in the
kernel.
Regards,
Auke
^ permalink raw reply [flat|nested] 125+ messages in thread
* [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
@ 2008-04-04 21:11 ` Kok, Auke
0 siblings, 0 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-04 21:11 UTC (permalink / raw
To: Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist
Cc: Jeff Garzik, Greg KH, Allan, Bruce W, Jesse Brandeburg,
Ronciak, John, Arjan van de Ven, Andrew Morton, Linus Torvalds,
David S. Miller
All,
>From kernel 2.6.26 onward all *PCI Express* device IDs previously
supported by e1000 will be moving to the e1000e driver. This includes
ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and
82571/2/3 chipset based adapters and variants.
If you have not already enabled CONFIG_E1000E make sure that you do so.
You can already do this with 2.6.25. From 2.6.26 on this change will be
required if you have such a device.
It is also worthwhile to note you will have to update your modprobe.conf
or equivalent file to point existing interfaces to the new driver.
For clarity, please note that all 8254x devices are only supported by
e1000, even if they are hidden behind a PCI Express bridge. They are
still regular PCI or PCI-X devices.
Intel will continue to support both e1000 and e1000e drivers in the
kernel.
Regards,
Auke
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-04 21:11 ` Kok, Auke
(?)
@ 2008-04-04 21:31 ` Dave Hansen
2008-04-04 21:49 ` [E1000-devel] " Kok, Auke
2008-04-04 21:52 ` Jeff Garzik
-1 siblings, 2 replies; 125+ messages in thread
From: Dave Hansen @ 2008-04-04 21:31 UTC (permalink / raw
To: Kok, Auke
Cc: Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven
On Fri, 2008-04-04 at 14:11 -0700, Kok, Auke wrote:
> >From kernel 2.6.26 onward all *PCI Express* device IDs previously
> supported by e1000 will be moving to the e1000e driver. This includes
> ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and
> 82571/2/3 chipset based adapters and variants.
>
> If you have not already enabled CONFIG_E1000E make sure that you do so.
> You can already do this with 2.6.25. From 2.6.26 on this change will be
> required if you have such a device.
I've been bitten by one or two of these in the past. Can we do
something like this for a couple of releases?
Shouldn't this default the E1000E config option to the same thing that
people have the E1000 set as? It should catch the dumb people like me
who's enter key gets held down during a 'make oldconfig'. :)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 3a0b20a..aa0fe14 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2005,6 +2005,7 @@ config E1000_DISABLE_PACKET_SPLIT
config E1000E
tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
depends on PCI
+ default E1000
---help---
This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
ethernet family of adapters. For PCI or PCI-X e1000 adapters,
-- Dave
^ permalink raw reply related [flat|nested] 125+ messages in thread
* Re: [E1000-devel] [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-04 21:31 ` Dave Hansen
@ 2008-04-04 21:49 ` Kok, Auke
2008-04-04 21:52 ` Jeff Garzik
1 sibling, 0 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-04 21:49 UTC (permalink / raw
To: Dave Hansen
Cc: Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Jesse Brandeburg,
Ronciak, John, Arjan van de Ven, Greg KH, linux-pci maillist,
Linus Torvalds, Andrew Morton
Dave Hansen wrote:
> On Fri, 2008-04-04 at 14:11 -0700, Kok, Auke wrote:
>> >From kernel 2.6.26 onward all *PCI Express* device IDs previously
>> supported by e1000 will be moving to the e1000e driver. This includes
>> ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and
>> 82571/2/3 chipset based adapters and variants.
>>
>> If you have not already enabled CONFIG_E1000E make sure that you do so.
>> You can already do this with 2.6.25. From 2.6.26 on this change will be
>> required if you have such a device.
>
> I've been bitten by one or two of these in the past. Can we do
> something like this for a couple of releases?
>
> Shouldn't this default the E1000E config option to the same thing that
> people have the E1000 set as? It should catch the dumb people like me
> who's enter key gets held down during a 'make oldconfig'. :)
that discussion went into the bar and never came out again last time it was
proposed. I really do not want to have any more bandages around.
Also your patch will not help much since in 2.6.24 there already is a
CONFIG_E1000E option so we've passed the stage for many people where this hack
would work.
Auke
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-04 21:31 ` Dave Hansen
@ 2008-04-04 21:52 ` Jeff Garzik
2008-04-04 21:52 ` Jeff Garzik
1 sibling, 0 replies; 125+ messages in thread
From: Jeff Garzik @ 2008-04-04 21:52 UTC (permalink / raw
To: Dave Hansen
Cc: Kok, Auke, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven
Dave Hansen wrote:
> On Fri, 2008-04-04 at 14:11 -0700, Kok, Auke wrote:
>> >From kernel 2.6.26 onward all *PCI Express* device IDs previously
>> supported by e1000 will be moving to the e1000e driver. This includes
>> ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and
>> 82571/2/3 chipset based adapters and variants.
>>
>> If you have not already enabled CONFIG_E1000E make sure that you do so.
>> You can already do this with 2.6.25. From 2.6.26 on this change will be
>> required if you have such a device.
>
> I've been bitten by one or two of these in the past. Can we do
> something like this for a couple of releases?
>
> Shouldn't this default the E1000E config option to the same thing that
> people have the E1000 set as? It should catch the dumb people like me
> who's enter key gets held down during a 'make oldconfig'. :)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 3a0b20a..aa0fe14 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2005,6 +2005,7 @@ config E1000_DISABLE_PACKET_SPLIT
> config E1000E
> tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
> depends on PCI
> + default E1000
> ---help---
> This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
> ethernet family of adapters. For PCI or PCI-X e1000 adapters,
That's not pretty for embedded folks who don't want an extra driver to
come along for the ride ;-)
It's also been suggested, as an alternative, to add 'select E1000E' to
E1000's Kconfig entry.
Rather than doing that, I am hoping that education -- Auke's
announcements -- plus "ripping the band-aid off quickly", will be the
best approach.
Most kernel distributions will have enabled both Kconfig options anyway,
so that leaves individual kernel hackers who missed the announcements as
the only target audience for the patch quoted above.
And as a side note... we really really try not to do this very often.
Migrating users from one driver to another is not a seamless process in
Linux -- but unfortuantely the alternative solution, the same PCI ID in
multiple drivers, presents an even worse set of breakages and problems.
This e1000->e1000e move is an exception to the rule.
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
@ 2008-04-04 21:52 ` Jeff Garzik
0 siblings, 0 replies; 125+ messages in thread
From: Jeff Garzik @ 2008-04-04 21:52 UTC (permalink / raw
To: Dave Hansen
Cc: Kok, Auke, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Jesse Brandeburg,
Ronciak, John, Arjan van de Ven, Greg KH, linux-pci maillist,
Linus Torvalds, Andrew Morton
Dave Hansen wrote:
> On Fri, 2008-04-04 at 14:11 -0700, Kok, Auke wrote:
>> >From kernel 2.6.26 onward all *PCI Express* device IDs previously
>> supported by e1000 will be moving to the e1000e driver. This includes
>> ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and
>> 82571/2/3 chipset based adapters and variants.
>>
>> If you have not already enabled CONFIG_E1000E make sure that you do so.
>> You can already do this with 2.6.25. From 2.6.26 on this change will be
>> required if you have such a device.
>
> I've been bitten by one or two of these in the past. Can we do
> something like this for a couple of releases?
>
> Shouldn't this default the E1000E config option to the same thing that
> people have the E1000 set as? It should catch the dumb people like me
> who's enter key gets held down during a 'make oldconfig'. :)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 3a0b20a..aa0fe14 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2005,6 +2005,7 @@ config E1000_DISABLE_PACKET_SPLIT
> config E1000E
> tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
> depends on PCI
> + default E1000
> ---help---
> This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
> ethernet family of adapters. For PCI or PCI-X e1000 adapters,
That's not pretty for embedded folks who don't want an extra driver to
come along for the ride ;-)
It's also been suggested, as an alternative, to add 'select E1000E' to
E1000's Kconfig entry.
Rather than doing that, I am hoping that education -- Auke's
announcements -- plus "ripping the band-aid off quickly", will be the
best approach.
Most kernel distributions will have enabled both Kconfig options anyway,
so that leaves individual kernel hackers who missed the announcements as
the only target audience for the patch quoted above.
And as a side note... we really really try not to do this very often.
Migrating users from one driver to another is not a seamless process in
Linux -- but unfortuantely the alternative solution, the same PCI ID in
multiple drivers, presents an even worse set of breakages and problems.
This e1000->e1000e move is an exception to the rule.
Jeff
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-04 21:11 ` Kok, Auke
(?)
(?)
@ 2008-04-08 8:36 ` Ingo Molnar
2008-04-08 14:21 ` Jeff Garzik
` (3 more replies)
-1 siblings, 4 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 8:36 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> From kernel 2.6.26 onward all *PCI Express* device IDs previously
> supported by e1000 will be moving to the e1000e driver. This includes
> ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and
> 82571/2/3 chipset based adapters and variants.
>
> If you have not already enabled CONFIG_E1000E make sure that you do
> so. You can already do this with 2.6.25. From 2.6.26 on this change
> will be required if you have such a device.
i'm not sure it's a good idea to unsupport hardware in a driver. It's OK
to phase out a driver and restrict it to legacy hardware, it's OK to
have an opt-in .config option for distros to select (or maybe even
opt-out) to narrow down the number of PCI IDs that a driver recognizes,
but lets not artificially break setups that worked before.
( sidenote: isnt there some facility that selects the "better" driver in
case there is an overlap between PCI IDs - with the ability for users
to override that selection? )
such driver transitions are never smooth. For example there's an open
e1000e/e1000 regression in .25 in this area that i just noticed on a
testbox while doing randconfig testing. (that's why i noticed this
message of yours on lkml, i was searching for e1000 regression reports).
The following .config results in a non-working e1000 driver in a
bzImage:
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
CONFIG_E1000_DISABLE_PACKET_SPLIT=y
CONFIG_E1000E=m
CONFIG_E1000E_ENABLED=y
the interface just doesnt come up.
This makes it work:
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
CONFIG_E1000_DISABLE_PACKET_SPLIT=y
# CONFIG_E1000E is not set
# CONFIG_E1000E_ENABLED is not set
please fix such interactions and make the transition as smooth and as
compatible as possible.
the hardware is a stock T60 laptop with:
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
ich7 onboard LAN. (can send more info if needed.)
I just tried the same .config on another box with onboard e1000 (a
desktop system with a different e1000 version), which is ich9, and that
broke too.
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-08 8:36 ` Ingo Molnar
@ 2008-04-08 14:21 ` Jeff Garzik
2008-04-08 15:08 ` Jeff Garzik
2008-04-08 14:56 ` Andi Kleen
` (2 subsequent siblings)
3 siblings, 1 reply; 125+ messages in thread
From: Jeff Garzik @ 2008-04-08 14:21 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> ( sidenote: isnt there some facility that selects the "better" driver in
> case there is an overlap between PCI IDs - with the ability for users
> to override that selection? )
No.
Multiple PCI IDs in the same driver creates all sorts of problems,
because it becomes an ambiguious selection where automated tools cannot
make a choice for you.
Each one typically requires special case code in relevant distro
installers, hardware detectors, and similar gadgets, since the normal
modules.pcimap stuff doesn't work due to the duplicate IDs.
We have no way to export which is the "preferred" driver -- and indeed
in many cases, that's an impossible task, since the "preferred" driver
for a user sometimes depends on the hardware's programmed mode rather
than just a choice.
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-08 8:36 ` Ingo Molnar
@ 2008-04-08 14:56 ` Andi Kleen
2008-04-08 14:56 ` Andi Kleen
` (2 subsequent siblings)
3 siblings, 0 replies; 125+ messages in thread
From: Andi Kleen @ 2008-04-08 14:56 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
Ingo Molnar <mingo@elte.hu> writes:
>
> ( sidenote: isnt there some facility that selects the "better" driver in
> case there is an overlap between PCI IDs - with the ability for users
> to override that selection? )
The default action for driver auto loaders in this case is usually to load
all of them unless specially overriden. That is because there are several
cases where one PCI-ID implements multiple functions served by different
drivers. So far there is no really clean solution to this problem and for
e1000 with PCI-E IDs it would do the wrong thing.
-Andi
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
@ 2008-04-08 14:56 ` Andi Kleen
0 siblings, 0 replies; 125+ messages in thread
From: Andi Kleen @ 2008-04-08 14:56 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Andrew Morton, Jeff Garzik, e1000-list, NetDev,
Allan, Bruce W, Linux Kernel Mailing List, Jesse Brandeburg,
Rafael J. Wysocki, Linus Torvalds, Ronciak, John, Greg KH,
linux-pci maillist, Arjan van de Ven, David S. Miller
Ingo Molnar <mingo@elte.hu> writes:
>
> ( sidenote: isnt there some facility that selects the "better" driver in
> case there is an overlap between PCI IDs - with the ability for users
> to override that selection? )
The default action for driver auto loaders in this case is usually to load
all of them unless specially overriden. That is because there are several
cases where one PCI-ID implements multiple functions served by different
drivers. So far there is no really clean solution to this problem and for
e1000 with PCI-E IDs it would do the wrong thing.
-Andi
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-08 14:21 ` Jeff Garzik
@ 2008-04-08 15:08 ` Jeff Garzik
0 siblings, 0 replies; 125+ messages in thread
From: Jeff Garzik @ 2008-04-08 15:08 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Jeff Garzik wrote:
> Multiple PCI IDs in the same driver creates all sorts of problems,
Clearly, I meant "the same PCI ID in multiple drivers"
Sigh. Need the morning coffee (Pepsi).
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-08 8:36 ` Ingo Molnar
2008-04-08 14:21 ` Jeff Garzik
2008-04-08 14:56 ` Andi Kleen
@ 2008-04-08 16:18 ` Kok, Auke
2008-04-08 18:15 ` Ingo Molnar
2008-04-08 18:39 ` Ingo Molnar
2008-04-09 19:08 ` [ANNOUNCE] e1000 to e1000e migration of PCI Express devices Ingo Molnar
3 siblings, 2 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-08 16:18 UTC (permalink / raw
To: Ingo Molnar
Cc: Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
Ingo Molnar wrote:
> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>
>> From kernel 2.6.26 onward all *PCI Express* device IDs previously
>> supported by e1000 will be moving to the e1000e driver. This includes
>> ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and
>> 82571/2/3 chipset based adapters and variants.
>>
>> If you have not already enabled CONFIG_E1000E make sure that you do
>> so. You can already do this with 2.6.25. From 2.6.26 on this change
>> will be required if you have such a device.
>
> i'm not sure it's a good idea to unsupport hardware in a driver. It's OK
> to phase out a driver and restrict it to legacy hardware, it's OK to
> have an opt-in .config option for distros to select (or maybe even
> opt-out) to narrow down the number of PCI IDs that a driver recognizes,
> but lets not artificially break setups that worked before.
>
> ( sidenote: isnt there some facility that selects the "better" driver in
> case there is an overlap between PCI IDs - with the ability for users
> to override that selection? )
>
> such driver transitions are never smooth. For example there's an open
> e1000e/e1000 regression in .25 in this area that i just noticed on a
> testbox while doing randconfig testing. (that's why i noticed this
> message of yours on lkml, i was searching for e1000 regression reports).
>
> The following .config results in a non-working e1000 driver in a
> bzImage:
>
> CONFIG_E1000=y
> CONFIG_E1000_NAPI=y
> CONFIG_E1000_DISABLE_PACKET_SPLIT=y
> CONFIG_E1000E=m
> CONFIG_E1000E_ENABLED=y
>
> the interface just doesnt come up.
>
> This makes it work:
>
> CONFIG_E1000=y
> CONFIG_E1000_NAPI=y
> CONFIG_E1000_DISABLE_PACKET_SPLIT=y
> # CONFIG_E1000E is not set
> # CONFIG_E1000E_ENABLED is not set
>
> please fix such interactions and make the transition as smooth and as
> compatible as possible.
This is really a vague report. Maybe you need to adjust your network setup to
explicitly load the correct driver at boot? The adapter works correct here and I
have a stock T60 here as well, just as you.
e1000e is a new module, so in your case maybe `CONFIG_E1000E=y` should just work?
Or just 'modprobe e1000e' ?
> the hardware is a stock T60 laptop with:
>
> 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
>
> ich7 onboard LAN. (can send more info if needed.)
>
> I just tried the same .config on another box with onboard e1000 (a
> desktop system with a different e1000 version), which is ich9, and that
> broke too.
Just like Jeff is pointing out, we really cannot keep these device IDs around (not
just for my sanity) on the long term.
I really hate to have this discussion again (third time already) and I fear that
this will not be the last time :(
Auke
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-08 16:18 ` Kok, Auke
@ 2008-04-08 18:15 ` Ingo Molnar
2008-04-08 18:39 ` Ingo Molnar
1 sibling, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 18:15 UTC (permalink / raw
To: Kok, Auke
Cc: Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> > The following .config results in a non-working e1000 driver in a
> > bzImage:
> >
> > CONFIG_E1000=y
> > CONFIG_E1000_NAPI=y
> > CONFIG_E1000_DISABLE_PACKET_SPLIT=y
> > CONFIG_E1000E=m
> > CONFIG_E1000E_ENABLED=y
> >
> > the interface just doesnt come up.
> >
> > This makes it work:
> >
> > CONFIG_E1000=y
> > CONFIG_E1000_NAPI=y
> > CONFIG_E1000_DISABLE_PACKET_SPLIT=y
> > # CONFIG_E1000E is not set
> > # CONFIG_E1000E_ENABLED is not set
> >
> > please fix such interactions and make the transition as smooth and as
> > compatible as possible.
>
> This is really a vague report. Maybe you need to adjust your network
> setup to explicitly load the correct driver at boot? The adapter works
> correct here and I have a stock T60 here as well, just as you.
try the config combination i gave you [that's all that is needed - plug
the above lines into your .config of choice] - does that work fine for
you?
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
@ 2008-04-08 18:15 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 18:15 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> > The following .config results in a non-working e1000 driver in a
> > bzImage:
> >
> > CONFIG_E1000=y
> > CONFIG_E1000_NAPI=y
> > CONFIG_E1000_DISABLE_PACKET_SPLIT=y
> > CONFIG_E1000E=m
> > CONFIG_E1000E_ENABLED=y
> >
> > the interface just doesnt come up.
> >
> > This makes it work:
> >
> > CONFIG_E1000=y
> > CONFIG_E1000_NAPI=y
> > CONFIG_E1000_DISABLE_PACKET_SPLIT=y
> > # CONFIG_E1000E is not set
> > # CONFIG_E1000E_ENABLED is not set
> >
> > please fix such interactions and make the transition as smooth and as
> > compatible as possible.
>
> This is really a vague report. Maybe you need to adjust your network
> setup to explicitly load the correct driver at boot? The adapter works
> correct here and I have a stock T60 here as well, just as you.
try the config combination i gave you [that's all that is needed - plug
the above lines into your .config of choice] - does that work fine for
you?
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices)
2008-04-08 16:18 ` Kok, Auke
@ 2008-04-08 18:39 ` Ingo Molnar
2008-04-08 18:39 ` Ingo Molnar
1 sibling, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 18:39 UTC (permalink / raw
To: Kok, Auke
Cc: Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> > such driver transitions are never smooth. For example there's an
> > open e1000e/e1000 regression in .25 in this area that i just noticed
> > on a testbox while doing randconfig testing. (that's why i noticed
> > this message of yours on lkml, i was searching for e1000 regression
> > reports).
> This is really a vague report. Maybe you need to adjust your network
> setup to explicitly load the correct driver at boot? The adapter works
> correct here and I have a stock T60 here as well, just as you.
this is a simple bzImage kernel, no modules at all. Here's the full
regression report:
kernel used: latest -git, head 7180c4c9e09888db0a188f729c96c6d7bd61fa83.
Regression seems to have been introduced into v2.6.25 by this commit:
| commit 040babf9d84e7010c457e9ce69e9eb1c27927c9e
| Author: Auke Kok <auke-jan.h.kok@intel.com>
| Date: Wed Oct 31 15:22:05 2007 -0700
|
| e1000/e1000e: Move PCI-Express device IDs over to e1000e
v2.6.25-rc8 regresses relative to v2.6.24, with the following config,
which config works fine in v2.6.24:
http://redhat.com/~mingo/misc/config.e1000.bad
the eth0 interface is not detected at all:
http://redhat.com/~mingo/misc/dmesg.e1000.bad
after more than an hour of experimenting around and bisecting the
.config variances it turned out that turning off E1000E driver _module_
completely (which isnt even loaded, nor attempted to be loaded) made the
kernel boot again:
http://redhat.com/~mingo/misc/config.e1000.good
and the e1000 interface is detected fine just like it was in v2.6.24:
http://redhat.com/~mingo/misc/dmesg.e1000.good
the difference in the config is:
--- config.e1000.good 2008-04-08 20:24:30.000000000 +0200
+++ config.e1000.bad 2008-04-08 20:20:53.000000000 +0200
@@ -1400,8 +1400,8 @@ CONFIG_DL2K=m
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
-# CONFIG_E1000E is not set
-# CONFIG_E1000E_ENABLED is not set
+CONFIG_E1000E=m
+CONFIG_E1000E_ENABLED=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
CONFIG_NS83820=m
it results in the following bootup difference:
--- dmesg.e1000.good 2008-04-08 20:27:20.000000000 +0200
+++ dmesg.e1000.bad 2008-04-08 20:27:20.000000000 +0200
@@ -1269,14 +1269,8 @@ initcall 0xc06b7ce9 ran for 0 msecs: cpq
Calling initcall 0xc06b81e1: e1000_init_module+0x0/0x6e()
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
-ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
-PCI: Setting latency timer of device 0000:02:00.0 to 64
-e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:17:49:d2
-e1000: 0000:02:00.0: e1000_probe: This device (id 8086:109a) will no longer be supported by this driver in the future.
-e1000: 0000:02:00.0: e1000_probe: please use the "e1000e" driver instead.
-e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
initcall 0xc06b81e1: e1000_init_module+0x0/0x6e() returned 0.
-initcall 0xc06b81e1 ran for 81 msecs: e1000_init_module+0x0/0x6e()
+initcall 0xc06b81e1 ran for 0 msecs: e1000_init_module+0x0/0x6e()
Calling initcall 0xc06b824f: e100_init_module+0x0/0x4d()
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
@@ -2087,7 +2080,6 @@ warning: `dbus-daemon' uses 32-bit capab
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Device Serial Number d2-49-17-ff-ff-41-16-00
- Kernel driver in use: e1000
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
Subsystem: Intel Corporation Unknown device 1010
so the pure presence of the e1000e module breaks the e1000 driver. That
is a regression and a bug that should be fixed.
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices)
@ 2008-04-08 18:39 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 18:39 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> > such driver transitions are never smooth. For example there's an
> > open e1000e/e1000 regression in .25 in this area that i just noticed
> > on a testbox while doing randconfig testing. (that's why i noticed
> > this message of yours on lkml, i was searching for e1000 regression
> > reports).
> This is really a vague report. Maybe you need to adjust your network
> setup to explicitly load the correct driver at boot? The adapter works
> correct here and I have a stock T60 here as well, just as you.
this is a simple bzImage kernel, no modules at all. Here's the full
regression report:
kernel used: latest -git, head 7180c4c9e09888db0a188f729c96c6d7bd61fa83.
Regression seems to have been introduced into v2.6.25 by this commit:
| commit 040babf9d84e7010c457e9ce69e9eb1c27927c9e
| Author: Auke Kok <auke-jan.h.kok@intel.com>
| Date: Wed Oct 31 15:22:05 2007 -0700
|
| e1000/e1000e: Move PCI-Express device IDs over to e1000e
v2.6.25-rc8 regresses relative to v2.6.24, with the following config,
which config works fine in v2.6.24:
http://redhat.com/~mingo/misc/config.e1000.bad
the eth0 interface is not detected at all:
http://redhat.com/~mingo/misc/dmesg.e1000.bad
after more than an hour of experimenting around and bisecting the
.config variances it turned out that turning off E1000E driver _module_
completely (which isnt even loaded, nor attempted to be loaded) made the
kernel boot again:
http://redhat.com/~mingo/misc/config.e1000.good
and the e1000 interface is detected fine just like it was in v2.6.24:
http://redhat.com/~mingo/misc/dmesg.e1000.good
the difference in the config is:
--- config.e1000.good 2008-04-08 20:24:30.000000000 +0200
+++ config.e1000.bad 2008-04-08 20:20:53.000000000 +0200
@@ -1400,8 +1400,8 @@ CONFIG_DL2K=m
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
-# CONFIG_E1000E is not set
-# CONFIG_E1000E_ENABLED is not set
+CONFIG_E1000E=m
+CONFIG_E1000E_ENABLED=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
CONFIG_NS83820=m
it results in the following bootup difference:
--- dmesg.e1000.good 2008-04-08 20:27:20.000000000 +0200
+++ dmesg.e1000.bad 2008-04-08 20:27:20.000000000 +0200
@@ -1269,14 +1269,8 @@ initcall 0xc06b7ce9 ran for 0 msecs: cpq
Calling initcall 0xc06b81e1: e1000_init_module+0x0/0x6e()
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
-ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
-PCI: Setting latency timer of device 0000:02:00.0 to 64
-e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:17:49:d2
-e1000: 0000:02:00.0: e1000_probe: This device (id 8086:109a) will no longer be supported by this driver in the future.
-e1000: 0000:02:00.0: e1000_probe: please use the "e1000e" driver instead.
-e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
initcall 0xc06b81e1: e1000_init_module+0x0/0x6e() returned 0.
-initcall 0xc06b81e1 ran for 81 msecs: e1000_init_module+0x0/0x6e()
+initcall 0xc06b81e1 ran for 0 msecs: e1000_init_module+0x0/0x6e()
Calling initcall 0xc06b824f: e100_init_module+0x0/0x4d()
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
@@ -2087,7 +2080,6 @@ warning: `dbus-daemon' uses 32-bit capab
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Device Serial Number d2-49-17-ff-ff-41-16-00
- Kernel driver in use: e1000
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
Subsystem: Intel Corporation Unknown device 1010
so the pure presence of the e1000e module breaks the e1000 driver. That
is a regression and a bug that should be fixed.
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices)
2008-04-08 18:39 ` Ingo Molnar
(?)
@ 2008-04-08 19:32 ` Matthew Wilcox
2008-04-08 19:51 ` Ingo Molnar
-1 siblings, 1 reply; 125+ messages in thread
From: Matthew Wilcox @ 2008-04-08 19:32 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Jeff Garzik, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
On Tue, Apr 08, 2008 at 08:39:21PM +0200, Ingo Molnar wrote:
> so the pure presence of the e1000e module breaks the e1000 driver. That
> is a regression and a bug that should be fixed.
I think you've found the wrong problem ... it looks deliberate to me that
enabling e1000e disables e1000 from claiming the PCI IDs (see the PCIE()
macro right before the e1000_pci_tbl in drivers/net/e1000/e1000_main.c).
The question is why e1000e isn't claiming the device ...
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 125+ messages in thread
* RE: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices)
2008-04-08 18:39 ` Ingo Molnar
@ 2008-04-08 19:43 ` Brandeburg, Jesse
-1 siblings, 0 replies; 125+ messages in thread
From: Brandeburg, Jesse @ 2008-04-08 19:43 UTC (permalink / raw
To: Ingo Molnar, Kok, Auke-jan H
Cc: Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Auke is out sick, so I'm responding...
Ingo Molnar wrote:
> this is a simple bzImage kernel, no modules at all. Here's the full
> regression report:
then why are you compiling e1000e as a module? no "=y" in your kernel
means no support, and this kernel .config has e1000e supporting your
hardware.
your expectation is that e1000 once loaded on this device in a previous
kernel (2.6.24) so it should continue to work, right? I see your point
but we are trying to make general improvements to both drivers, and the
best way forward was a split, in order to make the user experience
better by eliminating chances for regressions on older hardware.
> v2.6.25-rc8 regresses relative to v2.6.24, with the following config,
> which config works fine in v2.6.24:
> the eth0 interface is not detected at all:
> http://redhat.com/~mingo/misc/dmesg.e1000.bad
if you're running a no module kernel, you'll need to set CONFIG_E1000E=y
for your device to be detected.
> so the pure presence of the e1000e module breaks the e1000 driver.
> That
> is a regression and a bug that should be fixed.
The device IDs moved to e1000e, we don't want collisions between drivers
that support the same IDs, so to avoid those user support issues, we're
trying to make the process as painless as possible with announcements
and time. The distros are already including the e1000e driver in their
builds and new installs with the new ID layout will automatically select
the correct driver for their hardware.
Users that take an upgrade to their kernel (with e1000e enabled) might
benefit if the distro upgrading that kernel included a post upgrade
script that migrated e1000e devices previously using e1000 in
modprobe.conf to alias ethX e1000e
If there is a more reasonable solution you can come up with I am
interested.
Jesse
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices)
@ 2008-04-08 19:43 ` Brandeburg, Jesse
0 siblings, 0 replies; 125+ messages in thread
From: Brandeburg, Jesse @ 2008-04-08 19:43 UTC (permalink / raw
To: Ingo Molnar, Kok, Auke-jan H
Cc: Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Ronciak, John, Arjan van de Ven, Greg KH, linux-pci maillist,
Linus Torvalds, Andrew Morton
Auke is out sick, so I'm responding...
Ingo Molnar wrote:
> this is a simple bzImage kernel, no modules at all. Here's the full
> regression report:
then why are you compiling e1000e as a module? no "=y" in your kernel
means no support, and this kernel .config has e1000e supporting your
hardware.
your expectation is that e1000 once loaded on this device in a previous
kernel (2.6.24) so it should continue to work, right? I see your point
but we are trying to make general improvements to both drivers, and the
best way forward was a split, in order to make the user experience
better by eliminating chances for regressions on older hardware.
> v2.6.25-rc8 regresses relative to v2.6.24, with the following config,
> which config works fine in v2.6.24:
> the eth0 interface is not detected at all:
> http://redhat.com/~mingo/misc/dmesg.e1000.bad
if you're running a no module kernel, you'll need to set CONFIG_E1000E=y
for your device to be detected.
> so the pure presence of the e1000e module breaks the e1000 driver.
> That
> is a regression and a bug that should be fixed.
The device IDs moved to e1000e, we don't want collisions between drivers
that support the same IDs, so to avoid those user support issues, we're
trying to make the process as painless as possible with announcements
and time. The distros are already including the e1000e driver in their
builds and new installs with the new ID layout will automatically select
the correct driver for their hardware.
Users that take an upgrade to their kernel (with e1000e enabled) might
benefit if the distro upgrading that kernel included a post upgrade
script that migrated e1000e devices previously using e1000 in
modprobe.conf to alias ethX e1000e
If there is a more reasonable solution you can come up with I am
interested.
Jesse
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices)
2008-04-08 19:32 ` Matthew Wilcox
@ 2008-04-08 19:51 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 19:51 UTC (permalink / raw
To: Matthew Wilcox
Cc: Kok, Auke, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Jeff Garzik, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Matthew Wilcox <matthew@wil.cx> wrote:
> On Tue, Apr 08, 2008 at 08:39:21PM +0200, Ingo Molnar wrote:
> > so the pure presence of the e1000e module breaks the e1000 driver. That
> > is a regression and a bug that should be fixed.
>
> I think you've found the wrong problem ... it looks deliberate to me
> that enabling e1000e disables e1000 from claiming the PCI IDs (see the
> PCIE() macro right before the e1000_pci_tbl in
> drivers/net/e1000/e1000_main.c).
>
> The question is why e1000e isn't claiming the device ...
because i have e1000 built-in and dont load the e1000e module at all.
That worked before and doesnt work now.
the solution is rather straightforward: if E1000 is built-in then E1000E
should be built-in as well or disabled (i.e. it should not be possible
to build it as a module in that case) - because the PCI ID stealing
trick now connects the two drivers unconditionally. [ If e1000 is a
module then e1000e can be a module (or disabled) - this would be the
most common configuration. ]
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices)
@ 2008-04-08 19:51 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 19:51 UTC (permalink / raw
To: Matthew Wilcox
Cc: Kok, Auke, Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Matthew Wilcox <matthew@wil.cx> wrote:
> On Tue, Apr 08, 2008 at 08:39:21PM +0200, Ingo Molnar wrote:
> > so the pure presence of the e1000e module breaks the e1000 driver. That
> > is a regression and a bug that should be fixed.
>
> I think you've found the wrong problem ... it looks deliberate to me
> that enabling e1000e disables e1000 from claiming the PCI IDs (see the
> PCIE() macro right before the e1000_pci_tbl in
> drivers/net/e1000/e1000_main.c).
>
> The question is why e1000e isn't claiming the device ...
because i have e1000 built-in and dont load the e1000e module at all.
That worked before and doesnt work now.
the solution is rather straightforward: if E1000 is built-in then E1000E
should be built-in as well or disabled (i.e. it should not be possible
to build it as a module in that case) - because the PCI ID stealing
trick now connects the two drivers unconditionally. [ If e1000 is a
module then e1000e can be a module (or disabled) - this would be the
most common configuration. ]
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 19:51 ` Ingo Molnar
(?)
@ 2008-04-08 19:56 ` Jeff Garzik
2008-04-08 20:06 ` Ingo Molnar
-1 siblings, 1 reply; 125+ messages in thread
From: Jeff Garzik @ 2008-04-08 19:56 UTC (permalink / raw
To: Ingo Molnar
Cc: Matthew Wilcox, Kok, Auke, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> * Matthew Wilcox <matthew@wil.cx> wrote:
>
>> On Tue, Apr 08, 2008 at 08:39:21PM +0200, Ingo Molnar wrote:
>>> so the pure presence of the e1000e module breaks the e1000 driver. That
>>> is a regression and a bug that should be fixed.
>> I think you've found the wrong problem ... it looks deliberate to me
>> that enabling e1000e disables e1000 from claiming the PCI IDs (see the
>> PCIE() macro right before the e1000_pci_tbl in
>> drivers/net/e1000/e1000_main.c).
>>
>> The question is why e1000e isn't claiming the device ...
>
> because i have e1000 built-in and dont load the e1000e module at all.
> That worked before and doesnt work now.
>
> the solution is rather straightforward: if E1000 is built-in then E1000E
> should be built-in as well or disabled (i.e. it should not be possible
> to build it as a module in that case) - because the PCI ID stealing
> trick now connects the two drivers unconditionally. [ If e1000 is a
> module then e1000e can be a module (or disabled) - this would be the
> most common configuration. ]
Then disable E1000E in your kernel config, and the PCIE() macro will do
the right thing...
Have you reviewed the discussion that led to PCIE()?
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices)
2008-04-08 19:43 ` Brandeburg, Jesse
(?)
@ 2008-04-08 19:59 ` Ingo Molnar
2008-04-08 20:04 ` Matthew Wilcox
-1 siblings, 1 reply; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 19:59 UTC (permalink / raw
To: Brandeburg, Jesse
Cc: Kok, Auke-jan H, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Jeff Garzik, Andrew Morton, David S. Miller,
Linus Torvalds, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
* Brandeburg, Jesse <jesse.brandeburg@intel.com> wrote:
> your expectation is that e1000 once loaded on this device in a
> previous kernel (2.6.24) so it should continue to work, right? [...]
correct.
> > the eth0 interface is not detected at all:
> > http://redhat.com/~mingo/misc/dmesg.e1000.bad
>
> if you're running a no module kernel, you'll need to set
> CONFIG_E1000E=y for your device to be detected.
there should be no need for me to set something that the kernel can do
itself as well ...
> If there is a more reasonable solution you can come up with I am
> interested.
i think the solution is obvious and simple: if e1000 is built-in then
e1000e should not be allowed to be a module. (i.e. it should either be
built-in in which case it will handle the PCI IDs, or it should be
disabled - in which case e1000 will handle them.)
that way e1000e can take over the PCI IDs but we'll never get a
non-working system, which takes an hour for a kernel hacker to figure
out. The failure was totally silent. eth0 didnt show up at all.
Btw., a sidenote: this is another generally annoying property of Linux:
there's no easy and user-visible enumeration of PCI IDs (devices) that
we _could_ support but dont enable for some reason. It is a royal PITA
to track down when some driver decides to (silently) ignore a piece of
hardware.
Having a seemingly dead piece of hardware component is one of the most
frustrating user experiences possible - the first instinctive reaction
is "did my hw break???". The kernel should proactively know about all
inactive pieces of hardware and should have a one-stop-shop for users
where they can reassure themselves which devices are not active and why.
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices)
2008-04-08 19:59 ` Ingo Molnar
@ 2008-04-08 20:04 ` Matthew Wilcox
2008-04-08 20:12 ` Dan Noe
` (2 more replies)
0 siblings, 3 replies; 125+ messages in thread
From: Matthew Wilcox @ 2008-04-08 20:04 UTC (permalink / raw
To: Ingo Molnar
Cc: Brandeburg, Jesse, Kok, Auke-jan H, Linux Kernel Mailing List,
NetDev, e1000-list, linux-pci maillist, Jeff Garzik,
Andrew Morton, David S. Miller, Linus Torvalds, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
On Tue, Apr 08, 2008 at 09:59:49PM +0200, Ingo Molnar wrote:
> Btw., a sidenote: this is another generally annoying property of Linux:
> there's no easy and user-visible enumeration of PCI IDs (devices) that
> we _could_ support but dont enable for some reason. It is a royal PITA
> to track down when some driver decides to (silently) ignore a piece of
> hardware.
>
> Having a seemingly dead piece of hardware component is one of the most
> frustrating user experiences possible - the first instinctive reaction
> is "did my hw break???". The kernel should proactively know about all
> inactive pieces of hardware and should have a one-stop-shop for users
> where they can reassure themselves which devices are not active and why.
It's almost trivial to add new string attributes to sysfs. We could
have a file, say, /sys/bus/pci/devices/0000:07:03.0/broken which
lspci could read to see if anything's left a message for us.
Is that the kind of thing you had in mind?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 19:56 ` [regression] e1000e broke e1000 Jeff Garzik
@ 2008-04-08 20:06 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 20:06 UTC (permalink / raw
To: Jeff Garzik
Cc: Matthew Wilcox, Kok, Auke, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Jeff Garzik <jeff@garzik.org> wrote:
> Then disable E1000E in your kernel config, and the PCIE() macro will
> do the right thing...
it is an obvious regression that could and should be solved in the
Kconfig space: do not allow E1000=y && E1000E=m.
i repeat, it took me more than an hour to figure out why there's no
networking on my laptop. Guess how much it takes for a plain user to
figure out the same problem.
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
@ 2008-04-08 20:06 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 20:06 UTC (permalink / raw
To: Jeff Garzik
Cc: Kok, Auke, Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Jeff Garzik <jeff@garzik.org> wrote:
> Then disable E1000E in your kernel config, and the PCIE() macro will
> do the right thing...
it is an obvious regression that could and should be solved in the
Kconfig space: do not allow E1000=y && E1000E=m.
i repeat, it took me more than an hour to figure out why there's no
networking on my laptop. Guess how much it takes for a plain user to
figure out the same problem.
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:04 ` Matthew Wilcox
@ 2008-04-08 20:12 ` Dan Noe
2008-04-08 20:13 ` showing which hardware is unclaimed Rick Jones
2008-04-08 20:17 ` Ingo Molnar
2 siblings, 0 replies; 125+ messages in thread
From: Dan Noe @ 2008-04-08 20:12 UTC (permalink / raw
To: Matthew Wilcox
Cc: Ingo Molnar, Brandeburg, Jesse, Kok, Auke-jan H,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Matthew Wilcox wrote:
> It's almost trivial to add new string attributes to sysfs. We could
> have a file, say, /sys/bus/pci/devices/0000:07:03.0/broken which
> lspci could read to see if anything's left a message for us.
>
> Is that the kind of thing you had in mind?
I would consider this a worthwhile addition to the kernel (and lspci).
It would be nice if lspci could display what driver had claimed a
particular device, and which devices were unclaimed by any driver or
otherwise had an error that prevented initialization.
I don't have enough experience to gauge how invasive this would be, but
I'd be happy to contribute towards it if practical.
Cheers,
Dan
--
/--------------- - - - - - -
| Daniel Noe
| http://isomerica.net/~dpn/
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
@ 2008-04-08 20:12 ` Dan Noe
0 siblings, 0 replies; 125+ messages in thread
From: Dan Noe @ 2008-04-08 20:12 UTC (permalink / raw
To: Matthew Wilcox
Cc: Kok, Auke-jan H, Andrew Morton, Jeff Garzik, David S. Miller,
e1000-list, NetDev, Allan, Bruce W, Linux Kernel Mailing List,
Brandeburg, Jesse, Rafael J. Wysocki, Ronciak, John,
Arjan van de Ven, Greg KH, Ingo Molnar, Linus Torvalds,
linux-pci maillist
Matthew Wilcox wrote:
> It's almost trivial to add new string attributes to sysfs. We could
> have a file, say, /sys/bus/pci/devices/0000:07:03.0/broken which
> lspci could read to see if anything's left a message for us.
>
> Is that the kind of thing you had in mind?
I would consider this a worthwhile addition to the kernel (and lspci).
It would be nice if lspci could display what driver had claimed a
particular device, and which devices were unclaimed by any driver or
otherwise had an error that prevented initialization.
I don't have enough experience to gauge how invasive this would be, but
I'd be happy to contribute towards it if practical.
Cheers,
Dan
--
/--------------- - - - - - -
| Daniel Noe
| http://isomerica.net/~dpn/
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* showing which hardware is unclaimed
2008-04-08 20:04 ` Matthew Wilcox
2008-04-08 20:12 ` Dan Noe
@ 2008-04-08 20:13 ` Rick Jones
2008-04-08 20:35 ` Martin Mares
2008-04-08 20:17 ` Ingo Molnar
2 siblings, 1 reply; 125+ messages in thread
From: Rick Jones @ 2008-04-08 20:13 UTC (permalink / raw
To: Matthew Wilcox
Cc: Ingo Molnar, Brandeburg, Jesse, Kok, Auke-jan H,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Matthew Wilcox wrote:
> On Tue, Apr 08, 2008 at 09:59:49PM +0200, Ingo Molnar wrote:
>
>>Btw., a sidenote: this is another generally annoying property of Linux:
>>there's no easy and user-visible enumeration of PCI IDs (devices) that
>>we _could_ support but dont enable for some reason. It is a royal PITA
>>to track down when some driver decides to (silently) ignore a piece of
>>hardware.
>>
>>Having a seemingly dead piece of hardware component is one of the most
>>frustrating user experiences possible - the first instinctive reaction
>>is "did my hw break???". The kernel should proactively know about all
>>inactive pieces of hardware and should have a one-stop-shop for users
>>where they can reassure themselves which devices are not active and why.
>
>
> It's almost trivial to add new string attributes to sysfs. We could
> have a file, say, /sys/bus/pci/devices/0000:07:03.0/broken which
> lspci could read to see if anything's left a message for us.
>
> Is that the kind of thing you had in mind?
FWIW, this is what a command on "another OS" does with an unclaimed card:
# ioscan -fk -C lan
Class I H/W Path Driver S/W State H/W Type Description
====================================================================
lan 0 0/0/3/0 intl100 CLAIMED INTERFACE Intel PCI Pro
10/100Tx Server Adapter
lan 1 0/1/2/0 igelan CLAIMED INTERFACE HP PCI
1000Base-T Core
lan 2 0/2/1/0 iether CLAIMED INTERFACE HP A7012-60001
PCI/PCI-X 1000Base-T Dual-port Adapter
lan 3 0/2/1/1 iether CLAIMED INTERFACE HP A7012-60001
PCI/PCI-X 1000Base-T Dual-port Adapter
lan 4 0/3/1/0 ixgbe UNCLAIMED UNKNOWN PCI-X Ethernet
(17d55831)
I'd probably call that "unclaimed" rather than "broken" but that may
just be a preference thing.
rick jones
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices)
2008-04-08 20:04 ` Matthew Wilcox
@ 2008-04-08 20:17 ` Ingo Molnar
2008-04-08 20:13 ` showing which hardware is unclaimed Rick Jones
2008-04-08 20:17 ` Ingo Molnar
2 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 20:17 UTC (permalink / raw
To: Matthew Wilcox
Cc: Brandeburg, Jesse, Kok, Auke-jan H, Linux Kernel Mailing List,
NetDev, e1000-list, linux-pci maillist, Jeff Garzik,
Andrew Morton, David S. Miller, Linus Torvalds, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Matthew Wilcox <matthew@wil.cx> wrote:
> On Tue, Apr 08, 2008 at 09:59:49PM +0200, Ingo Molnar wrote:
> > Btw., a sidenote: this is another generally annoying property of Linux:
> > there's no easy and user-visible enumeration of PCI IDs (devices) that
> > we _could_ support but dont enable for some reason. It is a royal PITA
> > to track down when some driver decides to (silently) ignore a piece of
> > hardware.
> >
> > Having a seemingly dead piece of hardware component is one of the most
> > frustrating user experiences possible - the first instinctive reaction
> > is "did my hw break???". The kernel should proactively know about all
> > inactive pieces of hardware and should have a one-stop-shop for users
> > where they can reassure themselves which devices are not active and why.
>
> It's almost trivial to add new string attributes to sysfs. We could
> have a file, say, /sys/bus/pci/devices/0000:07:03.0/broken which lspci
> could read to see if anything's left a message for us.
>
> Is that the kind of thing you had in mind?
yep, that would be fantastic.
i guess more could be done as well - this was just the result of 10
seconds of thinking - please try to think all such scenarios through
with the mindset of the user who is faced with a non-working device. Our
failure diagnostics are rather ad-hoc in general. Say an USB stick did
not come up. Or some card isnt working. Or the mouse is dead. Plain
everyday annoyances - we need good, unified, understandable interfaces
for users to get reassurances and vectors of action from. Maybe even a
WARN_ON() for kerneloops.org to pick up automatically. _Anything_ that
is actionable by plain users. Because failures in hw functionality is
one of the most serious failure an OS can impose on users (it's only
slightly better than say data loss, and clearly worse to most users than
say sporadic crashes), and it is the main area where we _lose_ users
every day.
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices)
@ 2008-04-08 20:17 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 20:17 UTC (permalink / raw
To: Matthew Wilcox
Cc: Kok, Auke-jan H, Jeff Garzik, David S. Miller, e1000-list, NetDev,
Allan, Bruce W, Brandeburg, Jesse, Linux Kernel Mailing List,
Rafael J. Wysocki, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Matthew Wilcox <matthew@wil.cx> wrote:
> On Tue, Apr 08, 2008 at 09:59:49PM +0200, Ingo Molnar wrote:
> > Btw., a sidenote: this is another generally annoying property of Linux:
> > there's no easy and user-visible enumeration of PCI IDs (devices) that
> > we _could_ support but dont enable for some reason. It is a royal PITA
> > to track down when some driver decides to (silently) ignore a piece of
> > hardware.
> >
> > Having a seemingly dead piece of hardware component is one of the most
> > frustrating user experiences possible - the first instinctive reaction
> > is "did my hw break???". The kernel should proactively know about all
> > inactive pieces of hardware and should have a one-stop-shop for users
> > where they can reassure themselves which devices are not active and why.
>
> It's almost trivial to add new string attributes to sysfs. We could
> have a file, say, /sys/bus/pci/devices/0000:07:03.0/broken which lspci
> could read to see if anything's left a message for us.
>
> Is that the kind of thing you had in mind?
yep, that would be fantastic.
i guess more could be done as well - this was just the result of 10
seconds of thinking - please try to think all such scenarios through
with the mindset of the user who is faced with a non-working device. Our
failure diagnostics are rather ad-hoc in general. Say an USB stick did
not come up. Or some card isnt working. Or the mouse is dead. Plain
everyday annoyances - we need good, unified, understandable interfaces
for users to get reassurances and vectors of action from. Maybe even a
WARN_ON() for kerneloops.org to pick up automatically. _Anything_ that
is actionable by plain users. Because failures in hw functionality is
one of the most serious failure an OS can impose on users (it's only
slightly better than say data loss, and clearly worse to most users than
say sporadic crashes), and it is the main area where we _lose_ users
every day.
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:06 ` Ingo Molnar
@ 2008-04-08 20:19 ` Jeff Garzik
-1 siblings, 0 replies; 125+ messages in thread
From: Jeff Garzik @ 2008-04-08 20:19 UTC (permalink / raw
To: Ingo Molnar
Cc: Matthew Wilcox, Kok, Auke, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> i repeat, it took me more than an hour to figure out why there's no
> networking on my laptop. Guess how much it takes for a plain user to
> figure out the same problem.
A plain user would have obtained a working distro kernel, putting this
rare problem purely in the laps of people with highly unusual kernel
configs...
But as noted in the announcement, the fix is for this is to continue in
the next step in the transition, then you only have one driver claiming
those IDs, for any given config. No need for further Kconfig tweakage.
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
@ 2008-04-08 20:19 ` Jeff Garzik
0 siblings, 0 replies; 125+ messages in thread
From: Jeff Garzik @ 2008-04-08 20:19 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
Ingo Molnar wrote:
> i repeat, it took me more than an hour to figure out why there's no
> networking on my laptop. Guess how much it takes for a plain user to
> figure out the same problem.
A plain user would have obtained a working distro kernel, putting this
rare problem purely in the laps of people with highly unusual kernel
configs...
But as noted in the announcement, the fix is for this is to continue in
the next step in the transition, then you only have one driver claiming
those IDs, for any given config. No need for further Kconfig tweakage.
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:12 ` Dan Noe
(?)
@ 2008-04-08 20:20 ` Matthew Wilcox
2008-04-08 20:35 ` Ingo Molnar
2008-04-08 20:39 ` Dan Noe
-1 siblings, 2 replies; 125+ messages in thread
From: Matthew Wilcox @ 2008-04-08 20:20 UTC (permalink / raw
To: Dan Noe
Cc: Ingo Molnar, Brandeburg, Jesse, Kok, Auke-jan H,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
On Tue, Apr 08, 2008 at 04:12:29PM -0400, Dan Noe wrote:
> It would be nice if lspci could display what driver had claimed a
> particular device
You need to upgrade to a more recent version of lspci -- it already does
this ;-)
Maybe 'status' would be a better name than 'broken'. We could even
default it to 'unclaimed' then. Or 'driver_status' to avoid conflicting
with some bus that might have a 'status' bit we try to report through
sysfs.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:06 ` Ingo Molnar
(?)
(?)
@ 2008-04-08 20:31 ` Kok, Auke
2008-04-09 19:12 ` Ingo Molnar
-1 siblings, 1 reply; 125+ messages in thread
From: Kok, Auke @ 2008-04-08 20:31 UTC (permalink / raw
To: Ingo Molnar
Cc: Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> * Jeff Garzik <jeff@garzik.org> wrote:
>
>> Then disable E1000E in your kernel config, and the PCIE() macro will
>> do the right thing...
>
> it is an obvious regression that could and should be solved in the
> Kconfig space: do not allow E1000=y && E1000E=m.
this is really not the solution imho, having e1000 builtin and e1000e as a module
is a perfectly viable choice. They are two separate drivers that are completely
independent.
I also think that the word "regression" is way out of proportion. I did not
complain myself when IDE/ATA->SATA driver merges broke all my systems and I was
pleasantly provided with the 'cannot find root vfs' message. (that's what I get
for running my own distro).
> i repeat, it took me more than an hour to figure out why there's no
> networking on my laptop. Guess how much it takes for a plain user to
> figure out the same problem.
a plain user uses a distro which is aware of the issue and that will load e1000e
automatically, because it was tested by the distro.
that is just pushing the discussion to the wrong point. The decision has been made
a long time ago to split e1000 in two. now that we have two drivers, we have a
migration issue. you can't fix this migration issue by forcing a specific .config
endresult on the user.
I've seen suggestions that will alleviate the issue by adding a 'default E1000' to
the e1000e Kconfig section, and something like that makes sense to me and I still
would be happy to merge something like that.
I do not think that hiding the existence of e1000e for any user by always enabling
it will fix things at all however, and will just lead to a lot of other issues
later on.
Auke
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:19 ` Jeff Garzik
@ 2008-04-08 20:33 ` Ingo Molnar
-1 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 20:33 UTC (permalink / raw
To: Jeff Garzik
Cc: Matthew Wilcox, Kok, Auke, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Jeff Garzik <jeff@garzik.org> wrote:
> Ingo Molnar wrote:
>> i repeat, it took me more than an hour to figure out why there's no
>> networking on my laptop. Guess how much it takes for a plain user to
>> figure out the same problem.
>
> A plain user would have obtained a working distro kernel, putting this
> rare problem purely in the laps of people with highly unusual kernel
> configs...
>
> But as noted in the announcement, the fix is for this is to continue
> in the next step in the transition, then you only have one driver
> claiming those IDs, for any given config. No need for further Kconfig
> tweakage.
i find it mindboggling and rather sad that you are still in denial :-(
this is an obvious regression to me, with a very simple fix. No other
PCI driver breaks like this. We've got three thousand Kconfig options -
it is clearly not realistic for users to keep such details in mind to
avoid pitfalls. E1000=y && E1000E=m is uncommon but can easily happen.
E1000=y && E1000E=m simply makes no sense in light of the PCI ID
stealing that occurs if E1000E is enabled.
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
@ 2008-04-08 20:33 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 20:33 UTC (permalink / raw
To: Jeff Garzik
Cc: Kok, Auke, Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Jeff Garzik <jeff@garzik.org> wrote:
> Ingo Molnar wrote:
>> i repeat, it took me more than an hour to figure out why there's no
>> networking on my laptop. Guess how much it takes for a plain user to
>> figure out the same problem.
>
> A plain user would have obtained a working distro kernel, putting this
> rare problem purely in the laps of people with highly unusual kernel
> configs...
>
> But as noted in the announcement, the fix is for this is to continue
> in the next step in the transition, then you only have one driver
> claiming those IDs, for any given config. No need for further Kconfig
> tweakage.
i find it mindboggling and rather sad that you are still in denial :-(
this is an obvious regression to me, with a very simple fix. No other
PCI driver breaks like this. We've got three thousand Kconfig options -
it is clearly not realistic for users to keep such details in mind to
avoid pitfalls. E1000=y && E1000E=m is uncommon but can easily happen.
E1000=y && E1000E=m simply makes no sense in light of the PCI ID
stealing that occurs if E1000E is enabled.
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:20 ` Matthew Wilcox
@ 2008-04-08 20:35 ` Ingo Molnar
2008-04-08 20:36 ` Martin Mares
2008-04-08 20:39 ` Dan Noe
1 sibling, 1 reply; 125+ messages in thread
From: Ingo Molnar @ 2008-04-08 20:35 UTC (permalink / raw
To: Matthew Wilcox
Cc: Dan Noe, Brandeburg, Jesse, Kok, Auke-jan H,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
* Matthew Wilcox <matthew@wil.cx> wrote:
> On Tue, Apr 08, 2008 at 04:12:29PM -0400, Dan Noe wrote:
> > It would be nice if lspci could display what driver had claimed a
> > particular device
>
> You need to upgrade to a more recent version of lspci -- it already
> does this ;-)
yes, but it does not (yet) display the negative condition and the reason
for that. (if the kernel knows the reason - and in most cases it knows
it)
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: showing which hardware is unclaimed
2008-04-08 20:13 ` showing which hardware is unclaimed Rick Jones
@ 2008-04-08 20:35 ` Martin Mares
0 siblings, 0 replies; 125+ messages in thread
From: Martin Mares @ 2008-04-08 20:35 UTC (permalink / raw
To: Rick Jones
Cc: Matthew Wilcox, Ingo Molnar, Brandeburg, Jesse, Kok, Auke-jan H,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Hi!
> FWIW, this is what a command on "another OS" does with an unclaimed card:
>
> # ioscan -fk -C lan
> Class I H/W Path Driver S/W State H/W Type Description
> ====================================================================
> lan 0 0/0/3/0 intl100 CLAIMED INTERFACE Intel PCI Pro
> 10/100Tx Server Adapter
> lan 1 0/1/2/0 igelan CLAIMED INTERFACE HP PCI
> 1000Base-T Core
> lan 2 0/2/1/0 iether CLAIMED INTERFACE HP A7012-60001
> PCI/PCI-X 1000Base-T Dual-port Adapter
> lan 3 0/2/1/1 iether CLAIMED INTERFACE HP A7012-60001
> PCI/PCI-X 1000Base-T Dual-port Adapter
> lan 4 0/3/1/0 ixgbe UNCLAIMED UNKNOWN PCI-X Ethernet
> (17d55831)
>
> I'd probably call that "unclaimed" rather than "broken" but that may
> just be a preference thing.
`lspci -k' already reports which devices are claimed by which driver.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
MS has designed a perfect copy protection scheme: There is no reason to pirate Vista.
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: showing which hardware is unclaimed
@ 2008-04-08 20:35 ` Martin Mares
0 siblings, 0 replies; 125+ messages in thread
From: Martin Mares @ 2008-04-08 20:35 UTC (permalink / raw
To: Rick Jones
Cc: Kok, Auke-jan H, Ronciak, John, Andrew Morton, Jeff Garzik,
Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, Brandeburg, Jesse, Rafael J. Wysocki,
David S. Miller, Arjan van de Ven, Greg KH, Ingo Molnar,
Linus Torvalds, linux-pci maillist
Hi!
> FWIW, this is what a command on "another OS" does with an unclaimed card:
>
> # ioscan -fk -C lan
> Class I H/W Path Driver S/W State H/W Type Description
> ====================================================================
> lan 0 0/0/3/0 intl100 CLAIMED INTERFACE Intel PCI Pro
> 10/100Tx Server Adapter
> lan 1 0/1/2/0 igelan CLAIMED INTERFACE HP PCI
> 1000Base-T Core
> lan 2 0/2/1/0 iether CLAIMED INTERFACE HP A7012-60001
> PCI/PCI-X 1000Base-T Dual-port Adapter
> lan 3 0/2/1/1 iether CLAIMED INTERFACE HP A7012-60001
> PCI/PCI-X 1000Base-T Dual-port Adapter
> lan 4 0/3/1/0 ixgbe UNCLAIMED UNKNOWN PCI-X Ethernet
> (17d55831)
>
> I'd probably call that "unclaimed" rather than "broken" but that may
> just be a preference thing.
`lspci -k' already reports which devices are claimed by which driver.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
MS has designed a perfect copy protection scheme: There is no reason to pirate Vista.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:35 ` Ingo Molnar
@ 2008-04-08 20:36 ` Martin Mares
0 siblings, 0 replies; 125+ messages in thread
From: Martin Mares @ 2008-04-08 20:36 UTC (permalink / raw
To: Ingo Molnar
Cc: Matthew Wilcox, Dan Noe, Brandeburg, Jesse, Kok, Auke-jan H,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
> > You need to upgrade to a more recent version of lspci -- it already
> > does this ;-)
>
> yes, but it does not (yet) display the negative condition and the reason
> for that. (if the kernel knows the reason - and in most cases it knows
> it)
Yes, it would be nice to have.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Noli tangere fila metalica, ne in solum incasa quidem.
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
@ 2008-04-08 20:36 ` Martin Mares
0 siblings, 0 replies; 125+ messages in thread
From: Martin Mares @ 2008-04-08 20:36 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke-jan H, Ronciak, John, Jeff Garzik, Matthew Wilcox,
e1000-list, NetDev, Dan Noe, Allan, Bruce W,
Linux Kernel Mailing List, Brandeburg, Jesse, Rafael J. Wysocki,
David S. Miller, Arjan van de Ven, Greg KH, linux-pci maillist,
Linus Torvalds, Andrew Morton
> > You need to upgrade to a more recent version of lspci -- it already
> > does this ;-)
>
> yes, but it does not (yet) display the negative condition and the reason
> for that. (if the kernel knows the reason - and in most cases it knows
> it)
Yes, it would be nice to have.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Noli tangere fila metalica, ne in solum incasa quidem.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:20 ` Matthew Wilcox
@ 2008-04-08 20:39 ` Dan Noe
2008-04-08 20:39 ` Dan Noe
1 sibling, 0 replies; 125+ messages in thread
From: Dan Noe @ 2008-04-08 20:39 UTC (permalink / raw
To: Matthew Wilcox
Cc: Ingo Molnar, Brandeburg, Jesse, Kok, Auke-jan H,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Jeff Garzik, Andrew Morton, David S. Miller, Linus Torvalds,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Matthew Wilcox wrote:
> On Tue, Apr 08, 2008 at 04:12:29PM -0400, Dan Noe wrote:
>> It would be nice if lspci could display what driver had claimed a
>> particular device
>
> You need to upgrade to a more recent version of lspci -- it already does
> this ;-)
Hah, thanks. That is useful and very new :) I built a newer lspci and
I see it is now displayed with the -k option.
> Maybe 'status' would be a better name than 'broken'. We could even
> default it to 'unclaimed' then. Or 'driver_status' to avoid conflicting
> with some bus that might have a 'status' bit we try to report through
> sysfs.
I agree however that the opportunity for more status would be good. And
status is a better name than "broken". This way it is easy to scan all
devices on the system via sysfs and easily visualize via lspci or some
other tool:
1) Unclaimed devices
2) Devices that aren't working properly - and why (please something more
than "This device is not working properly" :)
3) Devices that are claimed and working properly
Cheers,
Dan
--
/--------------- - - - - - -
| Daniel Noe
| http://isomerica.net/~dpn/
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
@ 2008-04-08 20:39 ` Dan Noe
0 siblings, 0 replies; 125+ messages in thread
From: Dan Noe @ 2008-04-08 20:39 UTC (permalink / raw
To: Matthew Wilcox
Cc: Kok, Auke-jan H, Andrew Morton, Jeff Garzik, David S. Miller,
e1000-list, NetDev, Allan, Bruce W, Linux Kernel Mailing List,
Brandeburg, Jesse, Rafael J. Wysocki, Ronciak, John,
Arjan van de Ven, Greg KH, Ingo Molnar, Linus Torvalds,
linux-pci maillist
Matthew Wilcox wrote:
> On Tue, Apr 08, 2008 at 04:12:29PM -0400, Dan Noe wrote:
>> It would be nice if lspci could display what driver had claimed a
>> particular device
>
> You need to upgrade to a more recent version of lspci -- it already does
> this ;-)
Hah, thanks. That is useful and very new :) I built a newer lspci and
I see it is now displayed with the -k option.
> Maybe 'status' would be a better name than 'broken'. We could even
> default it to 'unclaimed' then. Or 'driver_status' to avoid conflicting
> with some bus that might have a 'status' bit we try to report through
> sysfs.
I agree however that the opportunity for more status would be good. And
status is a better name than "broken". This way it is easy to scan all
devices on the system via sysfs and easily visualize via lspci or some
other tool:
1) Unclaimed devices
2) Devices that aren't working properly - and why (please something more
than "This device is not working properly" :)
3) Devices that are claimed and working properly
Cheers,
Dan
--
/--------------- - - - - - -
| Daniel Noe
| http://isomerica.net/~dpn/
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [E1000-devel] [regression] e1000e broke e1000
2008-04-08 20:33 ` Ingo Molnar
(?)
@ 2008-04-08 20:47 ` Kok, Auke
-1 siblings, 0 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-08 20:47 UTC (permalink / raw
To: Ingo Molnar
Cc: Jeff Garzik, Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
Ingo Molnar wrote:
> * Jeff Garzik <jeff@garzik.org> wrote:
>
>> Ingo Molnar wrote:
>>> i repeat, it took me more than an hour to figure out why there's no
>>> networking on my laptop. Guess how much it takes for a plain user to
>>> figure out the same problem.
>> A plain user would have obtained a working distro kernel, putting this
>> rare problem purely in the laps of people with highly unusual kernel
>> configs...
>>
>> But as noted in the announcement, the fix is for this is to continue
>> in the next step in the transition, then you only have one driver
>> claiming those IDs, for any given config. No need for further Kconfig
>> tweakage.
>
> i find it mindboggling and rather sad that you are still in denial :-(
>
> this is an obvious regression to me, with a very simple fix. No other
> PCI driver breaks like this. We've got three thousand Kconfig options -
> it is clearly not realistic for users to keep such details in mind to
> avoid pitfalls. E1000=y && E1000E=m is uncommon but can easily happen.
> E1000=y && E1000E=m simply makes no sense in light of the PCI ID
> stealing that occurs if E1000E is enabled.
hence the patch that is in jeff's upstream tree that puts an end to this :)
Auke
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:33 ` Ingo Molnar
(?)
(?)
@ 2008-04-08 20:56 ` Jeff Garzik
2008-04-09 19:38 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Ingo Molnar
-1 siblings, 1 reply; 125+ messages in thread
From: Jeff Garzik @ 2008-04-08 20:56 UTC (permalink / raw
To: Ingo Molnar
Cc: Matthew Wilcox, Kok, Auke, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> No other
> PCI driver breaks like this.
That's because PCI ID transitions are extremely, extremely rare.
Not because this transition is particularly unusual.
> We've got three thousand Kconfig options -
> it is clearly not realistic for users to keep such details in mind to
> avoid pitfalls.
Agreed -- hence the multiple announcements, including in this thread, to
put said details into mind.
It's an unusual situation, thus it received announcements so that people
are aware of the transition taking place, and what to do about it.
> E1000=y && E1000E=m is uncommon but can easily happen.
> E1000=y && E1000E=m simply makes no sense in light of the PCI ID
> stealing that occurs if E1000E is enabled.
"makes no sense"... for your personal situation.
They are two independent drivers, and that's a valid mix of Kconfig
settings.
Someone could easily have an e1000 card in an e1000e machine, and come
up with that specific config mix.
It is not denial to say "people other than Ingo might validly choose
that config mix."
Overall, fundamentally, any transition of a user base from one driver to
another is going to be an ad-hoc process. That's the nature of the
problem -- each case is different.
So we avoid driver transitions if at all possible, as a general rule.
In this case, a rare exception to that rule, you have to hammer out a
user-education process as best you can.
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-08 8:36 ` Ingo Molnar
` (2 preceding siblings ...)
2008-04-08 16:18 ` Kok, Auke
@ 2008-04-09 19:08 ` Ingo Molnar
2008-04-09 19:38 ` Andi Kleen
3 siblings, 1 reply; 125+ messages in thread
From: Ingo Molnar @ 2008-04-09 19:08 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Ingo Molnar <mingo@elte.hu> wrote:
> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>
> > From kernel 2.6.26 onward all *PCI Express* device IDs previously
> > supported by e1000 will be moving to the e1000e driver. This
> > includes ich8 and ich9 onboard LAN, server 5000 platform onboard LAN
> > (es2) and 82571/2/3 chipset based adapters and variants.
> >
> > If you have not already enabled CONFIG_E1000E make sure that you do
> > so. You can already do this with 2.6.25. From 2.6.26 on this change
> > will be required if you have such a device.
>
> i'm not sure it's a good idea to unsupport hardware in a driver. It's
> OK to phase out a driver and restrict it to legacy hardware, it's OK
> to have an opt-in .config option for distros to select (or maybe even
> opt-out) to narrow down the number of PCI IDs that a driver
> recognizes, but lets not artificially break setups that worked before.
perhaps all the opposition with regard to the regression roots back to
this section i said, so i take this objection back - it looks quite
acceptable to do the migration the way you implemented it, considering
the choices.
except for the E1000=y && E1000E=m regression that bit me - that should
be solved and everyone will be happy.
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 20:31 ` [regression] e1000e broke e1000 Kok, Auke
@ 2008-04-09 19:12 ` Ingo Molnar
2008-04-09 19:33 ` Jeff Garzik
0 siblings, 1 reply; 125+ messages in thread
From: Ingo Molnar @ 2008-04-09 19:12 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> > it is an obvious regression that could and should be solved in the
> > Kconfig space: do not allow E1000=y && E1000E=m.
>
> this is really not the solution imho, having e1000 builtin and e1000e
> as a module is a perfectly viable choice. They are two separate
> drivers that are completely independent.
you try to argue against a strong and established concept that Linux
always had from day one on: DRIVER_X=y means the user prefers that
driver so strongly that he has selected it built-in. Such drivers are
special in every sense: they run first before any of the module init,
they cannot be disabled, etc. etc.
The only case where that should be overriden as the primary driver for
that piece of hardware if _another_ driver is built-in _too_.
... which is exactly the E1000=y && E1000E=m regression that bit me and
the simple solution of forcing E1000E to follow the mode of the E1000
driver solves it.
The most common distro setup is E1000=m and E1000E=m. The most common
embedded setup is _one_ of the two drivers as =y. So i'm not sure why
you are arguing about all this. Please just fix this bug, simple as
that.
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-09 19:12 ` Ingo Molnar
@ 2008-04-09 19:33 ` Jeff Garzik
2008-04-11 11:30 ` Ingo Molnar
0 siblings, 1 reply; 125+ messages in thread
From: Jeff Garzik @ 2008-04-09 19:33 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> The most common distro setup is E1000=m and E1000E=m. The most common
> embedded setup is _one_ of the two drivers as =y.
Agreed, and agreed.
> So i'm not sure why
> you are arguing about all this. Please just fix this bug, simple as
> that.
I haven't said NAK, but I think the suggested fix is a waste of time because
1) it breaks (by disallowing) a valid setup based on one report
2) it only happens to experienced kernel hackers with weird configs
3) the suggested fix binds together more tightly two drivers we are
trying to keep separate
4) it is a temporary situation that will go away in 2.6.26 anyway
So from my point of view, your request is to pick the breakage you don't
care about (#1, above) to fix the breakage you do care about.
It's a "pick your poison" choice, from my POV.
Given that POV, that's why I lean towards avoiding your Kconfig fix --
viewing this as a transition issue, and not something to be fixed by
limiting the choices of others.
But if everyone strongly agrees with you... go ahead and patch, I won't
NAK it.
I dislike the Kconfig system growing "temporary" hacks, which tend to
accumulate false dependencies over time. But I readily admit that's a
general principle and not a hard rule...
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices
2008-04-09 19:08 ` [ANNOUNCE] e1000 to e1000e migration of PCI Express devices Ingo Molnar
@ 2008-04-09 19:38 ` Andi Kleen
0 siblings, 0 replies; 125+ messages in thread
From: Andi Kleen @ 2008-04-09 19:38 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Jeff Garzik, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
Ingo Molnar <mingo@elte.hu> writes:
>
> except for the E1000=y && E1000E=m regression that bit me - that should
> be solved and everyone will be happy.
Regarding getting bitten: could you please add E1000E to the x86 defconfigs?
That bit me an hour ago or so.
Thanks,
-Andi
^ permalink raw reply [flat|nested] 125+ messages in thread
* [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-08 20:56 ` Jeff Garzik
@ 2008-04-09 19:38 ` Ingo Molnar
2008-04-09 19:50 ` [patch] e1000=y && e1000e=m regression fix Jeff Garzik
` (2 more replies)
0 siblings, 3 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-09 19:38 UTC (permalink / raw
To: Jeff Garzik
Cc: Matthew Wilcox, Kok, Auke, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Jeff Garzik <jeff@garzik.org> wrote:
>> We've got three thousand Kconfig options - it is clearly not
>> realistic for users to keep such details in mind to avoid pitfalls.
>
> Agreed -- hence the multiple announcements, including in this thread,
> to put said details into mind.
which part of "it took a kernel developer more than an hour to figure
out why his laptop had a dead network interface" did you not understand?
Whatever you did, it was not apparent to me. I dont follow every tiny
detail of the e1000 driver family, nor do 99%+ [*] of our users.
find the fix below, against current -git.
the current upstream behavior is the worst possible one and is just a
plain bug, and the solution is dead-simple.
Ingo
[*] guesstimate
--------------->
Subject: e1000=y && e1000e=m regression fix
From: Ingo Molnar <mingo@elte.hu>
Date: Wed Apr 09 21:09:35 CEST 2008
fix a regression from v2.6.24: do not transfer the e1000e PCI IDs from
e1000 to e1000e if e1000 is built-in and e1000e is a module.
Built-in drivers take precedence over modules in many ways - and in this
case it's clear that the user intended the e1000 driver to be the
primary one. "Silently change behavior and break existing configs" is
never a good migration strategy. Most users will use distro kernels that
are not affected by this problem at all - nor are they affected by this
patch - but this problem can hit users and developers who build their
kernels themselves and migrate from v2.6.24 to v2.6.25.
this fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10427
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
drivers/net/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-x86.q/drivers/net/Kconfig
===================================================================
--- linux-x86.q.orig/drivers/net/Kconfig
+++ linux-x86.q/drivers/net/Kconfig
@@ -2022,7 +2022,7 @@ config E1000E
will be called e1000e.
config E1000E_ENABLED
- def_bool E1000E != n
+ def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
config IP1000
tristate "IP1000 Gigabit Ethernet support"
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-09 19:38 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Ingo Molnar
@ 2008-04-09 19:50 ` Jeff Garzik
2008-04-09 20:04 ` Ingo Molnar
2008-04-09 20:12 ` Kok, Auke
2008-04-09 20:49 ` Frans Pop
2 siblings, 1 reply; 125+ messages in thread
From: Jeff Garzik @ 2008-04-09 19:50 UTC (permalink / raw
To: Ingo Molnar
Cc: Matthew Wilcox, Kok, Auke, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> * Jeff Garzik <jeff@garzik.org> wrote:
>
>>> We've got three thousand Kconfig options - it is clearly not
>>> realistic for users to keep such details in mind to avoid pitfalls.
>> Agreed -- hence the multiple announcements, including in this thread,
>> to put said details into mind.
>
> which part of "it took a kernel developer more than an hour to figure
> out why his laptop had a dead network interface" did you not understand?
> Whatever you did, it was not apparent to me. I dont follow every tiny
> detail of the e1000 driver family, nor do 99%+ [*] of our users.
You do follow LKML, where multiple announcements have and are being posted.
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-09 19:50 ` [patch] e1000=y && e1000e=m regression fix Jeff Garzik
@ 2008-04-09 20:04 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-09 20:04 UTC (permalink / raw
To: Jeff Garzik
Cc: Matthew Wilcox, Kok, Auke, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Jeff Garzik <jeff@garzik.org> wrote:
> Ingo Molnar wrote:
>> * Jeff Garzik <jeff@garzik.org> wrote:
>>
>>>> We've got three thousand Kconfig options - it is clearly not realistic
>>>> for users to keep such details in mind to avoid pitfalls.
>>> Agreed -- hence the multiple announcements, including in this thread, to
>>> put said details into mind.
>>
>> which part of "it took a kernel developer more than an hour to figure
>> out why his laptop had a dead network interface" did you not
>> understand? Whatever you did, it was not apparent to me. I dont
>> follow every tiny detail of the e1000 driver family, nor do 99%+ [*]
>> of our users.
>
> You do follow LKML, where multiple announcements have and are being
> posted.
... what you say is contrary to the well-known regression rules of the
upstream kernel. You cannot seriously expect users to follow mailings
related to the 8+ million lines of code kernel they are utilizing, just
to not end up with a dead networking interface ....
so please comment on the fix i sent. The patch solves the problem i had
and it's end of this story as far as i'm concerned. Do you have any
strong technical argument why it should not be applied?
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-09 20:04 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-09 20:04 UTC (permalink / raw
To: Jeff Garzik
Cc: Kok, Auke, Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Jeff Garzik <jeff@garzik.org> wrote:
> Ingo Molnar wrote:
>> * Jeff Garzik <jeff@garzik.org> wrote:
>>
>>>> We've got three thousand Kconfig options - it is clearly not realistic
>>>> for users to keep such details in mind to avoid pitfalls.
>>> Agreed -- hence the multiple announcements, including in this thread, to
>>> put said details into mind.
>>
>> which part of "it took a kernel developer more than an hour to figure
>> out why his laptop had a dead network interface" did you not
>> understand? Whatever you did, it was not apparent to me. I dont
>> follow every tiny detail of the e1000 driver family, nor do 99%+ [*]
>> of our users.
>
> You do follow LKML, where multiple announcements have and are being
> posted.
... what you say is contrary to the well-known regression rules of the
upstream kernel. You cannot seriously expect users to follow mailings
related to the 8+ million lines of code kernel they are utilizing, just
to not end up with a dead networking interface ....
so please comment on the fix i sent. The patch solves the problem i had
and it's end of this story as far as i'm concerned. Do you have any
strong technical argument why it should not be applied?
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-09 19:38 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Ingo Molnar
2008-04-09 19:50 ` [patch] e1000=y && e1000e=m regression fix Jeff Garzik
@ 2008-04-09 20:12 ` Kok, Auke
2008-04-09 20:53 ` Ingo Molnar
2008-04-10 18:29 ` Kok, Auke
2008-04-09 20:49 ` Frans Pop
2 siblings, 2 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-09 20:12 UTC (permalink / raw
To: Ingo Molnar
Cc: Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> * Jeff Garzik <jeff@garzik.org> wrote:
>
>>> We've got three thousand Kconfig options - it is clearly not
>>> realistic for users to keep such details in mind to avoid pitfalls.
>> Agreed -- hence the multiple announcements, including in this thread,
>> to put said details into mind.
>
> which part of "it took a kernel developer more than an hour to figure
> out why his laptop had a dead network interface" did you not understand?
> Whatever you did, it was not apparent to me. I dont follow every tiny
> detail of the e1000 driver family, nor do 99%+ [*] of our users.
>
> find the fix below, against current -git.
>
> the current upstream behavior is the worst possible one and is just a
> plain bug, and the solution is dead-simple.
If this makes people happy then I am happy to ack this.
Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
>
> Ingo
>
> [*] guesstimate
>
> --------------->
> Subject: e1000=y && e1000e=m regression fix
> From: Ingo Molnar <mingo@elte.hu>
> Date: Wed Apr 09 21:09:35 CEST 2008
>
> fix a regression from v2.6.24: do not transfer the e1000e PCI IDs from
> e1000 to e1000e if e1000 is built-in and e1000e is a module.
>
> Built-in drivers take precedence over modules in many ways - and in this
> case it's clear that the user intended the e1000 driver to be the
> primary one. "Silently change behavior and break existing configs" is
> never a good migration strategy. Most users will use distro kernels that
> are not affected by this problem at all - nor are they affected by this
> patch - but this problem can hit users and developers who build their
> kernels themselves and migrate from v2.6.24 to v2.6.25.
>
> this fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10427
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> drivers/net/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-x86.q/drivers/net/Kconfig
> ===================================================================
> --- linux-x86.q.orig/drivers/net/Kconfig
> +++ linux-x86.q/drivers/net/Kconfig
> @@ -2022,7 +2022,7 @@ config E1000E
> will be called e1000e.
>
> config E1000E_ENABLED
> - def_bool E1000E != n
> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
>
> config IP1000
> tristate "IP1000 Gigabit Ethernet support"
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-09 19:38 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Ingo Molnar
@ 2008-04-09 20:49 ` Frans Pop
2008-04-09 20:12 ` Kok, Auke
2008-04-09 20:49 ` Frans Pop
2 siblings, 0 replies; 125+ messages in thread
From: Frans Pop @ 2008-04-09 20:49 UTC (permalink / raw
To: Ingo Molnar
Cc: jeff, matthew, auke-jan.h.kok, linux-kernel, netdev, e1000-devel,
linux-pci, akpm, davem, torvalds, jesse.brandeburg, john.ronciak,
bruce.w.allan, greg, arjan, rjw
Ingo Molnar wrote:
> Subject: e1000=y && e1000e=m regression fix
> From: Ingo Molnar <mingo@elte.hu>
> Date: Wed Apr 09 21:09:35 CEST 2008
>
> fix a regression from v2.6.24: do not transfer the e1000e PCI IDs from
> e1000 to e1000e if e1000 is built-in and e1000e is a module.
>
> Built-in drivers take precedence over modules in many ways - and in this
> case it's clear that the user intended the e1000 driver to be the
> primary one. "Silently change behavior and break existing configs" is
> never a good migration strategy. Most users will use distro kernels that
> are not affected by this problem at all - nor are they affected by this
> patch - but this problem can hit users and developers who build their
> kernels themselves and migrate from v2.6.24 to v2.6.25.
>
> this fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10427
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Speaking as someone who's mostly (guestimated at 97% ;-) a user, I'd be in
favor of a patch like this.
The scenario I have in mind that would lead to exactly the situation Ingo is
trying to solve is this:
Fairly experienced user wants a kernel which supports his hardware without
having to load modules, but wants other modules available "just in case".
So he takes his distro kernel and selectively changes some modules to
built-ins, including e1000.
Next he upgrades to 2.6.25 and finds his NIC no longer works. Files bug
reports all over the place and loads of people waste valuable time trying
to help him. I doubt any of the people trying to help (who are trying to do
so without access to the hardware) will soon think of this scenario. It's
much more likely they'll get stuck on "but e1000e is available as a module,
so it should get loaded, right".
Maybe, just very maybe, someone, in an act of desperation will say "ok, try
compiling in the module, see if that works".
Or maybe they will stumble on this thread at some point. Anyway, I
completely agree with Ingo that it would be really nice if all the wasted
time and frustration could just be avoided.
Cheers,
FJP
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
@ 2008-04-09 20:49 ` Frans Pop
0 siblings, 0 replies; 125+ messages in thread
From: Frans Pop @ 2008-04-09 20:49 UTC (permalink / raw
To: Ingo Molnar
Cc: auke-jan.h.kok, jeff, matthew, e1000-devel, netdev, bruce.w.allan,
linux-kernel, davem, rjw, jesse.brandeburg, john.ronciak, arjan,
greg, linux-pci, torvalds, akpm
Ingo Molnar wrote:
> Subject: e1000=y && e1000e=m regression fix
> From: Ingo Molnar <mingo@elte.hu>
> Date: Wed Apr 09 21:09:35 CEST 2008
>
> fix a regression from v2.6.24: do not transfer the e1000e PCI IDs from
> e1000 to e1000e if e1000 is built-in and e1000e is a module.
>
> Built-in drivers take precedence over modules in many ways - and in this
> case it's clear that the user intended the e1000 driver to be the
> primary one. "Silently change behavior and break existing configs" is
> never a good migration strategy. Most users will use distro kernels that
> are not affected by this problem at all - nor are they affected by this
> patch - but this problem can hit users and developers who build their
> kernels themselves and migrate from v2.6.24 to v2.6.25.
>
> this fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10427
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Speaking as someone who's mostly (guestimated at 97% ;-) a user, I'd be in
favor of a patch like this.
The scenario I have in mind that would lead to exactly the situation Ingo is
trying to solve is this:
Fairly experienced user wants a kernel which supports his hardware without
having to load modules, but wants other modules available "just in case".
So he takes his distro kernel and selectively changes some modules to
built-ins, including e1000.
Next he upgrades to 2.6.25 and finds his NIC no longer works. Files bug
reports all over the place and loads of people waste valuable time trying
to help him. I doubt any of the people trying to help (who are trying to do
so without access to the hardware) will soon think of this scenario. It's
much more likely they'll get stuck on "but e1000e is available as a module,
so it should get loaded, right".
Maybe, just very maybe, someone, in an act of desperation will say "ok, try
compiling in the module, see if that works".
Or maybe they will stumble on this thread at some point. Anyway, I
completely agree with Ingo that it would be really nice if all the wasted
time and frustration could just be avoided.
Cheers,
FJP
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-09 20:12 ` Kok, Auke
@ 2008-04-09 20:53 ` Ingo Molnar
2008-04-10 18:29 ` Kok, Auke
1 sibling, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-09 20:53 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> > find the fix below, against current -git.
> >
> > the current upstream behavior is the worst possible one and is just
> > a plain bug, and the solution is dead-simple.
>
> If this makes people happy then I am happy to ack this.
>
> Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
thanks Auke!
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-09 20:53 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-09 20:53 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> > find the fix below, against current -git.
> >
> > the current upstream behavior is the worst possible one and is just
> > a plain bug, and the solution is dead-simple.
>
> If this makes people happy then I am happy to ack this.
>
> Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
thanks Auke!
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-09 20:49 ` Frans Pop
(?)
@ 2008-04-09 23:59 ` Krzysztof Halasa
2008-04-10 1:40 ` Linus Torvalds
-1 siblings, 1 reply; 125+ messages in thread
From: Krzysztof Halasa @ 2008-04-09 23:59 UTC (permalink / raw
To: Frans Pop
Cc: Ingo Molnar, jeff, matthew, auke-jan.h.kok, linux-kernel, netdev,
e1000-devel, linux-pci, akpm, davem, torvalds, jesse.brandeburg,
john.ronciak, bruce.w.allan, greg, arjan, rjw
Frans Pop <elendil@planet.nl> writes:
> Fairly experienced user wants a kernel which supports his hardware without
> having to load modules, but wants other modules available "just in case".
> So he takes his distro kernel and selectively changes some modules to
> built-ins, including e1000.
> Next he upgrades to 2.6.25 and finds his NIC no longer works.
Nope, udev with normal distro config will load e1000e just fine.
A custom system, without automatic loading of modules (or with
unavailable module) could have this problem. A root fs on NFS or
something like that, too.
But while it can be changed for 2.6.25 it will break with 2.6.26 again,
definitely.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-08 19:51 ` Ingo Molnar
(?)
(?)
@ 2008-04-10 0:52 ` Bill Davidsen
2008-04-11 8:59 ` Ingo Molnar
-1 siblings, 1 reply; 125+ messages in thread
From: Bill Davidsen @ 2008-04-10 0:52 UTC (permalink / raw
To: linux-kernel; +Cc: e1000-devel, netdev, netdev, linux-kernel
Ingo Molnar wrote:
> * Matthew Wilcox <matthew@wil.cx> wrote:
>
>> On Tue, Apr 08, 2008 at 08:39:21PM +0200, Ingo Molnar wrote:
>>> so the pure presence of the e1000e module breaks the e1000 driver. That
>>> is a regression and a bug that should be fixed.
>> I think you've found the wrong problem ... it looks deliberate to me
>> that enabling e1000e disables e1000 from claiming the PCI IDs (see the
>> PCIE() macro right before the e1000_pci_tbl in
>> drivers/net/e1000/e1000_main.c).
>>
>> The question is why e1000e isn't claiming the device ...
>
> because i have e1000 built-in and dont load the e1000e module at all.
> That worked before and doesnt work now.
>
> the solution is rather straightforward: if E1000 is built-in then E1000E
> should be built-in as well or disabled (i.e. it should not be possible
> to build it as a module in that case) - because the PCI ID stealing
> trick now connects the two drivers unconditionally. [ If e1000 is a
> module then e1000e can be a module (or disabled) - this would be the
> most common configuration. ]
>
And this would seem to break the most common means of testing a new
driver for existing (and working!) hardware, which is to build both
drivers as modules, install the new one, and if it appears to have
problems either remove and insert the old driver by hand, or boot
forcing the old driver.
I can't be the only person who tests kernels on machines I wouldn't use
to build a kernel, and uses modprobe.conf to test new driver functionality.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-09 23:59 ` Krzysztof Halasa
@ 2008-04-10 1:40 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-10 1:40 UTC (permalink / raw
To: Krzysztof Halasa
Cc: Frans Pop, Ingo Molnar, jeff, matthew, auke-jan.h.kok,
linux-kernel, netdev, e1000-devel, linux-pci, akpm, davem,
jesse.brandeburg, john.ronciak, bruce.w.allan, greg, arjan, rjw
On Thu, 10 Apr 2008, Krzysztof Halasa wrote:
>
> Nope, udev with normal distro config will load e1000e just fine.
Not for us that don't compile modules at all, or only modules for the
devices we actually have.
Which should be about 99% of all kernel developers, because otherwise
you're just wasting your time.
I certainly want the configurations to be sane by default, because I'm not
in the insane camp that has every single module and depend on udev picking
the right one out.
Linus
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
@ 2008-04-10 1:40 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-10 1:40 UTC (permalink / raw
To: Krzysztof Halasa
Cc: auke-jan.h.kok, akpm, jeff, matthew, e1000-devel, netdev,
Frans Pop, bruce.w.allan, linux-kernel, davem, rjw,
jesse.brandeburg, john.ronciak, greg, Ingo Molnar, arjan,
linux-pci
On Thu, 10 Apr 2008, Krzysztof Halasa wrote:
>
> Nope, udev with normal distro config will load e1000e just fine.
Not for us that don't compile modules at all, or only modules for the
devices we actually have.
Which should be about 99% of all kernel developers, because otherwise
you're just wasting your time.
I certainly want the configurations to be sane by default, because I'm not
in the insane camp that has every single module and depend on udev picking
the right one out.
Linus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-10 1:40 ` Linus Torvalds
(?)
@ 2008-04-10 9:57 ` Krzysztof Halasa
2008-04-10 14:30 ` Linus Torvalds
-1 siblings, 1 reply; 125+ messages in thread
From: Krzysztof Halasa @ 2008-04-10 9:57 UTC (permalink / raw
To: Linus Torvalds
Cc: Frans Pop, Ingo Molnar, jeff, matthew, auke-jan.h.kok,
linux-kernel, netdev, e1000-devel, linux-pci, akpm, davem,
jesse.brandeburg, john.ronciak, bruce.w.allan, greg, arjan, rjw
Linus Torvalds <torvalds@linux-foundation.org> writes:
>> Nope, udev with normal distro config will load e1000e just fine.
>
> Not for us that don't compile modules at all, or only modules for the
> devices we actually have.
That would work, too.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-10 9:57 ` Krzysztof Halasa
@ 2008-04-10 14:30 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-10 14:30 UTC (permalink / raw
To: Krzysztof Halasa
Cc: Frans Pop, Ingo Molnar, jeff, matthew, auke-jan.h.kok,
linux-kernel, netdev, e1000-devel, linux-pci, akpm, davem,
jesse.brandeburg, john.ronciak, bruce.w.allan, greg, arjan, rjw
On Thu, 10 Apr 2008, Krzysztof Halasa wrote:
> >
> > Not for us that don't compile modules at all, or only modules for the
> > devices we actually have.
>
> That would work, too.
No it wouldn't, not when the driver we used forever suddenly stopped
supporting them.
The fact that some *other* driver that I'd never ever enabled in my life
suddenly supports them is irrelevant - it's not in my list of "hardware I
have", and it's not even getting compiled.
And no, I'm not talking about some theoretical "this could happen" thing.
I hit exactly that with commit 040babf9d84e7010c457e9ce69e9eb1c27927c9e (I
then thought that the new driver didn't even work for me, but that turned
out to be an unrelated bug).
It's very irritating when a working machine suddenly just stops working
because some config option just changed its meaning. VERY irritating.
Linus
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
@ 2008-04-10 14:30 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-10 14:30 UTC (permalink / raw
To: Krzysztof Halasa
Cc: auke-jan.h.kok, akpm, jeff, matthew, e1000-devel, netdev,
Frans Pop, bruce.w.allan, linux-kernel, davem, rjw,
jesse.brandeburg, john.ronciak, greg, Ingo Molnar, arjan,
linux-pci
On Thu, 10 Apr 2008, Krzysztof Halasa wrote:
> >
> > Not for us that don't compile modules at all, or only modules for the
> > devices we actually have.
>
> That would work, too.
No it wouldn't, not when the driver we used forever suddenly stopped
supporting them.
The fact that some *other* driver that I'd never ever enabled in my life
suddenly supports them is irrelevant - it's not in my list of "hardware I
have", and it's not even getting compiled.
And no, I'm not talking about some theoretical "this could happen" thing.
I hit exactly that with commit 040babf9d84e7010c457e9ce69e9eb1c27927c9e (I
then thought that the new driver didn't even work for me, but that turned
out to be an unrelated bug).
It's very irritating when a working machine suddenly just stops working
because some config option just changed its meaning. VERY irritating.
Linus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-10 14:30 ` Linus Torvalds
(?)
@ 2008-04-10 17:55 ` Grant Grundler
2008-04-10 18:04 ` Matthew Wilcox
2008-04-10 19:27 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Linus Torvalds
-1 siblings, 2 replies; 125+ messages in thread
From: Grant Grundler @ 2008-04-10 17:55 UTC (permalink / raw
To: Linus Torvalds
Cc: Krzysztof Halasa, Frans Pop, Ingo Molnar, jeff, matthew,
auke-jan.h.kok, linux-kernel, netdev, e1000-devel, linux-pci,
akpm, davem, jesse.brandeburg, john.ronciak, bruce.w.allan, greg,
arjan, rjw
On Thu, Apr 10, 2008 at 07:30:34AM -0700, Linus Torvalds wrote:
...
> The fact that some *other* driver that I'd never ever enabled in my life
> suddenly supports them is irrelevant - it's not in my list of "hardware I
> have", and it's not even getting compiled.
If e1000e is not getting compiled, my understanding was the original e1000
driver will claim whatever devices it historically has.
> And no, I'm not talking about some theoretical "this could happen" thing.
> I hit exactly that with commit 040babf9d84e7010c457e9ce69e9eb1c27927c9e (I
> then thought that the new driver didn't even work for me, but that turned
> out to be an unrelated bug).
>
> It's very irritating when a working machine suddenly just stops working
> because some config option just changed its meaning. VERY irritating.
Agreed. I like Ingo's Kconfig patch which forces both drivers
(e1000 and e1000e) to be built the same way (ie both modules or both
builtin).
grant
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-10 17:55 ` Grant Grundler
@ 2008-04-10 18:04 ` Matthew Wilcox
2008-04-10 18:26 ` [patch] e1000=y && e1000e=m regression fix Kok, Auke
2008-04-10 19:27 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Linus Torvalds
1 sibling, 1 reply; 125+ messages in thread
From: Matthew Wilcox @ 2008-04-10 18:04 UTC (permalink / raw
To: Grant Grundler
Cc: Linus Torvalds, Krzysztof Halasa, Frans Pop, Ingo Molnar, jeff,
auke-jan.h.kok, linux-kernel, netdev, e1000-devel, linux-pci,
akpm, davem, jesse.brandeburg, john.ronciak, bruce.w.allan, greg,
arjan, rjw
On Thu, Apr 10, 2008 at 11:55:03AM -0600, Grant Grundler wrote:
> Agreed. I like Ingo's Kconfig patch which forces both drivers
> (e1000 and e1000e) to be built the same way (ie both modules or both
> builtin).
Uh, that's /not/ what Ingo's patch does. His patch makes e1000 claim
the e1000e IDs if e1000 is built-in and e1000e is a module.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 18:04 ` Matthew Wilcox
@ 2008-04-10 18:26 ` Kok, Auke
2008-04-10 21:20 ` Chris Friesen
0 siblings, 1 reply; 125+ messages in thread
From: Kok, Auke @ 2008-04-10 18:26 UTC (permalink / raw
To: Matthew Wilcox
Cc: Grant Grundler, Linus Torvalds, Krzysztof Halasa, Frans Pop,
Ingo Molnar, jeff, auke-jan.h.kok, linux-kernel, netdev,
e1000-devel, linux-pci, akpm, davem, jesse.brandeburg,
john.ronciak, bruce.w.allan, greg, arjan, rjw
Matthew Wilcox wrote:
> On Thu, Apr 10, 2008 at 11:55:03AM -0600, Grant Grundler wrote:
>> Agreed. I like Ingo's Kconfig patch which forces both drivers
>> (e1000 and e1000e) to be built the same way (ie both modules or both
>> builtin).
>
> Uh, that's /not/ what Ingo's patch does. His patch makes e1000 claim
> the e1000e IDs if e1000 is built-in and e1000e is a module.
It does? that's definately not the right thing to do at all, so I'd like to
retract my ACK to that patch.
We want to move users over to e1000e, because with 2.6.26 they must (or at one
point in time anyway).
I'm all for making the move easier, but I'm really against prolonging these hacks
that make people just bump their noses later. If they hit the problem now instead
of when 2.6.26 ships, then it's all for the better IMHO.
Auke
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-09 20:12 ` Kok, Auke
2008-04-09 20:53 ` Ingo Molnar
@ 2008-04-10 18:29 ` Kok, Auke
2008-04-10 19:27 ` Ingo Molnar
1 sibling, 1 reply; 125+ messages in thread
From: Kok, Auke @ 2008-04-10 18:29 UTC (permalink / raw
To: Ingo Molnar
Cc: Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
Kok, Auke wrote:
> Ingo Molnar wrote:
>> * Jeff Garzik <jeff@garzik.org> wrote:
>>
>>>> We've got three thousand Kconfig options - it is clearly not
>>>> realistic for users to keep such details in mind to avoid pitfalls.
>>> Agreed -- hence the multiple announcements, including in this thread,
>>> to put said details into mind.
>> which part of "it took a kernel developer more than an hour to figure
>> out why his laptop had a dead network interface" did you not understand?
>> Whatever you did, it was not apparent to me. I dont follow every tiny
>> detail of the e1000 driver family, nor do 99%+ [*] of our users.
>>
>> find the fix below, against current -git.
>>
>> the current upstream behavior is the worst possible one and is just a
>> plain bug, and the solution is dead-simple.
>
>
> If this makes people happy then I am happy to ack this.
>
> Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
>
>> Ingo
>>
>> [*] guesstimate
>>
>> --------------->
>> Subject: e1000=y && e1000e=m regression fix
>> From: Ingo Molnar <mingo@elte.hu>
>> Date: Wed Apr 09 21:09:35 CEST 2008
>>
>> fix a regression from v2.6.24: do not transfer the e1000e PCI IDs from
>> e1000 to e1000e if e1000 is built-in and e1000e is a module.
>>
>> Built-in drivers take precedence over modules in many ways - and in this
>> case it's clear that the user intended the e1000 driver to be the
>> primary one. "Silently change behavior and break existing configs" is
>> never a good migration strategy. Most users will use distro kernels that
>> are not affected by this problem at all - nor are they affected by this
>> patch - but this problem can hit users and developers who build their
>> kernels themselves and migrate from v2.6.24 to v2.6.25.
>>
>> this fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10427
>>
>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>> ---
>> drivers/net/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: linux-x86.q/drivers/net/Kconfig
>> ===================================================================
>> --- linux-x86.q.orig/drivers/net/Kconfig
>> +++ linux-x86.q/drivers/net/Kconfig
>> @@ -2022,7 +2022,7 @@ config E1000E
>> will be called e1000e.
>>
>> config E1000E_ENABLED
>> - def_bool E1000E != n
>> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
Matthew Wilcox wrote:
> On Thu, Apr 10, 2008 at 11:55:03AM -0600, Grant Grundler wrote:
>> Agreed. I like Ingo's Kconfig patch which forces both drivers
>> (e1000 and e1000e) to be built the same way (ie both modules or both
>> builtin).
>
> Uh, that's /not/ what Ingo's patch does. His patch makes e1000 claim
> the e1000e IDs if e1000 is built-in and e1000e is a module.
so that's definately _not_ what I would like to see at all. Matthew points out
that this will just prolong users to use e1000 instead of e1000e (which is what
they should be encouraged to switch to in those cases).
so I'm dropping my ACK
this patch doesn't solve anything and we'll have the same issue back when 2.6.26
ships which will have no PCI Express device IDs in e1000.
Auke
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 18:29 ` Kok, Auke
@ 2008-04-10 19:27 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-10 19:27 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> >> config E1000E_ENABLED
> >> - def_bool E1000E != n
> >> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
>
> > Uh, that's /not/ what Ingo's patch does. His patch makes e1000
> > claim the e1000e IDs if e1000 is built-in and e1000e is a module.
>
> so that's definately _not_ what I would like to see at all. Matthew
> points out that this will just prolong users to use e1000 instead of
> e1000e (which is what they should be encouraged to switch to in those
> cases).
>
> so I'm dropping my ACK
why you want to cripple an existing, rather well working and popular
Linux driver is beyond me.
You have a wide array of measures if you want to migrate users to the
new and shiny e1000e driver: you can stop adding _new_ IDs to the old
driver, you can unsupport it, you can claim that it wont work in certain
situations, you can print out messages to the user in the dmesg (if
those messages are true), you can even remove IDs from it if the user
has the new driver enabled.
But what you cannot do is to intentionally cripple a popular driver.
It's plain stupid. It does not matter how many times you've announced
it, it's still madness. Unless your goal is to reduce the Linux userbase
as quickly as possible that is ... ;-)
And please understand: _you_ are the maintainer of this code so
_please_, if you wish to do so, solve the problem differently, but dont
just stand there _talking_. I gave you ample feedback about what the
problem is (which you initially denied to even exist) and i even wrote a
patch. You might never use e1000=y && e1000e=m or e1000=y && e1000e=n
but i do. Guys, the ball is in your court now.
> this patch doesn't solve anything [...]
huh? How can you claim that?? It definitely solved my problem. Did you
miss that aspect of my patch?
> [...] and we'll have the same issue back when 2.6.26 ships which will
> have no PCI Express device IDs in e1000.
... and not changing existing behavior for a perfectly well working
system is exactly what compatibility and smooth migration is about. New
drivers need several kernel releases to be fully known, to be fully
trusted and to be fully accepted and integrated - and not the least, to
be fully tested ...
These are all well-known principles. It's nothing new at all and there's
nothing special about it: dont break existing drivers and setups and
dont create silent side-effects between drivers.
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-10 19:27 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-10 19:27 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> >> config E1000E_ENABLED
> >> - def_bool E1000E != n
> >> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
>
> > Uh, that's /not/ what Ingo's patch does. His patch makes e1000
> > claim the e1000e IDs if e1000 is built-in and e1000e is a module.
>
> so that's definately _not_ what I would like to see at all. Matthew
> points out that this will just prolong users to use e1000 instead of
> e1000e (which is what they should be encouraged to switch to in those
> cases).
>
> so I'm dropping my ACK
why you want to cripple an existing, rather well working and popular
Linux driver is beyond me.
You have a wide array of measures if you want to migrate users to the
new and shiny e1000e driver: you can stop adding _new_ IDs to the old
driver, you can unsupport it, you can claim that it wont work in certain
situations, you can print out messages to the user in the dmesg (if
those messages are true), you can even remove IDs from it if the user
has the new driver enabled.
But what you cannot do is to intentionally cripple a popular driver.
It's plain stupid. It does not matter how many times you've announced
it, it's still madness. Unless your goal is to reduce the Linux userbase
as quickly as possible that is ... ;-)
And please understand: _you_ are the maintainer of this code so
_please_, if you wish to do so, solve the problem differently, but dont
just stand there _talking_. I gave you ample feedback about what the
problem is (which you initially denied to even exist) and i even wrote a
patch. You might never use e1000=y && e1000e=m or e1000=y && e1000e=n
but i do. Guys, the ball is in your court now.
> this patch doesn't solve anything [...]
huh? How can you claim that?? It definitely solved my problem. Did you
miss that aspect of my patch?
> [...] and we'll have the same issue back when 2.6.26 ships which will
> have no PCI Express device IDs in e1000.
... and not changing existing behavior for a perfectly well working
system is exactly what compatibility and smooth migration is about. New
drivers need several kernel releases to be fully known, to be fully
trusted and to be fully accepted and integrated - and not the least, to
be fully tested ...
These are all well-known principles. It's nothing new at all and there's
nothing special about it: dont break existing drivers and setups and
dont create silent side-effects between drivers.
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-10 17:55 ` Grant Grundler
2008-04-10 18:04 ` Matthew Wilcox
@ 2008-04-10 19:27 ` Linus Torvalds
1 sibling, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-10 19:27 UTC (permalink / raw
To: Grant Grundler
Cc: Krzysztof Halasa, Frans Pop, Ingo Molnar, jeff, matthew,
auke-jan.h.kok, linux-kernel, netdev, e1000-devel, linux-pci,
akpm, davem, jesse.brandeburg, john.ronciak, bruce.w.allan, greg,
arjan, rjw
On Thu, 10 Apr 2008, Grant Grundler wrote:
>
> If e1000e is not getting compiled, my understanding was the original e1000
> driver will claim whatever devices it historically has.
Yes. And the patch to do so was done by yours truly, exactly because I hit
this thing ;)
But it only works when the e1000e driver isn't enabled at all, which is
why the "e1000e=m" case ends up being different, and Ingo then hit that
one.
Linus
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 18:26 ` [patch] e1000=y && e1000e=m regression fix Kok, Auke
@ 2008-04-10 21:20 ` Chris Friesen
0 siblings, 0 replies; 125+ messages in thread
From: Chris Friesen @ 2008-04-10 21:20 UTC (permalink / raw
To: Kok, Auke
Cc: Matthew Wilcox, Grant Grundler, Linus Torvalds, Krzysztof Halasa,
Frans Pop, Ingo Molnar, jeff, linux-kernel, netdev, e1000-devel,
linux-pci, akpm, davem, jesse.brandeburg, john.ronciak,
bruce.w.allan, greg, arjan, rjw
Kok, Auke wrote:
> We want to move users over to e1000e, because with 2.6.26 they must (or at one
> point in time anyway).
>
> I'm all for making the move easier, but I'm really against prolonging these hacks
> that make people just bump their noses later. If they hit the problem now instead
> of when 2.6.26 ships, then it's all for the better IMHO.
Obviously e1000e hasn't been out for long enough to become common
knowledge. (Both Ingo and Linus running into the problem is probably a
sign...)
Maybe it would make sense to have "e1000 implies setting e1000e to the
same as e1000" for a couple releases, so that word gets around a bit
more. Then you can remove the auto-select of e1000e and anyone that
hasn't updated by then will get bit.
Chris
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 19:27 ` Ingo Molnar
(?)
@ 2008-04-10 21:23 ` Kok, Auke
2008-04-10 21:44 ` Randy Dunlap
` (2 more replies)
-1 siblings, 3 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-10 21:23 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List,
NetDev, e1000-list, linux-pci maillist, Andrew Morton,
David S. Miller, Linus Torvalds, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>
>>>> config E1000E_ENABLED
>>>> - def_bool E1000E != n
>>>> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
>>> Uh, that's /not/ what Ingo's patch does. His patch makes e1000
>>> claim the e1000e IDs if e1000 is built-in and e1000e is a module.
>> so that's definately _not_ what I would like to see at all. Matthew
>> points out that this will just prolong users to use e1000 instead of
>> e1000e (which is what they should be encouraged to switch to in those
>> cases).
>>
>> so I'm dropping my ACK
>
> why you want to cripple an existing, rather well working and popular
> Linux driver is beyond me.
Because we decided a long time ago to do this driver split. And everyone at that
time agreed with that, and we set out to do this. And part of that plan was to
move (not copy) the device IDs over.
We accepted that that might break some kernel developers' systems in the process
and consulted several vendors and distros if they were OK with the change and they
all agreed with the plan.
I do not want people with PCI Express e1000 cards to use e1000 for any day longer
than is strictly needed, and I certainly do not want to prolong the period where
both drivers could work on their adapters. That will be a far bigger nightmare for
me than just a few kernel developers having a bad day.
I guarantee, I will get e-mails about 2.6.25+e1000(e) issues for far longer then
you guys :)
Users will outnumber us kernel developers in complaints if we keep the situation
unclear to them, and we already told them that they need to switch to e1000e for
their PCI Express devices. If we now do stuff like what you proposed in that
patch, we just prolong this confusion. That cannot be good for anyone. Imagine if
distro's start picking random device IDs or worse. Stuff like that is already
happening, and discussions like these just add to the confusion.
Again - If there is a way to auto-enable e1000e in the right way so that more
systems migrate better then I'm all for it (even if forcing E1000E=y). But it
seems that the various patches proposed don't cut it and frankly Kconfig is
completely inadequate as a hardware enabling script since it knows absolutely
nothing about the hardware in the first place. And it wasn't meant for that
either. `make oldconfig` is not the answer ;).
Again - this has happened before, I remember many of my boxes not booting because
SATA Kconfig options changed and all my boxes failed to move the proper Kconfig
symbols over when I ran `make oldconfig` myself. Somewhere around 2.6.20 or so.
Auke
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
2008-04-10 14:30 ` Linus Torvalds
@ 2008-04-10 21:35 ` Krzysztof Halasa
-1 siblings, 0 replies; 125+ messages in thread
From: Krzysztof Halasa @ 2008-04-10 21:35 UTC (permalink / raw
To: Linus Torvalds
Cc: Frans Pop, Ingo Molnar, jeff, matthew, auke-jan.h.kok,
linux-kernel, netdev, e1000-devel, linux-pci, akpm, davem,
jesse.brandeburg, john.ronciak, bruce.w.allan, greg, arjan, rjw
Linus Torvalds <torvalds@linux-foundation.org> writes:
> No it wouldn't, not when the driver we used forever suddenly stopped
> supporting them.
In this case e1000 stops supporting them only if you enable e1000e
too. No e1000e, e1000 still does those IDs. For now, if I understand
it correctly. And it seems to print a warning.
So it doesn't work if you make e1000e a module and don't load it.
> And no, I'm not talking about some theoretical "this could happen" thing.
> I hit exactly that with commit
> 040babf9d84e7010c457e9ce69e9eb1c27927c9e
Right. Now it's a different situation, though.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)
@ 2008-04-10 21:35 ` Krzysztof Halasa
0 siblings, 0 replies; 125+ messages in thread
From: Krzysztof Halasa @ 2008-04-10 21:35 UTC (permalink / raw
To: Linus Torvalds
Cc: auke-jan.h.kok, akpm, jeff, matthew, e1000-devel, netdev,
Frans Pop, bruce.w.allan, linux-kernel, davem, rjw,
jesse.brandeburg, john.ronciak, greg, Ingo Molnar, arjan,
linux-pci
Linus Torvalds <torvalds@linux-foundation.org> writes:
> No it wouldn't, not when the driver we used forever suddenly stopped
> supporting them.
In this case e1000 stops supporting them only if you enable e1000e
too. No e1000e, e1000 still does those IDs. For now, if I understand
it correctly. And it seems to print a warning.
So it doesn't work if you make e1000e a module and don't load it.
> And no, I'm not talking about some theoretical "this could happen" thing.
> I hit exactly that with commit
> 040babf9d84e7010c457e9ce69e9eb1c27927c9e
Right. Now it's a different situation, though.
--
Krzysztof Halasa
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 21:23 ` Kok, Auke
@ 2008-04-10 21:44 ` Randy Dunlap
2008-04-10 21:52 ` Kok, Auke
2008-04-11 7:54 ` Andi Kleen
2008-04-11 0:46 ` Philip Craig
2008-04-11 11:26 ` Ingo Molnar
2 siblings, 2 replies; 125+ messages in thread
From: Randy Dunlap @ 2008-04-10 21:44 UTC (permalink / raw
To: Kok, Auke
Cc: Ingo Molnar, Jeff Garzik, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
On Thu, 10 Apr 2008 14:23:50 -0700 Kok, Auke wrote:
> Ingo Molnar wrote:
> > * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> >
> >>>> config E1000E_ENABLED
> >>>> - def_bool E1000E != n
> >>>> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
> >>> Uh, that's /not/ what Ingo's patch does. His patch makes e1000
> >>> claim the e1000e IDs if e1000 is built-in and e1000e is a module.
> >> so that's definately _not_ what I would like to see at all. Matthew
> >> points out that this will just prolong users to use e1000 instead of
> >> e1000e (which is what they should be encouraged to switch to in those
> >> cases).
> >>
> >> so I'm dropping my ACK
> >
> > why you want to cripple an existing, rather well working and popular
> > Linux driver is beyond me.
>
> Because we decided a long time ago to do this driver split. And everyone at that
> time agreed with that, and we set out to do this. And part of that plan was to
> move (not copy) the device IDs over.
>
> We accepted that that might break some kernel developers' systems in the process
> and consulted several vendors and distros if they were OK with the change and they
> all agreed with the plan.
>
> I do not want people with PCI Express e1000 cards to use e1000 for any day longer
> than is strictly needed, and I certainly do not want to prolong the period where
> both drivers could work on their adapters. That will be a far bigger nightmare for
> me than just a few kernel developers having a bad day.
>
> I guarantee, I will get e-mails about 2.6.25+e1000(e) issues for far longer then
> you guys :)
>
> Users will outnumber us kernel developers in complaints if we keep the situation
> unclear to them, and we already told them that they need to switch to e1000e for
> their PCI Express devices. If we now do stuff like what you proposed in that
> patch, we just prolong this confusion. That cannot be good for anyone. Imagine if
> distro's start picking random device IDs or worse. Stuff like that is already
> happening, and discussions like these just add to the confusion.
>
> Again - If there is a way to auto-enable e1000e in the right way so that more
> systems migrate better then I'm all for it (even if forcing E1000E=y). But it
> seems that the various patches proposed don't cut it and frankly Kconfig is
> completely inadequate as a hardware enabling script since it knows absolutely
> nothing about the hardware in the first place. And it wasn't meant for that
> either. `make oldconfig` is not the answer ;).
It would make much more sense IMO to add
CONFIG_E1000E=y
to defconfig ... and also to change
CONFIG_FUSION=y
to
CONFIG_FUSION=n
while there :)
> Again - this has happened before, I remember many of my boxes not booting because
> SATA Kconfig options changed and all my boxes failed to move the proper Kconfig
> symbols over when I ran `make oldconfig` myself. Somewhere around 2.6.20 or so.
---
~Randy
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 21:44 ` Randy Dunlap
@ 2008-04-10 21:52 ` Kok, Auke
2008-04-11 7:54 ` Andi Kleen
1 sibling, 0 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-10 21:52 UTC (permalink / raw
To: Randy Dunlap
Cc: Kok, Auke, Ingo Molnar, Jeff Garzik, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Randy Dunlap wrote:
> On Thu, 10 Apr 2008 14:23:50 -0700 Kok, Auke wrote:
>
>> Ingo Molnar wrote:
>>> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>>>
>>>>>> config E1000E_ENABLED
>>>>>> - def_bool E1000E != n
>>>>>> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
>>>>> Uh, that's /not/ what Ingo's patch does. His patch makes e1000
>>>>> claim the e1000e IDs if e1000 is built-in and e1000e is a module.
>>>> so that's definately _not_ what I would like to see at all. Matthew
>>>> points out that this will just prolong users to use e1000 instead of
>>>> e1000e (which is what they should be encouraged to switch to in those
>>>> cases).
>>>>
>>>> so I'm dropping my ACK
>>> why you want to cripple an existing, rather well working and popular
>>> Linux driver is beyond me.
>> Because we decided a long time ago to do this driver split. And everyone at that
>> time agreed with that, and we set out to do this. And part of that plan was to
>> move (not copy) the device IDs over.
>>
>> We accepted that that might break some kernel developers' systems in the process
>> and consulted several vendors and distros if they were OK with the change and they
>> all agreed with the plan.
>>
>> I do not want people with PCI Express e1000 cards to use e1000 for any day longer
>> than is strictly needed, and I certainly do not want to prolong the period where
>> both drivers could work on their adapters. That will be a far bigger nightmare for
>> me than just a few kernel developers having a bad day.
>>
>> I guarantee, I will get e-mails about 2.6.25+e1000(e) issues for far longer then
>> you guys :)
>>
>> Users will outnumber us kernel developers in complaints if we keep the situation
>> unclear to them, and we already told them that they need to switch to e1000e for
>> their PCI Express devices. If we now do stuff like what you proposed in that
>> patch, we just prolong this confusion. That cannot be good for anyone. Imagine if
>> distro's start picking random device IDs or worse. Stuff like that is already
>> happening, and discussions like these just add to the confusion.
>>
>> Again - If there is a way to auto-enable e1000e in the right way so that more
>> systems migrate better then I'm all for it (even if forcing E1000E=y). But it
>> seems that the various patches proposed don't cut it and frankly Kconfig is
>> completely inadequate as a hardware enabling script since it knows absolutely
>> nothing about the hardware in the first place. And it wasn't meant for that
>> either. `make oldconfig` is not the answer ;).
>
> It would make much more sense IMO to add
> CONFIG_E1000E=y
> to defconfig ... and also to change
> CONFIG_FUSION=y
> to
> CONFIG_FUSION=n
> while there :)
that first part (for x86 at least) I already sent (straight to linus even) after
same comment from Andy.
Auke
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 21:23 ` Kok, Auke
2008-04-10 21:44 ` Randy Dunlap
@ 2008-04-11 0:46 ` Philip Craig
2008-04-11 11:26 ` Ingo Molnar
2 siblings, 0 replies; 125+ messages in thread
From: Philip Craig @ 2008-04-11 0:46 UTC (permalink / raw
To: Kok, Auke
Cc: Ingo Molnar, Jeff Garzik, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Kok, Auke wrote:
> Again - If there is a way to auto-enable e1000e in the right way so that more
> systems migrate better then I'm all for it (even if forcing E1000E=y). But it
> seems that the various patches proposed don't cut it and frankly Kconfig is
> completely inadequate as a hardware enabling script since it knows absolutely
> nothing about the hardware in the first place. And it wasn't meant for that
> either. `make oldconfig` is not the answer ;).
One problem is that the meaning of E1000 has been changed. It covers less
hardware than it used to.
You could add a new option to control the e1000 driver, and make E1000 set
both this new option and E1000E. Thus it will always cover at least all
the IDs that the original e1000 driver handled.
config E1000
tristate "Both Intel(R) PRO/1000 Gigabit Ethernet support"
depends on PCI
config E1000_ONLY
tristate "Intel(R) PRO/1000 Gigabit Ethernet support" if E1000=n
default E1000
depends on PCI
config E1000E
tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support" if E1000=n
default E1000
depends on PCI
The E1000E prompt restriction is required to upgrade existing E1000=y,
E1000E=m configs to E1000E=y.
But it will also upgrade E1000=y/m,E1000E=n to E1000E=y/m, which may not
always be right.
This still doesn't solve any problems with loading modules for E1000=m.
Loading the e1000 module will still load support for less than it used to.
(Because make oldconfig is not the answer ;-)
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 21:44 ` Randy Dunlap
2008-04-10 21:52 ` Kok, Auke
@ 2008-04-11 7:54 ` Andi Kleen
1 sibling, 0 replies; 125+ messages in thread
From: Andi Kleen @ 2008-04-11 7:54 UTC (permalink / raw
To: Randy Dunlap
Cc: Kok, Auke, Ingo Molnar, Jeff Garzik, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Randy Dunlap <rdunlap@xenotime.net> writes:
>
> to defconfig ... and also to change
> CONFIG_FUSION=y
> to
> CONFIG_FUSION=n
> while there :)
In my experience with FUSION=y and AIC78xx=y most of the relatively
modern (2000+) pre SAS SCSI systems are covered, at least near all
those without special RAID controllers. That is why I kept both of
those enabled in the defconfigs originally.
Might actually make sense to update this for SAS, but I don't have
a good feeling what chipsets are really popular here.
-Andi
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-10 0:52 ` Bill Davidsen
@ 2008-04-11 8:59 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-11 8:59 UTC (permalink / raw
To: Bill Davidsen
Cc: Matthew Wilcox, Kok, Auke, Jeff Garzik, e1000-list, NetDev,
Allan, Bruce W, Linux Kernel Mailing List, David S. Miller,
Rafael J. Wysocki, Jesse Brandeburg, Ronciak, John,
Arjan van de Ven, Greg KH, linux-pci maillist, Linus Torvalds,
Andrew Morton
* Bill Davidsen <davidsen@tmr.com> wrote:
>> the solution is rather straightforward: if E1000 is built-in then
>> E1000E should be built-in as well or disabled (i.e. it should not be
>> possible to build it as a module in that case) - because the PCI ID
>> stealing trick now connects the two drivers unconditionally. [ If
>> e1000 is a module then e1000e can be a module (or disabled) - this
>> would be the most common configuration. ]
>
> And this would seem to break the most common means of testing a new
> driver for existing (and working!) hardware, which is to build both
> drivers as modules, install the new one, and if it appears to have
> problems either remove and insert the old driver by hand, or boot
> forcing the old driver.
>
> I can't be the only person who tests kernels on machines I wouldn't
> use to build a kernel, and uses modprobe.conf to test new driver
> functionality.
yes, but note that the breakage you are talking about is not caused my
patch, it is caused by the planned change to remove those PCI IDs from
e1000.
my suggested change only solves part of the more general problem you
touch upon. (and it does not make it worse in any way)
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-10 21:23 ` Kok, Auke
@ 2008-04-11 11:26 ` Ingo Molnar
2008-04-11 0:46 ` Philip Craig
2008-04-11 11:26 ` Ingo Molnar
2 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-11 11:26 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> Again - this has happened before, I remember many of my boxes not
> booting because SATA Kconfig options changed and all my boxes failed
> to move the proper Kconfig symbols over when I ran `make oldconfig`
> myself. Somewhere around 2.6.20 or so.
that's an insane argument ... because we messed up in the past and have
hurt users (and probably lost users) you feel like it gives you a free
card to mess up again???
The IDE -> SATA migration, while i like the new SATA code and find it
excellent and well-maintained (many kudos for that to Tejun, Jeff, Alan
& co), caused a lot of trouble for users in one specific area, for no
good reasons other than stupid personality conflicts: /dev/hda worked
just as well as /dev/sda, the _name_ of the device should never have
been changed.
So if you use _that_ aspect of the (otherwise cool) SATA/PATA code as a
blueprint for the e1000 -> e1000e migration then you are on the worst
possible track in terms of picking a role model ;-) It's as if you
adored Sylvester Stallone for his vivid mimics, Jean-Claude Van Damne
for his excellent acting skills and Paris Hilton for her brillant brain.
really, just because you do exceedingly good things to Linux does not
give you a free card to do something bad to Linux in exchange. The two
do not cancel out each other - because the bad things _add up_ and drive
away users, irreversibly. To you e1000 is the center of the universe so
you feel the price is worth paying. For others it is not. We want the
good things from you and we'll say no thanks to the bad ideas. Kernel
developers, especially old-timers, regularly forget about that.
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 11:26 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-11 11:26 UTC (permalink / raw
To: Kok, Auke
Cc: Jeff Garzik, Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Rafael J. Wysocki,
Jesse Brandeburg, Ronciak, John, Arjan van de Ven, Greg KH,
linux-pci maillist, Linus Torvalds, Andrew Morton
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> Again - this has happened before, I remember many of my boxes not
> booting because SATA Kconfig options changed and all my boxes failed
> to move the proper Kconfig symbols over when I ran `make oldconfig`
> myself. Somewhere around 2.6.20 or so.
that's an insane argument ... because we messed up in the past and have
hurt users (and probably lost users) you feel like it gives you a free
card to mess up again???
The IDE -> SATA migration, while i like the new SATA code and find it
excellent and well-maintained (many kudos for that to Tejun, Jeff, Alan
& co), caused a lot of trouble for users in one specific area, for no
good reasons other than stupid personality conflicts: /dev/hda worked
just as well as /dev/sda, the _name_ of the device should never have
been changed.
So if you use _that_ aspect of the (otherwise cool) SATA/PATA code as a
blueprint for the e1000 -> e1000e migration then you are on the worst
possible track in terms of picking a role model ;-) It's as if you
adored Sylvester Stallone for his vivid mimics, Jean-Claude Van Damne
for his excellent acting skills and Paris Hilton for her brillant brain.
really, just because you do exceedingly good things to Linux does not
give you a free card to do something bad to Linux in exchange. The two
do not cancel out each other - because the bad things _add up_ and drive
away users, irreversibly. To you e1000 is the center of the universe so
you feel the price is worth paying. For others it is not. We want the
good things from you and we'll say no thanks to the bad ideas. Kernel
developers, especially old-timers, regularly forget about that.
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-09 19:33 ` Jeff Garzik
@ 2008-04-11 11:30 ` Ingo Molnar
2008-04-11 15:40 ` Chris Friesen
0 siblings, 1 reply; 125+ messages in thread
From: Ingo Molnar @ 2008-04-11 11:30 UTC (permalink / raw
To: Jeff Garzik
Cc: Kok, Auke, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Linus Torvalds, Jesse Brandeburg, Ronciak, John, Allan, Bruce W,
Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Jeff Garzik <jeff@garzik.org> wrote:
>> So i'm not sure why you are arguing about all this. Please just fix
>> this bug, simple as that.
>
> I haven't said NAK, but I think the suggested fix is a waste of time
> because
>
> 1) it breaks (by disallowing) a valid setup based on one report
>
> 2) it only happens to experienced kernel hackers with weird configs
>
> 3) the suggested fix binds together more tightly two drivers we are
> trying to keep separate
>
> 4) it is a temporary situation that will go away in 2.6.26 anyway
well, your 2.6.26 plans, if i understand them correctly, is to move
currently working PCI IDs from e1000 to e1000e, like you attempted to d
it in v2.6.24, which Linus reverted - correct? I.e. e1000 simply wont
support eth0 on my T60 from 2.6.26 on? That is still an incredibly
stupid plan, and no amount of announcement on lkml will make it any less
stupid.
... which pretty much pulls the rug from under your argument, no?
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 11:26 ` Ingo Molnar
(?)
@ 2008-04-11 11:36 ` Christoph Hellwig
2008-04-11 12:16 ` Ingo Molnar
-1 siblings, 1 reply; 125+ messages in thread
From: Christoph Hellwig @ 2008-04-11 11:36 UTC (permalink / raw
To: Ingo Molnar
Cc: Kok, Auke, Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List,
NetDev, e1000-list, linux-pci maillist, Andrew Morton,
David S. Miller, Linus Torvalds, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
On Fri, Apr 11, 2008 at 01:26:53PM +0200, Ingo Molnar wrote:
> really, just because you do exceedingly good things to Linux does not
> give you a free card to do something bad to Linux in exchange. The two
> do not cancel out each other - because the bad things _add up_ and drive
> away users, irreversibly. To you e1000 is the center of the universe so
> you feel the price is worth paying. For others it is not. We want the
> good things from you and we'll say no thanks to the bad ideas. Kernel
> developers, especially old-timers, regularly forget about that.
Hey, hey calm down. The device moving over to e1000e shouldn never
have been added to e1000. They're totally differnet and the only reason
they got added in thefirst time was because soemone talked intel into
it.
We discussed this a long time and came to a wide agreement it should
move out. Now the actual transition could and should have been handled
better, but with all the pci-e hardware in a separate driver we're all
off better in the long term.
And this is not really comparable to the libata transition at all,
there's no user-visible changed. For every distro kernel that just
builds both driver it's a completely seamless transition, and for
people who build their own kernel we should find some Kconfig trickery
to make the transition easier. For example we could just built e1000e
when CONFIG_E1000 is set and spill a warning that starting from 1.1.2009
you will have to have CONFIG_E1000E set aswell.
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 11:36 ` Christoph Hellwig
@ 2008-04-11 12:16 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-11 12:16 UTC (permalink / raw
To: Christoph Hellwig
Cc: Kok, Auke, Jeff Garzik, Matthew Wilcox, Linux Kernel Mailing List,
NetDev, e1000-list, linux-pci maillist, Andrew Morton,
David S. Miller, Linus Torvalds, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
* Christoph Hellwig <hch@infradead.org> wrote:
> And this is not really comparable to the libata transition at all,
> there's no user-visible changed. [...]
well it was Auke who compared it to the libata transition not me ...
> [...] For every distro kernel that just builds both driver it's a
> completely seamless transition, and for people who build their own
> kernel we should find some Kconfig trickery to make the transition
> easier. For example we could just built e1000e when CONFIG_E1000 is
> set and spill a warning that starting from 1.1.2009 you will have to
> have CONFIG_E1000E set aswell.
firstly, a good deal of our alpha testers use =y drivers. Secondly, your
kind of constructive email is exactly what i wanted to see in the first
place...
i dont really care _how_ this gets solved - i'm not maintaining this
code. What forced me to deal with it was this outright denial of my
problem, the ridiculing and NACK-ing of it and general stonewalling.
I'd have preferred to have sent only my first report. The networking
driver guys on the other hand:
1) forced me to send a full bugreport about something that i described
adequately in my very first mail already, and which they should have
immediately recognized, based on the trouble they had with Linus. (i
wasnt aware of that back when i made my report)
2) repeatedly denied that there is any problem. Claimed that "this is a
careful migration balance we decided" and other babbling.
3) forced me to write a patch for code they are supposed to be
maintaining to actually get things moving.
4) moved the regression bugzilla entry to REJECTED+INVALID without
actually resolving the bug and forced me to write several comments
there too. (See http://bugzilla.kernel.org/show_bug.cgi?id=10427)
5) forced me to write 20 mails with still no clear resolution yet at
this point.
it's insane and i'm really curious what kind of language you'd use in
your replies if i ever forced you through such an excercise in arch/x86
or the scheduler ;-)
and no, it wasnt a case of miscommunication. My bug was i think
well-understood in the very first mailings already, but it was
discounted as unimportant and resolution was delayed all the way up
until this point. That shows fundamental insensitivity to bug reporters
which is more worrisome than the bug itself (the bug is fairly minor and
i never claimed otherwise).
Hours of my time wasted on something that should have been a 2 minutes
matter - and yes, as i go through these chores i do get increasingly
annoyed about it, and rightfully so. I cannot just let this happen
silently, way too much crap like this gets pulled off. If the networking
driver guys are pulling off a show like that with a fellow kernel
developer how do they manage to deal with plain users (who, in
comparison, are in essence defense-less against rejections from
maintainers)?
and yes, moving those IDs over into e1000e in v2.6.26 might work out
fine in the end, if the migration is all totally problem free up to that
point. We simply cannot make that determination right now. What exactly
is so hard to understand about the concept of not degrading the quality
of an existing, rather well-working driver?
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 12:16 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-04-11 12:16 UTC (permalink / raw
To: Christoph Hellwig
Cc: Kok, Auke, Jeff Garzik, Matthew Wilcox, e1000-list, NetDev,
Allan, Bruce W, Linux Kernel Mailing List, David S. Miller,
Rafael J. Wysocki, Jesse Brandeburg, Ronciak, John,
Arjan van de Ven, Greg KH, linux-pci maillist, Linus Torvalds,
Andrew Morton
* Christoph Hellwig <hch@infradead.org> wrote:
> And this is not really comparable to the libata transition at all,
> there's no user-visible changed. [...]
well it was Auke who compared it to the libata transition not me ...
> [...] For every distro kernel that just builds both driver it's a
> completely seamless transition, and for people who build their own
> kernel we should find some Kconfig trickery to make the transition
> easier. For example we could just built e1000e when CONFIG_E1000 is
> set and spill a warning that starting from 1.1.2009 you will have to
> have CONFIG_E1000E set aswell.
firstly, a good deal of our alpha testers use =y drivers. Secondly, your
kind of constructive email is exactly what i wanted to see in the first
place...
i dont really care _how_ this gets solved - i'm not maintaining this
code. What forced me to deal with it was this outright denial of my
problem, the ridiculing and NACK-ing of it and general stonewalling.
I'd have preferred to have sent only my first report. The networking
driver guys on the other hand:
1) forced me to send a full bugreport about something that i described
adequately in my very first mail already, and which they should have
immediately recognized, based on the trouble they had with Linus. (i
wasnt aware of that back when i made my report)
2) repeatedly denied that there is any problem. Claimed that "this is a
careful migration balance we decided" and other babbling.
3) forced me to write a patch for code they are supposed to be
maintaining to actually get things moving.
4) moved the regression bugzilla entry to REJECTED+INVALID without
actually resolving the bug and forced me to write several comments
there too. (See http://bugzilla.kernel.org/show_bug.cgi?id=10427)
5) forced me to write 20 mails with still no clear resolution yet at
this point.
it's insane and i'm really curious what kind of language you'd use in
your replies if i ever forced you through such an excercise in arch/x86
or the scheduler ;-)
and no, it wasnt a case of miscommunication. My bug was i think
well-understood in the very first mailings already, but it was
discounted as unimportant and resolution was delayed all the way up
until this point. That shows fundamental insensitivity to bug reporters
which is more worrisome than the bug itself (the bug is fairly minor and
i never claimed otherwise).
Hours of my time wasted on something that should have been a 2 minutes
matter - and yes, as i go through these chores i do get increasingly
annoyed about it, and rightfully so. I cannot just let this happen
silently, way too much crap like this gets pulled off. If the networking
driver guys are pulling off a show like that with a fellow kernel
developer how do they manage to deal with plain users (who, in
comparison, are in essence defense-less against rejections from
maintainers)?
and yes, moving those IDs over into e1000e in v2.6.26 might work out
fine in the end, if the migration is all totally problem free up to that
point. We simply cannot make that determination right now. What exactly
is so hard to understand about the concept of not degrading the quality
of an existing, rather well-working driver?
Ingo
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-11 11:30 ` Ingo Molnar
@ 2008-04-11 15:40 ` Chris Friesen
2008-04-11 19:29 ` Willy Tarreau
0 siblings, 1 reply; 125+ messages in thread
From: Chris Friesen @ 2008-04-11 15:40 UTC (permalink / raw
To: Ingo Molnar
Cc: Jeff Garzik, Kok, Auke, Matthew Wilcox, Linux Kernel Mailing List,
NetDev, e1000-list, linux-pci maillist, Andrew Morton,
David S. Miller, Linus Torvalds, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
Ingo Molnar wrote:
> well, your 2.6.26 plans, if i understand them correctly, is to move
> currently working PCI IDs from e1000 to e1000e, like you attempted to d
> it in v2.6.24, which Linus reverted - correct? I.e. e1000 simply wont
> support eth0 on my T60 from 2.6.26 on? That is still an incredibly
> stupid plan, and no amount of announcement on lkml will make it any less
> stupid.
It seems like you're saying that once hardware is supported by a
particular config option, it can never ever be split out to another
config option, even if it makes both drivers cleaner.
A similar situation happened when the sk98lin driver was split into skge
and sky2...I don't remember a big fuss back then. Is it just that no
major developers were using the hardware so they didn't notice?
Chris
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 12:16 ` Ingo Molnar
(?)
@ 2008-04-11 16:22 ` Kok, Auke
2008-04-11 16:45 ` Christoph Hellwig
2008-04-11 17:10 ` Martin Mares
-1 siblings, 2 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-11 16:22 UTC (permalink / raw
To: Ingo Molnar
Cc: Christoph Hellwig, Jeff Garzik, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Ingo Molnar wrote:
> i dont really care _how_ this gets solved - i'm not maintaining this
> code. What forced me to deal with it was this outright denial of my
> problem, the ridiculing and NACK-ing of it and general stonewalling.
this is a gross misrepresentation and misunderstanding. You're completely ignoring
the fact that:
(1) I debated whether it was a "regression" - in my opinion design changes that
deliberately break things are hardly worth this incredibly negative stamp
(2) I never NACK'ed your patch. I just withdrew my ack.
(3) You're stonewalling me by pretty much forcing me to completely drop the driver
split and not showing any understanding for the reason behind the split at all.
You don't provide a solution, nor does anyone, and I don't see any solution to
what you want but to completely cancel this driver split.
And I'm _not_ going to do that.
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 16:22 ` Kok, Auke
@ 2008-04-11 16:45 ` Christoph Hellwig
2008-04-11 17:26 ` Kok, Auke
2008-04-11 17:34 ` Linus Torvalds
2008-04-11 17:10 ` Martin Mares
1 sibling, 2 replies; 125+ messages in thread
From: Christoph Hellwig @ 2008-04-11 16:45 UTC (permalink / raw
To: Kok, Auke
Cc: Ingo Molnar, Christoph Hellwig, Jeff Garzik, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
On Fri, Apr 11, 2008 at 09:22:56AM -0700, Kok, Auke wrote:
> You don't provide a solution, nor does anyone, and I don't see any solution to
> what you want but to completely cancel this driver split.
>
> And I'm _not_ going to do that.
As a start we could do two driver keyed off a single Kconfig variable.
And then find a way to get users informed that they might need to
enabled the other one
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 16:22 ` Kok, Auke
2008-04-11 16:45 ` Christoph Hellwig
@ 2008-04-11 17:10 ` Martin Mares
1 sibling, 0 replies; 125+ messages in thread
From: Martin Mares @ 2008-04-11 17:10 UTC (permalink / raw
To: Kok, Auke
Cc: Ingo Molnar, Christoph Hellwig, Jeff Garzik, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Hello!
> You don't provide a solution, nor does anyone, and I don't see any solution to
> what you want but to completely cancel this driver split.
Maybe you could rename both configuration switches, so that you bring it to
the attention of everybody who does make oldconfig?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
main(){char *s="main(){char *s=%c%s%c;printf(s,34,s,34);}";printf(s,34,s,34);}
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 16:45 ` Christoph Hellwig
@ 2008-04-11 17:26 ` Kok, Auke
2008-04-11 17:34 ` Linus Torvalds
1 sibling, 0 replies; 125+ messages in thread
From: Kok, Auke @ 2008-04-11 17:26 UTC (permalink / raw
To: Jeff Garzik, NetDev
Cc: Christoph Hellwig, Ingo Molnar, Matthew Wilcox,
Linux Kernel Mailing List, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
Christoph Hellwig wrote:
> On Fri, Apr 11, 2008 at 09:22:56AM -0700, Kok, Auke wrote:
>> You don't provide a solution, nor does anyone, and I don't see any solution to
>> what you want but to completely cancel this driver split.
>>
>> And I'm _not_ going to do that.
>
> As a start we could do two driver keyed off a single Kconfig variable.
> And then find a way to get users informed that they might need to
> enabled the other one
This is probably the ugliest way to do it, but I just checked and if E1000=m then
automatically becomes E1000E=m etc.
Using 'default' will not work as people will misunderstand the issue and disable
e1000e anyway, while they often need e1000e instead of e1000.
Yes, this does mean that it's impossible to have e1000 but not enable e1000e, but
given the threads I think this is becoming more reasonable then ever for this
particular issue.
---
e1000e: select automatically if e1000 is enabled
This terrible Kconfig hack prevents most people from accidentally forgetting to
enable e1000e where appropriate - just enable it by default. This patch should be
removed once e1000e merge is done and settled.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ec764a9..19b5b2b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1968,6 +1968,7 @@ config DL2K
config E1000
tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
depends on PCI
+ select E1000E
---help---
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
^ permalink raw reply related [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 16:45 ` Christoph Hellwig
2008-04-11 17:26 ` Kok, Auke
@ 2008-04-11 17:34 ` Linus Torvalds
2008-04-11 17:53 ` Matthew Wilcox
2008-04-11 22:06 ` Daniel Barkalow
1 sibling, 2 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 17:34 UTC (permalink / raw
To: Christoph Hellwig
Cc: Kok, Auke, Ingo Molnar, Jeff Garzik, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Christoph Hellwig wrote:
>
> As a start we could do two driver keyed off a single Kconfig variable.
> And then find a way to get users informed that they might need to
> enabled the other one
I think that's a great solution.
Here's a suggested patch. Not much tested, but it's fairly obvious.
It basically makes one top-level config option (E1000) to pick the driver
at all, and two sub-options (E1000_PCI and E1000_PCIE) that you can choose
between.
If you pick E1000 support, you're given the choice between "PCI only",
"PCI-E only" or "support both", and that will then pick the right
combination of support for E1000_PCI and E1000_PCIE.
This also does imply that you cannot mix the "module-ness" of the two
drivers, because you choose whether the E1000 support (in general) is
going to be a module or built-in, and that choice will automatically
affect the sub-choices.
I do think that this makes the whole driver status much more obvious.
(It does mean that if you chose E1000E before, and chose _not_ to support
E1000 at all, you will now not even be asked about PCI-E support, because
you've effectively said "no" to E1000 support in the first place. If we
want to avoid that, then the top-level E1000 config variable should
probably be renamed to E1000_SUPPORT or something like that).
Linus
---
drivers/net/Kconfig | 52 +++++++++++++++++++++++-------------------
drivers/net/Makefile | 4 +-
drivers/net/e1000/Makefile | 2 +-
drivers/net/e1000e/Makefile | 2 +-
4 files changed, 32 insertions(+), 28 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 3a0b20a..6968e20 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1979,9 +1979,35 @@ config E1000
To compile this driver as a module, choose M here. The module
will be called e1000.
+choice
+ prompt "E1000 bus type support"
+ depends on E1000
+ default E1000_BOTH
+ help
+ Choose PCI or PCI-E support for E1000 driver
+
+config E1000_PCI_ONLY
+ bool "Support only older E1000 PCI cards"
+
+config E1000_PCIE_ONLY
+ bool "Support newer E1000 PCI-E cards"
+
+config E1000_BOTH
+ bool "Support all E1000 cards"
+
+endchoice
+
+config E1000_PCI
+ tristate
+ default E1000 && !E1000_PCIE_ONLY
+
+config E1000_PCIE
+ tristate
+ default E1000 && !E1000_PCI_ONLY
+
config E1000_NAPI
bool "Use Rx Polling (NAPI)"
- depends on E1000
+ depends on E1000_PCI
help
NAPI is a new driver API designed to reduce CPU and interrupt load
when the driver is receiving lots of packets from the card. It is
@@ -1995,35 +2021,13 @@ config E1000_NAPI
config E1000_DISABLE_PACKET_SPLIT
bool "Disable Packet Split for PCI express adapters"
- depends on E1000
+ depends on E1000_PCI
help
Say Y here if you want to use the legacy receive path for PCI express
hardware.
If in doubt, say N.
-config E1000E
- tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
- depends on PCI
- ---help---
- This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
- ethernet family of adapters. For PCI or PCI-X e1000 adapters,
- use the regular e1000 driver For more information on how to
- identify your adapter, go to the Adapter & Driver ID Guide at:
-
- <http://support.intel.com/support/network/adapter/pro100/21397.htm>
-
- For general information and support, go to the Intel support
- website at:
-
- <http://support.intel.com>
-
- To compile this driver as a module, choose M here. The module
- will be called e1000e.
-
-config E1000E_ENABLED
- def_bool E1000E != n
-
config IP1000
tristate "IP1000 Gigabit Ethernet support"
depends on PCI && EXPERIMENTAL
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 3b1ea32..c1bead0 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -2,8 +2,8 @@
# Makefile for the Linux network (ethercard) device drivers.
#
-obj-$(CONFIG_E1000) += e1000/
-obj-$(CONFIG_E1000E) += e1000e/
+obj-$(CONFIG_E1000_PCI) += e1000/
+obj-$(CONFIG_E1000_PCIE) += e1000e/
obj-$(CONFIG_IBM_EMAC) += ibm_emac/
obj-$(CONFIG_IBM_NEW_EMAC) += ibm_newemac/
obj-$(CONFIG_IGB) += igb/
diff --git a/drivers/net/e1000/Makefile b/drivers/net/e1000/Makefile
index 4a6ab15..431052b 100644
--- a/drivers/net/e1000/Makefile
+++ b/drivers/net/e1000/Makefile
@@ -30,6 +30,6 @@
# Makefile for the Intel(R) PRO/1000 ethernet driver
#
-obj-$(CONFIG_E1000) += e1000.o
+obj-$(CONFIG_E1000_PCI) += e1000.o
e1000-objs := e1000_main.o e1000_hw.o e1000_ethtool.o e1000_param.o
diff --git a/drivers/net/e1000e/Makefile b/drivers/net/e1000e/Makefile
index 650f866..a1e977e 100644
--- a/drivers/net/e1000e/Makefile
+++ b/drivers/net/e1000e/Makefile
@@ -30,7 +30,7 @@
# Makefile for the Intel(R) PRO/1000 ethernet driver
#
-obj-$(CONFIG_E1000E) += e1000e.o
+obj-$(CONFIG_E1000_PCIE) += e1000e.o
e1000e-objs := 82571.o ich8lan.o es2lan.o \
lib.o phy.o param.o ethtool.o netdev.o
^ permalink raw reply related [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 17:34 ` Linus Torvalds
@ 2008-04-11 17:53 ` Matthew Wilcox
2008-04-11 18:51 ` Linus Torvalds
2008-04-11 22:06 ` Daniel Barkalow
1 sibling, 1 reply; 125+ messages in thread
From: Matthew Wilcox @ 2008-04-11 17:53 UTC (permalink / raw
To: Linus Torvalds
Cc: Christoph Hellwig, Kok, Auke, Ingo Molnar, Jeff Garzik,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
On Fri, Apr 11, 2008 at 10:34:01AM -0700, Linus Torvalds wrote:
> Here's a suggested patch. Not much tested, but it's fairly obvious.
>
> It basically makes one top-level config option (E1000) to pick the driver
> at all, and two sub-options (E1000_PCI and E1000_PCIE) that you can choose
> between.
I think it's a little over-engineered ... why not simply:
config E1000_SUPPORT
bool "Intel(R) PRO/1000 Gigabit Ethernet support"
depends on PCI
config E1000
depends on E1000_SUPPORT
tristate "E1000 PCI support"
help
Include support for Conventional PCI devices. This includes
chips built into motherboards ... blah blah, if unsure say "Y"
or "M"
config E1000E
depends on E1000_SUPPORT
tristate "E1000 PCI Express support"
help
Include support for PCI Express devices. This includes chips
built into motherboards such as ICH9 ... blah blah, if unsure
say "Y" or "M".
and get rid of the PCIE() macros from the e1000 driver. While it does
allow someone like Ingo to create a E1000=y and E1000E=m situation
(which won't bind to an ethernet card that E1000 used to), having the
E1000_SUPPORT symbol means that oldconfig will stop and ask you which
hopefully makes it obvious enough that things have changed here and you
need to pay attention.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 17:53 ` Matthew Wilcox
@ 2008-04-11 18:51 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 18:51 UTC (permalink / raw
To: Matthew Wilcox
Cc: Christoph Hellwig, Kok, Auke, Ingo Molnar, Jeff Garzik,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Matthew Wilcox wrote:
>
> I think it's a little over-engineered ... why not simply:
Because your version has exactly the same problem that the current code
has: it asks questions that aren't sensible to people who don't care. It
also keeps the old E1000 name for "PCI chips only", which means that
people who just use an old config and ignore new questions will suddenly
lose their ability to use the E1000 driver if they have a PCI-E card.
So most users:
- want to just say "E1000", and not care about type.
- want to have old configurations continue working (ie if you haev had
"E1000" driving your hardware before, it should _continue_ to do so,
with no need to select a _new_ E1000E question!
Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
it's almost impossible to tell. Here, quickly, tell me which one mine is
(this is from /sbin/lspci):
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
and tell me how you knew..
Linus
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 18:51 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 18:51 UTC (permalink / raw
To: Matthew Wilcox
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Jeff Garzik,
e1000-list, NetDev, Allan, Bruce W, Linux Kernel Mailing List,
David S. Miller, Christoph Hellwig, Jesse Brandeburg,
Ronciak, John, Greg KH, Ingo Molnar, Arjan van de Ven,
linux-pci maillist
On Fri, 11 Apr 2008, Matthew Wilcox wrote:
>
> I think it's a little over-engineered ... why not simply:
Because your version has exactly the same problem that the current code
has: it asks questions that aren't sensible to people who don't care. It
also keeps the old E1000 name for "PCI chips only", which means that
people who just use an old config and ignore new questions will suddenly
lose their ability to use the E1000 driver if they have a PCI-E card.
So most users:
- want to just say "E1000", and not care about type.
- want to have old configurations continue working (ie if you haev had
"E1000" driving your hardware before, it should _continue_ to do so,
with no need to select a _new_ E1000E question!
Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
it's almost impossible to tell. Here, quickly, tell me which one mine is
(this is from /sbin/lspci):
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
and tell me how you knew..
Linus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 18:51 ` Linus Torvalds
(?)
@ 2008-04-11 19:01 ` Matthew Wilcox
2008-04-11 19:25 ` Willy Tarreau
2008-04-11 20:21 ` Linus Torvalds
-1 siblings, 2 replies; 125+ messages in thread
From: Matthew Wilcox @ 2008-04-11 19:01 UTC (permalink / raw
To: Linus Torvalds
Cc: Christoph Hellwig, Kok, Auke, Ingo Molnar, Jeff Garzik,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
On Fri, Apr 11, 2008 at 11:51:07AM -0700, Linus Torvalds wrote:
> Because your version has exactly the same problem that the current code
> has: it asks questions that aren't sensible to people who don't care. It
> also keeps the old E1000 name for "PCI chips only", which means that
> people who just use an old config and ignore new questions will suddenly
> lose their ability to use the E1000 driver if they have a PCI-E card.
We only support people keeping their old configs after they run 'make
oldconfig', right? At which point they'd be prompted for E1000_SUPPORT.
Presumably they'd think "That's odd. I'm sure I had that selected
before", then select it. Then oldconfig skips over CONFIG_E1000 because
it already knows the answer to that one and they're prompted with a
question about PCIe support. Now something is clearly strange. Perhaps
they look at the help text at this point and it says to go with 'Y' or
'M' if they're not sure.
That's the most important bit of help texts for me. Do I want Control
Groups? Will my machine break if I don't select them? I have no idea
what a 'process cgroup subsystem' is, and I don't care. But the help
text tells me I can say "n" and nothing will break.
> So most users:
> - want to just say "E1000", and not care about type.
> - want to have old configurations continue working (ie if you haev had
> "E1000" driving your hardware before, it should _continue_ to do so,
> with no need to select a _new_ E1000E question!
>
> Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
> it's almost impossible to tell. Here, quickly, tell me which one mine is
> (this is from /sbin/lspci):
>
> 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
I quite agree. I have no idea either. All I know is that my ICH9 box
didn't work until e1000e was released ;-)
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 19:01 ` Matthew Wilcox
@ 2008-04-11 19:25 ` Willy Tarreau
2008-04-11 20:21 ` Linus Torvalds
1 sibling, 0 replies; 125+ messages in thread
From: Willy Tarreau @ 2008-04-11 19:25 UTC (permalink / raw
To: Matthew Wilcox
Cc: Linus Torvalds, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Jeff Garzik, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, Apr 11, 2008 at 01:01:28PM -0600, Matthew Wilcox wrote:
> On Fri, Apr 11, 2008 at 11:51:07AM -0700, Linus Torvalds wrote:
> > Because your version has exactly the same problem that the current code
> > has: it asks questions that aren't sensible to people who don't care. It
> > also keeps the old E1000 name for "PCI chips only", which means that
> > people who just use an old config and ignore new questions will suddenly
> > lose their ability to use the E1000 driver if they have a PCI-E card.
>
> We only support people keeping their old configs after they run 'make
> oldconfig', right? At which point they'd be prompted for E1000_SUPPORT.
> Presumably they'd think "That's odd. I'm sure I had that selected
> before", then select it. Then oldconfig skips over CONFIG_E1000 because
> it already knows the answer to that one and they're prompted with a
> question about PCIe support. Now something is clearly strange. Perhaps
> they look at the help text at this point and it says to go with 'Y' or
> 'M' if they're not sure.
I don't think this will happen like that. People will simply think as
usual "ah, they have added support for new hardware, but since everything
in my machine was supported, I don't need it".
I think that the correct solution to help people is not at build time,
but at run time. The e1000 driver should just *check* if there are PCI-IDs
that it used to manage and that it does not anymore, for unclaimed devices,
and report a warning message clearly indicating that these devices are not
handled anymore and that for this, the user must load e1000e. It will :
a) help people know what to load if they need to update modprobe.conf
b) just require a new "make menuconfig;make modules" after the poor guy
has been caught.
It's not a problem to have to tweak the config and reboot several times,
provided that the user is guided. Almost none of us has ever blindly
upgraded without a few post-boot adjustments.
> That's the most important bit of help texts for me. Do I want Control
> Groups? Will my machine break if I don't select them? I have no idea
> what a 'process cgroup subsystem' is, and I don't care. But the help
> text tells me I can say "n" and nothing will break.
Here if people don't know, they will reply "no" too.
> > So most users:
> > - want to just say "E1000", and not care about type.
> > - want to have old configurations continue working (ie if you haev had
> > "E1000" driving your hardware before, it should _continue_ to do so,
> > with no need to select a _new_ E1000E question!
> >
> > Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
> > it's almost impossible to tell. Here, quickly, tell me which one mine is
> > (this is from /sbin/lspci):
> >
> > 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
>
> I quite agree. I have no idea either. All I know is that my ICH9 box
> didn't work until e1000e was released ;-)
I'm pretty sure it's PCI-E, because Linus got caught first ;-) But of
course, that should not be an accepted guess method.
Willy
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 19:25 ` Willy Tarreau
0 siblings, 0 replies; 125+ messages in thread
From: Willy Tarreau @ 2008-04-11 19:25 UTC (permalink / raw
To: Matthew Wilcox
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Jeff Garzik,
e1000-list, NetDev, Allan, Bruce W, Linux Kernel Mailing List,
David S. Miller, Christoph Hellwig, Jesse Brandeburg,
Ronciak, John, Arjan van de Ven, Greg KH, Ingo Molnar,
Linus Torvalds, linux-pci maillist
On Fri, Apr 11, 2008 at 01:01:28PM -0600, Matthew Wilcox wrote:
> On Fri, Apr 11, 2008 at 11:51:07AM -0700, Linus Torvalds wrote:
> > Because your version has exactly the same problem that the current code
> > has: it asks questions that aren't sensible to people who don't care. It
> > also keeps the old E1000 name for "PCI chips only", which means that
> > people who just use an old config and ignore new questions will suddenly
> > lose their ability to use the E1000 driver if they have a PCI-E card.
>
> We only support people keeping their old configs after they run 'make
> oldconfig', right? At which point they'd be prompted for E1000_SUPPORT.
> Presumably they'd think "That's odd. I'm sure I had that selected
> before", then select it. Then oldconfig skips over CONFIG_E1000 because
> it already knows the answer to that one and they're prompted with a
> question about PCIe support. Now something is clearly strange. Perhaps
> they look at the help text at this point and it says to go with 'Y' or
> 'M' if they're not sure.
I don't think this will happen like that. People will simply think as
usual "ah, they have added support for new hardware, but since everything
in my machine was supported, I don't need it".
I think that the correct solution to help people is not at build time,
but at run time. The e1000 driver should just *check* if there are PCI-IDs
that it used to manage and that it does not anymore, for unclaimed devices,
and report a warning message clearly indicating that these devices are not
handled anymore and that for this, the user must load e1000e. It will :
a) help people know what to load if they need to update modprobe.conf
b) just require a new "make menuconfig;make modules" after the poor guy
has been caught.
It's not a problem to have to tweak the config and reboot several times,
provided that the user is guided. Almost none of us has ever blindly
upgraded without a few post-boot adjustments.
> That's the most important bit of help texts for me. Do I want Control
> Groups? Will my machine break if I don't select them? I have no idea
> what a 'process cgroup subsystem' is, and I don't care. But the help
> text tells me I can say "n" and nothing will break.
Here if people don't know, they will reply "no" too.
> > So most users:
> > - want to just say "E1000", and not care about type.
> > - want to have old configurations continue working (ie if you haev had
> > "E1000" driving your hardware before, it should _continue_ to do so,
> > with no need to select a _new_ E1000E question!
> >
> > Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
> > it's almost impossible to tell. Here, quickly, tell me which one mine is
> > (this is from /sbin/lspci):
> >
> > 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
>
> I quite agree. I have no idea either. All I know is that my ICH9 box
> didn't work until e1000e was released ;-)
I'm pretty sure it's PCI-E, because Linus got caught first ;-) But of
course, that should not be an accepted guess method.
Willy
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [regression] e1000e broke e1000
2008-04-11 15:40 ` Chris Friesen
@ 2008-04-11 19:29 ` Willy Tarreau
0 siblings, 0 replies; 125+ messages in thread
From: Willy Tarreau @ 2008-04-11 19:29 UTC (permalink / raw
To: Chris Friesen
Cc: Ingo Molnar, Jeff Garzik, Kok, Auke, Matthew Wilcox,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Linus Torvalds, Jesse Brandeburg,
Ronciak, John, Allan, Bruce W, Greg KH, Arjan van de Ven,
Rafael J. Wysocki
On Fri, Apr 11, 2008 at 09:40:23AM -0600, Chris Friesen wrote:
> Ingo Molnar wrote:
>
> >well, your 2.6.26 plans, if i understand them correctly, is to move
> >currently working PCI IDs from e1000 to e1000e, like you attempted to d
> >it in v2.6.24, which Linus reverted - correct? I.e. e1000 simply wont
> >support eth0 on my T60 from 2.6.26 on? That is still an incredibly
> >stupid plan, and no amount of announcement on lkml will make it any less
> >stupid.
>
> It seems like you're saying that once hardware is supported by a
> particular config option, it can never ever be split out to another
> config option, even if it makes both drivers cleaner.
>
> A similar situation happened when the sk98lin driver was split into skge
> and sky2...I don't remember a big fuss back then. Is it just that no
> major developers were using the hardware so they didn't notice?
The difference is that :
1) either could be used for a long time
2) the old worked so bad that the word has spread among people in forums
to try the new driver instead.
I think that splitting drivers should be something accepted in the kernel's
lifetime, but users must not be left confused. It's clearly easier to insert
ourselves in their common process to wave hands indicating that their setup
will soon not work anymore (eg: by having e1000 indicate what driver must be
loaded for unsupported devices).
Willy
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 19:25 ` Willy Tarreau
(?)
@ 2008-04-11 19:38 ` Matthew Wilcox
-1 siblings, 0 replies; 125+ messages in thread
From: Matthew Wilcox @ 2008-04-11 19:38 UTC (permalink / raw
To: Willy Tarreau
Cc: Linus Torvalds, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Jeff Garzik, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, Apr 11, 2008 at 09:25:19PM +0200, Willy Tarreau wrote:
> Here if people don't know, they will reply "no" too.
I learned not to do that ... back in 2.3, iirc, when the console
became selectable ;-)
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 19:01 ` Matthew Wilcox
@ 2008-04-11 20:21 ` Linus Torvalds
2008-04-11 20:21 ` Linus Torvalds
1 sibling, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 20:21 UTC (permalink / raw
To: Matthew Wilcox
Cc: Christoph Hellwig, Kok, Auke, Ingo Molnar, Jeff Garzik,
Linux Kernel Mailing List, NetDev, e1000-list, linux-pci maillist,
Andrew Morton, David S. Miller, Jesse Brandeburg, Ronciak, John,
Allan, Bruce W, Greg KH, Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Matthew Wilcox wrote:
>
> We only support people keeping their old configs after they run 'make
> oldconfig', right? At which point they'd be prompted for E1000_SUPPORT.
> Presumably they'd think "That's odd.
Ok, I'm not even interested in discussing this.
Have you followed the discussion at all? Did you even notice _why_ we're
discussing it?
Here's a damn big hint: teh thing you say "Presumably they'd think" is
exactly what we're talking about, AND HELL NO THEY DIDN'T!
That goes for both me and Ingo.
So stop blathering. The _fact_ is that two kernel developers were really
upset about the fact that their machines stopped working with old
configurations. Stop the inane ".. but that would never happen", because
the whole discussion is because IT DID HAPPEN!
Linus
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 20:21 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 20:21 UTC (permalink / raw
To: Matthew Wilcox
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Jeff Garzik,
e1000-list, NetDev, Allan, Bruce W, Linux Kernel Mailing List,
David S. Miller, Christoph Hellwig, Jesse Brandeburg,
Ronciak, John, Greg KH, Ingo Molnar, Arjan van de Ven,
linux-pci maillist
On Fri, 11 Apr 2008, Matthew Wilcox wrote:
>
> We only support people keeping their old configs after they run 'make
> oldconfig', right? At which point they'd be prompted for E1000_SUPPORT.
> Presumably they'd think "That's odd.
Ok, I'm not even interested in discussing this.
Have you followed the discussion at all? Did you even notice _why_ we're
discussing it?
Here's a damn big hint: teh thing you say "Presumably they'd think" is
exactly what we're talking about, AND HELL NO THEY DIDN'T!
That goes for both me and Ingo.
So stop blathering. The _fact_ is that two kernel developers were really
upset about the fact that their machines stopped working with old
configurations. Stop the inane ".. but that would never happen", because
the whole discussion is because IT DID HAPPEN!
Linus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 18:51 ` Linus Torvalds
(?)
(?)
@ 2008-04-11 20:22 ` Krzysztof Halasa
2008-04-11 20:29 ` Linus Torvalds
-1 siblings, 1 reply; 125+ messages in thread
From: Krzysztof Halasa @ 2008-04-11 20:22 UTC (permalink / raw
To: Linus Torvalds
Cc: Matthew Wilcox, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Jeff Garzik, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
> it's almost impossible to tell. Here, quickly, tell me which one mine is
> (this is from /sbin/lspci):
>
> 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
>
> and tell me how you knew..
I guess PCIE. You already came across a similar problem.
Have I won something? :-)
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 20:22 ` Krzysztof Halasa
@ 2008-04-11 20:29 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 20:29 UTC (permalink / raw
To: Krzysztof Halasa
Cc: Matthew Wilcox, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Jeff Garzik, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Krzysztof Halasa wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
> > it's almost impossible to tell. Here, quickly, tell me which one mine is
> > (this is from /sbin/lspci):
> >
> > 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
> >
> > and tell me how you knew..
>
> I guess PCIE. You already came across a similar problem.
>
> Have I won something? :-)
Nope. You apparently guessed just because I had told earlier about how the
E1000 changes screwed over my setup.
The fact is, people don't know. And they shouldn't care. If the E1000
driver worked before, we simply shouldn't break that from a configuration
standpoint.
Linus
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 20:29 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 20:29 UTC (permalink / raw
To: Krzysztof Halasa
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Jeff Garzik,
Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Christoph Hellwig,
Jesse Brandeburg, Ronciak, John, Greg KH, Ingo Molnar,
Arjan van de Ven, linux-pci maillist
On Fri, 11 Apr 2008, Krzysztof Halasa wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
> > it's almost impossible to tell. Here, quickly, tell me which one mine is
> > (this is from /sbin/lspci):
> >
> > 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
> >
> > and tell me how you knew..
>
> I guess PCIE. You already came across a similar problem.
>
> Have I won something? :-)
Nope. You apparently guessed just because I had told earlier about how the
E1000 changes screwed over my setup.
The fact is, people don't know. And they shouldn't care. If the E1000
driver worked before, we simply shouldn't break that from a configuration
standpoint.
Linus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 18:51 ` Linus Torvalds
@ 2008-04-11 21:01 ` Dan Noe
-1 siblings, 0 replies; 125+ messages in thread
From: Dan Noe @ 2008-04-11 21:01 UTC (permalink / raw
To: Linus Torvalds
Cc: Matthew Wilcox, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Jeff Garzik, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On 4/11/2008 14:51, Linus Torvalds wrote:
> Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
> it's almost impossible to tell. Here, quickly, tell me which one mine is
> (this is from /sbin/lspci):
>
> 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
>
> and tell me how you knew..
lspci -vv will tell you (if you're root :)!
Yet, the only part of that output that makes it even somewhat obvious is
the "Link: Speed 2.5Gb/s, Width x1" which clearly makes no sense for
legacy PCI.
Cheers,
Dan
--
/--------------- - - - - - -
| Dan Noe
| http://isomerica.net/~dpn/
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 21:01 ` Dan Noe
0 siblings, 0 replies; 125+ messages in thread
From: Dan Noe @ 2008-04-11 21:01 UTC (permalink / raw
To: Linus Torvalds
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Jeff Garzik,
Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Christoph Hellwig,
Jesse Brandeburg, Ronciak, John, Greg KH, Ingo Molnar,
Arjan van de Ven, linux-pci maillist
On 4/11/2008 14:51, Linus Torvalds wrote:
> Nobody wants to care deeply whether it's a PCI-E or PCI chip. In fact,
> it's almost impossible to tell. Here, quickly, tell me which one mine is
> (this is from /sbin/lspci):
>
> 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
>
> and tell me how you knew..
lspci -vv will tell you (if you're root :)!
Yet, the only part of that output that makes it even somewhat obvious is
the "Link: Speed 2.5Gb/s, Width x1" which clearly makes no sense for
legacy PCI.
Cheers,
Dan
--
/--------------- - - - - - -
| Dan Noe
| http://isomerica.net/~dpn/
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 17:34 ` Linus Torvalds
2008-04-11 17:53 ` Matthew Wilcox
@ 2008-04-11 22:06 ` Daniel Barkalow
2008-04-11 22:21 ` Jeff Garzik
2008-04-11 23:00 ` Linus Torvalds
1 sibling, 2 replies; 125+ messages in thread
From: Daniel Barkalow @ 2008-04-11 22:06 UTC (permalink / raw
To: Linus Torvalds
Cc: Christoph Hellwig, Kok, Auke, Ingo Molnar, Jeff Garzik,
Matthew Wilcox, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Linus Torvalds wrote:
> On Fri, 11 Apr 2008, Christoph Hellwig wrote:
> >
> > As a start we could do two driver keyed off a single Kconfig variable.
> > And then find a way to get users informed that they might need to
> > enabled the other one
>
> I think that's a great solution.
>
> Here's a suggested patch. Not much tested, but it's fairly obvious.
>
> It basically makes one top-level config option (E1000) to pick the driver
> at all, and two sub-options (E1000_PCI and E1000_PCIE) that you can choose
> between.
>
> If you pick E1000 support, you're given the choice between "PCI only",
> "PCI-E only" or "support both", and that will then pick the right
> combination of support for E1000_PCI and E1000_PCIE.
Wouldn't it make more sense to turn E1000 into a option that does nothing
except select both E1000E and E1000_PCI, and have those two be the options
that build drivers? Then, after a while, we drop the E1000 option
entirely, and people are fine as long as they used any of the kernels in
between (since the system will have forgotten that E1000E was only set by
an option that has disappeared).
Right now, E1000 means "support both PCI and PCI-E E1000" and E1000E means
"support PCI-E E1000". I don't see any reason not to add a "support PCI
E1000" option and keep the semantics of existing options the same and just
change the implementation.
AFAICT, this makes "make oldconfig" always give the same support that the
the earlier kernel had and people get set it to what they actually want if
they notice.
I.e., something like this (plus removing the ID-stealing in e1000):
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f337800..9078bde 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1955,6 +1955,11 @@ config DL2K
config E1000
tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
+ select E1000_PCI
+ select E1000E
+
+config E1000_PCI
+ tristate "Intel(R) PRO/1000 PCI Gigabit Ethernet support"
depends on PCI
---help---
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
@@ -1976,7 +1981,7 @@ config E1000
config E1000_NAPI
bool "Use Rx Polling (NAPI)"
- depends on E1000
+ depends on E1000_PCI
help
NAPI is a new driver API designed to reduce CPU and interrupt load
when the driver is receiving lots of packets from the card. It is
@@ -1990,7 +1995,7 @@ config E1000_NAPI
config E1000_DISABLE_PACKET_SPLIT
bool "Disable Packet Split for PCI express adapters"
- depends on E1000
+ depends on E1000_PCI
help
Say Y here if you want to use the legacy receive path for PCI express
hardware.
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 3b1ea32..8026e63 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -2,7 +2,7 @@
# Makefile for the Linux network (ethercard) device drivers.
#
-obj-$(CONFIG_E1000) += e1000/
+obj-$(CONFIG_E1000_PCI) += e1000/
obj-$(CONFIG_E1000E) += e1000e/
obj-$(CONFIG_IBM_EMAC) += ibm_emac/
obj-$(CONFIG_IBM_NEW_EMAC) += ibm_newemac/
^ permalink raw reply related [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 22:06 ` Daniel Barkalow
@ 2008-04-11 22:21 ` Jeff Garzik
2008-04-11 23:05 ` Daniel Barkalow
2008-04-11 23:00 ` Linus Torvalds
1 sibling, 1 reply; 125+ messages in thread
From: Jeff Garzik @ 2008-04-11 22:21 UTC (permalink / raw
To: Daniel Barkalow
Cc: Linus Torvalds, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Matthew Wilcox, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
Daniel Barkalow wrote:
> Right now, E1000 means "support both PCI and PCI-E E1000" and E1000E means
> "support PCI-E E1000".
It's even more confusing than that :)
E1000 means "support PCI and a few PCI-E"
E1000E means "all PCI-E"
There is a goodly number of PCI-E not supported by e1000 (some ich8, all
ich9 and thereafter).
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 22:06 ` Daniel Barkalow
@ 2008-04-11 23:00 ` Linus Torvalds
2008-04-11 23:00 ` Linus Torvalds
1 sibling, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 23:00 UTC (permalink / raw
To: Daniel Barkalow
Cc: Christoph Hellwig, Kok, Auke, Ingo Molnar, Jeff Garzik,
Matthew Wilcox, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Daniel Barkalow wrote:
>
> Wouldn't it make more sense to turn E1000 into a option that does nothing
> except select both E1000E and E1000_PCI, and have those two be the options
> that build drivers?
Yes, that sounds fine too. Although you need to add a
depends on PCI
to the E1000 thing (because the "select" would not honor the dependencies
that E1000E and E1000_PCI have).
However:
> Then, after a while, we drop the E1000 option entirely
I agree we could, but as I tried to explain, I fundamentally don't think
we _should_.
Why should people _ever_ be asked about whether they want "E1000 PCI
support" vs "E1000 PCI-E" support, when it's almost impossible to tell
which kind of card you have?
In other words, I suspect that anybody who selects E1000 support would
actually want the "support both" case, and simply not care. Unless they
were _really_ deeply aware of their hardware.
> AFAICT, this makes "make oldconfig" always give the same support that the
> the earlier kernel had and people get set it to what they actually want if
> they notice.
.. but that said, I think your patch is certainly better than what we have
now (or what Ingo was complaining about for the next merge window). I
certainly could live with it. I would just suggest against ever then
removing that "generic E1000" choice.
Linus
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 23:00 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-11 23:00 UTC (permalink / raw
To: Daniel Barkalow
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Jeff Garzik,
Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Christoph Hellwig,
Jesse Brandeburg, Ronciak, John, Greg KH, Ingo Molnar,
Arjan van de Ven, linux-pci maillist
On Fri, 11 Apr 2008, Daniel Barkalow wrote:
>
> Wouldn't it make more sense to turn E1000 into a option that does nothing
> except select both E1000E and E1000_PCI, and have those two be the options
> that build drivers?
Yes, that sounds fine too. Although you need to add a
depends on PCI
to the E1000 thing (because the "select" would not honor the dependencies
that E1000E and E1000_PCI have).
However:
> Then, after a while, we drop the E1000 option entirely
I agree we could, but as I tried to explain, I fundamentally don't think
we _should_.
Why should people _ever_ be asked about whether they want "E1000 PCI
support" vs "E1000 PCI-E" support, when it's almost impossible to tell
which kind of card you have?
In other words, I suspect that anybody who selects E1000 support would
actually want the "support both" case, and simply not care. Unless they
were _really_ deeply aware of their hardware.
> AFAICT, this makes "make oldconfig" always give the same support that the
> the earlier kernel had and people get set it to what they actually want if
> they notice.
.. but that said, I think your patch is certainly better than what we have
now (or what Ingo was complaining about for the next merge window). I
certainly could live with it. I would just suggest against ever then
removing that "generic E1000" choice.
Linus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 22:21 ` Jeff Garzik
@ 2008-04-11 23:05 ` Daniel Barkalow
0 siblings, 0 replies; 125+ messages in thread
From: Daniel Barkalow @ 2008-04-11 23:05 UTC (permalink / raw
To: Jeff Garzik
Cc: Linus Torvalds, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Matthew Wilcox, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Jeff Garzik wrote:
> Daniel Barkalow wrote:
> > Right now, E1000 means "support both PCI and PCI-E E1000" and E1000E means
> > "support PCI-E E1000".
>
> It's even more confusing than that :)
>
> E1000 means "support PCI and a few PCI-E"
>
> E1000E means "all PCI-E"
>
> There is a goodly number of PCI-E not supported by e1000 (some ich8, all ich9
> and thereafter).
Okay, so with my change E1000 will incidentally give you ich9 support. But
it doesn't fail to "support PCI and a few PCI-E", it just does some more
that it has to give you for coverage of the traditional things.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 23:00 ` Linus Torvalds
@ 2008-04-11 23:15 ` Daniel Barkalow
-1 siblings, 0 replies; 125+ messages in thread
From: Daniel Barkalow @ 2008-04-11 23:15 UTC (permalink / raw
To: Linus Torvalds
Cc: Christoph Hellwig, Kok, Auke, Ingo Molnar, Jeff Garzik,
Matthew Wilcox, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Linus Torvalds wrote:
>
>
> On Fri, 11 Apr 2008, Daniel Barkalow wrote:
> >
> > Wouldn't it make more sense to turn E1000 into a option that does nothing
> > except select both E1000E and E1000_PCI, and have those two be the options
> > that build drivers?
>
> Yes, that sounds fine too. Although you need to add a
>
> depends on PCI
>
> to the E1000 thing (because the "select" would not honor the dependencies
> that E1000E and E1000_PCI have).
Oh, right.
> However:
>
> > Then, after a while, we drop the E1000 option entirely
>
> I agree we could, but as I tried to explain, I fundamentally don't think
> we _should_.
>
> Why should people _ever_ be asked about whether they want "E1000 PCI
> support" vs "E1000 PCI-E" support, when it's almost impossible to tell
> which kind of card you have?
>
> In other words, I suspect that anybody who selects E1000 support would
> actually want the "support both" case, and simply not care. Unless they
> were _really_ deeply aware of their hardware.
Eh, they'll both default to Y on PCs individually, so it's only people who
are turning unused stuff off who will even look, and they'll probably ask
/sys/class/net/eth0/device/driver or lsmod.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 23:15 ` Daniel Barkalow
0 siblings, 0 replies; 125+ messages in thread
From: Daniel Barkalow @ 2008-04-11 23:15 UTC (permalink / raw
To: Linus Torvalds
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Jeff Garzik,
Matthew Wilcox, e1000-list, NetDev, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Christoph Hellwig,
Jesse Brandeburg, Ronciak, John, Greg KH, Ingo Molnar,
Arjan van de Ven, linux-pci maillist
On Fri, 11 Apr 2008, Linus Torvalds wrote:
>
>
> On Fri, 11 Apr 2008, Daniel Barkalow wrote:
> >
> > Wouldn't it make more sense to turn E1000 into a option that does nothing
> > except select both E1000E and E1000_PCI, and have those two be the options
> > that build drivers?
>
> Yes, that sounds fine too. Although you need to add a
>
> depends on PCI
>
> to the E1000 thing (because the "select" would not honor the dependencies
> that E1000E and E1000_PCI have).
Oh, right.
> However:
>
> > Then, after a while, we drop the E1000 option entirely
>
> I agree we could, but as I tried to explain, I fundamentally don't think
> we _should_.
>
> Why should people _ever_ be asked about whether they want "E1000 PCI
> support" vs "E1000 PCI-E" support, when it's almost impossible to tell
> which kind of card you have?
>
> In other words, I suspect that anybody who selects E1000 support would
> actually want the "support both" case, and simply not care. Unless they
> were _really_ deeply aware of their hardware.
Eh, they'll both default to Y on PCs individually, so it's only people who
are turning unused stuff off who will even look, and they'll probably ask
/sys/class/net/eth0/device/driver or lsmod.
-Daniel
*This .sig left intentionally blank*
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 23:00 ` Linus Torvalds
@ 2008-04-11 23:43 ` Jeff Garzik
-1 siblings, 0 replies; 125+ messages in thread
From: Jeff Garzik @ 2008-04-11 23:43 UTC (permalink / raw
To: Linus Torvalds
Cc: Daniel Barkalow, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Matthew Wilcox, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
Linus Torvalds wrote:
> .. but that said, I think your patch is certainly better than what we have
> now (or what Ingo was complaining about for the next merge window). I
> certainly could live with it. I would just suggest against ever then
> removing that "generic E1000" choice.
You mean never ever remove PCI-E support from e1000?
Won't that will inflict long term headaches on the people that matter
most -- users and maintainers -- to avoid short term headaches for
kernel power users?
To review the overall situation,
* e1000 supports so many chips, that making a change for new hardware in
e1000 involves breaking stability of older chips
* //You know this// from past kernel history, when late-breaking e1000
changes for new hardware wound up breaking working setups on multiple
occasions
* There is 100% agreement that e1000 is a maintenance nightmare, from
the people who actually touch the code (or even read it).
* Therefore, e1000e receives new h/w support and new devel, leaving
e1000 to sit and be stable
However, due to a mistake now released to the public -- a tiny few PCI-E
chips are supported by e1000 -- you have a widely disparate feature set:
e1000, old chips: full support
e1000, a few PCI-E chips: basic support
e1000e, all PCI-E chips: full support
Since e1000e is all new and fancy AND CLEAN, the code for the same chips
is different -- thus Intel must make every PCI-E fix _twice_.
It also means WE HAVE TO KEEP TOUCHING E1000, while supporting PCI-E
chips. After this PCI-E issue is resolved, I want to let e1000 sit and
be stable and not be touched.
For a temporary situation, this is fine. Give me transition
suggestions, please!
For a permanent situation, that sucks.
Distros will ship e1000 sans PCI-E support, which means you are asking
that PCI-E support be maintained indefinitely, purely for the few kernel
hackers that still use it?
I __don't care__ how we get there, but a permanent situation where e1000
continues to support a few PCI-E chips in basic mode seems the least
desireable of all available options.
Wait six months? Sure. Whatever. As long as we get to where we can
disable PCI-E support in e1000.
Jeff
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-11 23:43 ` Jeff Garzik
0 siblings, 0 replies; 125+ messages in thread
From: Jeff Garzik @ 2008-04-11 23:43 UTC (permalink / raw
To: Linus Torvalds
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Matthew Wilcox,
e1000-list, NetDev, Daniel Barkalow, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Christoph Hellwig,
Jesse Brandeburg, Ronciak, John, Greg KH, Ingo Molnar,
Arjan van de Ven, linux-pci maillist
Linus Torvalds wrote:
> .. but that said, I think your patch is certainly better than what we have
> now (or what Ingo was complaining about for the next merge window). I
> certainly could live with it. I would just suggest against ever then
> removing that "generic E1000" choice.
You mean never ever remove PCI-E support from e1000?
Won't that will inflict long term headaches on the people that matter
most -- users and maintainers -- to avoid short term headaches for
kernel power users?
To review the overall situation,
* e1000 supports so many chips, that making a change for new hardware in
e1000 involves breaking stability of older chips
* //You know this// from past kernel history, when late-breaking e1000
changes for new hardware wound up breaking working setups on multiple
occasions
* There is 100% agreement that e1000 is a maintenance nightmare, from
the people who actually touch the code (or even read it).
* Therefore, e1000e receives new h/w support and new devel, leaving
e1000 to sit and be stable
However, due to a mistake now released to the public -- a tiny few PCI-E
chips are supported by e1000 -- you have a widely disparate feature set:
e1000, old chips: full support
e1000, a few PCI-E chips: basic support
e1000e, all PCI-E chips: full support
Since e1000e is all new and fancy AND CLEAN, the code for the same chips
is different -- thus Intel must make every PCI-E fix _twice_.
It also means WE HAVE TO KEEP TOUCHING E1000, while supporting PCI-E
chips. After this PCI-E issue is resolved, I want to let e1000 sit and
be stable and not be touched.
For a temporary situation, this is fine. Give me transition
suggestions, please!
For a permanent situation, that sucks.
Distros will ship e1000 sans PCI-E support, which means you are asking
that PCI-E support be maintained indefinitely, purely for the few kernel
hackers that still use it?
I __don't care__ how we get there, but a permanent situation where e1000
continues to support a few PCI-E chips in basic mode seems the least
desireable of all available options.
Wait six months? Sure. Whatever. As long as we get to where we can
disable PCI-E support in e1000.
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 23:43 ` Jeff Garzik
(?)
@ 2008-04-11 23:58 ` david
-1 siblings, 0 replies; 125+ messages in thread
From: david @ 2008-04-11 23:58 UTC (permalink / raw
To: Jeff Garzik
Cc: Linus Torvalds, Daniel Barkalow, Christoph Hellwig, Kok, Auke,
Ingo Molnar, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Jeff Garzik wrote:
> Linus Torvalds wrote:
>> .. but that said, I think your patch is certainly better than what we have
>> now (or what Ingo was complaining about for the next merge window). I
>> certainly could live with it. I would just suggest against ever then
>> removing that "generic E1000" choice.
>
>
> You mean never ever remove PCI-E support from e1000?
>
> Won't that will inflict long term headaches on the people that matter most --
> users and maintainers -- to avoid short term headaches for kernel power
> users?
no, it sounds like he's saying make the E1000 option select both E1000_PCI
and E1000_PCIE (which could be selected seperately) and never remove the
E1000 option.
after people trust the E1000e driver the PCI ids can be removed from
E1000, but people who only select E1000 will continue to work becouse the
build system will now build both the PCI and PCI-e drivers when E1000 is
selected.
David Lang
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 23:43 ` Jeff Garzik
(?)
(?)
@ 2008-04-12 13:07 ` Christoph Hellwig
-1 siblings, 0 replies; 125+ messages in thread
From: Christoph Hellwig @ 2008-04-12 13:07 UTC (permalink / raw
To: Jeff Garzik
Cc: Linus Torvalds, Daniel Barkalow, Christoph Hellwig, Kok, Auke,
Ingo Molnar, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, Apr 11, 2008 at 07:43:49PM -0400, Jeff Garzik wrote:
> However, due to a mistake now released to the public -- a tiny few PCI-E
> chips are supported by e1000 -- you have a widely disparate feature set:
>
> e1000, old chips: full support
>
> e1000, a few PCI-E chips: basic support
>
> e1000e, all PCI-E chips: full support
>
> Since e1000e is all new and fancy AND CLEAN, the code for the same chips is
> different -- thus Intel must make every PCI-E fix _twice_.
>
> It also means WE HAVE TO KEEP TOUCHING E1000, while supporting PCI-E chips.
> After this PCI-E issue is resolved, I want to let e1000 sit and be stable
> and not be touched.
>
> For a temporary situation, this is fine. Give me transition suggestions,
> please!
PCI-E support should be removed from the e1000 driver ASAP, that is .26.
What we need is a way to have CONFIG_E1000 pull in the e1000e driver
automatically to not confuse kernel developers that don't know what
hardware they actually have..
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-11 23:43 ` Jeff Garzik
@ 2008-04-13 21:13 ` Linus Torvalds
-1 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-13 21:13 UTC (permalink / raw
To: Jeff Garzik
Cc: Daniel Barkalow, Christoph Hellwig, Kok, Auke, Ingo Molnar,
Matthew Wilcox, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Fri, 11 Apr 2008, Jeff Garzik wrote:
> Linus Torvalds wrote:
> > .. but that said, I think your patch is certainly better than what we have
> > now (or what Ingo was complaining about for the next merge window). I
> > certainly could live with it. I would just suggest against ever then
> > removing that "generic E1000" choice.
>
> You mean never ever remove PCI-E support from e1000?
No. I mean never ever remove the *configure* level thinking that "e1000 is
e1000".
There is no sense in *ever* showing it as two drivers to users, because
users do not see them as separate chipsets. They look identical, down to
the part names.
If it's a single family, and users can't even easily tell whether they
have version 1 or version 2 (PCI vs PCI-E), you shouldn't even ask them.
You should literally ask them: "do you want e1000 support".
That's it.
Once you have asked them that, you can then decide "ok, if you *really*
know what version of the chip you have, you can decide to only get limited
driver support".
But that's a secondary thing from a user perspective.
See the patch I already sent out.
Linus
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-04-13 21:13 ` Linus Torvalds
0 siblings, 0 replies; 125+ messages in thread
From: Linus Torvalds @ 2008-04-13 21:13 UTC (permalink / raw
To: Jeff Garzik
Cc: Rafael J. Wysocki, Kok, Auke, Andrew Morton, Matthew Wilcox,
e1000-list, NetDev, Daniel Barkalow, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Christoph Hellwig,
Jesse Brandeburg, Ronciak, John, Greg KH, Ingo Molnar,
Arjan van de Ven, linux-pci maillist
On Fri, 11 Apr 2008, Jeff Garzik wrote:
> Linus Torvalds wrote:
> > .. but that said, I think your patch is certainly better than what we have
> > now (or what Ingo was complaining about for the next merge window). I
> > certainly could live with it. I would just suggest against ever then
> > removing that "generic E1000" choice.
>
> You mean never ever remove PCI-E support from e1000?
No. I mean never ever remove the *configure* level thinking that "e1000 is
e1000".
There is no sense in *ever* showing it as two drivers to users, because
users do not see them as separate chipsets. They look identical, down to
the part names.
If it's a single family, and users can't even easily tell whether they
have version 1 or version 2 (PCI vs PCI-E), you shouldn't even ask them.
You should literally ask them: "do you want e1000 support".
That's it.
Once you have asked them that, you can then decide "ok, if you *really*
know what version of the chip you have, you can decide to only get limited
driver support".
But that's a secondary thing from a user perspective.
See the patch I already sent out.
Linus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-13 21:13 ` Linus Torvalds
(?)
@ 2008-04-13 21:34 ` Ondrej Zary
-1 siblings, 0 replies; 125+ messages in thread
From: Ondrej Zary @ 2008-04-13 21:34 UTC (permalink / raw
To: Linus Torvalds
Cc: Jeff Garzik, Daniel Barkalow, Christoph Hellwig, Kok, Auke,
Ingo Molnar, Matthew Wilcox, Linux Kernel Mailing List, NetDev,
e1000-list, linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
On Sunday 13 April 2008 23:13:01 Linus Torvalds wrote:
> On Fri, 11 Apr 2008, Jeff Garzik wrote:
> > Linus Torvalds wrote:
> > > .. but that said, I think your patch is certainly better than what we
> > > have now (or what Ingo was complaining about for the next merge
> > > window). I certainly could live with it. I would just suggest against
> > > ever then removing that "generic E1000" choice.
> >
> > You mean never ever remove PCI-E support from e1000?
>
> No. I mean never ever remove the *configure* level thinking that "e1000 is
> e1000".
>
> There is no sense in *ever* showing it as two drivers to users, because
> users do not see them as separate chipsets. They look identical, down to
> the part names.
>
> If it's a single family, and users can't even easily tell whether they
> have version 1 or version 2 (PCI vs PCI-E), you shouldn't even ask them.
> You should literally ask them: "do you want e1000 support".
It's something like RTL8139. There are two versions of the chips. They even
have the same PCI IDs. But there are two different drivers - 8139cp and
8139too. It's really bad for users
>
> That's it.
>
> Once you have asked them that, you can then decide "ok, if you *really*
> know what version of the chip you have, you can decide to only get limited
> driver support".
>
> But that's a secondary thing from a user perspective.
>
> See the patch I already sent out.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ondrej Zary
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
2008-04-13 21:13 ` Linus Torvalds
@ 2008-06-09 19:24 ` Ingo Molnar
-1 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-06-09 19:24 UTC (permalink / raw
To: Linus Torvalds
Cc: Jeff Garzik, Daniel Barkalow, Christoph Hellwig, Kok, Auke,
Matthew Wilcox, Linux Kernel Mailing List, NetDev, e1000-list,
linux-pci maillist, Andrew Morton, David S. Miller,
Jesse Brandeburg, Ronciak, John, Allan, Bruce W, Greg KH,
Arjan van de Ven, Rafael J. Wysocki
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 11 Apr 2008, Jeff Garzik wrote:
> > Linus Torvalds wrote:
> > > .. but that said, I think your patch is certainly better than what we have
> > > now (or what Ingo was complaining about for the next merge window). I
> > > certainly could live with it. I would just suggest against ever then
> > > removing that "generic E1000" choice.
> >
> > You mean never ever remove PCI-E support from e1000?
>
> No. I mean never ever remove the *configure* level thinking that
> "e1000 is e1000".
>
> There is no sense in *ever* showing it as two drivers to users,
> because users do not see them as separate chipsets. They look
> identical, down to the part names.
>
> If it's a single family, and users can't even easily tell whether they
> have version 1 or version 2 (PCI vs PCI-E), you shouldn't even ask
> them. You should literally ask them: "do you want e1000 support".
>
> That's it.
>
> Once you have asked them that, you can then decide "ok, if you
> *really* know what version of the chip you have, you can decide to
> only get limited driver support".
>
> But that's a secondary thing from a user perspective.
>
> See the patch I already sent out.
btw., in the last 2-3 months i've hit this bug about a dozen times, on
various test-systems i have. And i just hit it a minute ago again,
reminding me of this open issue, with such a config:
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
CONFIG_E1000_DISABLE_PACKET_SPLIT=y
CONFIG_E1000E=y
CONFIG_E1000E_ENABLED=y
Every time this bug hits i lose about 30 minutes of testing (sometimes
hours of it, because my testing stalls) and once it took half an hour of
head-scratching to notice that the bl**dy CONFIG_E1000E_ENABLED=y again
was killing the e1000 driver i rely on having.
With up to 10 test-systems and a healthy mix of old and new distros it's
just not realistic to reconfigure all those distros to use e1000e.
(Also, i frequently have to bisect back into older kernels and have
scripting to make this work most of the time - if i standardized on
e1000e i'd lose the ability to do automated bisection.)
i have a patch that undoes this e1000 damage but sometimes i forget to
apply it and then the bug can hit me. Whoever thinks that this isnt a
problem in practice hasnt been doing a lot of systematic testing. It's
quite a PITA and it's still not fixed upstream. (and it's not eligible
for the v2.6.26 regression list anymore as it got introduced in v2.6.25)
Ingo
^ permalink raw reply [flat|nested] 125+ messages in thread
* Re: [patch] e1000=y && e1000e=m regression fix
@ 2008-06-09 19:24 ` Ingo Molnar
0 siblings, 0 replies; 125+ messages in thread
From: Ingo Molnar @ 2008-06-09 19:24 UTC (permalink / raw
To: Linus Torvalds
Cc: Rafael J. Wysocki, Kok, Auke, Jeff Garzik, Matthew Wilcox,
e1000-list, NetDev, Daniel Barkalow, Allan, Bruce W,
Linux Kernel Mailing List, David S. Miller, Christoph Hellwig,
Jesse Brandeburg, Ronciak, John, Greg KH, linux-pci maillist,
Arjan van de Ven, Andrew Morton
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 11 Apr 2008, Jeff Garzik wrote:
> > Linus Torvalds wrote:
> > > .. but that said, I think your patch is certainly better than what we have
> > > now (or what Ingo was complaining about for the next merge window). I
> > > certainly could live with it. I would just suggest against ever then
> > > removing that "generic E1000" choice.
> >
> > You mean never ever remove PCI-E support from e1000?
>
> No. I mean never ever remove the *configure* level thinking that
> "e1000 is e1000".
>
> There is no sense in *ever* showing it as two drivers to users,
> because users do not see them as separate chipsets. They look
> identical, down to the part names.
>
> If it's a single family, and users can't even easily tell whether they
> have version 1 or version 2 (PCI vs PCI-E), you shouldn't even ask
> them. You should literally ask them: "do you want e1000 support".
>
> That's it.
>
> Once you have asked them that, you can then decide "ok, if you
> *really* know what version of the chip you have, you can decide to
> only get limited driver support".
>
> But that's a secondary thing from a user perspective.
>
> See the patch I already sent out.
btw., in the last 2-3 months i've hit this bug about a dozen times, on
various test-systems i have. And i just hit it a minute ago again,
reminding me of this open issue, with such a config:
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
CONFIG_E1000_DISABLE_PACKET_SPLIT=y
CONFIG_E1000E=y
CONFIG_E1000E_ENABLED=y
Every time this bug hits i lose about 30 minutes of testing (sometimes
hours of it, because my testing stalls) and once it took half an hour of
head-scratching to notice that the bl**dy CONFIG_E1000E_ENABLED=y again
was killing the e1000 driver i rely on having.
With up to 10 test-systems and a healthy mix of old and new distros it's
just not realistic to reconfigure all those distros to use e1000e.
(Also, i frequently have to bisect back into older kernels and have
scripting to make this work most of the time - if i standardized on
e1000e i'd lose the ability to do automated bisection.)
i have a patch that undoes this e1000 damage but sometimes i forget to
apply it and then the bug can hit me. Whoever thinks that this isnt a
problem in practice hasnt been doing a lot of systematic testing. It's
quite a PITA and it's still not fixed upstream. (and it's not eligible
for the v2.6.26 regression list anymore as it got introduced in v2.6.25)
Ingo
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
^ permalink raw reply [flat|nested] 125+ messages in thread
end of thread, other threads:[~2008-06-09 19:25 UTC | newest]
Thread overview: 125+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-04 21:11 [ANNOUNCE] e1000 to e1000e migration of PCI Express devices Kok, Auke
2008-04-04 21:11 ` Kok, Auke
2008-04-04 21:31 ` Dave Hansen
2008-04-04 21:49 ` [E1000-devel] " Kok, Auke
2008-04-04 21:52 ` Jeff Garzik
2008-04-04 21:52 ` Jeff Garzik
2008-04-08 8:36 ` Ingo Molnar
2008-04-08 14:21 ` Jeff Garzik
2008-04-08 15:08 ` Jeff Garzik
2008-04-08 14:56 ` Andi Kleen
2008-04-08 14:56 ` Andi Kleen
2008-04-08 16:18 ` Kok, Auke
2008-04-08 18:15 ` Ingo Molnar
2008-04-08 18:15 ` Ingo Molnar
2008-04-08 18:39 ` [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 to e1000e migration of PCI Express devices) Ingo Molnar
2008-04-08 18:39 ` Ingo Molnar
2008-04-08 19:32 ` Matthew Wilcox
2008-04-08 19:51 ` Ingo Molnar
2008-04-08 19:51 ` Ingo Molnar
2008-04-08 19:56 ` [regression] e1000e broke e1000 Jeff Garzik
2008-04-08 20:06 ` Ingo Molnar
2008-04-08 20:06 ` Ingo Molnar
2008-04-08 20:19 ` Jeff Garzik
2008-04-08 20:19 ` Jeff Garzik
2008-04-08 20:33 ` Ingo Molnar
2008-04-08 20:33 ` Ingo Molnar
2008-04-08 20:47 ` [E1000-devel] " Kok, Auke
2008-04-08 20:56 ` Jeff Garzik
2008-04-09 19:38 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Ingo Molnar
2008-04-09 19:50 ` [patch] e1000=y && e1000e=m regression fix Jeff Garzik
2008-04-09 20:04 ` Ingo Molnar
2008-04-09 20:04 ` Ingo Molnar
2008-04-09 20:12 ` Kok, Auke
2008-04-09 20:53 ` Ingo Molnar
2008-04-09 20:53 ` Ingo Molnar
2008-04-10 18:29 ` Kok, Auke
2008-04-10 19:27 ` Ingo Molnar
2008-04-10 19:27 ` Ingo Molnar
2008-04-10 21:23 ` Kok, Auke
2008-04-10 21:44 ` Randy Dunlap
2008-04-10 21:52 ` Kok, Auke
2008-04-11 7:54 ` Andi Kleen
2008-04-11 0:46 ` Philip Craig
2008-04-11 11:26 ` Ingo Molnar
2008-04-11 11:26 ` Ingo Molnar
2008-04-11 11:36 ` Christoph Hellwig
2008-04-11 12:16 ` Ingo Molnar
2008-04-11 12:16 ` Ingo Molnar
2008-04-11 16:22 ` Kok, Auke
2008-04-11 16:45 ` Christoph Hellwig
2008-04-11 17:26 ` Kok, Auke
2008-04-11 17:34 ` Linus Torvalds
2008-04-11 17:53 ` Matthew Wilcox
2008-04-11 18:51 ` Linus Torvalds
2008-04-11 18:51 ` Linus Torvalds
2008-04-11 19:01 ` Matthew Wilcox
2008-04-11 19:25 ` Willy Tarreau
2008-04-11 19:25 ` Willy Tarreau
2008-04-11 19:38 ` Matthew Wilcox
2008-04-11 20:21 ` Linus Torvalds
2008-04-11 20:21 ` Linus Torvalds
2008-04-11 20:22 ` Krzysztof Halasa
2008-04-11 20:29 ` Linus Torvalds
2008-04-11 20:29 ` Linus Torvalds
2008-04-11 21:01 ` Dan Noe
2008-04-11 21:01 ` Dan Noe
2008-04-11 22:06 ` Daniel Barkalow
2008-04-11 22:21 ` Jeff Garzik
2008-04-11 23:05 ` Daniel Barkalow
2008-04-11 23:00 ` Linus Torvalds
2008-04-11 23:00 ` Linus Torvalds
2008-04-11 23:15 ` Daniel Barkalow
2008-04-11 23:15 ` Daniel Barkalow
2008-04-11 23:43 ` Jeff Garzik
2008-04-11 23:43 ` Jeff Garzik
2008-04-11 23:58 ` david
2008-04-12 13:07 ` Christoph Hellwig
2008-04-13 21:13 ` Linus Torvalds
2008-04-13 21:13 ` Linus Torvalds
2008-04-13 21:34 ` Ondrej Zary
2008-06-09 19:24 ` Ingo Molnar
2008-06-09 19:24 ` Ingo Molnar
2008-04-11 17:10 ` Martin Mares
2008-04-09 20:49 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Frans Pop
2008-04-09 20:49 ` Frans Pop
2008-04-09 23:59 ` Krzysztof Halasa
2008-04-10 1:40 ` Linus Torvalds
2008-04-10 1:40 ` Linus Torvalds
2008-04-10 9:57 ` Krzysztof Halasa
2008-04-10 14:30 ` Linus Torvalds
2008-04-10 14:30 ` Linus Torvalds
2008-04-10 17:55 ` Grant Grundler
2008-04-10 18:04 ` Matthew Wilcox
2008-04-10 18:26 ` [patch] e1000=y && e1000e=m regression fix Kok, Auke
2008-04-10 21:20 ` Chris Friesen
2008-04-10 19:27 ` [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000) Linus Torvalds
2008-04-10 21:35 ` Krzysztof Halasa
2008-04-10 21:35 ` Krzysztof Halasa
2008-04-08 20:31 ` [regression] e1000e broke e1000 Kok, Auke
2008-04-09 19:12 ` Ingo Molnar
2008-04-09 19:33 ` Jeff Garzik
2008-04-11 11:30 ` Ingo Molnar
2008-04-11 15:40 ` Chris Friesen
2008-04-11 19:29 ` Willy Tarreau
2008-04-10 0:52 ` Bill Davidsen
2008-04-11 8:59 ` Ingo Molnar
2008-04-08 19:43 ` [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices) Brandeburg, Jesse
2008-04-08 19:43 ` Brandeburg, Jesse
2008-04-08 19:59 ` Ingo Molnar
2008-04-08 20:04 ` Matthew Wilcox
2008-04-08 20:12 ` [regression] e1000e broke e1000 Dan Noe
2008-04-08 20:12 ` Dan Noe
2008-04-08 20:20 ` Matthew Wilcox
2008-04-08 20:35 ` Ingo Molnar
2008-04-08 20:36 ` Martin Mares
2008-04-08 20:36 ` Martin Mares
2008-04-08 20:39 ` Dan Noe
2008-04-08 20:39 ` Dan Noe
2008-04-08 20:13 ` showing which hardware is unclaimed Rick Jones
2008-04-08 20:35 ` Martin Mares
2008-04-08 20:35 ` Martin Mares
2008-04-08 20:17 ` [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices) Ingo Molnar
2008-04-08 20:17 ` Ingo Molnar
2008-04-09 19:08 ` [ANNOUNCE] e1000 to e1000e migration of PCI Express devices Ingo Molnar
2008-04-09 19:38 ` Andi Kleen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.