On Jun 30, 2007, at 12:42:06, Jeff Garzik wrote:
Definitely matters. Switch renegotiation can take a while, and you
must take into account the common case of interface bouncing
(immediate down, then up).
Hoards actively complained the few times we experimented with this,
because of e.g. D
Dhananjay Phadke wrote:
This stage is safe to bail out on signal. It's initializing about a
hundred registers
and trying to guaranty by retrying, so can get stretched too much on
faulty h/w.
This implies that you have -add- code to check for and handle signals at
each delay point. Don't both
These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state.
Signed-off-by: Dhananjay Phadke <[EMAIL PROTECTED]>
Signed-off-by: Milan Bag <[EMAIL PROTECTED]>
Signed-off-by
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off by: Dhananjay Phadke <[EMAIL PROTECTED]>
Signed-off by: Milan Bag <[EM
Resending with changes suggested.
--
Dhananjay Phadke
NetXen Inc.
drivers/net/netxen/netxen_nic.h | 177 +++---
drivers/net/netxen/netxen_nic_hdr.h |2 +
drivers/net/netxen/netxen_nic_hw.c | 39 +--
drivers/net/netxen/netxen_nic_init.c
NetXen driver uses PCI function 0 to provide the functionality of MSI.
The patch makes driver check the bus master bit for function 0 and
enable it after the card initialization.
Signed-off-by: Dhananjay Phadke<[EMAIL PROTECTED]>
Signed-off-by: Milan Bag <[EMAIL PROTECTED]>
Signed-off-by: Wen Xion
This stage is safe to bail out on signal. It's initializing about a
hundred registers
and trying to guaranty by retrying, so can get stretched too much on faulty h/w.
-Dhananjay
On 7/1/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
While strictly this is true, I strongly urge the use of
non-interru
On Sun, Jul 01, 2007 at 12:24:40AM +0200, Michael Buesch wrote:
> > > Hm, I was going to measure the real power advantage with a
> > > PCI-extender card. But my B44B0 card doesn't seem to work in
> > > that extender card. It works perfectly fine sticked directly into
> > > the motherboard, though,
Michael Buesch wrote:
On Saturday 30 June 2007 22:38:47 [EMAIL PROTECTED] wrote:
These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state.
Signed-off-by: Dhananjay
On Sunday 01 July 2007 00:03:01 Lennert Buytenhek wrote:
> On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote:
>
> > > When the interface is down (or driver removed), the BroadCom 44xx card
> > > remains
> > > powered on, and both its MAC and PHY is using up power.
> > > This patch ma
On Saturday 30 June 2007 22:38:47 [EMAIL PROTECTED] wrote:
> These changes allow driver close routine to be called during module unload,
> to clean-up buffers and other software resources, flush queues etc. Also,
> hardware is reset to pristine state.
>
> Signed-off-by: Dhananjay Phadke <[EMAIL P
On Saturday 30 June 2007 22:38:46 [EMAIL PROTECTED] wrote:
> This patch updates the various access routines to access different
> control and status settings present in different register locations.
> This will fix problems related to working of different ports in
> multi Port card.
>
> Signed-off
On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote:
> > When the interface is down (or driver removed), the BroadCom 44xx card
> > remains
> > powered on, and both its MAC and PHY is using up power.
> > This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
> > is h
On Saturday 30 June 2007 13:47:35 Török Edvin wrote:
> When the interface is down (or driver removed), the BroadCom 44xx card remains
> powered on, and both its MAC and PHY is using up power.
> This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
> is halted, and does a partial
Hi Auke,
On Fri, 2007-06-29 at 12:51 -0700, Kok, Auke wrote:
> Jason Lunz wrote:
> > On Fri, Jun 29, 2007 at 06:29:18PM +0100, Mark McLoughlin wrote:
> >>I understand there is some delay in getting e1000-7.5.5 into the
> >> upstream kernel given the major re-working of the chipset specific
> >
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off by: Dhananjay Phadke <[EMAIL PROTECTED]>
Signed-off by: Milan Bag <[EM
These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state.
Signed-off-by: Dhananjay Phadke <[EMAIL PROTECTED]>
Signed-off-by: Milan Bag <[EMAIL PROTECTED]>
Signed-off-by
Sending reworked patches based on Michael's feedback (originally sent
by Mithlesh Thukral). These patches address interrupt mask issues on
multiport adapters, as well as stability issues on powerpc blades.
--
Dhananjay Phadke
NetXen Inc.
drivers/net/netxen/netxen_nic.h | 176
NetXen driver uses PCI function 0 to provide the functionality of MSI.
The patch makes driver check the bus master bit for function 0 and
enable it after the card initialization.
Signed-off-by: Dhananjay Phadke<[EMAIL PROTECTED]>
Signed-off-by: Milan Bag <[EMAIL PROTECTED]>
Signed-off-by: Wen Xion
Fixup dm9601_bind() so it returns 0 on success rather than just a positive
number, as otherwise usbnet doesn't init the status handler.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
drivers/net/usb/dm9601.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux-2.
Patrick McHardy wrote:
While adding support for secondary unicast addresses to 8021q and
macvlan, I've tried keeping dev->dev_addr as global address on
dev->uc_list and have drivers skip them to avoid having all
dev_unicast_add users implement a state machine like this:
[...]
Something that is
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sat, 30 Jun 2007 18:46:29 +0200
> Fix a bug introduced by the secondary unicast address patches.
Applied, thanks Patrick.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordom
From: jamal <[EMAIL PROTECTED]>
Date: Sat, 30 Jun 2007 10:52:44 -0400
> On Fri, 2007-29-06 at 21:35 -0700, David Miller wrote:
>
> > Awesome, but let's concentrate on the client since I can actually
> > implement and test anything we come up with :-)
>
> Ok, you need to clear one premise for me
There's change of guard from NetXen side. I have reworked Mithlesh's
original patches based on Michael's feedback. Will be sending out shortly.
--
Dhananjay Phadke
NetXen Inc.
On 6/22/07, Mithlesh Thukral <[EMAIL PROTECTED]> wrote:
Hi All,
I will be sending updates for NetXen NIC 1/10 G Ethern
Francois Romieu <[EMAIL PROTECTED]> :
[...]
> The patch will not apply directly against 2.6.21.5. Is it an option for
> you to try 2.6.22-rc6 or are you stuck with 2.6.21.5 ?
If you feel adventurous, you will find a compile-tested-only patchkit for
2.6.21.5 here:
http://www.fr.zoreil.com/linux/ker
While adding support for secondary unicast addresses to 8021q and
macvlan, I've tried keeping dev->dev_addr as global address on
dev->uc_list and have drivers skip them to avoid having all
dev_unicast_add users implement a state machine like this:
open(struct net_device *dev)
{
struct net_dev
On Sat, 30 Jun 2007, Jeff Garzik wrote:
> Like SATA, we actually want to support BOTH -- active hotplug and PHY
> power-down -- and so this wanders into power management policy.
>
> Give me a knob, and we can program plenty of ethernet|SATA|USB|... drivers
> to power down the PHY and save power.
On Sat, 30 Jun 2007 12:42:06 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > Matthew Garrett wrote:
> >> Do you still get link beat detection when the phy is powered down?
>
> > does that matter?
> > If the interface is down, nic drivers aren't expected to detect link..
Fix a bug introduced by the secondary unicast address patches.
[NET]: Fix secondary unicast/multicast address count maintenance
When a reference to an existing address is increased or decreased without
hitting zero, the address count is incorrectly adjusted.
Signed-off-by: Patrick McHardy <[E
Arjan van de Ven wrote:
Matthew Garrett wrote:
Do you still get link beat detection when the phy is powered down?
does that matter?
If the interface is down, nic drivers aren't expected to detect link...
if userspace wants to find link status it should have the interface up.
Definitely ma
James Chapman wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Can knowledgeable people characterize the PCIe adapters somehow? Is
that "ICH8-era and later", or does it go back further than that?
ich8 and 9 are consistent with 82571/2/3 - on-board nic's based on the
82571 design with different PHY'
On Sat, Jun 30, 2007 at 04:19:23PM +0100, Matthew Garrett wrote:
> I'd agree that there's a need for a state where we power down as much as
> possible (even at the cost of functionality), but where possible it
> would also be nice to offer a state where the mac is powered down and
> the phy lef
On Fri, 2007-29-06 at 16:56 +0200, Johannes Berg wrote:
> +static void genl_unregister_mc_group(struct genl_multicast_group *grp)
> +{
> + /*
> + * TODO: fix multicast group re-use by clearing the bit
> + * for this group in all genetlink sockets.
> + */
> + clear_bit
On Sat, Jun 30, 2007 at 07:44:59AM -0700, Arjan van de Ven wrote:
> Matthew Garrett wrote:
> >Do you still get link beat detection when the phy is powered down?
> >
> does that matter?
> If the interface is down, nic drivers aren't expected to detect
> link... if userspace wants to find link statu
On Fri, 2007-29-06 at 21:35 -0700, David Miller wrote:
> Awesome, but let's concentrate on the client since I can actually
> implement and test anything we come up with :-)
Ok, you need to clear one premise for me then ;->
You said the model is for the guest/client to hook have a port to the
host
Matthew Garrett wrote:
On Sat, Jun 30, 2007 at 02:47:35PM +0300, Török Edvin wrote:
When the interface is down (or driver removed), the BroadCom 44xx card
remains
powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is
On Sat, 2007-06-30 at 05:47 -0400, Jeff Garzik wrote:
> Francois Romieu wrote:
> > Jeff Garzik <[EMAIL PROTECTED]> :
> >> Arjan van de Ven wrote:
> +pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
> >>> can you create a pci_set_latency_timer() for this please?
> > [...]
>
[ Trimmed Cc: list ]
On 6/30/07, Steve French <[EMAIL PROTECTED]> wrote:
The reason that cifs switched from wait_for_completion to the kthread
call to cifs_demultiplex_thread in the first place is because without
use of kthread it won't work with a linux-vserver. See the thread:
http://marc.i
> It would be great if we could finally get a working e1000
> multiqueue patch so work in this area can actually be tested.
I'm actively working on this right now. I'm on vacation next week, but
hopefully I can get something working before I leave OLS and post it.
-PJ
-
To unsubscribe from this
David Miller wrote:
> Now I get to pose a problem for everyone, prove to me how useful
> this new code is by showing me how it can be used to solve a
> reocurring problem in virtualized network drivers of which I've
> had to code one up recently, see my most recent blog entry at:
>
> http://
Kok, Auke wrote:
Jeff Garzik wrote:
Can knowledgeable people characterize the PCIe adapters somehow? Is
that "ICH8-era and later", or does it go back further than that?
ich8 and 9 are consistent with 82571/2/3 - on-board nic's based on the
82571 design with different PHY's, and added feature
Peter Missel <[EMAIL PROTECTED]> :
[...]
> It is now on 2.6.21.5 as downloaded from www.kernel.org, built for AMD64.
> Unfortunately, the problem is not gone. After suspend-to-disk and resume,
> link speed is 100. Unplugging and replugging the cable does not help.
> Unloading and reloading the
The reason that cifs switched from wait_for_completion to the kthread
call to cifs_demultiplex_thread in the first place is because without
use of kthread it won't work with a linux-vserver. See the thread:
http://marc.info/?l=linux-cifs-client&m=117552761703381&w=2
If we take out the kthread
Hello Francois!
I have finally gotten round to updating the kernel on this workstation.
It is now on 2.6.21.5 as downloaded from www.kernel.org, built for AMD64.
Unfortunately, the problem is not gone. After suspend-to-disk and resume, link
speed is 100. Unplugging and replugging the cable does
On Sat, Jun 30, 2007 at 02:47:35PM +0300, Török Edvin wrote:
> When the interface is down (or driver removed), the BroadCom 44xx card
> remains
> powered on, and both its MAC and PHY is using up power.
> This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
> is halted, and doe
When the interface is down (or driver removed), the BroadCom 44xx card remains
powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is halted, and does a partial chip reset turns off the activity LEDs too.
Applies to 2.6
On Sat, 30 Jun 2007 09:42:09 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 25, 2007 at 05:25:00PM -0500, Steve French wrote:
> > Jeff,
> > Not seeing any objections to your revised approach (to not allowing
> > signals for cifsd kernel thread), I just merged something similar to
Francois Romieu wrote:
Jeff Garzik <[EMAIL PROTECTED]> :
Arjan van de Ven wrote:
+ pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
can you create a pci_set_latency_timer() for this please?
[...]
+ if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
+ pci_write_config_byte(t
Jeff Garzik <[EMAIL PROTECTED]> :
> Arjan van de Ven wrote:
> >>+ pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
> >
> >can you create a pci_set_latency_timer() for this please?
[...]
> >>+ if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
> >>+ pci_write_config_byte(tp->pci_d
On Jun 29, 2007, at 6:06 AM, Jeff Garzik wrote:
Kumar Gala wrote:
Please pull from 'for_linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
for_linus
to receive the following updates:
drivers/net/gianfar.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Mon, Jun 25, 2007 at 05:25:00PM -0500, Steve French wrote:
> Jeff,
> Not seeing any objections to your revised approach (to not allowing
> signals for cifsd kernel thread), I just merged something similar to
> your patch to the cifs-2.6.git tree (also fixed some nearby lines that
> went past 80
On Fri, Jun 29, 2007 at 04:57:46PM -0700, Andrew Grover wrote:
> When I was at Intel, I heard a lot of "the linux community won't let
> us split the driver". "Oh well, guess we gotta keep lugging around all
> the old crap." So it was a (perhaps misunderstood) desire to make you
> guys happy that le
On Fri, Jun 29, 2007 at 07:31:55PM -0700, Kok, Auke wrote:
> all the pci-express adapters that are supported are extremely similar:
>
> - they all support 2 queues
> - the register sets are (almost entirely) identical
> - there is minimal feature variance between 82571/2/3, esb2lan, ich8/9
>
> Th
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
DM> And some people still use hubs, believe it or not.
Hubs are 100Mbps at most. You could of course make a flooding Gbps
switch, but it would be rather silly. If you care about multicast
performance, you get a switch with IGMP snooping.
/B
54 matches
Mail list logo
