Compex FreedomLine 32 PnP-PCI2 broken with de2104x - Kernel

This is a discussion on Compex FreedomLine 32 PnP-PCI2 broken with de2104x - Kernel ; Hello, I was having problems with these FreedomLine cards with Linux before but tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC connectors: 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21041 [Tulip Pass ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

  1. Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    Hello,
    I was having problems with these FreedomLine cards with Linux before but
    tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC
    connectors:

    00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip
    21041 [Tulip Pass 3] [1011:0014] (rev 21)


    de2104x driver was loaded automatically by udev and card seemed to work. Until
    I disconnected the TP cable and putting it back after a while. The driver
    then switched to (non-existing) AUI port and remained there. I tried to set
    media to TP using ethtool - and the whole kernel crashed because of
    BUG_ON(de_is_running(de));
    in de_set_media(). Seems that the driver is unable to stop the DMA in
    de_stop_rxtx().

    I commented out AUI detection in the driver - this time it switched to BNC
    after unplugging the cable and remained there. I also attempted to reset the
    chip when de_stop_rxtx failed but failed to do it.

    Then I found that there's de4x5 driver which supports the same cards as
    de2104x (and some other too) - and this one works fine! I can plug and unplug
    the cable and even change between TP and BNC ports just by unplugging one and
    plugging the other cable in. Unfortunately, this driver is blacklisted by
    default - at least in Slackware and Debian.

    The question is: why does de2104x exist? Does it work better with some
    hardware?

    BTW. Found that the problem exist at least since 2003:
    http://oss.sgi.com/archives/netdev/2.../msg00951.html

    --
    Ondrej Zary
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
    > Hello,
    > I was having problems with these FreedomLine cards with Linux before but
    > tested it thoroughly today. This card uses DEC 21041 chip and has TP and
    > BNC connectors:
    >
    > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip
    > 21041 [Tulip Pass 3] [1011:0014] (rev 21)
    >
    >
    > de2104x driver was loaded automatically by udev and card seemed to work.
    > Until I disconnected the TP cable and putting it back after a while. The
    > driver then switched to (non-existing) AUI port and remained there. I tried
    > to set media to TP using ethtool - and the whole kernel crashed because of
    > BUG_ON(de_is_running(de));
    > in de_set_media(). Seems that the driver is unable to stop the DMA in
    > de_stop_rxtx().
    >
    > I commented out AUI detection in the driver - this time it switched to BNC
    > after unplugging the cable and remained there. I also attempted to reset
    > the chip when de_stop_rxtx failed but failed to do it.
    >
    > Then I found that there's de4x5 driver which supports the same cards as
    > de2104x (and some other too) - and this one works fine! I can plug and
    > unplug the cable and even change between TP and BNC ports just by
    > unplugging one and plugging the other cable in. Unfortunately, this driver
    > is blacklisted by default - at least in Slackware and Debian.
    >
    > The question is: why does de2104x exist? Does it work better with some
    > hardware?
    >
    > BTW. Found that the problem exist at least since 2003:
    > http://oss.sgi.com/archives/netdev/2.../msg00951.html


    Does the de2104x driver work correctly for anyone?

    --
    Ondrej Zary
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
    > On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
    > > Hello,
    > > I was having problems with these FreedomLine cards with Linux before but
    > > tested it thoroughly today. This card uses DEC 21041 chip and has TP and
    > > BNC connectors:
    > >
    > > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip
    > > 21041 [Tulip Pass 3] [1011:0014] (rev 21)
    > >
    > >
    > > de2104x driver was loaded automatically by udev and card seemed to work.
    > > Until I disconnected the TP cable and putting it back after a while. The
    > > driver then switched to (non-existing) AUI port and remained there. I tried
    > > to set media to TP using ethtool - and the whole kernel crashed because of
    > > BUG_ON(de_is_running(de));
    > > in de_set_media(). Seems that the driver is unable to stop the DMA in
    > > de_stop_rxtx().


    The BUG_ON() is probably fine normally. But the media selection sounds broken.
    It's possible to select the wrong media type with 21040 chip but shouldn't
    be possible with 21041. For 21040 support, see de21040_get_media_info().
    But de21041_get_srom_info() is expected to determine which media
    types are supported from SEPROM "media blocks". My guess is that code
    is broken since it seems to work with de405 driver. If you care to
    work the difference, I'd be happy to make a patch to fix that up.

    Also, from code review, DE2104X driver still has a few places with
    potential PCI MMIO Write posting issues. Specifically, I was looking
    in de_stop_hw() and de_set_media(). Several other bits of code correctly
    flush MMIO writes: e.g. tulip_read_eeprom().


    > > I commented out AUI detection in the driver - this time it switched to BNC
    > > after unplugging the cable and remained there. I also attempted to reset
    > > the chip when de_stop_rxtx failed but failed to do it.


    You'd have to basically hardcode only one media type and it's corresponding
    parameters.

    > > Then I found that there's de4x5 driver which supports the same cards as
    > > de2104x (and some other too) - and this one works fine! I can plug and
    > > unplug the cable and even change between TP and BNC ports just by
    > > unplugging one and plugging the other cable in. Unfortunately, this driver
    > > is blacklisted by default - at least in Slackware and Debian.


    ISTR there was a time when tulip would compete with de4x5 for devices.
    tulip is the preferred driver. That's clearly no longer the case
    and perhaps both distro's need to revisit this.

    > > The question is: why does de2104x exist? Does it work better with some
    > > hardware?


    de2104x is a "work in progress".
    That's why it's marked "EXPERIMENTAL" in the Kconfig file.

    > > BTW. Found that the problem exist at least since 2003:
    > > http://oss.sgi.com/archives/netdev/2.../msg00951.html

    >
    > Does the de2104x driver work correctly for anyone?


    No idea. I've only used tulip driver.

    thanks for the bug report,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    On Monday 18 February 2008 04:21:11 Grant Grundler wrote:
    > On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
    > > On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
    > > > Hello,
    > > > I was having problems with these FreedomLine cards with Linux before
    > > > but tested it thoroughly today. This card uses DEC 21041 chip and has
    > > > TP and BNC connectors:
    > > >
    > > > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation
    > > > DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)
    > > >
    > > >
    > > > de2104x driver was loaded automatically by udev and card seemed to
    > > > work. Until I disconnected the TP cable and putting it back after a
    > > > while. The driver then switched to (non-existing) AUI port and remained
    > > > there. I tried to set media to TP using ethtool - and the whole kernel
    > > > crashed because of BUG_ON(de_is_running(de));
    > > > in de_set_media(). Seems that the driver is unable to stop the DMA in
    > > > de_stop_rxtx().

    >
    > The BUG_ON() is probably fine normally. But the media selection sounds
    > broken. It's possible to select the wrong media type with 21040 chip but
    > shouldn't be possible with 21041. For 21040 support, see
    > de21040_get_media_info(). But de21041_get_srom_info() is expected to
    > determine which media
    > types are supported from SEPROM "media blocks". My guess is that code
    > is broken since it seems to work with de405 driver. If you care to
    > work the difference, I'd be happy to make a patch to fix that up.


    I don't think that BUG_ON() should be there. It should probably printk a
    warning but certainly not crash the whole machine.

    > Also, from code review, DE2104X driver still has a few places with
    > potential PCI MMIO Write posting issues. Specifically, I was looking
    > in de_stop_hw() and de_set_media(). Several other bits of code correctly
    > flush MMIO writes: e.g. tulip_read_eeprom().
    >
    > > > I commented out AUI detection in the driver - this time it switched to
    > > > BNC after unplugging the cable and remained there. I also attempted to
    > > > reset the chip when de_stop_rxtx failed but failed to do it.

    >
    > You'd have to basically hardcode only one media type and it's corresponding
    > parameters.


    That's bad. It just works with de4x5 with any cable at any time.

    > > > Then I found that there's de4x5 driver which supports the same cards as
    > > > de2104x (and some other too) - and this one works fine! I can plug and
    > > > unplug the cable and even change between TP and BNC ports just by
    > > > unplugging one and plugging the other cable in. Unfortunately, this
    > > > driver is blacklisted by default - at least in Slackware and Debian.

    >
    > ISTR there was a time when tulip would compete with de4x5 for devices.
    > tulip is the preferred driver. That's clearly no longer the case
    > and perhaps both distro's need to revisit this.


    de4x5 has no MODULE_DEVICE_TABLE for PCI devices anymore, so no conflicts.
    That's probably good for cards that work with tulip driver but bad for mine
    card and also probably for some other cards that (should) work with de2104x.

    >
    > > > The question is: why does de2104x exist? Does it work better with some
    > > > hardware?

    >
    > de2104x is a "work in progress".
    > That's why it's marked "EXPERIMENTAL" in the Kconfig file.


    Great, it looks to be 6 years old and it's still experimental. Probably
    because it never worked properly.

    I think that de2104x driver should be removed (or at least its
    MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI
    IDs added to de4x5.

    I can send a patch if this is acceptable.

    >
    > > > BTW. Found that the problem exist at least since 2003:
    > > > http://oss.sgi.com/archives/netdev/2.../msg00951.html

    > >
    > > Does the de2104x driver work correctly for anyone?

    >
    > No idea. I've only used tulip driver.
    >
    > thanks for the bug report,
    > grant
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/




    --
    Ondrej Zary
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
    > On Monday 18 February 2008 04:21:11 Grant Grundler wrote:
    > > On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
    > > > On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
    > > > > Hello,
    > > > > I was having problems with these FreedomLine cards with Linux before
    > > > > but tested it thoroughly today. This card uses DEC 21041 chip and has
    > > > > TP and BNC connectors:
    > > > >
    > > > > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation
    > > > > DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)
    > > > >
    > > > >
    > > > > de2104x driver was loaded automatically by udev and card seemed to
    > > > > work. Until I disconnected the TP cable and putting it back after a
    > > > > while. The driver then switched to (non-existing) AUI port and remained
    > > > > there. I tried to set media to TP using ethtool - and the whole kernel
    > > > > crashed because of BUG_ON(de_is_running(de));
    > > > > in de_set_media(). Seems that the driver is unable to stop the DMA in
    > > > > de_stop_rxtx().

    > >
    > > The BUG_ON() is probably fine normally. But the media selection sounds
    > > broken. It's possible to select the wrong media type with 21040 chip but
    > > shouldn't be possible with 21041. For 21040 support, see
    > > de21040_get_media_info(). But de21041_get_srom_info() is expected to
    > > determine which media
    > > types are supported from SEPROM "media blocks". My guess is that code
    > > is broken since it seems to work with de405 driver. If you care to
    > > work the difference, I'd be happy to make a patch to fix that up.

    >
    > I don't think that BUG_ON() should be there. It should probably printk a
    > warning but certainly not crash the whole machine.


    Ah ok - I agree. I'll see if we can fail more gracfully there.
    If you have an idea already, please send me a patch.

    > > > > Then I found that there's de4x5 driver which supports the same cards as
    > > > > de2104x (and some other too) - and this one works fine! I can plug and
    > > > > unplug the cable and even change between TP and BNC ports just by
    > > > > unplugging one and plugging the other cable in. Unfortunately, this
    > > > > driver is blacklisted by default - at least in Slackware and Debian.

    > >
    > > ISTR there was a time when tulip would compete with de4x5 for devices.
    > > tulip is the preferred driver. That's clearly no longer the case
    > > and perhaps both distro's need to revisit this.

    >
    > de4x5 has no MODULE_DEVICE_TABLE for PCI devices anymore, so no conflicts.
    > That's probably good for cards that work with tulip driver but bad for mine
    > card and also probably for some other cards that (should) work with de2104x.
    >
    > >
    > > > > The question is: why does de2104x exist? Does it work better with some
    > > > > hardware?

    > >
    > > de2104x is a "work in progress".
    > > That's why it's marked "EXPERIMENTAL" in the Kconfig file.

    >
    > Great, it looks to be 6 years old and it's still experimental. Probably
    > because it never worked properly.


    Yeah, probably.

    > I think that de2104x driver should be removed (or at least its
    > MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI
    > IDs added to de4x5.
    >
    > I can send a patch if this is acceptable.


    It's acceptable to me. Jeff? (jgarzik)

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    Grant Grundler wrote:
    > ISTR there was a time when tulip would compete with de4x5 for devices.
    > tulip is the preferred driver. That's clearly no longer the case
    > and perhaps both distro's need to revisit this.


    The only reason why de4x5 still exists is that the /tulip/ driver fails
    to work on a few chips like the 21142 (43?) shipped in various alpha boxen.

    de4x5 needs to go away, it's been unmaintained for ages, doesn't support
    any of the new hotplug APIs.


    > de2104x is a "work in progress".
    > That's why it's marked "EXPERIMENTAL" in the Kconfig file.


    It's not a work in progress, it works just fine for most people (the few
    that are left).

    Last I heard, there was a problem with non-twisted-pair stuff, but
    that's about it.

    'experimental' is generally a poorly maintained marker.

    Jeff


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    Grant Grundler wrote:
    > On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
    >> I think that de2104x driver should be removed (or at least its
    >> MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI
    >> IDs added to de4x5.
    >>
    >> I can send a patch if this is acceptable.

    >
    > It's acceptable to me. Jeff? (jgarzik)


    NAK, sorry, for two reasons:

    1) we don't delete otherwise clean, working drivers simply because of a
    bug triggered by unplugging a cable.

    2) de4x5 needs to go away.

    Jeff


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. [PATCH] de2104x: remove BUG_ON() when changing media type

    When the chip dies (probably because of a bug somewhere in the driver),
    de_stop_rxtx() fails and changing the media type crashes the whole machine.
    Replace BUG_ON() in de_set_media() with a warning.

    Signed-off-by: Ondrej Zary

    --- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25 18:27:34.000000000 +0100
    +++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c 2008-02-25 18:34:56.000000000 +0100
    @@ -910,7 +910,8 @@
    unsigned media = de->media_type;
    u32 macmode = dr32(MacMode);

    - BUG_ON(de_is_running(de));
    + if (de_is_running(de))
    + printk(KERN_WARNING "%s: chip is running while changing media!\n", de->dev->name);

    if (de->de21040)
    dw32(CSR11, FULL_DUPLEX_MAGIC);


    --
    Ondrej Zary
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH] de2104x: remove BUG_ON() when changing media type

    Ondrej Zary wrote:
    > When the chip dies (probably because of a bug somewhere in the driver),
    > de_stop_rxtx() fails and changing the media type crashes the whole machine.
    > Replace BUG_ON() in de_set_media() with a warning.
    >
    > Signed-off-by: Ondrej Zary
    >
    > --- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25 18:27:34.000000000 +0100
    > +++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c 2008-02-25 18:34:56.000000000 +0100
    > @@ -910,7 +910,8 @@
    > unsigned media = de->media_type;
    > u32 macmode = dr32(MacMode);
    >
    > - BUG_ON(de_is_running(de));
    > + if (de_is_running(de))
    > + printk(KERN_WARNING "%s: chip is running while changing media!\n", de->dev->name);


    Certainly a sane improvement...


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    On Monday 25 February 2008 08:28:14 Jeff Garzik wrote:
    > Grant Grundler wrote:
    > > ISTR there was a time when tulip would compete with de4x5 for devices.
    > > tulip is the preferred driver. That's clearly no longer the case
    > > and perhaps both distro's need to revisit this.

    >
    > The only reason why de4x5 still exists is that the /tulip/ driver fails
    > to work on a few chips like the 21142 (43?) shipped in various alpha boxen.
    >
    > de4x5 needs to go away, it's been unmaintained for ages, doesn't support
    > any of the new hotplug APIs.


    But has extensive port auto-detection which seems to work great (at least on
    my card). I don't feel like porting that code to de2104x - the code looks
    complex.

    >
    > > de2104x is a "work in progress".
    > > That's why it's marked "EXPERIMENTAL" in the Kconfig file.

    >
    > It's not a work in progress, it works just fine for most people (the few
    > that are left).
    >
    > Last I heard, there was a problem with non-twisted-pair stuff, but
    > that's about it.
    >
    > 'experimental' is generally a poorly maintained marker.


    So we have two unmaintained drivers - one that works fine (and is production
    quality - or at least seems to be) but does not support hotplug APIs and one
    that was never finished (the TP-unplug problem is present at least since
    2003).
    Perhaps de4x5 could be ported to new API(s)? I think that it's much easier
    than fixing obscure hardware-related problems like cable auto-detection.

    --
    Ondrej Zary
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

    On Mon, Feb 25, 2008 at 02:30:00AM -0500, Jeff Garzik wrote:
    > Grant Grundler wrote:
    >> On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
    >>> I think that de2104x driver should be removed (or at least its
    >>> MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041
    >>> PCI IDs added to de4x5.
    >>>
    >>> I can send a patch if this is acceptable.

    >> It's acceptable to me. Jeff? (jgarzik)

    >
    > NAK, sorry, for two reasons:
    >
    > 1) we don't delete otherwise clean, working drivers


    Just to be clear - he's not trying to remove the driver.
    He's just interested in making de4x5 the "default" for this set of boards
    by doctoring with the pci device ids each driver will claim.

    > simply because of a bug triggered by unplugging a cable.


    Ondrej would be happy to test any patches sent. Tracking this sort
    of bug down usually isn't trivial as the statement above implies.

    > 2) de4x5 needs to go away.


    Ok. I'd prefer to wait until someone demonstrates de2104x driver is a fully
    functional alternative for all the PCI Ids it claims.

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH] de2104x: remove BUG_ON() when changing media type

    applied


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH] de2104x: remove BUG_ON() when changing media type

    On Mon, Feb 25, 2008 at 12:52:17PM -0500, Jeff Garzik wrote:
    > Ondrej Zary wrote:
    >> When the chip dies (probably because of a bug somewhere in the driver),
    >> de_stop_rxtx() fails and changing the media type crashes the whole
    >> machine. Replace BUG_ON() in de_set_media() with a warning.
    >> Signed-off-by: Ondrej Zary
    >> --- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25
    >> 18:27:34.000000000 +0100
    >> +++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c 2008-02-25
    >> 18:34:56.000000000 +0100
    >> @@ -910,7 +910,8 @@
    >> unsigned media = de->media_type;
    >> u32 macmode = dr32(MacMode);
    >> - BUG_ON(de_is_running(de));
    >> + if (de_is_running(de))
    >> + printk(KERN_WARNING "%s: chip is running while changing media!\n",
    >> de->dev->name);

    >
    > Certainly a sane improvement...


    Jeff,
    The above patch was applied and fixes the 'panic' part of the problme.
    Can you take a look at this patch to fix the "chip is still running"
    part of this bug?

    BTW, I inherited a bug report for the same symptom:
    http://bugzilla.kernel.org/show_bug.cgi?id=3156

    thanks,
    grant

    Signed-off-by: Grant Grundler

    --- linux-2.6.23/drivers/net/tulip/de2104x.c 2007-10-09 13:31:38.000000000 -0700
    +++ linux-2.6.23/drivers/net/tulip/de2104x.c-ggg 2007-11-02 23:24:46.000000000 -0700
    @@ -842,7 +842,7 @@
    static void de_stop_rxtx (struct de_private *de)
    {
    u32 macmode;
    - unsigned int work = 1000;
    + unsigned int i = 1300/100;

    macmode = dr32(MacMode);
    if (macmode & RxTx) {
    @@ -850,10 +850,14 @@
    dr32(MacMode);
    }

    - while (--work > 0) {
    + /* wait until in-flight frame completes.
    + * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin)
    + * Typically expect this loop to end in < 50 us on 100BT.
    + */
    + while (--i) {
    if (!de_is_running(de))
    return;
    - cpu_relax();
    + udelay(100);
    }

    printk(KERN_WARNING "%s: timeout expired stopping DMA\n", de->dev->name);
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH] de2104x: remove BUG_ON() when changing media type

    On Monday 24 March 2008 03:45:14 Grant Grundler wrote:
    > On Mon, Feb 25, 2008 at 12:52:17PM -0500, Jeff Garzik wrote:
    > > Ondrej Zary wrote:
    > >> When the chip dies (probably because of a bug somewhere in the driver),
    > >> de_stop_rxtx() fails and changing the media type crashes the whole
    > >> machine. Replace BUG_ON() in de_set_media() with a warning.
    > >> Signed-off-by: Ondrej Zary
    > >> --- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25
    > >> 18:27:34.000000000 +0100
    > >> +++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c 2008-02-25
    > >> 18:34:56.000000000 +0100
    > >> @@ -910,7 +910,8 @@
    > >> unsigned media = de->media_type;
    > >> u32 macmode = dr32(MacMode);
    > >> - BUG_ON(de_is_running(de));
    > >> + if (de_is_running(de))
    > >> + printk(KERN_WARNING "%s: chip is running while changing media!\n",
    > >> de->dev->name);

    > >
    > > Certainly a sane improvement...

    >
    > Jeff,
    > The above patch was applied and fixes the 'panic' part of the problme.
    > Can you take a look at this patch to fix the "chip is still running"
    > part of this bug?


    I'll test it but I doubt that it fixes the problem. IIRC, I tried something
    like that. Even tried resetting the chip multiple times when this problem
    appears but everything failed.


    >
    > BTW, I inherited a bug report for the same symptom:
    > http://bugzilla.kernel.org/show_bug.cgi?id=3156
    >
    > thanks,
    > grant
    >
    > Signed-off-by: Grant Grundler
    >
    > --- linux-2.6.23/drivers/net/tulip/de2104x.c 2007-10-09 13:31:38.000000000
    > -0700 +++ linux-2.6.23/drivers/net/tulip/de2104x.c-ggg 2007-11-02
    > 23:24:46.000000000 -0700 @@ -842,7 +842,7 @@
    > static void de_stop_rxtx (struct de_private *de)
    > {
    > u32 macmode;
    > - unsigned int work = 1000;
    > + unsigned int i = 1300/100;
    >
    > macmode = dr32(MacMode);
    > if (macmode & RxTx) {
    > @@ -850,10 +850,14 @@
    > dr32(MacMode);
    > }
    >
    > - while (--work > 0) {
    > + /* wait until in-flight frame completes.
    > + * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin)
    > + * Typically expect this loop to end in < 50 us on 100BT.
    > + */
    > + while (--i) {
    > if (!de_is_running(de))
    > return;
    > - cpu_relax();
    > + udelay(100);
    > }
    >
    > printk(KERN_WARNING "%s: timeout expired stopping DMA\n", de->dev->name);




    --
    Ondrej Zary
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH] de2104x: remove BUG_ON() when changing media type

    On Tue, Mar 25, 2008 at 12:02:19AM +0100, Ondrej Zary wrote:
    .....
    > > Jeff,
    > > The above patch was applied and fixes the 'panic' part of the problme.
    > > Can you take a look at this patch to fix the "chip is still running"
    > > part of this bug?

    >
    > I'll test it but I doubt that it fixes the problem. IIRC, I tried something
    > like that.


    Thanks (in advance) for testing!

    This patch fixed the same symptom for tulip driver many years ago.
    It's been validated already and should be applied to de2104x driver too.

    If it doesn't fix the problem, that just means something else
    is going wrong as well.

    > Even tried resetting the chip multiple times when this problem
    > appears but everything failed.


    Can you print the last value from dr32(MacStatus)?
    (just append the output to the "stopping DMA" printk)

    If resetting the chip isn't working, my guess is the PCI bus is
    out to lunch. Getting ~0 back on the MMIO read would be evidence
    of that. But resetting the chip isn't trivial and all sorts of
    things could go wrong with that.

    thanks,
    grant

    >
    >
    > >
    > > BTW, I inherited a bug report for the same symptom:
    > > http://bugzilla.kernel.org/show_bug.cgi?id=3156
    > >
    > > thanks,
    > > grant
    > >
    > > Signed-off-by: Grant Grundler
    > >
    > > --- linux-2.6.23/drivers/net/tulip/de2104x.c 2007-10-09 13:31:38.000000000
    > > -0700 +++ linux-2.6.23/drivers/net/tulip/de2104x.c-ggg 2007-11-02
    > > 23:24:46.000000000 -0700 @@ -842,7 +842,7 @@
    > > static void de_stop_rxtx (struct de_private *de)
    > > {
    > > u32 macmode;
    > > - unsigned int work = 1000;
    > > + unsigned int i = 1300/100;
    > >
    > > macmode = dr32(MacMode);
    > > if (macmode & RxTx) {
    > > @@ -850,10 +850,14 @@
    > > dr32(MacMode);
    > > }
    > >
    > > - while (--work > 0) {
    > > + /* wait until in-flight frame completes.
    > > + * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin)
    > > + * Typically expect this loop to end in < 50 us on 100BT.
    > > + */
    > > + while (--i) {
    > > if (!de_is_running(de))
    > > return;
    > > - cpu_relax();
    > > + udelay(100);
    > > }
    > >
    > > printk(KERN_WARNING "%s: timeout expired stopping DMA\n", de->dev->name);

    >
    >
    >
    > --
    > Ondrej Zary

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH] de2104x: remove BUG_ON() when changing media type

    On Wednesday 26 March 2008 16:59:57 Grant Grundler wrote:
    > On Tue, Mar 25, 2008 at 12:02:19AM +0100, Ondrej Zary wrote:
    > ....
    >
    > > > Jeff,
    > > > The above patch was applied and fixes the 'panic' part of the problme.
    > > > Can you take a look at this patch to fix the "chip is still running"
    > > > part of this bug?

    > >
    > > I'll test it but I doubt that it fixes the problem. IIRC, I tried
    > > something like that.

    >
    > Thanks (in advance) for testing!
    >
    > This patch fixed the same symptom for tulip driver many years ago.
    > It's been validated already and should be applied to de2104x driver too.
    >
    > If it doesn't fix the problem, that just means something else
    > is going wrong as well.


    As I expected, it did not fix the problem. This time, I used only BNC cable.
    Let ping run, disconnect the cable, change the media type a couple of times
    and it dies. When "timeout expired stopping DMA" appears, the card is dead
    until the module is reloaded.

    de2104x PCI Ethernet driver v0.7 (Mar 17, 2004)
    ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
    ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKC] -> GSI 11 (level, low) ->
    IRQ 11
    de0: SROM leaf offset 30, default media 10baseT auto
    de0: media block #0: BNC
    de0: media block #1: AUI
    de0: media block #2: 10baseT-FD
    de0: media block #3: 10baseT-HD
    eth1: 21041 at 0xd1084000, 00:80:48:ea:eb:0a, IRQ 11
    eth1: enabling interface
    eth1: set link 10baseT auto
    eth1: mode 0x7ffc0040, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008
    eth1: set mode 0x7ffc0040, set sia 0xef01,0xffff,0x8
    eth1: set link AUI
    eth1: mode 0x7ffc0000, sia 0x10c4,0xffffef09,0xfffff7fd,0xffff000e
    eth1: set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0xe
    eth1: link up, media AUI
    eth1: link down
    eth1: set link 10baseT auto
    eth1: mode 0x7ffc0000, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008
    eth1: set mode 0x7ffc0000, set sia 0xef01,0xffff,0x8
    eth1: set link AUI
    eth1: mode 0x7ffc0000, sia 0x10c4,0xffffef09,0xfffff7fd,0xffff000e
    eth1: set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0xe
    eth1: link up, media AUI
    eth1: link down
    eth1: timeout expired stopping DMA
    eth1: chip is running while changing media!
    eth1: set link 10baseT auto
    eth1: mode 0x7ffc0000, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008
    eth1: set mode 0x7ffc0000, set sia 0xef01,0xffff,0x8
    eth1: timeout expired stopping DMA
    eth1: chip is running while changing media!
    eth1: set link AUI
    eth1: mode 0x7ffc0000, sia 0x11c4,0xffffef09,0xfffff7fd,0xffff000e
    eth1: set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0xe
    eth1: set link BNC
    eth1: mode 0x7ffc0000, sia 0x10c4,0xffffef09,0xfffff7fd,0xffff0006
    eth1: set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0x6
    eth1: link up, media BNC
    eth1: link down
    eth1: set link AUI
    eth1: mode 0x7ffc0000, sia 0x10c4,0xffffef09,0xfffff7fd,0xffff000e
    eth1: set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0xe

    >
    > > Even tried resetting the chip multiple times when this problem
    > > appears but everything failed.

    >
    > Can you print the last value from dr32(MacStatus)?
    > (just append the output to the "stopping DMA" printk)
    >
    > If resetting the chip isn't working, my guess is the PCI bus is
    > out to lunch. Getting ~0 back on the MMIO read would be evidence
    > of that. But resetting the chip isn't trivial and all sorts of
    > things could go wrong with that.
    >
    > thanks,
    > grant
    >
    > > > BTW, I inherited a bug report for the same symptom:
    > > > http://bugzilla.kernel.org/show_bug.cgi?id=3156
    > > >
    > > > thanks,
    > > > grant
    > > >
    > > > Signed-off-by: Grant Grundler
    > > >
    > > > --- linux-2.6.23/drivers/net/tulip/de2104x.c 2007-10-09
    > > > 13:31:38.000000000 -0700 +++
    > > > linux-2.6.23/drivers/net/tulip/de2104x.c-ggg 2007-11-02
    > > > 23:24:46.000000000 -0700 @@ -842,7 +842,7 @@
    > > > static void de_stop_rxtx (struct de_private *de)
    > > > {
    > > > u32 macmode;
    > > > - unsigned int work = 1000;
    > > > + unsigned int i = 1300/100;
    > > >
    > > > macmode = dr32(MacMode);
    > > > if (macmode & RxTx) {
    > > > @@ -850,10 +850,14 @@
    > > > dr32(MacMode);
    > > > }
    > > >
    > > > - while (--work > 0) {
    > > > + /* wait until in-flight frame completes.
    > > > + * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin)
    > > > + * Typically expect this loop to end in < 50 us on 100BT.
    > > > + */
    > > > + while (--i) {
    > > > if (!de_is_running(de))
    > > > return;
    > > > - cpu_relax();
    > > > + udelay(100);
    > > > }
    > > >
    > > > printk(KERN_WARNING "%s: timeout expired stopping DMA\n",
    > > > de->dev->name);

    > >
    > > --
    > > Ondrej Zary




    --
    Ondrej Zary
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread