headers
Larry Finger | 1 Apr 2009 01:01
Favicon

Re: [PATCH 1/2 V2] kaweth: Fix locking to be SMP-safe

Oliver Neukum wrote:
> Am Dienstag 31 März 2009 20:45:49 schrieb Larry Finger:
>> On an SMP system, the following message is printed. The patch below gets
>> fixes the problem.
> 
> Are you sure it is never called with disabled interrupts?

I think not, but all I really know is that the change from spin_lock() to
spin_lock_irq() makes the errors go away.

I checked a number of drivers to see what their ndo_start_xmit routines do. Most
use spin_lock_irq(), but some do no locking.

I tried removing the locking, but that resulted in a stall even when I bypassed
the faulty router.

Larry
Permalink | Reply | 0 comments |
headers
Oliver Neukum | 1 Apr 2009 01:06

Re: [PATCH 1/2 V2] kaweth: Fix locking to be SMP-safe

Am Mittwoch 01 April 2009 00:10:28 schrieb David Miller:
> > Here you enable interrupts. Are you sure ndo_start_xmit is never
> > called with interrupts disabled?
>
> It must never be invoked that way, this would break so many
> drivers.
>
> On the other hand, all of these driver paths never execute
> in a real hardware interrupt context, the deepest it gets
> into is software interrupts.  So spin_*lock*_bh() might be
> more appropriate.

Thanks. The patch is good. I'll check the other USB network
drivers.

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Andy Grover | 1 Apr 2009 01:58
Picon
Favicon

Re: [PATCH] rds: only for x86 or 64-bit at the moment...

David Miller wrote:
> From: Kyle McMartin <kyle <at> mcmartin.ca>
> Date: Tue, 31 Mar 2009 17:06:09 -0400
> 
>> From: Kyle McMartin <kyle <at> redhat.com>
>>
>> set_64bit doesn't exist anywhere but x86 right now, so either
>> BITS_PER_LONG needs to be 64, or we need to be on x86, in order to
>> build this module.
>>
>> Signed-off-by: Kyle McMartin <kyle <at> redhat.com>
> 
> I would prefer the RDS folks simply fix this properly.

Ok... I'll redo the latest rds patchseries with crit fixes only and a
fix for this.

Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
David Miller | 1 Apr 2009 01:59
Favicon

Re: [PATCH] rds: only for x86 or 64-bit at the moment...

From: Andy Grover <andy.grover <at> oracle.com>
Date: Tue, 31 Mar 2009 16:58:46 -0700

> David Miller wrote:
> > From: Kyle McMartin <kyle <at> mcmartin.ca>
> > Date: Tue, 31 Mar 2009 17:06:09 -0400
> > 
> >> From: Kyle McMartin <kyle <at> redhat.com>
> >>
> >> set_64bit doesn't exist anywhere but x86 right now, so either
> >> BITS_PER_LONG needs to be 64, or we need to be on x86, in order to
> >> build this module.
> >>
> >> Signed-off-by: Kyle McMartin <kyle <at> redhat.com>
> > 
> > I would prefer the RDS folks simply fix this properly.
> 
> Ok... I'll redo the latest rds patchseries with crit fixes only and a
> fix for this.

Thanks a lot Andy.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Divy Le Ray | 1 Apr 2009 02:58
Favicon

[PATCH 2.6.30] cxgb3: clear shadow BAR registers

From: Divy Le Ray <divy <at> chelsio.com>

Ensure that internal shadow BAR registers are cleared on 32-bit platforms.

Signed-off-by: Divy Le Ray <divy <at> chelsio.com>
---

 drivers/net/cxgb3/cxgb3_main.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 2c2aaa7..3f22da4 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
 <at>  <at>  -2984,6 +2984,20  <at>  <at>  static void __devinit print_port_info(struct adapter *adap,
 	}
 }

