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 ...
[ message continues ]

Auke is out sick, so I'm responding...
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
if you're running a no module kernel, you'll need to set CONFIG_E1000E=y
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

--

there should be no need for me to set something that the kernel can do 
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

--

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."

--

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

--

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
--

`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.

--

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/

--

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."

--

Hah, thanks.  That is useful and very new :)  I built a newer lspci and 
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/

--

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

--

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.

--

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."

--

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

--

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
--

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

--

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
--

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 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
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

--

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

--

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
--

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

--

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

--

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

--

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
--

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

--

That's because PCI ID transitions are extremely, extremely rare.
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 
"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
--

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"

--

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

--

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

--

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

--

That would work, too.

--

Krzysztof Halasa

--

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

--

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.
Right. Now it's a different situation, though.

--

Krzysztof Halasa

--

On Thu, Apr 10, 2008 at 07:30:34AM -0700, Linus Torvalds wrote:
If e1000e is not getting compiled, my understanding was the original e1000
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

--

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

--

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."

--

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

--

If this makes people happy then I am happy to ack this.
--

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
--

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 
huh? How can you claim that?? It definitely solved my problem. Did you 
... 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

--

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

--

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

--

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

---end quoted text---

--

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 rightful...
[ message continues ]

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.
--

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);}

--

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"

+

+endc...
[ message continues ]

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/driver...
[ message continues ]

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).
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 
.. 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

--

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
--

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

--

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

--

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 
--

Ondrej Zary

--

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..

--

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
--

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*

--

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
--

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*

--

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."

--

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

--

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/
--

I guess PCIE. You already came across a similar problem.
Have I won something? :-)

--

Krzysztof Halasa

--

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

--

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
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."

--

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

--

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
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
--

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."

--

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

--

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 ;-)

--

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
---

~Randy

--

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

--

that first part (for x86 at least) I already sent (straight to linus even) after

same comment from Andy.
Auke
--

thanks Auke!
	Ingo

--

You do follow LKML, where multiple announcements have and are being posted.
	Jeff
--

... 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

--

hence the patch that is in jeff's upstream tree that puts an end to this :)
Auke
--