Bug 130079 - Ethernet controller Intel 82562EZ (e100) not operating
Summary: Ethernet controller Intel 82562EZ (e100) not operating
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Final
Hardware: i386 SuSE Linux 10.0
: P5 - None : Normal
Target Milestone: ---
Assignee: Thomas Renninger
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-21 20:05 UTC by Forgotten User gic99LgXZ-
Modified: 2005-12-12 17:25 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Forgotten User gic99LgXZ- 2005-10-21 20:05:58 UTC
The above network card is recognized as e100 compatible card as onboard card in
a HP DX2000 Microtower Workstation. Yast configuration runs normal, but no dhcp
address can be assigned.
output of lspci -v is:
-------------------------------------
01:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet
Controller (rev 02)
        Subsystem: GVC/BCM Advanced Research: Unknown device 2181
        Flags: bus master, medium devsel, latency 32, IRQ 10
        Memory at fe5fe000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at a000 [size=64]
        Capabilities: [dc] Power Management version 2
-------------------------------------------------------
rcnetwork restart results in:
-------------------------------------------------------
   eth0      device: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 02)
    eth0      configuration: eth-id-00:0f:fe:1b:bd:34
    eth0      (DHCP) . . . . . no IP address yet... backgrounding.    waiting
-------------------------------------------------------
output of ifconfig:
-------------------------------------------------------
eth0      Link encap:Ethernet  HWaddr 00:0F:FE:1B:BD:34
          inet6 addr: fe80::20f:feff:fe1b:bd34/64 Scope:Link
          UP BROADCAST NOTRAILERS MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
-------------------------------------------------------
Fix ip address assigment seems to work as normal in yast, but no ip address
within the subnet is pingable, the firewall is unconfigured, of course, i have a
second NIC (dlink dfe530-tx / via rhine), to be able to post this here...

I have downloaded + compiled + installed the sources from intel (version 3.4.14)
but the result stays the same...

Any known (maybe kernel) issues?
Comment 3 Forgotten User gic99LgXZ- 2005-10-25 06:31:40 UTC
The Network Card works fine, after changing the ACPI settings inside of the BIOS:
Upon boottime press F10, and within the 'advanced CMOS settings' change the following setting:
"APIC ACPI SCI IRQ" = Disabled. (from former default setting = 'enabled').
(APIC ACPI SCI IRQ Allows you to enable or disable the internal I/O APIC and multi processor tables... Enabled= IRQ 20-23 ; Disabled = IRQ 9-11)

This seems to be a ACPI problem, i guess.
The Network card still needs a bit longer, for dhcp, but at least it works.

Any Hints?
Comment 4 Olaf Kirch 2005-11-15 11:09:06 UTC
Thomas, any idea?
Comment 5 Thomas Renninger 2005-12-08 18:15:57 UTC
So what you did is the same as passing noapic boot param it seems.
Please first be sure you have the latest BIOS installed.
I'd like to set this one won't fix as you shouldn't see any problems with noapic option beside a bit more IRQ traffic on single IRQs and I doubt I could find the problem anyways. Hmmm, just doing it, it's not the only machine needing this param and there are much more important problems... Please tell me if a BIOS update helped if it does.
Comment 6 Forgotten User gic99LgXZ- 2005-12-12 13:05:12 UTC
(In reply to comment #5)
A BIOS update did not fixed this problem.
The problem is reproducable, the same way as before (with old bios version).
Nevertheless i installed on other machines (e.g. Maxdata, ASUS-Pundit, etc.), with a similar setting in the bios sucessfuly.
Thanx & Regards
Comment 7 Thomas Renninger 2005-12-12 17:25:00 UTC
Could you only try with the BIOS setting that does not work.
Please pass noapic boot param and verify whether it works then and attach /proc/interrupts and dmesg output of both configurations.
Please also attach acpidmp output (doesn't matter which boot param orBIOS setting).

I am not sure whether it's worth to look at this one deeper. Some BIOSes are known to be broken concerning APIC setup and the first params one should try is pci=noacpi and/or noapic. If all devices work you should not have any functionality degression, beside more interrupt traffic (because of more devices sharing one interrupt) using noapic.

It is probably better to just write an article with the description of your machine's hardware (BIOS) here:
http://www.opensuse.org/End-User_Documentation
maybe best is here:
http://www.opensuse.org/Hardware_Trouble_Shooting

I always wanted to write an article about exactly this problem:
"Wrong IRQ assignment" or "machine only boots with acpi=off"
The recommended way is first to update the BIOS, then to try pci=noacpi and/or noapic boot option.
If one of them works people should be just happy (if the boot param is added at installation time, it will be added automatically to all other installed SuSE kernels later). Do you mind to add a short article to inform others?