All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auke Kok <auke-jan.h.kok@intel.com>
To: Len Brown <lenb@kernel.org>
Cc: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Ronciak, John" <john.ronciak@intel.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dim@openvz.org
Subject: Re: e1000_intr in request_irq faults in 2.6.20-git
Date: Thu, 15 Feb 2007 21:21:12 -0800	[thread overview]
Message-ID: <45D53F48.9010903@intel.com> (raw)
In-Reply-To: <200702152259.34162.lenb@kernel.org>


[Adding Dimitri Mishin to the CC - he proposed the same patch earlier]

Len Brown wrote:
> On Thursday 15 February 2007 21:10, Brandeburg, Jesse wrote:
>> Eric W. Biederman wrote:
>>> Len Brown <lenb@kernel.org> writes:
>>>
>>>> e1000 faults in 2.6.20-git, while 2.6.20 worked fine.
>>>>
>>>> System is a D875PBZ with LOM.
>>>>
>>>> clues?
>>> I'm guessing this is an old bug found by the following bit of
>>> debug coded added into since v2.6.20
>>>
>>> +#ifdef CONFIG_DEBUG_SHIRQ
>>> +       if (irqflags & IRQF_SHARED) {
>>> +               /*
>>> +                * It's a shared IRQ -- the driver ought to be
>>> prepared for it +                * to happen immediately, so let's
>>> make sure.... +                * We do this before actually
>>> registering it, to make sure that +                * a 'real' IRQ
>>> doesn't run in parallel with our fake +                */
>>> +               if (irqflags & IRQF_DISABLED) {
>>> +                       unsigned long flags;
>>> +
>>> +                       local_irq_save(flags);
>>> +                       handler(irq, dev_id);
>>> +                       local_irq_restore(flags);
>>> +               } else
>>> +                       handler(irq, dev_id);
>>> +       }
>>> +#endif
>>>
>>> I don't have a clue why the e1000 wasn't ready though.
>>>
>> our code is clearly calling request_irq before we have assigned the
>> function pointer adapter->clean_rx as well as adapter->alloc_rx_buf
>>
>> That would be a bug, a possible patch would be (inline and attached):
>> compile tested, *but* I couldn't test this patch to make sure it worked
>> because I couldn't boot 2.6.20-git due to it not finding my RAID0 + lvm
>> disk.
>>
>> [PATCH] e1000: fix shared interrupt warning message
>>
>> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>>
>> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> ---
>>
>>  drivers/net/e1000/e1000_main.c |   13 +++++++------
>>  1 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/e1000/e1000_main.c
>> b/drivers/net/e1000/e1000_main.c
>> index 619c892..b8c4d5c 100644
>> --- a/drivers/net/e1000/e1000_main.c
>> +++ b/drivers/net/e1000/e1000_main.c
>> @@ -1417,10 +1417,6 @@ e1000_open(struct net_device *netdev)
>>         if ((err = e1000_setup_all_rx_resources(adapter)))
>>                 goto err_setup_rx;
>>
>> -       err = e1000_request_irq(adapter);
>> -       if (err)
>> -               goto err_req_irq;
>> -
>>         e1000_power_up_phy(adapter);
>>
>>         if ((err = e1000_up(adapter)))
>> @@ -1431,6 +1427,10 @@ e1000_open(struct net_device *netdev)
>>                 e1000_update_mng_vlan(adapter);
>>         }
>>
>> +       err = e1000_request_irq(adapter);
>> +       if (err)
>> +               goto err_req_irq;
>> +
>>         /* If AMT is enabled, let the firmware know that the network
>>          * interface is now open */
>>         if (adapter->hw.mac_type == e1000_82573 &&
>> @@ -1439,10 +1439,11 @@ e1000_open(struct net_device *netdev)
>>
>>         return E1000_SUCCESS;
>>
>> +err_req_irq:
>> +       e1000_down(adapter);
>> +       e1000_free_irq(adapter);
>>  err_up:
>>         e1000_power_down_phy(adapter);
>> -       e1000_free_irq(adapter);
>> -err_req_irq:
>>         e1000_free_all_rx_resources(adapter);
>>  err_setup_rx:
>>         e1000_free_all_tx_resources(adapter);
>>
> 
> Works for me(tm) on latest 2.6.20-git and D875PBZ.


If there are no objections I'll push this patch to Jeff Garzik together with two 
other changes I have for him.

Cheers,

Auke

  reply	other threads:[~2007-02-16  5:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-15 22:28 e1000_intr in request_irq faults in 2.6.20-git Len Brown
2007-02-15 22:50 ` Eric W. Biederman
2007-02-16  2:10   ` Brandeburg, Jesse
2007-02-16  3:59     ` Len Brown
2007-02-16  5:21       ` Auke Kok [this message]
2007-02-16  6:01     ` Andrew Morton
2007-02-16  6:25       ` Auke Kok

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=45D53F48.9010903@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=dim@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.