From: Kenzo Iwami <k-iwami@cj.jp.nec.com>
To: Auke Kok <auke-jan.h.kok@intel.com>
Cc: Shaw Vrana <shaw@vranix.com>,
netdev@vger.kernel.org,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
"Ronciak, John" <john.ronciak@intel.com>
Subject: Re: watchdog timeout panic in e1000 driver
Date: Thu, 16 Nov 2006 18:23:10 +0900 [thread overview]
Message-ID: <455C2DFE.3050907@cj.jp.nec.com> (raw)
In-Reply-To: <455B3C3B.2070308@intel.com>
Hi,
Thank you for your comment.
>>> I think this problem occurs because interrupt handler is executed in same
>>> CPU as process that acquires semaphore.
>>> How about disabling interrupt while the process is holding the semaphore?
>>> I think this is possible, if the total lock time has been reduced.
>> I created the attached patch based on the method described above.
>> This patch disables interrupt while the process is holding the semaphore.
[...]
> I'm not sure why you would have to disable interrupts when freeing the semaphore, but
> more importantly I don't want to introduce irq code in the swfw handling functions.
>
> Since the major (only) user running this piece of code in intterupt context is the
> watchdog, we might as well see if we can only disable interrupts for that code path,
> which would only be once per 2 seconds. We don't need to protect the ethtool path into
> this code as it doesn't run in irq context.
>
> Would you mind giving attached patch a try and let me know if it works for you? It will
> disable irqs for a bit longer time than your patch, and it begs for a special
> check-link-in-watchdog function that doesn't take so damn long :(
I tried your patch, but the system panicked with the same symptom.
This problem occurs because e1000_watchdog is called from the interrupt
handler while ethtool processing is holding the semaphore.
ethtool processing holding semaphore
INTERRUPT
e1000_watchdog waits for semaphore to be released
The semaphore e1000_watchdog is waiting for can only be released when
ethtool resumes from interrupt after e1000_watchdog finishes (basically
a deadlock)
In order to solve this problem, interrupts has to be disabled on the
interrupted side (during ethtool processing) and not during
e1000_watchdog within the interrupt handler.
e1000_get_hw_eeprom_semaphore is called from both the interrupt level
and the normal level, and needs to be protected by irq code. The reason
the patch disables interrupts when freeing the semaphore is because
e1000_swfw_sync_release also calls e1000_get_hw_eeprom_semaphore.
--
Kenzo Iwami (k-iwami@cj.jp.nec.com)
next prev parent reply other threads:[~2006-11-16 9:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 10:19 watchdog timeout panic in e1000 driver Kenzo Iwami
2006-10-19 15:39 ` Auke Kok
[not found] ` <4538BFF2.2040207@cj.jp.nec.com>
2006-10-20 15:51 ` Auke Kok
2006-10-24 9:01 ` Kenzo Iwami
2006-10-24 16:15 ` Auke Kok
2006-10-25 13:41 ` Kenzo Iwami
2006-10-25 15:09 ` Auke Kok
2006-10-26 10:35 ` Kenzo Iwami
2006-10-26 14:34 ` Auke Kok
2006-10-30 11:36 ` Kenzo Iwami
2006-10-30 17:30 ` Auke Kok
2006-10-31 3:22 ` Shaw Vrana
2006-11-01 13:21 ` Kenzo Iwami
2006-11-15 10:33 ` Kenzo Iwami
2006-11-15 16:11 ` Auke Kok
2006-11-16 9:23 ` Kenzo Iwami [this message]
2007-02-20 9:26 ` Kenzo Iwami
2007-02-20 16:10 ` Auke Kok
2007-02-21 5:17 ` Kenzo Iwami
-- strict thread matches above, loose matches on Subject: below --
2006-11-16 17:20 Brandeburg, Jesse
2006-11-21 10:16 ` Kenzo Iwami
2006-12-04 9:14 ` Kenzo Iwami
2006-12-05 0:46 ` Auke Kok
2006-12-12 7:58 ` Kenzo Iwami
2006-12-19 0:13 ` Kenzo Iwami
2007-01-15 9:12 ` Kenzo Iwami
2007-01-15 16:14 ` Auke Kok
2007-01-16 8:42 ` Kenzo Iwami
2007-01-18 9:22 ` Kenzo Iwami
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=455C2DFE.3050907@cj.jp.nec.com \
--to=k-iwami@cj.jp.nec.com \
--cc=auke-jan.h.kok@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=netdev@vger.kernel.org \
--cc=shaw@vranix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).