lkml.org 
[lkml]   [2006]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjecte100 fails, eepro100 works
    Hi,

    we have a couple of industrial PCs here with Intel PRO/100 controllers
    on board. Most of them work fine with the e100, but today I stumbled
    over one box that doesn't: Reception works (RX counter increases, ARP
    cache gets filled up), but transmission fails (TX counter is also zero).
    In contrast, the eepro100 is fine, also Etherboot's driver.

    I'm currently on 2.6.17.8, but I don't see any changes up to latest git
    that may have positive influence. This is what lspci -v tells about this
    piece of hardware:

    00:12.0 Ethernet controller: Intel Corporation 8255xER/82551IT Fast
    Ethernet Controller (rev 08)
    Subsystem: Intel Corporation: Unknown device 1229
    Flags: bus master, medium devsel, latency 66, IRQ 10
    Memory at fc020000 (32-bit, non-prefetchable) [size=4K]
    I/O ports at 1080 [size=64]
    Memory at fc000000 (32-bit, non-prefetchable) [size=128K]
    Capabilities: [dc] Power Management version 2

    And here is the kernel log of e100 with highest debug level when sending
    out a few pings while other packets arrive on the network:

    e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
    e100: Copyright(c) 1999-2005 Intel Corporation
    PCI: Found IRQ 10 for device 0000:00:12.0
    e100: eth0: e100_probe: addr 0xfc020000, irq 10, MAC addr 00:30:59:01:07:A7
    e100: eth0: e100_watchdog: right now = 35470
    e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
    e100: eth0: e100_intr: stat_ack = 0x04
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_watchdog: right now = 35970
    e100: eth0: e100_intr: stat_ack = 0x04
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_watchdog: right now = 36470
    e100: eth0: e100_intr: stat_ack = 0x04
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_watchdog: right now = 36970
    e100: eth0: e100_intr: stat_ack = 0x04
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_watchdog: right now = 37470
    e100: eth0: e100_intr: stat_ack = 0x04
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_watchdog: right now = 37970
    e100: eth0: e100_intr: stat_ack = 0x04
    e100: eth0: e100_watchdog: right now = 38470
    e100: eth0: e100_intr: stat_ack = 0x04
    e100: eth0: e100_intr: stat_ack = 0x40
    e100: eth0: e100_watchdog: right now = 38970
    e100: eth0: e100_intr: stat_ack = 0x04

    I may find the time one day to debug this at lower levels, but you could
    accelerate this process with any pointer where to dig deeper precisely.

    Jan

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2006-09-08 15:43    [W:0.025 / U:89.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site