Bug 49198
| Summary: | install using e100 driver | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Bryan Leopard <bryan.leopard> |
| Component: | distribution | Assignee: | Bill Nottingham <notting> |
| Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-08-01 19:02:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bryan Leopard
2001-07-16 19:45:45 UTC
Matt is this workable with just a driver disk and using the 'noprobe' option to the installer? I don't understand the question. You should be able to use the e100 module if the user uses 'noprobe'. otherwise, do these PCI IDs apply only to your cards? With your choice of the e100 module, are you indemnifying from having to fix problems that using the e100 module will cause? It is true that the user can reconfigure to use the e100 driver. The request is that the installation default to the e100 rather than the eepro100 at least for Compaq Intel based NICs. Compaq engineering feels that it is a more reliable driver and that it is better supported since it is an Intel driver and has considerable more testing on that driver here at Compaq. Reassigning to 'distribution' component. Default driver selection is not handled by the installer, but kudzu. Um, no. We've answered this before. I'd like to know what extensive technical analysis Compaq has done to come up with this idea. Has your team of crack network device driver writers audited the source code? When they did the audit, did they happen to notice the half second busy-wait with IRQs disabled that 1) may damage their own P4 processor, and 2) may cause data loss by confusing the SCSI subsystem? Have they tried to fix a bug in the driver? The current question is not whether the e100 driver will become the default, but whether it will even continue to be part of the distribution. Intel is working on changing the driver to fix bugs enough that we can continue to include it in the distribution. Their current driver revision has introduced bugs that not only make the driver even less maintainable than it was before, but also threaten data integrity. (Not to mention that the source code for the e100 driver is unnecessarily an *order of magnitude* larger than the eepro100 driver and the source code is harder to read -- the e100 driver is larger than some entire operating systems...) We could go into all the problems with the e100 driver, but we'd rather do that with Intel directly and help them improve their driver instead, and we are in the process of doing precisely that. But we will not be making this driver the default in the forseeable future. Please do not continue to open bug reports regarding this behavior. Thank you for your future cooperation in this matter. |