+static void touch_bars(struct pci_dev *pdev)
+{
+#if BITS_PER_LONG < 64
+	u32 v;
+
+	pci_config_dword(pdev, PCI_BASE_ADDRESS_1, &v);
+	pci_write_config_dword(pdev, PCI_BASE_ADDRESS_1, v);
+	pci_read_config_dword(pdev, PCI_BASE_ADDRESS_3, &v);
+	pci_write_config_dword(pdev, PCI_BASE_ADDRESS_3, v);
+	pci_read_config_dword(pdev, PCI_BASE_ADDRESS_5, &v);
+	pci_write_config_dword(pdev, PCI_BASE_ADDRESS_5, v);
+#endif
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Likely | 1 Apr 2009 03:45
Picon

Re: [PATCH 00/14] Add common OF device tree support for MDIO busses

On Tue, Mar 31, 2009 at 4:22 PM, David Miller <davem <at> davemloft.net> wrote:
> From: Grant Likely <grant.likely <at> secretlab.ca>
> Date: Tue, 31 Mar 2009 16:19:42 -0600
>
>> On Tue, Mar 31, 2009 at 3:57 PM, David Miller <davem <at> davemloft.net> wrote:
>> > It therefore didn't get any -next exposure, so it's unreasonable to
>> > merge this stuff now.
>>
>> Since when has sitting in a -next tree been a requirement for merging
>> when the series has been kept up to date and tested?  I purposefully
>> kept it out of -next to ensure that when it was applied for real to a
>> -next tree it would be as complete, bug free, and bisectable as
>> possible since once it hits a signed-off -next branch the individual
>> commit cannot be modified.
>
> I know your pissed off, but take a deep breath and consider this
> from my position.
>
> If I don't put a line in the sand somewhere, everyone can say
> "I've been working so hard, I posted it to the lists a thousand
> times, I have tons of testers" and I have to put the change in.
>
> That doesn't work, so please wait until the next release to get
> your changes in.  And get them into a tree that gets exposure
> in linux-next.  Then you have nothing to worry about.

Dammit.  Why did you have to go and sound so reasonable when I was all
geared up for a pointless flame war.

well... alright... but I reserve the right to be grumpy and surly for
(Continue reading)

Permalink | Reply | 11 comments |
headers
Ramkrishna Vepa | 1 Apr 2009 04:38
Favicon

RE: [ANNOUNCE] New driver vxge for Neterion's X3100 series 10 GbEPCIe adapter

> For the most part I think the bit you would be interested in is the
> "sysfs" patch, http://patchwork.kernel.org/patch/8066/, which is what
I
> had used in the original implementation to enable the VFs.  I am going
> to push this to a module parameter similar to your max_config_dev.
The
> rest of the patches handle PF to VF communications and configuration
> which it sounds like is handled via firmware for your adapter.
[Ram]Currently, the messaging interface is not part of this driver
submission and each function driver is independent of the other - there
are no dependencies between the PF and the VF driver.

> Most of the changes you would probably need to make would be in
> vxge_probe/vxge_remove.  All you would end up needing to do is call
> pci_enable_sriov(pdev, max_config_dev - 1) on your physical function
> devices and then you would end up getting exactly as many VFs as you
> need.  The call should be safe since I am assuming your VFs don't
> implement their own SR-IOV capability structures.  The cleanup would
be
> pretty strait forward as well since you would just need to call
> pci_disable_sriov in remove.
[Ram] When the device indicates that it is SRIOV capable in the pci
config space, why not create the VF pci config spaces as part of the
enumeration process? This way, there would be no change required for the
network drivers. 

Ram
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 7 comments |
headers
Yu Zhao | 1 Apr 2009 04:53
Picon
Favicon

Re: [ANNOUNCE] New driver vxge for Neterion's X3100 series 10 GbEPCIe adapter

On Wed, Apr 01, 2009 at 10:38:07AM +0800, Ramkrishna Vepa wrote:
> > For the most part I think the bit you would be interested in is the
> > "sysfs" patch, http://patchwork.kernel.org/patch/8066/, which is what
> I
> > had used in the original implementation to enable the VFs.  I am going
> > to push this to a module parameter similar to your max_config_dev.
> The
> > rest of the patches handle PF to VF communications and configuration
> > which it sounds like is handled via firmware for your adapter.
> [Ram]Currently, the messaging interface is not part of this driver
> submission and each function driver is independent of the other - there
> are no dependencies between the PF and the VF driver.
> 
> > Most of the changes you would probably need to make would be in
> > vxge_probe/vxge_remove.  All you would end up needing to do is call
> > pci_enable_sriov(pdev, max_config_dev - 1) on your physical function
> > devices and then you would end up getting exactly as many VFs as you
> > need.  The call should be safe since I am assuming your VFs don't
> > implement their own SR-IOV capability structures.  The cleanup would
> be
> > pretty strait forward as well since you would just need to call
> > pci_disable_sriov in remove.
> [Ram] When the device indicates that it is SRIOV capable in the pci
> config space, why not create the VF pci config spaces as part of the
> enumeration process? This way, there would be no change required for the
> network drivers. 

Yes, and that's what the PCI subsystem does. If the vxge VF is identical
to its PF, then vxge should be able to drive both PF and VF without any
modification.
(Continue reading)

Permalink | Reply | 6 comments |
headers
David Miller | 1 Apr 2009 05:34
Favicon

Re: [PATCH 2.6.30] cxgb3: clear shadow BAR registers

From: Divy Le Ray <divy <at> chelsio.com>
Date: Tue, 31 Mar 2009 17:58:54 -0700

> From: Divy Le Ray <divy <at> chelsio.com>
> 
> Ensure that internal shadow BAR registers are cleared on 32-bit platforms.
> 
> Signed-off-by: Divy Le Ray <divy <at> chelsio.com>

Why is this a problem and why is it not possible to rely
on these being setup to zero by either the BIOS or the PCI
layer?

At best this is a PCI quirk and not something that belongs
in the driver.

I'm not applying this.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ramkrishna Vepa | 1 Apr 2009 05:36
Favicon

RE: [ANNOUNCE] New driver vxge for Neterion's X3100 series 10GbEPCIe adapter

> Yes, and that's what the PCI subsystem does. If the vxge VF is
identical
> to its PF, then vxge should be able to drive both PF and VF without
any
> modification.
[Ram] Ok. In that case, is the call to pci_enable/disable_sriov still
required for vxge?

Ram
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |

Gmane