lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 21 Sep 2008 23:38:09 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Arjan van de Ven <arjan@...radead.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, ipw2100-devel@...ts.sourceforge.net,
	linux-wireless@...r.kernel.org, yi.zhu@...el.com,
	reinette.chatre@...el.com, jgarzik@...ox.com,
	linville@...driver.com, davem@...emloft.net
Subject: Re: Mark IPW2100 as BROKEN: Fatal interrupt. Scheduling firmware restart.

Hi.

On Sun, Sep 21, 2008 at 09:14:04PM +0200, Johannes Berg (johannes@...solutions.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists