"Hen, Shmulik" wrote:
>
> OK guys, you were right. The bug was in our code - sorry for trouble.
> Turns out that while I was away, the problem was solved by someone else. The
> problem is probably related to the fact that when we did
> 'spin_lock_irqsave(c,d)', 'd' was a global variable. The fix
TED]]
Sent: Wednesday, March 07, 2001 2:54 PM
To: Hen, Shmulik
Cc: 'LKML'
Subject: Re: spinlock help
"Hen, Shmulik" wrote:
>
> The kdb trace was accurate, we could actually see the e100 ISR pop from no
> where right in the middle of our ans_notify every time the TX que
rom: Hen, Shmulik [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 12:47 PM
To: 'Ofer Fryman'; Hen, Shmulik
Cc: [EMAIL PROTECTED]
Subject: RE: spinlock help
e100 implements all sorts of hooks for our intermediate driver (kind of a
co-development effort), so eepro100 is out of
> spin_lock_bh() won't block interrupts and we need them blocked to prevent
> more indications.
> spin_lock_irq() could do the trick but it's counterpart spin_unlock_irq()
> enables all interrupts by calling sti(), and this is even worse for us.
Why dont you queue your indications then. The eepro
"Hen, Shmulik" wrote:
>
> The kdb trace was accurate, we could actually see the e100 ISR pop from no
> where right in the middle of our ans_notify every time the TX queue would
> fill up. When we commented out the call to spin_*_irqsave(), it worked fine
> under heavy stress for days.
>
> Is it
PM
To: Hen, Shmulik
Subject: Re: spinlock help
"Hen, Shmulik" wrote:
>
> How about if the same sequence occurred, but from two different drivers ?
>
> We've had some bad experience with this stuff. Our driver, which acts as
an
> intermediate net driver, would call t
rom: Manoj Sontakke [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 12:27 PM
To: Hen, Shmulik
Cc: '[EMAIL PROTECTED]'; Manoj Sontakke; [EMAIL PROTECTED]
Subject: Re: spinlock help
hi
spin_lock_irq() andspin_lock_bh()
can they be of any use to u?
"Hen, Shmulik&
k'
Cc: [EMAIL PROTECTED]
Subject: RE: spinlock help
Did you try looking at Becker eepro100 driver it seems to be simple, no
unnecessary spin_lock_irqsave?.
-Original Message-
From: Hen, Shmulik [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 11:21 AM
To: '[EMAIL PRO
ced Networking Services
> Intel Network Communications Group
> Jerusalem, Israel.
>
> -Original Message-
> From: Nigel Gamble [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 07, 2001 1:54 AM
> To: Manoj Sontakke
> Cc: [EMAIL PROTECTED]
> Subject: Re:
ubject: RE: spinlock help
How about if the same sequence occurred, but from two different drivers ?
We've had some bad experience with this stuff. Our driver, which acts as an
intermediate net driver, would call the hard_start_xmit in the base driver.
The base driver, wanting to block receive i
-Original Message-
From: Nigel Gamble [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 1:54 AM
To: Manoj Sontakke
Cc: [EMAIL PROTECTED]
Subject: Re: spinlock help
On Tue, 6 Mar 2001, Manoj Sontakke wrote:
> 1. when spin_lock_irqsave() function is called the subsequent code is
> e
On Tue, 6 Mar 2001, Manoj Sontakke wrote:
> 1. when spin_lock_irqsave() function is called the subsequent code is
> executed untill spin_unloc_irqrestore()is called. is this right?
Yes. The protected code will not be interrupted, or simultaneously
executed by another CPU.
> 2. is this sequence
Hi
Thankx in idvance for the help.
1. when spin_lock_irqsave() function is called the subsequent code is
executed untill spin_unloc_irqrestore()is called. is this right?
2. is this sequence valid?
spin_lock_irqsave(a,b);
spin_lock_irqsave(c,d);
Manoj
-
To unsubscribe from this l
13 matches
Mail list logo
