8139-based Airlink ASOHORL PCI network card not working under 2.6? - Hardware

This is a discussion on 8139-based Airlink ASOHORL PCI network card not working under 2.6? - Hardware ; I'm using Ubuntu 5.10 (x86) and just popped in a cheap Airlink ASOHORL 10/100 PCI network card, which I bought because it was something like $5 and promised Linux compatibility on the box. The card is based on the RTL-8139C ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: 8139-based Airlink ASOHORL PCI network card not working under 2.6?

  1. 8139-based Airlink ASOHORL PCI network card not working under 2.6?

    I'm using Ubuntu 5.10 (x86) and just popped in a cheap Airlink ASOHORL
    10/100 PCI network card, which I bought because it was something like
    $5 and promised Linux compatibility on the box. The card is based on
    the RTL-8139C chipset (according to rtl8139-diag). However, when I add
    the card to /etc/network/interfaces and try to ifup it, I get these
    errors:

    SIOCSIFADDR: No such device
    eth2: ERROR while getting interface flags: No such device
    SIOCSIFNETMASK: No such device
    eth2: ERROR while getting interface flags: No such device
    Failed to bring up eth2.

    (Yes, it's the third network card in this box.) I looked at the driver
    diskette and they provide drivers for 2.2.x and 2.4.x, but not 2.6.x
    (I'm running 2.6.12-10-386). Foo.

    Using the 8139too module with debugging turned on says this:

    8139too Fast Ethernet driver 0.9.27
    ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKA] -> GSI 10 (level,
    low) -> IRQ 10
    PCI: Unable to reserve I/O region #1:100@de00 for device 0000:00:0c.0
    Trying to free nonexistent resource <0000de00-0000deff>
    Trying to free nonexistent resource
    8139too: probe of 0000:00:0c.0 failed with error -16

    and I likewise get errors from 8139cp.

    lspci -vv -n says this:

    0000:00:0c.0 0200: 10ec:8139 (rev 10)
    Subsystem: 1259:c10f
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
    ParErr- Stepping- SERR+ FastB2B-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
    >TAbort- SERR-
    Latency: 64 (8000ns min, 16000ns max)
    Interrupt: pin A routed to IRQ 10
    Region 0: I/O ports at de00 [size=256]
    Region 1: Memory at efffff00 (32-bit, non-prefetchable)
    [size=256]
    Capabilities: [50] Power Management version 2
    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
    PME(D0-,D1+,D2+,D3hot+,D3cold-)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME-

    or, without the -n:

    0000:00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
    RTL-8139/8139C/8139C+ (rev 10)
    Subsystem: Allied Telesyn International: Unknown device c10f
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
    ParErr- Stepping- SERR+ FastB2B-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
    >TAbort- SERR-
    Latency: 64 (8000ns min, 16000ns max)
    Interrupt: pin A routed to IRQ 10
    Region 0: I/O ports at de00 [size=256]
    Region 1: Memory at efffff00 (32-bit, non-prefetchable)
    [size=256]
    Capabilities: [50] Power Management version 2
    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
    PME(D0-,D1+,D2+,D3hot+,D3cold-)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME-

    I glanced at the source for the 8139too driver and I see 10ec:8139
    listed there, so I'd think this would work, but clearly it doesn't. I
    suspect the root cause is that it can't reserve the I/O region, and
    that this isn't really 8139-driver-specific -- I just don't have a good
    idea how to go about fixing that. Any suggestions?


  2. Re: 8139-based Airlink ASOHORL PCI network card not working under 2.6?

    vmontressor@yahoo.com wrote:
    > PCI: Unable to reserve I/O region #1:100@de00 for device 0000:00:0c.0
    > Trying to free nonexistent resource <0000de00-0000deff>
    > Trying to free nonexistent resource
    > 8139too: probe of 0000:00:0c.0 failed with error -16




    > I
    > suspect the root cause is that it can't reserve the I/O region, and
    > that this isn't really 8139-driver-specific


    Agreed. If you look at /proc/ioports, you should see what
    has beaten the driver to that region.

    Steve