I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
I'm assuming the table is a power of 2 in size with open chaining
for collisions. When the chains get too long, the table is doubled.
When the chains get too
Hello:
I am a new subscriber to netdev. Hope my first post is properly done.
I have a question about the quota per poll in NAPI. Any idea how the
quota of 64 packets per poll per NIC was selected? Why 64, not any
other number? Is there science behind this number.
And the same goes for the bu
"Adam Kropelin" <[EMAIL PROTECTED]> writes:
> Naive question... Can the pci layer (or e1000) detect that MSI is not enabled
> in
> the hardware and avoid using it in that case? With the number of MSI problems
> showing up it seems risky to assume it's usable on any given platform without
> some s
Eric W. Biederman wrote:
"Adam Kropelin" <[EMAIL PROTECTED]> writes:
Can I get the corresponding lspci -xxx output. I suspect the BIOS
did not program the hypertransport MSI mapping capabilities
correctly. All it has to do is set the enable but still,
occasionally BIOS writers miss the most am
> We need to use different auto-neg initial settings between
> for 10/100Mbps ethernet switches and for Gbps ethernet switches.
That is strange ! What PHY chip are you using ? Are you sure it's not
just you not properly configuring the PHY ? Is the datasheet for the PHY
available somewhere ?
> D
From: Jay Cliburn <[EMAIL PROTECTED]>
pci_ids: add Attansic vendor id
Add Attansic to pci_ids and use the ID in the driver.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |2 +-
include/linux/pci_ids.h |2 ++
2 files changed, 3 insertions(+), 1 del
From: Jay Cliburn <[EMAIL PROTECTED]>
MAINTAINERS: add atl1 maintainers
Add a maintainers entry for atl1.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
MAINTAINERS | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 465e083..8
From: Jay Cliburn <[EMAIL PROTECTED]>
atl1: fix whitespace damage
Remove trailing whitespace and spaces preceding tabs.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1.h |8 +-
drivers/net/atl1/atl1_ethtool.c | 42 ++--
drivers/net/atl1/atl1_hw.h
This set of patches completes the final bit of tidying up in the Attansic
ethernet driver. Sorry for nickel-and-diming you, Jeff, but this really
should be the end of it for awhile.
Summary:
1. Clean up whitespace damage.
2. Add a maintainers entry.
3. Add a pci_ids entry.
---
MAINTAINERS
"Adam Kropelin" <[EMAIL PROTECTED]> writes:
>> Can I get the corresponding lspci -xxx output. I suspect the BIOS
>> did not program the hypertransport MSI mapping capabilities correctly.
>> All it has to do is set the enable but still, occasionally BIOS
>> writers miss the most amazing things.
>
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
maybe I've been unclear, but here's how e1000 detects link changes:
1) by checking every 2 seconds in the watchdog by reading PHY
registers 2) by receiving an interrupt from the NIC with the LSI bit
in the interrupt control register
Hi Arnd,
On Sat, Jan 27, 2007 at 02:53:07AM +0100, Arnd Bergmann wrote:
> On Tuesday 16 January 2007 19:55, Marcelo Tosatti wrote:
> >
> > Announcing an updated patch of the Marvell Libertas 8388 802.11 USB
> > driver.
> >
> > Diff can be found at
> > http://dev.laptop.org/~marcelo/libertas-838
Hi Stephen,
On Fri, Feb 02, 2007 at 03:34:25PM -0800, Stephen Hemminger wrote:
> Turn flow control off for sky2. When flow control is on, the transmitter
> may get randomly stuck. Perhaps there is hardware problem, but until
> Marvell provides errata information for workaround, it should default t
Auke Kok <[EMAIL PROTECTED]> writes:
> that's explained by a driver change that did that. Since at initialization
> we're
> basically waiting for a link change to tell the stack that we're up, we
> decided
> to change the order to have the hardware fire an LSI interrupt to trigger a
> watchdog r
Adam Kropelin wrote:
Auke Kok wrote:
Adam Kropelin wrote:
I've never had this device work 100% with MSI on any kernel version
I've tested so far. But I'm not the original reporter of the
problem, and I believe for him it was a true regression where a
previous kernel wored correctly.
maybe I've
Auke Kok <[EMAIL PROTECTED]> writes:
> maybe I've been unclear, but here's how e1000 detects link changes:
>
> 1) by checking every 2 seconds in the watchdog by reading PHY registers
> 2) by receiving an interrupt from the NIC with the LSI bit in the interrupt
> control register
>
> if the link is
Auke Kok wrote:
Adam Kropelin wrote:
I've never had this device work 100% with MSI on any kernel version
I've tested so far. But I'm not the original reporter of the
problem, and I believe for him it was a true regression where a
previous kernel wored correctly.
maybe I've been unclear, but he
Adam Kropelin wrote:
> Eric W. Biederman wrote:
>> Auke Kok <[EMAIL PROTECTED]> writes:
>>> None of the MSI code in e1000 has changed significantly either. as
>>> far as I can see, the msi code in e1000 has not changed since
>>> 2.6.18. Nonetheless there's no way I can debug any of this without a
Two bit-field values are extracted from the sprom data and never used.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm4
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
None of the MSI code in e1000 has changed significantly either. as
far as I can see, the msi code in e1000 has not changed since
2.6.18. Nonetheless there's no way I can debug any of this without a
system.
[...]
Perhaps Adam can git-b
On Saturday 03 February 2007 11:40, Ivo van Doorn wrote:
> It would only be generated for AP mode.
> In any case, the new patch:
>
> Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
>
ACK
Thanks,
-Michael Wu
pgprYlsoEM9TR.pgp
Description: PGP signature
On Saturday 03 February 2007 17:25, Ivo van Doorn wrote:
> Drivers that require beacon templates will also have the
> control structure at their disposal and should always free it.
>
> bcm43xx doesn't use the control structure, but should still free it.
>
> Signed-off-by Ivo van Doorn <[EMAIL PRO
On Saturday 03 February 2007 17:33, Michael Wu wrote:
> On Saturday 03 February 2007 11:25, Ivo van Doorn wrote:
> > p54 seems to ignore the beacon that is being passed,
> > even though it is requesting the BEACON_TEMPLATE.
> > That is why I not only added a line to free the control structure
> > b
On Saturday 03 February 2007 11:25, Ivo van Doorn wrote:
> p54 seems to ignore the beacon that is being passed,
> even though it is requesting the BEACON_TEMPLATE.
> That is why I not only added a line to free the control structure
> but also the beacon itself.
>
Yeah, beacons aren't actually handl
Drivers that require beacon templates will also have the
control structure at their disposal and should always free it.
p54 seems to ignore the beacon that is being passed,
even though it is requesting the BEACON_TEMPLATE.
That is why I not only added a line to free the control structure
but also
When rt2500usb and rt73usb will start using beacontemplates,
they would also need a control structure to be passed along to
correctly set the tx parameters.
This patch will add the allocation an initialization of a
ieee80211_tx_control especially for the beacontemplate.
This does require drivers
Drivers that require beacon templates will also have the
control structure at their disposal and should always free it.
bcm43xx doesn't use the control structure, but should still free it.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43
Hello.
I am pleased to announce new release of the acrypto for 2.6.20 kernel -
first asynchronous crypto layer for Linux kernel 2.6.
Acrypto allows to handle crypto requests asynchronously in hardware.
Acrypto supports following features:
* multiple asynchronous crypto device queues
* crypto s
On Fri, Feb 02, 2007 at 06:57:37PM -0500, Brian Haley wrote:
> Hi Vlad,
>
> Vlad Yasevich wrote:
> >Brian Haley wrote:
> >>Hi Neil,
> >>
> >>>@@ -830,7 +836,8 @@ retry:
> >>> ift = !max_addresses ||
> >>> ipv6_count_addresses(idev) < max_addresses ?
> >>>ipv6_add_addr(idev,
On Fri, Feb 02, 2007 at 05:22:31PM -0500, Vlad Yasevich wrote:
> Neil Horman wrote:
> > On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote:
> >> From: Neil Horman <[EMAIL PROTECTED]>
> >> Date: Fri, 2 Feb 2007 14:06:34 -0500
> >>
> >>> Ok, I'm still testing it, but heres a new patch for r
On Fri, Feb 02, 2007 at 04:50:35PM -0500, Vlad Yasevich wrote:
> Neil Horman wrote:
> > Ok, I'm still testing it, but heres a new patch for review. Significant
> > changes
> > include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is
> > dependent on
> > the inclusion of both IPPV6 and
On Sat, 2007-03-02 at 09:28 +0900, Shinta Sugimoto wrote:
> Yes. A XFRM_MSG_MIGRATE message can update an SPD entry and associated
> SAD entries (if any) at a time.
>
Ok, you have convinced me on the need for the message.
> By "Mobile VPN", I meant a VPN scenario where clients roam around
> su
This patch makes sure the multiread/multiwrite
functions for eeprom_93cx6 work with little endian
data. The singleread still works with host endian.
Most drivers still want the multiread to work with little
endian because this is used for data like the MAC address.
Signed-off-by Ivo van Doorn <[E
On Wednesday 31 January 2007 20:16, Ivo van Doorn wrote:
> Most hardware can keep track of sequence numbers themselves,
> unfortunately *most* doesn't cover all devices. ;)
> This patch will keep track of the sequence number if the flag
> IEEE80211_HW_SOFTWARE_SEQUENCE has been set.
>
> Signed-off
Hi John,
Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git
for these patches:
adm8211-week05 branch:
Michael Wu (1):
adm8211: set MAC address properly
p54-week05 branch:
Michael Wu (3):
p54: set MAC address properly
p54usb: silence warnings on BE
35 matches
Mail list logo
