lkml.org 
[lkml]   [2008]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Mark IPW2100 as BROKEN: Fatal interrupt. Scheduling firmware restart.
    [Evgeniy Polyakov - Sun, Sep 21, 2008 at 11:38:09PM +0400]
    | Hi.
    |
    | On Sun, Sep 21, 2008 at 09:14:04PM +0200, Johannes Berg (johannes@sipsolutions.net) wrote:
    | > > Do you want me to implement ipw2100 driver as a big work structure
    | > > which will run ipw2100_init()/wait/ipw2100_exit() in a loop?
    | > > And that will be the fix suggested by Intel? That would explain a lot.
    | >
    | > I think what Arjan is saying is that it would be better to put pressure
    | > on the responsible folks (I don't think Arjan is anywhere near them at
    |
    | Both maintainers were added to the copy list.
    |
    | > all) if you'd put in a WARN_ON() for this error and that would make the
    | > top entry on kerneloops.org all the time... And additionally put in a
    | > workaround for yourself for now.
    |
    | As I pointed, I can rewrite the whole driver's initialization process,
    | so that it looked like init/wait/exit loop, which can be processed at
    | the module load and when fatal interrupt fires. Do this a fix? This is
    | not even a remotely workaround. We can just add
    | rmmod/modprobe/ifdown/ifup to the crontab job. Another users reported in
    | bugzilla that they needed to reboot a machine to make card working
    | again. I'm not sure that user tried to do a rmmod/modprobe though.
    |
    | > And can we keep the flames off this list please? That comment from Wei
    | > Weng was absolutely uncalled for, and inciting a flamewar (as you have
    | > already blogged) was not really productive either.
    |
    | If we will keep silence, no one will notice that problem exists.
    |
    | I do hope this will result in a progress. Arjan, do you aggree to add
    | this patch to the current tree?
    |
    | diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
    | index 19a401c..9a7b64c 100644
    | --- a/drivers/net/wireless/ipw2100.c
    | +++ b/drivers/net/wireless/ipw2100.c
    | @@ -206,6 +206,8 @@ MODULE_PARM_DESC(disable, "manually disable the radio (default 0 [radio on])");
    |
    | static u32 ipw2100_debug_level = IPW_DL_NONE;
    |
    | +static int ipw2100_max_fatal_ints = 10;
    | +
    | #ifdef CONFIG_IPW2100_DEBUG
    | #define IPW_DEBUG(level, message...) \
    | do { \
    | @@ -3174,6 +3176,10 @@ static void ipw2100_irq_tasklet(struct ipw2100_priv *priv)
    | if (inta & IPW2100_INTA_FATAL_ERROR) {
    | printk(KERN_WARNING DRV_NAME
    | ": Fatal interrupt. Scheduling firmware restart.\n");
    | + WARN_ON(1);
    | +
    | + BUG_ON(ipw2100_max_fatal_ints-- <= 0);
    | +
    | priv->inta_other++;
    | write_register(dev, IPW_REG_INTA, IPW2100_INTA_FATAL_ERROR);
    |
    |
    |
    | --
    | Evgeniy Polyakov
    |

    Since it's that serious maybe we should change

    IPW_DEBUG_INFO("%s: Fatal error value: 0x%08X\n",
    priv->net_dev->name, priv->fatal_error);

    to printk(KERN_WARN)? And here is why - as I see now we can't say what
    exactly is wrong - Evgeniy said he has a suspicious about firmware so
    this WARNS will be collected by Arjan thru kerneloops and we could not
    ask users to change debug level and repost problem - oops will have it
    by default - and if it really firmware problem - firmware engineers could
    find this _additional_ info usefull and resolve it (probably).

    - Cyrill -


    \
     
     \ /
      Last update: 2008-09-21 22:07    [W:0.024 / U:1.144 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site