From: Mike Mason <hidden> Date: 2008-07-20 18:28:23
This patch changes the EEH_MAX_FAILS action from panic to printing an error message. Panicking under under this condition is too harsh. Although performance will be affected and the device may not recover, the system is still running, which at the very least, should allow for a more graceful shutdown. The panic() is now wrapped in a DEBUG statement for development purposes. The patch also removes the msleep() within a spinlock, which is not allowed.
Signed-off-by: Mike Mason <redacted>
@@ -75,9 +75,9 @@*//* If a device driver keeps reading an MMIO register in an interrupt-*handlerafteraslotisolationeventhasoccurred,weassumeit-*isbrokenandpanic.Thissetsthethresholdforhowmanyread-*attemptsweallowbeforepanicking.+*handlerafteraslotisolationevent,itmightbebroken.+*Thissetsthethresholdforhowmanyreadattemptsweallow+*beforeprintinganerrormessage.*/#define EEH_MAX_FAILS 2100000
@@ -509,18 +510,24 @@rc=1;if(pdn->eeh_mode&EEH_MODE_ISOLATED){pdn->eeh_check_count++;-if(pdn->eeh_check_count>=EEH_MAX_FAILS){-printk(KERN_ERR"EEH: Device driver ignored %d bad reads, panicing\n",-pdn->eeh_check_count);+if(pdn->eeh_check_count%EEH_MAX_FAILS==0){+location=(char*)of_get_property(dn,"ibm,loc-code",NULL);+printk(KERN_ERR"EEH: %d reads ignored for recovering device at "+"location=%s driver=%s pci addr=%s\n",+pdn->eeh_check_count,location,+dev->driver->name,pci_name(dev));+printk(KERN_ERR"EEH: Might be infinite loop in %s driver\n",+dev->driver->name);+#ifdef DEBUGdump_stack();-msleep(5000);-+/* re-read the slot reset state */if(read_slot_reset_state(pdn,rets)!=0)rets[0]=-1;/* reset state unknown *//* If we are here, then we hit an infinite loop. Stop. */panic("EEH: MMIO halt (%d) on device:%s\n",rets[0],pci_name(dev));+#endif}gotodn_unlock;}
This patch changes the EEH_MAX_FAILS action from panic to printing an
error message. Panicking under under this condition is too harsh.
Although performance will be affected and the device may not recover,
the system is still running, which at the very least, should allow
for a more graceful shutdown. The panic() is now wrapped in a DEBUG
statement for development purposes. The patch also removes the
msleep() within a spinlock, which is not allowed.
Why can you not msleep within a spinlock? And when was this change
brought in?
Cheers,
Sean
This patch changes the EEH_MAX_FAILS action from panic to printing an
error message. Panicking under under this condition is too harsh.
Although performance will be affected and the device may not recover,
the system is still running, which at the very least, should allow
for a more graceful shutdown. The panic() is now wrapped in a DEBUG
statement for development purposes. The patch also removes the
msleep() within a spinlock, which is not allowed.
Why can you not msleep within a spinlock? And when was this change
brought in?
Giving up the cpu while holding a spinlock risks locking up the system
in the worst case -- if another task tries to acquire the held lock it
can spin indefinitely.
This patch changes the EEH_MAX_FAILS action from panic to printing
an error message. Panicking under under this condition is too
harsh. Although performance will be affected and the device may not
recover, the system is still running, which at the very least,
should allow for a more graceful shutdown. The panic() is now
wrapped in a DEBUG statement for development purposes. The patch
also removes the msleep() within a spinlock, which is not allowed.
quoted hunk
@@ -509,18 +510,24 @@
For ease of review, please try to use diff -p to generate patches.
+ printk (KERN_ERR "EEH: %d reads ignored for recovering device at "
+ "location=%s driver=%s pci addr=%s\n",
+ pdn->eeh_check_count, location,
+ dev->driver->name, pci_name(dev));
+ printk (KERN_ERR "EEH: Might be infinite loop in %s driver\n",
+ dev->driver->name);
+#ifdef DEBUG
dump_stack();
- msleep(5000);
-
+
/* re-read the slot reset state */
if (read_slot_reset_state(pdn, rets) != 0)
rets[0] = -1; /* reset state unknown */
/* If we are here, then we hit an infinite loop. Stop. */
panic("EEH: MMIO halt (%d) on device:%s\n", rets[0], pci_name(dev));
+#endif
While I tend to agree that panic() is unnecessary, don't we want a
stack dump unconditionally (i.e. not bracketed in #ifdef DEBUG)?
I'd prefer just removing the code instead of adding #ifdef's in the
middle of this function. eeh.c needs less #ifdef DEBUG, not more :)
This patch changes the EEH_MAX_FAILS action from panic to printing
an error message. Panicking under under this condition is too
harsh.
quoted
/* re-read the slot reset state */
if (read_slot_reset_state(pdn, rets) != 0)
rets[0] = -1; /* reset state unknown */
While I tend to agree that panic() is unnecessary, don't we want a
stack dump unconditionally (i.e. not bracketed in #ifdef DEBUG)?
Probably. This stack trace would reveal a point inside the
inf loop, which can then be analyzed and fixed.
I'd prefer just removing the code instead of adding #ifdef's in the
middle of this function. eeh.c needs less #ifdef DEBUG, not more :)
I didn't know that there was a lot of ifdef DEBUG in there.
Yes, we don't need an ifdef DEBUG for this.
Pending these changes, I'd happily add:
Acked-by: Linas Vepstas <linasvepstas@gmail.com>
--linas
Why can you not msleep within a spinlock? And when was this change
brought in?
Giving up the cpu while holding a spinlock risks locking up the system
in the worst case -- if another task tries to acquire the held lock it
can spin indefinitely.
I guess I am too x86 centric. On the x86 an msleep does not give up the
CPU. It does a busy wait.
So what sleep do you use on the PowerPC when you need a delay for
hardware reasons?
Cheers,
Sean
Correct you are! I didn't even know there was an msleep() so I just
mapped it to mdelay() ;)
I'll have to look at msleep() though, there are places we could use it.
Cheers,
Sean
From: Mike Mason <hidden> Date: 2008-07-21 16:40:48
Here's a repost of the patch with the suggested changes.
This patch changes the EEH_MAX_FAILS action from panic to printing an
error message. Panicking under under this condition is too harsh.
Although performance will be affected and the device may not recover,
the system is still running, which at the very least should allow for a
more graceful shutdown. The patch also removes the msleep() within a
spinlock, which can lead to a deadlock and is not recommended.
Signed-off-by: Mike Mason <redacted>
Acked-by: Linas Vepstas <linasvepstas@gmail.com>
@@ -75,9 +75,9 @@*//* If a device driver keeps reading an MMIO register in an interrupt-*handlerafteraslotisolationeventhasoccurred,weassumeit-*isbrokenandpanic.Thissetsthethresholdforhowmanyread-*attemptsweallowbeforepanicking.+*handlerafteraslotisolationevent,itmightbebroken.+*Thissetsthethresholdforhowmanyreadattemptsweallow+*beforeprintinganerrormessage.*/#define EEH_MAX_FAILS 2100000
@@ -470,6 +470,7 @@ int eeh_dn_check_failure(struct device_nunsignedlongflags;structpci_dn*pdn;intrc=0;+constchar*location;total_mmio_ffs++;
@@ -509,18 +510,15 @@ int eeh_dn_check_failure(struct device_nrc=1;if(pdn->eeh_mode&EEH_MODE_ISOLATED){pdn->eeh_check_count++;-if(pdn->eeh_check_count>=EEH_MAX_FAILS){-printk(KERN_ERR"EEH: Device driver ignored %d bad reads, panicing\n",-pdn->eeh_check_count);+if(pdn->eeh_check_count%EEH_MAX_FAILS==0){+location=of_get_property(dn,"ibm,loc-code",NULL);+printk(KERN_ERR"EEH: %d reads ignored for recovering device at "+"location=%s driver=%s pci addr=%s\n",+pdn->eeh_check_count,location,+dev->driver->name,pci_name(dev));+printk(KERN_ERR"EEH: Might be infinite loop in %s driver\n",+dev->driver->name);dump_stack();-msleep(5000);--/* re-read the slot reset state */-if(read_slot_reset_state(pdn,rets)!=0)-rets[0]=-1;/* reset state unknown */--/* If we are here, then we hit an infinite loop. Stop. */-panic("EEH: MMIO halt (%d) on device:%s\n",rets[0],pci_name(dev));}gotodn_unlock;}