>
> Whereas it should probably go:
>
> if (max == 0) {
> max = (flags & HASH_HIGHMEM) ? nr_all_pages : nr_kernel_pages;
> max = (max << PAGE_SHIFT) >> 4;
> do_div(max, bucketsize);
> }
>
> or something like that.
That's still too big. Consi
Theodore Tso wrote:
> Thanks, that description was very helpful. Would you accept a patch
> with adding a comment describing this?
I will put it on my queue to add some comments for ASF.
>
> It appears that there is no way of disabling ASF; is that a true
> statement?
>
Turning off ASF is ju
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 07:11:06 +0200
> The hash sizing code needs far more tweaks. iirc it can still
> allocate several GB hash tables on large memory systems (i've seen
> that once in the boot log of a 2TB system). Even on smaller systems
> it is usually too
On Tue, Aug 08, 2006 at 03:41:15PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> On Tue, Aug 08, 2006 at 09:24:08AM +0400, Evgeniy Polyakov wrote:
> >
> > So there is no place at the end of skb for additional pointer.
> > And new question arises - until what Jesse suggested is implemented in
> >
> -Original Message-
> From: jamal [mailto:[EMAIL PROTECTED]
> On Mon, 2006-07-08 at 13:53 -0700, Brandeburg, Jesse wrote:
>
> > we don't enable it right now, but you could use the TXQE (tx queue
> empty)
> > interrupt to avoid the starvation case. I think it might flood you
with
> > TXQE
On Tue, Aug 08, 2006 at 09:24:08AM +0400, Evgeniy Polyakov wrote:
>
> So there is no place at the end of skb for additional pointer.
> And new question arises - until what Jesse suggested is implemented in
> some way, do we need to store a pointer to shared info inside skb and
> allocate it from c
On Mon, Aug 07, 2006 at 05:09:39PM -0700, Jesse Brandeburg ([EMAIL PROTECTED])
wrote:
> LPE controls whether long packet reception is permitted. Hardware
> discards long packets if LPE is 0. A long packet is one longer than
> 1522 bytes. If LPE is 1, the maximum packet size that the device can
> r
> So for now it is probably sufficient to just get rid of the
> HASH_HIGHMEM flag here. Later we can try changing this multiplier
> of "16" to something like "8" or even "4".
The hash sizing code needs far more tweaks. iirc it can still allocate several
GB
hash tables on large memory systems (
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Mon, 7 Aug 2006 17:49:47 +0200
> This patch makes needlessly global code static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Looks reasonable, applied.
> It doesn't seem to be intended that the new
> ipv4/fib_rules.c:fib4_rules_cleanup() is com
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 14:23:36 +1000
> On Mon, Aug 07, 2006 at 09:21:35PM -0700, David Miller wrote:
> > From: "Michael Chan" <[EMAIL PROTECTED]>
> > Date: Mon, 07 Aug 2006 21:10:14 -0700
> >
> > > Fix a subtle race condition between tg3_start_xmit() and tg3_t
On Mon, Aug 07, 2006 at 09:21:35PM -0700, David Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Mon, 07 Aug 2006 21:10:14 -0700
>
> > Fix a subtle race condition between tg3_start_xmit() and tg3_tx()
> > discovered by Herbert Xu <[EMAIL PROTECTED]>:
>
> This one looks good to me.
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 21:10:14 -0700
> Fix a subtle race condition between tg3_start_xmit() and tg3_tx()
> discovered by Herbert Xu <[EMAIL PROTECTED]>:
This one looks good to me. Herbert please ACK this if you agree.
Thanks a lot Michael.
-
To unsubscr
Fix a subtle race condition between tg3_start_xmit() and tg3_tx()
discovered by Herbert Xu <[EMAIL PROTECTED]>:
CPU0CPU1
tg3_start_xmit()
if (tx_ring_full) {
tx_lock
tg3_tx()
From: Wei Yongjun <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 04:45:13 -0400
> I used tcb->end_seq instead of tcb->seq. And add a new condition 'tcb-
> seq == tcb->end_seq' to make ACK segment to be counted.
...
> Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]>
Applied, thanks a lot.
-
To unsubscr
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 16:00:32 -0700
> Update sunrpc to use in-kernel sockets API.
>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
> Acked-by: James Morris <[EMAIL PROTECTED]>
Applied, thanks.
> @@ -207,7 +207,7 @@ static inline int xs_sendp
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 16:00:29 -0700
> This patch implements wrapper functions that provide a convenient way to
> access the sockets API for in-kernel users like sunrpc, cifs & ocfs2 etc
> and any future users.
>
> Signed-off-by: Sridhar Samudrala <[EM
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Mon, 7 Aug 2006 20:48:42 +0400
> The patch looks OK. But I am not sure too.
>
> To be honest, I do not understand the sense of HASH_HIGHMEM flag.
> At the first sight, hash table eats low memory, objects hashed in this table
> also eat low memory.
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 7 Aug 2006 16:36:02 -0700
> This patch will linearize and check there is enough data.
> It handles the pprop case as well as avoiding a whole audit of
> the routing code.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, with
On Tue, 2006-08-08 at 12:17 +1000, Herbert Xu wrote:
> CPU0 CPU1
> __qdisc_run
> netif_queue_stopped
> netif_wake_queue
> __netif_schedule
> test_bit
>
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 20:05:36 -0700
> Actually, I can probably hide it in the TX_BUFFS_AVAIL() macro.
Sounds like a good idea.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Tue, 2006-08-08 at 12:51 +1000, Herbert Xu wrote:
> > 2. Eliminate the private tx_lock altogether and rely solely on
> > netif_tx_lock. This eliminates one spinlock in tg3_start_xmit()
> > when the ring is full.
>
> Why not get rid of the lock altogether? By making sure memory
> barriers are
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 19:46:26 -0700
> 4. Make tx_cons and tx_prod volatile to guarantee that
> tg3_start_xmit() and tg3_tx() will see the latest ring indices.
Marking variables volatile is always an error.
If the locks and memory barriers are in the rig
On Mon, Aug 07, 2006 at 07:46:26PM -0700, Michael Chan wrote:
> Fix a subtle race condition between tg3_start_xmit() and tg3_tx()
> discovered by Herbert Xu <[EMAIL PROTECTED]>:
Thanks for the patch Michael.
> 2. Eliminate the private tx_lock altogether and rely solely on
> netif_tx_lock. This
Fix a subtle race condition between tg3_start_xmit() and tg3_tx()
discovered by Herbert Xu <[EMAIL PROTECTED]>:
CPU0CPU1
tg3_start_xmit()
if (tx_ring_full) {
tx_lock
tg3_tx()
On Mon, Aug 07, 2006 at 09:33:52PM -0400, jamal wrote:
>
> Is there a need for a schedule if that happens? i.e assuming that the
> clearing happens because there are no more packets to process.
> OTOH, if the other side sets the QDISC_RUNNING right after the test,
> then qdisc is running will be
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 19:09:44 +0200
> Pretty much straight forward, some minor fixes that go
> along with it.
Looks good, all applied.
Thanks Thomas.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PRO
From: Al Viro <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 01:56:19 +0100
> On Mon, Aug 07, 2006 at 04:20:33PM -0700, Stephen Hemminger wrote:
> > Please consider EXPORT_SYMBOL_GPL because this interface would be a obvious
> > target for binary modules writers to use.
>
> As opposed to duplicating i
On Tue, 2006-08-08 at 11:22 +1000, Herbert Xu wrote:
> I'm not sure if this is safe. What if the other side clears QDISC_RUNNING
> right after you test it here? Wouldn't you miss the schedule altogether?
>
Is there a need for a schedule if that happens? i.e assuming that the
clearing happens be
On Mon, Aug 07, 2006 at 09:19:31PM -0400, jamal wrote:
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index d95e262..977e77e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1092,7 +1092,8 @@ static void dev_queue_xmit_nit(struct sk
>
> void __netif_schedule(struct net_device *dev)
On Sun, 2006-06-08 at 08:24 -0400, jamal wrote:
> On Sun, 2006-06-08 at 12:51 +1000, Herbert Xu wrote:
> > On Sat, Aug 05, 2006 at 07:36:50PM -0400, jamal wrote:
> > >
> > > I know the qlen is >= 0 otherwise i will hit the BUG().
> > > A qlen of 0 will be interesting to find as well.
> >
> > When
On Mon, 2006-07-08 at 13:53 -0700, Brandeburg, Jesse wrote:
> we don't enable it right now, but you could use the TXQE (tx queue empty)
> interrupt to avoid the starvation case. I think it might flood you with
> TXQE interrupts however, so we'd probably have to figure out some way to
> turn it
On Mon, Aug 07, 2006 at 04:20:33PM -0700, Stephen Hemminger wrote:
> Please consider EXPORT_SYMBOL_GPL because this interface would be a obvious
> target for binary modules writers to use.
As opposed to duplicating it? WTFPoint of restriction that is trivial to
bypass? Look at those functions; t
On Mon, 2006-07-08 at 22:28 +0200, Edgar E. Iglesias wrote:
>
> I can see two calls to e1000_prune_tx_ring with jamal _defined_.
>
Ok, never mind - I think thats the source of our confusion. Just ignore
those entries since they are ifdefed out (The second one i dont know how
it made it in since
On Mon, 2006-08-07 at 16:20 -0700, Stephen Hemminger wrote:
> On Mon, 07 Aug 2006 16:00:29 -0700
> Sridhar Samudrala <[EMAIL PROTECTED]> wrote:
>
> > Dave,
> >
> > Could you consider this for inclusion into 2.6.19 tree?
> >
> > Thanks
> > Sridhar
> >
> > This patch implements wrapper functions
From: "Jesse Brandeburg" <[EMAIL PROTECTED]>
Date: Mon, 7 Aug 2006 17:09:39 -0700
> also, eth_type_trans wants skb->data to point to header, which would
> require us to memcpy data from a page back to skb->data.
You merely would need to call pskb_may_pull() right before invoking
eth_type_trans.
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 17:02:08 -0700
> All the structures in sctp.h that use packed atrribute define
> standard on-wire SCTP chunk/parameter formats. They need to be at the
> exact offsets as they go on wire.
> I think we saw some issues without the pac
On 8/7/06, Pavel Roskin <[EMAIL PROTECTED]> wrote:
- pci_rc = pci_module_init(&vortex_driver);
+ pci_rc = pci_register_driver(&vortex_driver);
eisa_rc = vortex_eisa_init();
not sure why this *function name change* really matters, but
technically I'm okay with the e100/e1000/
On 8/7/06, David Miller <[EMAIL PROTECTED]> wrote:
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Sat, 5 Aug 2006 15:01:09 +0200
> All caller of netdev_alloc_skb need to assign skb->dev shortly
> afterwards. Move it into common code.
>
> I also had to fixup a little bit of the surrounding co
On 8/7/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
On Mon, Aug 07, 2006 at 11:31:03AM +0400, Evgeniy Polyakov wrote:
>
> Only if they form contiguous region?
> Jesse, is it possible for every e1000 chip to split frame into several
> page-sized chunks i.e. create some kind of receiving scatter-gathe
On Mon, 2006-08-07 at 13:34 -0700, Stephen Hemminger wrote:
> After reading:
> http://bugzilla.kernel.org/show_bug.cgi?id=6693
>
> I noticed there were stupid uses of packed attribute in several network
> headers.
>
> Silly offenders: include/net/ipx.h
> include/
This patch should update the fs_enet infrastructure to utilize
Phy Abstraction Layer subsystem. Along with the above, there are apparent
bugfixes, overhaul and improvements.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/Makefile |6
drivers/net/fs_enet/fec.
This makes it possible for HW PHY-less boards to utilize PAL goodies.
Generic routines to connect to fixed PHY are provided, as well as ability
to specify software callback that fills up link, speed, etc. information
into PHY descriptor (the latter feature not tested so far).
Signed-off-by: Vital
This contains board-specific portion to respect driver changes (for 8272ads
, 885ads and 866ads). Altered platform_data structures as well as initial
setup routines relevant to fs_enet.
Changes to the mpc8560ads ppc/ code are also introduced, but mainly as
reference, since the entire board suppor
On Tue, 2006-08-08 at 01:24 +0200, Bernd Schubert wrote:
>
> tg3.c:v3.49 (Feb 2, 2006)
> acpi_bus-0201 [01] bus_set_power : Device is not power manageable
> eth1: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit)
> 10/100/1000BaseT Ethernet 00:e0:81:2b:aa:28
> eth1: RXc
On Mon, Aug 07, 2006 at 04:35:36PM -0700, Brandeburg, Jesse wrote:
>
> e1000 only clears the interrupts when it reads ICR in e1000_intr (before
> scheduling napi poll) so any interrupts that occur while polling (and
> interrupts are disabled) will cause a new assertion once interrupts are
> re-
On Tue, 8 Aug 2006, Herbert Xu wrote:
> > -#define E1000_TX_WEIGHT 64
> > - /* weight of a sort for tx, to avoid endless transmit
> > cleanup */
> > - if (count++ == E1000_TX_WEIGHT) break;
> > + /* avoid endless transmit cleanup */
> > + if (
This contains board-specific portion to respect driver changes (for 8272ads
, 885ads and 866ads). Altered platform_data structures as well as initial
setup routines relevant to fs_enet.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
arch/ppc/platforms/85xx/mpc8560_ads.c| 89
These are patches, that utilize Phy Abstraction Layer API in the fs_enet
Freescale SoC Ethernet driver. Comments gavered from the community addressed,
+ minor fixes and improvements.
--
Sincerely, Vitaly
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message t
This patch will linearize and check there is enough data.
It handles the pprop case as well as avoiding a whole audit of
the routing code.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/ipx/af_ipx.c 2006-08-07 13:45:59.0 -0700
+++ b/net/ipx/af_ipx.c 2006-08-07 16:34:00.0
This patch should update the fs_enet infrastructure to utilize
Phy Abstraction Layer subsystem. Along with the abouve, there are apparent
bugfixes, rehaul and improvements.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/Makefile |6
drivers/net/fs_enet/fec.h
This makes it possible for HW PHY-less boards to utilize PAL goodies.
Generic routines to connect to fixed PHY are provided, as well as ability
to specify software callback that fills up link, speed, etc. information
into PHY descriptor (the latter feature not tested so far).
Signed-off-by: Vital
QoS header processing mangled unencrypted WMM frames on software
retry. The QoS data needs to be removed even when encryption key is
not configured.
Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211.c
Fixed dot11RTSThreshold use which was off-by-3:
- must add FCS_LEN to the skb->len
- frame length needs to be greater than threshold; not greater than
or equal
Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211.c
===
Fixed TKIP replay protection for the case where hwaccel is enabled.
rx_initialized flag was not set in this case and the TSC validation
was skipped for the frames.
Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/tkip.c
==
Hi Michael,
thanks for your help!
On Tuesday 08 August 2006 01:07, Michael Chan wrote:
> > ... [many hamilton not responding messages]
> > 4554928.798000] nfs: server hamilton not responding, still trying
> > [4554935.319000] nfs: server hamilton not responding, still trying
> > [4555468.94]
Here's a set of small fixes to net/d80211 from the Devicescape tree.
Please consider applying.
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majo
On Mon, Aug 07, 2006 at 03:03:33PM -0400, jamal wrote:
>
> -#define E1000_TX_WEIGHT 64
> - /* weight of a sort for tx, to avoid endless transmit
> cleanup */
> - if (count++ == E1000_TX_WEIGHT) break;
> + /* avoid endless transmit cleanup */
> +
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 7 Aug 2006 13:46:36 -0700
> IPX is not checking for non-linear (and short packets) in it's
> receive routine. This is serious because it may mean it ends up
> reading past end of skb.
This takes care of ipx_rcv() but the rest of the IPX prot
Fixed a typo in a comment: PLCP header length is in microseconds, not
milliseconds.
Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wire
Send Layer 2 Update frame from the 802.11 code in kernel to the netdev
that the STA is bound to. If the STA is bound to another VLAN netdev,
send another update frame. This fixes an issue in which a local bridge
table was not updated when hostapd sent this frame.
Signed-off-by: Jouni Malinen <[EMA
Fixed PS-Poll processing for STAs that are not authenticated or
associated:
- 80211.ko dropped these frames even though it should have sent them
to hostapd (this was broken by addition of IBSS support)
Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211.c
=
On Mon, 07 Aug 2006 16:00:29 -0700
Sridhar Samudrala <[EMAIL PROTECTED]> wrote:
> Dave,
>
> Could you consider this for inclusion into 2.6.19 tree?
>
> Thanks
> Sridhar
>
> This patch implements wrapper functions that provide a convenient way to
> access the sockets API for in-kernel users like
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 7 Aug 2006 13:34:23 -0700
> Silly offenders: include/net/ipx.h
> include/net/ieee80211.h
> include/net/ip6_tunnel.h
> include/net/ndisc.h
> include/li
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Sat, 5 Aug 2006 15:01:09 +0200
> All caller of netdev_alloc_skb need to assign skb->dev shortly
> afterwards. Move it into common code.
>
> I also had to fixup a little bit of the surrounding control flow in
> e1000 - it was just too convoluted.
On Tue, 2006-08-08 at 00:43 +0200, Bernd Schubert wrote:
> Hi,
>
> I have seen a few reports like this, but now broadcom seems to actively
> support tg3, so I decided to send this.
>
> ... [many hamilton not responding messages]
> 4554928.798000] nfs: server hamilton not responding, still trying
Dave,
Could you consider this for inclusion into 2.6.19 tree?
Thanks
Sridhar
This patch implements wrapper functions that provide a convenient way to
access the sockets API for in-kernel users like sunrpc, cifs & ocfs2 etc
and any future users.
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED
Update sunrpc to use in-kernel sockets API.
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
---
net/sunrpc/svcsock.c | 38 ++
net/sunrpc/xprtsock.c |8
2 files changed, 18 insertions(+), 28 delet
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Sat, 5 Aug 2006 14:59:06 +0200
> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Applied, thanks Christoph.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Hi,
I have seen a few reports like this, but now broadcom seems to actively
support tg3, so I decided to send this.
... [many hamilton not responding messages]
4554928.798000] nfs: server hamilton not responding, still trying
[4554935.319000] nfs: server hamilton not responding, still trying
[455
You know, I suddenly feel very foolish. Sorry for having wasted
everyone's time, and thanks for your keen eye.
On Tue, Aug 08, 2006 at 12:19:24AM +0200, Krzysztof Halasa wrote:
> Frank v Waveren <[EMAIL PROTECTED]> writes:
>
> > The nforce2 builtin network on my A7N8X-delux motherboard won't dete
From: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/3c59x.c |2 +-
drivers/net/8139cp.c |2 +-
drivers/net/8139too.c |2 +-
drivers/net/acenic.c |2 +-
drivers/net/amd8111e.c
Frank v Waveren <[EMAIL PROTECTED]> writes:
> The nforce2 builtin network on my A7N8X-delux motherboard won't detect
> as gigabit-capable using the forcedeth driver.
Asustek doesn't seem to indicate it has gigabit ports, are you
sure your mb does have them? Perhaps it's a different version,
some
This patch removes three no longer used functions (that are even
generating gcc warnings).
This patch doesn't look right, but it is the result of
58e5528ee464d38040b9489e10033c9387a10d56 in git-netdev...
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/wireless/bcm43xx/bcm43xx_
On Mon, 7 Aug 2006, jamal wrote:
> -#define E1000_TX_WEIGHT 64
> - /* weight of a sort for tx, to avoid endless transmit
> cleanup */
> - if (count++ == E1000_TX_WEIGHT) break;
> + /* avoid endless transmit cleanup */
> + if (count++ == tx_rin
From: Grant Grundler <[EMAIL PROTECTED]>
As the cookie returned by pci_iomap() is fairly useless...
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip_core.c | 10 --
1 files changed, 8 insertions(+), 2 deletio
From: Grant Grundler <[EMAIL PROTECTED]>
IRQs are racing with tulip_down().
DMA can be restarted by tulip_interrupt() _after_ we call
tulip_stop_rxtx() and the DMA buffers are unmapped. The result
is an MCA (hard crash on ia64) because of an IO TLB miss.
Signed-off-by: Grant Grundler <[EMAIL PRO
From: Thibaut Varene <[EMAIL PROTECTED]>
Signed-off-by: Thibaut Varene <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tul
From: Grant Grundler <[EMAIL PROTECTED]>
Include "tulip.h" in winbond-840.c and clean up lots of redundant
definitions.
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip.h | 17 ++
drivers/net/tulip/tuli
From: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip.h |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tulip/tulip.h b/drivers/net/tulip/tu
From: Grant Grundler <[EMAIL PROTECTED]>
The obvious safe registers to read is one from PCI config space.
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip_core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions
From: Francois Romieu <[EMAIL PROTECTED]>
Move tulip_select_media() processing to a workqueue, instead of delaying
in interrupt context.
[Edit by Kyle to use kevent thread, instead of creating its own
workqueue.]
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/21142.c
From: Helge Deller <[EMAIL PROTECTED]>
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to
.init.text:de_init_one from .data.rel.local after 'de_driver' (at offset 0x20)
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to
.exit.text:de_remove_one from .data.re
From: Grant Grundler <[EMAIL PROTECTED]>
A whole slew of fixes for tulip_select_media for:
- Flush posted MMIO writes as per PCI spec
- Polling the reset bit (bit 15) is required to determine when
the "init" sequence can be sent.
This fixes tulip on HP PA-RISC systems, which use DP83840A and
Within our PCI Network Device there is a special feature, that allows
out-of-band signaling-messeging (by using special interrupt and shared
registers) to control system state: Reboot, Shutdown.
What would be an acceptable method of executing such controls?
So, the sequence is:
1. Device Driv
IPX is not checking for non-linear (and short packets) in it's receive routine.
This is serious because it may mean it ends up reading past end of skb.
This maybe related to this bug, because sky2 will copy small packets into small
skb's.
http://bugzilla.kernel.org/show_bug.cgi?id=6693
Signe
[Val asked that I split this out, instead of just publishing a git tree,
so here goes nothing. I don't think I've ever used git-send-email before,
but hopefully I won't screw up too badly.]
The following patch series brings the mainline tulip driver in synch
with the modifications made in parisc-l
After reading:
http://bugzilla.kernel.org/show_bug.cgi?id=6693
I noticed there were stupid uses of packed attribute in several network headers.
Silly offenders:include/net/ipx.h
include/net/ieee80211.h
include/net/ip6_tunnel.h
On Mon, Aug 07, 2006 at 03:34:30PM -0400, jamal wrote:
> On Mon, 2006-07-08 at 21:14 +0200, Edgar E. Iglesias wrote:
>
> > > If yes, what is the likelihood they will sit there forever? I think
> > > perhaps some TX interupts will happen, no?
> >
> > with jamal undefined, absolutely. With jamal de
hopefully queued-by, as well...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linas Vepstas wrote:
Resending patch from 23 June 2006; there was some confusion about
whether a similar patch had already been applied; seems it wasn't.
Minor janitorial patch: use #defines for literal values.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Acked-by: Auke Kok <[EMAIL PROTEC
Resending patch from 23 June 2006; there was some confusion about
whether a similar patch had already been applied; seems it wasn't.
Minor janitorial patch: use #defines for literal values.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/e1000/e1000_main.c |4 ++--
1 file
On Mon, 2006-07-08 at 21:14 +0200, Edgar E. Iglesias wrote:
> > If yes, what is the likelihood they will sit there forever? I think
> > perhaps some TX interupts will happen, no?
>
> with jamal undefined, absolutely. With jamal defined, TX interrupts will come
> but I couldnt find a way into e100
On Mon, Aug 07, 2006 at 03:03:33PM -0400, jamal wrote:
> On Mon, 2006-07-08 at 20:47 +0200, Edgar E. Iglesias wrote:
>
> > I think we are out of sync :)
>
> Imagine that, eh? ;->
>
> > My, fault I haven't been clear enough.
> >
>
> Not just your transmit but also my receive is at fault ;-> (a
On Mon, 2006-07-08 at 20:47 +0200, Edgar E. Iglesias wrote:
> I think we are out of sync :)
Imagine that, eh? ;->
> My, fault I haven't been clear enough.
>
Not just your transmit but also my receive is at fault ;-> (aka, I may
not be listening as well as i should). Now two machines or CPUs y
On Mon, Aug 07, 2006 at 02:00:24PM -0400, jamal wrote:
> On Mon, 2006-07-08 at 19:04 +0200, Edgar E. Iglesias wrote:
>
> >
> > I'll give you an example.
>
> Thanks - that matches my understanding.
>
> > A TCP flow sends X data and later waits for a response, host is now quietly
> > waiting. Ass
On Monday 07 August 2006 10:20, Jouni Malinen wrote:
> Changing WLAN_STATUS_* and WLAN_REASON_* to be enum's while keeping
> their old names is fine. However, I would rather not change the names of
> the information element IDs (WLAN_EID_*) into MFIE_TYPE_*. What is that
> 'MFIE' anyway? Management
On Mon, 2006-07-08 at 10:49 -0700, Stephen Hemminger wrote:
> I needed to merge the branch in, the git tree is now up to date.
I have never gathered the energy to figure that stuff out so i dont envy
you.
In any case, seems to be missing the majority of the patches i sent,
including this one who
From: Randy Dunlap <[EMAIL PROTECTED]>
tiacx sparse cleanups:
- use NULL instead of 0 for pointer value
- use C99 struct initializers
- use ANSI function declaration
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/net/wireless/tiacx/common.c |2
drivers/net/wireless/tiacx/ioctl.
On Mon, 2006-07-08 at 19:04 +0200, Edgar E. Iglesias wrote:
>
> I'll give you an example.
Thanks - that matches my understanding.
> A TCP flow sends X data and later waits for a response, host is now quietly
> waiting. Assume fdesc >= tx_ring->prunet, so we dont free any skbs, right?
>
I am h
On Fri, 04 Aug 2006 23:23:14 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Sat, 05 Aug 2006 22:42:18 -0700
>
> > Thomas Graf wrote:
> > > -/* The struct should be in sync with struct net_device_stats */
> > > -struct rtnl_link_stats
> >
1 - 100 of 132 matches
Mail list logo
