* Re: [PATCH][IPX] Use existing sock refcnt debugging infrastructure
From: Arnaldo Carvalho de Melo @ 2007-11-09 14:39 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: David Miller, Arnaldo Carvalho de Melo, Linux Netdev List, devel
In-Reply-To: <473463AD.9000807@openvz.org>
Em Fri, Nov 09, 2007 at 04:42:05PM +0300, Pavel Emelyanov escreveu:
> Just like in the af_packet.c, the ipx_sock_nr variable is used
> for debugging purposes.
>
> Switch to using existing infrastructure. Thanks to Arnaldo for
> pointing this out.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
^ permalink raw reply
* [RFC][PATCH][LLC] Use existing sock refcnt debugging
From: Pavel Emelyanov @ 2007-11-09 14:43 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: Linux Netdev List, devel
Hi, Arnaldo.
I've grep-ed through the code and found one more place, where
the sk refcnt debugging is required, but is still performed in
an old fashion - this is the LLC2.
The problem in using the sk_refcnt_debug_xxx here is that these
socks do not provide the sk_destruct callback to catch the
moment of the sock destruction.
Making this callback mandatory is not a good solution, as most
often it will be empty and thus useless. Making this callback
be set under the #ifdef SOCK_REFCNT_DEBUG is even more ugly
than the previous one.
So, I propose to extend the sk_refcnt_debug_xxx set of helperf
for those socks not having the sk_destruct callback by default,
like the LLC2 ones.
The new helper is sk_refcnt_debug_inc_undo(sk) sets the
sk_destruct callback into the sk_refcnt_debug_dec() in case the
SOCK_REFCNT_DEBUG is on.
What do you think about it?
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/include/net/sock.h b/include/net/sock.h
index 5504fb9..1404ab9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -654,10 +654,21 @@ static inline void sk_refcnt_debug_release(const struct sock *sk)
printk(KERN_DEBUG "Destruction of the %s socket %p delayed, refcnt=%d\n",
sk->sk_prot->name, sk, atomic_read(&sk->sk_refcnt));
}
+
+/*
+ * this one is to be used *only* for thouse socks, that
+ * do not have their own sk_destruct callback
+ */
+static inline void sk_refcnt_debug_inc_undo(struct sock *sk)
+{
+ sk_refcnt_debug_inc(sk);
+ sk->sk_destruct = sk_refcnt_debug_dec;
+}
#else /* SOCK_REFCNT_DEBUG */
#define sk_refcnt_debug_inc(sk) do { } while (0)
#define sk_refcnt_debug_dec(sk) do { } while (0)
#define sk_refcnt_debug_release(sk) do { } while (0)
+#define sk_refcnt_debug_inc_undo(sk) do { } while (0)
#endif /* SOCK_REFCNT_DEBUG */
/* Called with local bh disabled */
diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
index 5c0b484..6ee8778 100644
--- a/net/llc/llc_conn.c
+++ b/net/llc/llc_conn.c
@@ -775,11 +775,6 @@ drop_unlock:
goto out;
}
-#undef LLC_REFCNT_DEBUG
-#ifdef LLC_REFCNT_DEBUG
-static atomic_t llc_sock_nr;
-#endif
-
/**
* llc_backlog_rcv - Processes rx frames and expired timers.
* @sk: LLC sock (p8022 connection)
@@ -875,11 +870,7 @@ struct sock *llc_sk_alloc(struct net *net, int family, gfp_t priority, struct pr
goto out;
llc_sk_init(sk);
sock_init_data(NULL, sk);
-#ifdef LLC_REFCNT_DEBUG
- atomic_inc(&llc_sock_nr);
- printk(KERN_DEBUG "LLC socket %p created in %s, now we have %d alive\n", sk,
- __FUNCTION__, atomic_read(&llc_sock_nr));
-#endif
+ sk_refcnt_debug_inc_undo(sk);
out:
return sk;
}
@@ -905,18 +896,7 @@ void llc_sk_free(struct sock *sk)
skb_queue_purge(&sk->sk_receive_queue);
skb_queue_purge(&sk->sk_write_queue);
skb_queue_purge(&llc->pdu_unack_q);
-#ifdef LLC_REFCNT_DEBUG
- if (atomic_read(&sk->sk_refcnt) != 1) {
- printk(KERN_DEBUG "Destruction of LLC sock %p delayed in %s, cnt=%d\n",
- sk, __FUNCTION__, atomic_read(&sk->sk_refcnt));
- printk(KERN_DEBUG "%d LLC sockets are still alive\n",
- atomic_read(&llc_sock_nr));
- } else {
- atomic_dec(&llc_sock_nr);
- printk(KERN_DEBUG "LLC socket %p released in %s, %d are still alive\n", sk,
- __FUNCTION__, atomic_read(&llc_sock_nr));
- }
-#endif
+ sk_refcnt_debug_release(sk);
sock_put(sk);
}
^ permalink raw reply related
* [PATCH] Fix infinite loop on dev_mc_unsync()
From: Luis R. Rodriguez @ 2007-11-09 15:11 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jeff Garzik
While reviewing net/core/dev_mcast.c I found what I think is an
infinite loop on dev_mc_unsync(). This fixes it. We make use of
this guy on mac80211 in ieee80211_stop(). This is untested.
Signed-off-by: Luis R. Rodriguez <mcgrof-NvJAj8134tRxEa0u/P/EHDe48wsgrGvP@public.gmane.org>
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 15241cf..5373c03 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -168,8 +168,10 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
da = from->mc_list;
while (da != NULL) {
next = da->next;
- if (!da->da_synced)
+ if (!da->da_synced) {
+ da = next;
continue;
+ }
__dev_addr_delete(&to->mc_list, &to->mc_count,
da->da_addr, da->da_addrlen, 0);
da->da_synced = 0;
^ permalink raw reply related
* [PATCH 2.6.24] RDMA/cxgb3: Set the max_qp_init_rd_atom attribute.
From: Steve Wise @ 2007-11-09 15:21 UTC (permalink / raw)
To: rdreier; +Cc: netdev, general
RDMA/cxgb3: Set the max_qp_init_rd_atom attribute.
Attribute max_qp_init_rd_atom is not getting set. Version 1.0.4 of
librdmacm now validates the user's requested initiator and responder
resources vs the max supported by the device. Since iw_cxgb3 wasn't
setting this attribute (and it defaulted to 0), all rdma_connect()s fail
if there are initiator resources requested by the app.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index f0c7775..b5436ca 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -1000,6 +1000,7 @@ static int iwch_query_device(struct ib_device *ibdev,
props->max_sge = dev->attr.max_sge_per_wr;
props->max_sge_rd = 1;
props->max_qp_rd_atom = dev->attr.max_rdma_reads_per_qp;
+ props->max_qp_init_rd_atom = dev->attr.max_rdma_reads_per_qp;
props->max_cq = dev->attr.max_cqs;
props->max_cqe = dev->attr.max_cqes_per_cq;
props->max_mr = dev->attr.max_mem_regs;
^ permalink raw reply related
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Scott Wood @ 2007-11-09 16:03 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, netdev, jgarzik
In-Reply-To: <1194608283.8755.10.camel@p60635-ste.ids.de>
Sergej Stepanov wrote:
>> We also need to change the reference to port C in fsl,mdio-pin and
>> fsl,mdc-pin.
> Do you mean this:
> Currently defined compatibles:
> fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
> -> fsl,cpm2-mdio-bitbang (reg is port C registers)
>
> Properties for fsl,cpm2-mdio-bitbang:
> -> fsl,mdio-pin : pin of port C controlling mdio data
> -> fsl,mdc-pin : pin of port C controlling mdio clock
Yes.
> Right. But i thought it would be related to the example,
> and than the reader gets the short comment about I/O ports.
No, the example is the example, and the spec is the spec. :-)
> Or the other variant would be:
> --------------------
> iv) MDIO
>
> Currently defined compatibles:
> fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
> fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
>
> Properties for fsl,cpm2-mdio-bitbang:
> The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC.
> fsl,mdio-pin : pin of chosen port for controlling mdio data
> fsl,mdc-pin : pin of chosen port for controlling mdio clock
Looks good. We can eliminate the parenthetical for
fsl,cpm2-mdio-bitbang because reg is now explained below.
-Scott
^ permalink raw reply
* Re: [PATCH 02/05] ipv6: RFC4214 Support (2)
From: osprey67 @ 2007-11-09 16:30 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
In-Reply-To: <20071109.082950.122508269.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <47337483.3080309@yahoo.com> (at Thu, 08 Nov 2007 12:41:39 -0800), osprey67 <osprey67@yahoo.com> says:
>
>> From: Fred L. Templin <osprey67@yahoo.com>
>>
>> This is experimental support for the Intra-Site Automatic
>> Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
>> the SIT module, and is configured using the unmodified
>> "ip" utility with device names beginning with: "isatap".
>>
>> The following diffs are specific to the Linux 2.6.24-rc2
>> kernel distribution.
>>
>> Signed-off-by: Fred L. Templin <osprey67@yahoo.com>
>
> Hmm...tabs are still mangled, and it's better to have your
> official address. Anyway...
I have switched over to Thunderbird and POP mail. I submitted
the patches by cutting and pasting from a text file into the
mail message. Is there a way to stop it from clobbering tabs?
>> --- linux-2.6.24-rc2/include/net/addrconf.h.orig 2007-11-08 12:06:17.000000000 -0800
>> +++ linux-2.6.24-rc2/include/net/addrconf.h 2007-11-08 08:27:24.000000000 -0800
>> @@ -241,6 +241,37 @@ static inline int ipv6_addr_is_ll_all_ro
>> addr->s6_addr32[3] == htonl(0x00000002));
>> }
>>
>> +#if defined(CONFIG_IPV6_ISATAP)
>> +static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
>> +{
>> +
>> + /* RFC3330 Special-Use IPv4 Addresses */
>> + eui[0] = (((addr & htonl(0xFF000000)) == htonl(0x00000000)) ||
>> + ((addr & htonl(0xFF000000)) == htonl(0x0A000000)) ||
>> + ((addr & htonl(0xFF000000)) == htonl(0x0D000000)) ||
>> + ((addr & htonl(0xFF000000)) == htonl(0x18000000)) ||
>> + ((addr & htonl(0xFF000000)) == htonl(0x7F000000)) ||
>> + ((addr & htonl(0xFFFF0000)) == htonl(0xA9FE0000)) ||
>> + ((addr & htonl(0xFFF00000)) == htonl(0xAC100000)) ||
>> + ((addr & htonl(0xFFFFFF00)) == htonl(0xC0000200)) ||
>> + ((addr & htonl(0xFFFFFF00)) == htonl(0xC0586300)) ||
>> + ((addr & htonl(0xFFFF0000)) == htonl(0xC0A80000)) ||
>> + ((addr & htonl(0xFFFE0000)) == htonl(0xC6120000)) ||
>> + ((addr & htonl(0xF0000000)) == htonl(0xE0000000)) ||
>> + ((addr & htonl(0xF0000000)) == htonl(0xF0000000))) ?
>> + 0x00 : 0x02;
>> +
>> + eui[1] = 0; eui[2] = 0x5E; eui[3] = 0xFE;
>> + memcpy (eui+4, &addr, 4);
>> + return 0;
>> +}
>> +
>
> Please put this function in net/ipv6/addrconf.c as addrconf_ifid_isatap().
>
> Please use MULTICAST, LOCALNET etc. (and probaly introduce new macro
> for others). IMHO, it's better to add a comment for each entry, e.g.,
> MULTICAST(addr) || /* 224.0.0.0/4 */
> instead of
> ((addr & htonl(0xF0000000)) == htonl(0xE0000000)) ||
OK - will do.
>> +static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
>> +{
>> + return ((addr->s6_addr32[2] | htonl(0x02000000)) == htonl(0x02005EFE));
>> +}
>> +#endif
>> +
>
> ipv6_addr_isatap(), maybe (to align with ipv6_addr_any() etc.).
Well, if you look in addrconf.h immediately above this the convention
seems to be to call it as "*_is_*" if it is testing an address and
to omit the "*_is_*" if it is setting an address. Since this is an
address test, maybe more consistent to keep the "*_is_*"?
Thanks - Fred
fred.l.templin@boeing.com
>
> --yoshfuji
>
^ permalink raw reply
* Re: [PATCH] PCI: export pci_restore_msi_state()
From: Linas Vepstas @ 2007-11-09 16:42 UTC (permalink / raw)
To: Wen Xiong; +Cc: Kok, Auke, David S. Miller, linux-pci, mcarlson, mchan, netdev
In-Reply-To: <OFD31717CC.A38DF9AF-ON8725738E.00069FB3-8625738E.00077F2A@us.ibm.com>
On Thu, Nov 08, 2007 at 07:21:01PM -0600, Wen Xiong wrote:
> Hi Linas,
>
> I saw you have submitted several patches to support pci-express network
> adapters EEH. But looks only this patch fixed something in linux kernel
> code.
And its an old patch, submitted long ago ... I've resubmitted, because
it seems that its the best/most correct thing to do.
> Do you mean I can test EEH callback functions in device driver after I
> apply this patch in the kernel?
Yes, please. Note, however, I was never able to make the pci-e
version of the e1000 work. It comes up, generates interrupts, and
registeres are readable and writeable. But it behvaes as if the PHY
is turned off -- no network traffic goes thorugh. (I tried turning
PHY on explicitly; that didn't help). So there is still something
wrong somewhere, probably in the e1000 deice driver. I'm guessing
the pci-e to pci-x bridge chip on that card is not quite resetting
the card completely.
> Do you do "pci_save_msi_state" somewhere in the kernel? Or you suggest to
> do "pci_save_msi_state" and "pci_restore_msi_state" in each device driver?
There is no "save state", the msi state can't be saved. The MSI regs
are write-only, and they are controlled by firmware. The restore_state
function is the only one you need.
--linas
^ permalink raw reply
* Re: [PATCH 08/13] SCTP: Use hashed lookup when looking for an association.
From: Vlad Yasevich @ 2007-11-09 16:48 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
In-Reply-To: <11944575913296-git-send-email-vladislav.yasevich@hp.com>
Vlad Yasevich wrote:
> A SCTP endpoint may have a lot of associations on them and walking
> the list is fairly inefficient. Instead, use a hashed lookup,
> and filter out the hash list based on the endopoint we already have.
This one is missing an unlock. Will send an update shortly.
-vlad
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
> ---
> net/sctp/endpointola.c | 33 +++++++++++++++++++++------------
> 1 files changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
> index 2d2d81e..f38fa0f 100644
> --- a/net/sctp/endpointola.c
> +++ b/net/sctp/endpointola.c
> @@ -328,24 +328,33 @@ static struct sctp_association *__sctp_endpoint_lookup_assoc(
> const union sctp_addr *paddr,
> struct sctp_transport **transport)
> {
> + struct sctp_association *asoc = NULL;
> + struct sctp_transport *t = NULL;
> + struct sctp_hashbucket *head;
> + struct sctp_ep_common *epb;
> + int hash;
> int rport;
> - struct sctp_association *asoc;
> - struct list_head *pos;
>
> + *transport = NULL;
> rport = ntohs(paddr->v4.sin_port);
>
> - list_for_each(pos, &ep->asocs) {
> - asoc = list_entry(pos, struct sctp_association, asocs);
> - if (rport == asoc->peer.port) {
> - *transport = sctp_assoc_lookup_paddr(asoc, paddr);
> -
> - if (*transport)
> - return asoc;
> + hash = sctp_assoc_hashfn(ep->base.bind_addr.port, rport);
> + head = &sctp_assoc_hashtable[hash];
> + read_lock(&head->lock);
> + for (epb = head->chain; epb; epb = epb->next) {
> + asoc = sctp_assoc(epb);
> + if (asoc->ep != ep || rport != asoc->peer.port)
> + goto next;
> +
> + t = sctp_assoc_lookup_paddr(asoc, paddr);
> + if (t) {
> + *transport = t;
> + break;
> }
> +next:
> + asoc = NULL;
> }
> -
> - *transport = NULL;
> - return NULL;
> + return asoc;
> }
>
> /* Lookup association on an endpoint based on a peer address. BH-safe. */
^ permalink raw reply
* Re: [PATCH 2/2]: e1000: avoid lockup durig error recovery
From: Ingo Oeser @ 2007-11-09 17:02 UTC (permalink / raw)
To: Linas Vepstas
Cc: Kok, Auke, Jeff Garzik, e1000-devel, NetDev, Brandeburg, Jesse,
john.ronciak, jeffrey.t.kirsher, 'Stephen Hemminger',
wenxiong
In-Reply-To: <20071107232119.GQ4239@austin.ibm.com>
Hi Linas,
Linas Vepstas schrieb:
> Index: linux-2.6.23-rc8-mm1/include/linux/netdevice.h
> ===================================================================
> --- linux-2.6.23-rc8-mm1.orig/include/linux/netdevice.h 2007-09-26 15:07:05.000000000 -0500
> +++ linux-2.6.23-rc8-mm1/include/linux/netdevice.h 2007-11-07 17:14:50.000000000 -0600
> @@ -384,6 +384,18 @@ static inline void napi_enable(struct na
> clear_bit(NAPI_STATE_SCHED, &n->state);
> }
>
> +/**
> + * napi_enabled_p - return non-zero if napi enabled
> + * @n: napi context
> + *
> + * Mnemonic: _p stands for "predicate", returning a yes/no
> + * answer to the question.
Call it "is_napi_enabled()" an nobody will ask :-)
> + */
> +static inline int napi_enabled_p(struct napi_struct *n)
And please make it return "bool" instead of "int".
Best Regards
Ingo Oeser
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: [PATCH 02/05] ipv6: RFC4214 Support
From: Ingo Oeser @ 2007-11-09 18:12 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: Fred.L.Templin, netdev
In-Reply-To: <20071108.044745.123583545.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 schrieb:
> In article <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF4@XCH-NW-7V2.nw.nos.boeing.com> (at Wed, 7 Nov 2007 10:52:47 -0800), "Templin, Fred L" <Fred.L.Templin@boeing.com> says:
>
> > > > > > > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
> > > > > > > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
> > > > > > > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
> > > > > > > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
> > > > > > > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
> > > > > > > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
> > > > > > > + ((ipv4 >= 0xc6140000) && (ipv4 <
> > > 0xe0000000))) eui[0] |=
> > > > > > > 0x2;
>
> > Maybe it is I who did not understand. Can you suggest a clean solution?
>
> You could write each element as LOOPBACK(), MULTICAST()
> etc.
> eui[0] = (!ZERONETO(a) &&
> !PRIVATE_10(a) &&
> !LINKLOCAL(a) &&
> !PRIVATE_172(a) &&
> !PRIVATE_192(a) &&
> !NETICDEVBENCH(a) &&
> !MULTICAST(a)) ? 2 : 0;
Oh, yes that's great! Now even *I* can read what this is all about
without reading any RFC :-)
Please Fred, try to do it that way.
Best Regards
Ingo Oeser
^ permalink raw reply
* Re: [PATCH] Fix infinite loop on dev_mc_unsync()
From: Luis R. Rodriguez @ 2007-11-09 18:51 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jeff Garzik, David Miller
In-Reply-To: <20071109151135.GA12982@pogo>
Sorry, forgot to CC David.
On Fri, Nov 09, 2007 at 10:11:35AM -0500, Luis R. Rodriguez wrote:
While reviewing net/core/dev_mcast.c I found what I think is an
infinite loop on dev_mc_unsync(). This fixes it. We make use of
this guy on mac80211 in ieee80211_stop(). This is untested.
Signed-off-by: Luis R. Rodriguez <mcgrof-NvJAj8134tRxEa0u/P/EHDe48wsgrGvP@public.gmane.org>
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 15241cf..5373c03 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -168,8 +168,10 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
da = from->mc_list;
while (da != NULL) {
next = da->next;
- if (!da->da_synced)
+ if (!da->da_synced) {
+ da = next;
continue;
+ }
__dev_addr_delete(&to->mc_list, &to->mc_count,
da->da_addr, da->da_addrlen, 0);
da->da_synced = 0;
^ permalink raw reply related
* Re: [PATCH] Fix infinite loop on dev_mc_unsync()
From: Joe Perches @ 2007-11-09 19:07 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jeff Garzik, David Miller
In-Reply-To: <20071109183733.GA22714@pogo>
On Fri, 2007-11-09 at 13:51 -0500, Luis R. Rodriguez wrote:
> While reviewing net/core/dev_mcast.c I found what I think is an
> infinite loop on dev_mc_unsync(). This fixes it. We make use of
> this guy on mac80211 in ieee80211_stop(). This is untested.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof-NvJAj8134tRxEa0u/P/EHDe48wsgrGvP@public.gmane.org>
>
> diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
> index 15241cf..5373c03 100644
> --- a/net/core/dev_mcast.c
> +++ b/net/core/dev_mcast.c
> @@ -168,8 +168,10 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
> da = from->mc_list;
> while (da != NULL) {
> next = da->next;
> - if (!da->da_synced)
> + if (!da->da_synced) {
> + da = next;
> continue;
> + }
> __dev_addr_delete(&to->mc_list, &to->mc_count,
> da->da_addr, da->da_addrlen, 0);
> da->da_synced = 0;
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Perhaps this is clearer as:
void dev_mc_unsync(struct net_device *to, struct net_device *from)
{
struct dev_addr_list *da;
netif_tx_lock_bh(from);
netif_tx_lock_bh(to);
da = from->mc_list;
while (da) {
if (da->da_synced) {
__dev_addr_delete(&to->mc_list, &to->mc_count,
da->da_addr, da->da_addrlen, 0);
__dev_addr_delete(&from->mc_list, &from->mc_count,
da->da_addr, da->da_addrlen, 0);
da->da_synced = 0;
}
da = da->next;
}
__dev_set_rx_mode(to);
netif_tx_unlock_bh(to);
netif_tx_unlock_bh(from);
}
EXPORT_SYMBOL(dev_mc_unsync);
^ permalink raw reply
* Re: [PATCH] Fix infinite loop on dev_mc_unsync()
From: Luis R. Rodriguez @ 2007-11-09 19:21 UTC (permalink / raw)
To: Joe Perches
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jeff Garzik, David Miller
In-Reply-To: <1194635236.19522.3.camel@localhost>
On Fri, Nov 09, 2007 at 11:07:16AM -0800, Joe Perches wrote:
> On Fri, 2007-11-09 at 13:51 -0500, Luis R. Rodriguez wrote:
> > While reviewing net/core/dev_mcast.c I found what I think is an
> > infinite loop on dev_mc_unsync(). This fixes it. We make use of
> > this guy on mac80211 in ieee80211_stop(). This is untested.
> >
> > Signed-off-by: Luis R. Rodriguez <mcgrof-NvJAj8134tRxEa0u/P/EHDe48wsgrGvP@public.gmane.org>
> >
> > diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
> > index 15241cf..5373c03 100644
> > --- a/net/core/dev_mcast.c
> > +++ b/net/core/dev_mcast.c
> > @@ -168,8 +168,10 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
> > da = from->mc_list;
> > while (da != NULL) {
> > next = da->next;
> > - if (!da->da_synced)
> > + if (!da->da_synced) {
> > + da = next;
> > continue;
> > + }
> > __dev_addr_delete(&to->mc_list, &to->mc_count,
> > da->da_addr, da->da_addrlen, 0);
> > da->da_synced = 0;
> > -
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Perhaps this is clearer as:
>
> void dev_mc_unsync(struct net_device *to, struct net_device *from)
> {
> struct dev_addr_list *da;
>
> netif_tx_lock_bh(from);
> netif_tx_lock_bh(to);
>
> da = from->mc_list;
> while (da) {
> if (da->da_synced) {
> __dev_addr_delete(&to->mc_list, &to->mc_count,
> da->da_addr, da->da_addrlen, 0);
> __dev_addr_delete(&from->mc_list, &from->mc_count,
> da->da_addr, da->da_addrlen, 0);
> da->da_synced = 0;
> }
> da = da->next;
> }
>
> __dev_set_rx_mode(to);
>
> netif_tx_unlock_bh(to);
> netif_tx_unlock_bh(from);
> }
> EXPORT_SYMBOL(dev_mc_unsync);
Sure, or better with a for loop and do away with next pointer then:
void dev_mc_unsync(struct net_device *to, struct net_device *from)
{
struct dev_addr_list *da;
netif_tx_lock_bh(from);
netif_tx_lock_bh(to);
for (da = from->mc_list; da; da = da->next) {
if (!da->da_synced)
continue;
__dev_addr_delete(&to->mc_list, &to->mc_count,
da->da_addr, da->da_addrlen, 0);
da->da_synced = 0;
__dev_addr_delete(&from->mc_list, &from->mc_count,
da->da_addr, da->da_addrlen, 0);
}
__dev_set_rx_mode(to);
netif_tx_unlock_bh(to);
netif_tx_unlock_bh(from);
}
EXPORT_SYMBOL(dev_mc_unsync);
Patch below.
Signed-off-by: Luis R. Rodriguez <mcgrof-NvJAj8134tRxEa0u/P/EHDe48wsgrGvP@public.gmane.org>
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 15241cf..2aea8e1 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -160,14 +160,12 @@ EXPORT_SYMBOL(dev_mc_sync);
*/
void dev_mc_unsync(struct net_device *to, struct net_device *from)
{
- struct dev_addr_list *da, *next;
+ struct dev_addr_list *da;
netif_tx_lock_bh(from);
netif_tx_lock_bh(to);
- da = from->mc_list;
- while (da != NULL) {
- next = da->next;
+ for (da = from->mc_list; da; da = da->next) {
if (!da->da_synced)
continue;
__dev_addr_delete(&to->mc_list, &to->mc_count,
@@ -175,7 +173,6 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
da->da_synced = 0;
__dev_addr_delete(&from->mc_list, &from->mc_count,
da->da_addr, da->da_addrlen, 0);
- da = next;
}
__dev_set_rx_mode(to);
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-09 20:16 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071109132507.GA21232@localhost.localdomain>
On Fri, 9 Nov 2007 16:25:07 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
> [...]
> > right, but whether it does or not doesn't affect your failure outcome
> > either I'm assuming.
> >
> > > > If it's something like 0x03, the u-boot patch will probably look like:
> > > >
> > > > if ((bcsr[12] == 0x10) &&
> > > > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > > immr->sysconf.spridr == SPR_8360E_REV21))
> > > > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > > ...
> > > >
> > > > but these linux patches would remain the same (the clk and data delay
> > > > settings for the UCC's are still valid; it's just the PHY config
> > > > that is triggering your problem from what I can tell).
> > >
> > > Yup, most likely this is not UCC specific, but PHY. For some reason
> > > delays making harm here...
>
> And today I was unable to reproduce yesterday's behaviour. Your
> patches works fine, with sixth patch and without it. With -rxid
> and with just -id.
excellent. btw, you should be paying a 50% packet loss price by not
going with the -rxid. ping your board with '-q -s 1400 -i 0.01 -c 100'
to notice the difference.
>
> Though, after few resets I hit on that:
>
> - - - -
> U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
>
> Reset Status: External/Internal Soft, External/Internal Hard
>
> CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
> Board: Freescale MPC8360EMDS
> I2C: ready
> DRAM: 256 MB (DDR2, 64-bit, ECC on)
> SDRAM: 64 MB (local bus)
> FLASH: 32 MB
> In: serial
> Out: serial
> Err: serial
> Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
> FSL UEC0: Full Duplex
> switching to rgmii 100
> FSL UEC0: Speed 100BT
> FSL UEC0: Link is up
> read wrong value : mii_id 1,mii_reg 2, base e0103120
> read wrong value : mii_id 1,mii_reg 3, base e0103120
> UEC: PHY is Generic MII (ffffffff)
> read wrong value : mii_id 1,mii_reg 1, base e0103120
> read wrong value : mii_id 1,mii_reg 1, base e0103120
> read wrong value : mii_id 1,mii_reg 5, base e0103120
> FSL UEC1: Full Duplex
> switching to rgmii 100
> FSL UEC1: Speed 100BT
> FSL UEC1: Link is up
> FSL UEC0, FSL UEC1
> - - - -
>
> And UCC1 does not work at all. After another reset that message
> disappears and it does work again.
>
the RGMII bcsr settings survive soft-resets, which confuse u-boot since
it uses GMII mode.
Kim
^ permalink raw reply
* Re: stateless 1:1 NAT
From: Florin Andrei @ 2007-11-09 21:04 UTC (permalink / raw)
To: netdev
In-Reply-To: <E1IkrvI-00046G-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Florin Andrei <florin@andrei.myip.org> wrote:
>> OK, if I download 2.6.24-rc1, will it have this feature already?
>
> Yes.
OK, I want to test this feature with 2.6.24-rc2. I compiled
iproute2-2.6.23 with your patch applied.
The problem is, I have no experience with tc (and very little experience
with iproute2 in general). Can you give me an example on how to setup
1:1 NAT for one system?
Let's say, the firewall has the addresses 10.123.0.10 (eth0 outside) and
10.123.1.10 (eth1 inside), the server behind it is 10.123.1.253 and I
want to map the server's address to 10.123.0.253 on the outside interface.
What are the parameters for tc to setup 1:1 NAT like that?
--
Florin Andrei
http://florin.myip.org/
^ permalink raw reply
* Re: [PATCH 2.6.24] RDMA/cxgb3: Set the max_qp_init_rd_atom attribute.
From: Roland Dreier @ 2007-11-09 21:48 UTC (permalink / raw)
To: Steve Wise; +Cc: netdev, general
In-Reply-To: <20071109152158.21493.24110.stgit@dell3.ogc.int>
thanks, applied.
^ permalink raw reply
* Re: [PATCH 2/2]: e1000: avoid lockup durig error recovery
From: Linas Vepstas @ 2007-11-09 22:40 UTC (permalink / raw)
To: Ingo Oeser
Cc: Kok, Auke, wenxiong, e1000-devel, Brandeburg, Jesse, john.ronciak,
jeffrey.t.kirsher, Jeff Garzik, NetDev,
'Stephen Hemminger'
In-Reply-To: <200711091802.36365.netdev@axxeo.de>
On Fri, Nov 09, 2007 at 06:02:34PM +0100, Ingo Oeser wrote:
> Linas Vepstas schrieb:
> > + * napi_enabled_p - return non-zero if napi enabled
> > + *
> > + * Mnemonic: _p stands for "predicate", returning a yes/no
> > + * answer to the question.
>
> Call it "is_napi_enabled()" an nobody will ask :-)
Heh. The suffix _p is standard coding style for lisp/scheme
and first-order logic interpreters. This was my lame attempt
to introduce it to the kernel. I guess that lame duck won't fly.
--linas
^ permalink raw reply
* Re: [PATCH] Fix infinite loop on dev_mc_unsync()
From: Patrick McHardy @ 2007-11-09 23:12 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Joe Perches, netdev, linux-wireless, Jeff Garzik, David Miller
In-Reply-To: <20071109192033.GB22714@pogo>
Luis R. Rodriguez wrote:
> diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
> index 15241cf..2aea8e1 100644
> --- a/net/core/dev_mcast.c
> +++ b/net/core/dev_mcast.c
> @@ -160,14 +160,12 @@ EXPORT_SYMBOL(dev_mc_sync);
> */
> void dev_mc_unsync(struct net_device *to, struct net_device *from)
> {
> - struct dev_addr_list *da, *next;
> + struct dev_addr_list *da;
>
> netif_tx_lock_bh(from);
> netif_tx_lock_bh(to);
>
> - da = from->mc_list;
> - while (da != NULL) {
> - next = da->next;
> + for (da = from->mc_list; da; da = da->next) {
>
This may cause a use-after-free since __dev_addr_delete frees the address
when all references are gone.
> if (!da->da_synced)
> continue;
> __dev_addr_delete(&to->mc_list, &to->mc_count,
> @@ -175,7 +173,6 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
> da->da_synced = 0;
> __dev_addr_delete(&from->mc_list, &from->mc_count,
> da->da_addr, da->da_addrlen, 0);
> - da = next;
> }
>
^ permalink raw reply
* [PATCH 1/5] Net: ibm_newemac, remove SPIN_LOCK_UNLOCKED
From: Jiri Slaby @ 2007-11-09 23:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jeff Garzik, netdev, bryan.wu
ibm_newemac, remove SPIN_LOCK_UNLOCKED
SPIN_LOCK_UNLOCKED is deprecated, use DEFINE_SPINLOCK instead
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
---
commit aefcf0f6b6ab925184e7cebff8b609e4da1f5c0d
tree 9e1e6240f26c759826959e8812885726c520019d
parent f87566db6dd9613dde8de59380cd2f423166511e
author Jiri Slaby <jirislaby@gmail.com> Thu, 25 Oct 2007 11:54:41 +0200
committer Jiri Slaby <jirislaby@gmail.com> Thu, 25 Oct 2007 11:54:41 +0200
drivers/net/ibm_newemac/debug.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/debug.c b/drivers/net/ibm_newemac/debug.c
index 170524e..ada13cd 100644
--- a/drivers/net/ibm_newemac/debug.c
+++ b/drivers/net/ibm_newemac/debug.c
@@ -21,7 +21,7 @@
#include "core.h"
-static spinlock_t emac_dbg_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(emac_dbg_lock);
static void emac_desc_dump(struct emac_instance *p)
{
^ permalink raw reply related
* [PATCH 5/5] Net: sunrpc, remove SPIN_LOCK_UNLOCKED
From: Jiri Slaby @ 2007-11-09 23:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, tom, okir, cel
In-Reply-To: <4827138842526222333@pripojeni.net>
sunrpc, remove SPIN_LOCK_UNLOCKED
SPIN_LOCK_UNLOCKED is deprecated, use DEFINE_SPINLOCK instead
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
commit d5e782e62a4fe2663a012571c3444445d9887b02
tree b993038b020d8c619f6ffdad412fbb992c073513
parent 828042d12cc0aa515e049889aa76d4066df100c0
author Jiri Slaby <jirislaby@gmail.com> Thu, 25 Oct 2007 12:00:13 +0200
committer Jiri Slaby <jirislaby@gmail.com> Thu, 25 Oct 2007 12:00:13 +0200
net/sunrpc/xprt.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 282a9a2..cd641c8 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -62,7 +62,7 @@ static inline void do_xprt_reserve(struct rpc_task *);
static void xprt_connect_status(struct rpc_task *task);
static int __xprt_get_cong(struct rpc_xprt *, struct rpc_task *);
-static spinlock_t xprt_list_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(xprt_list_lock);
static LIST_HEAD(xprt_list);
/*
^ permalink raw reply related
* Re: SIS190.c
From: Francois Romieu @ 2007-11-09 23:45 UTC (permalink / raw)
To: j gleacher; +Cc: jeff, drnlmuller+bugs, netdev, Linux Kernel Mailing List
In-Reply-To: <327198.23103.qm@web57010.mail.re3.yahoo.com>
j gleacher <jgleacher@yahoo.com> :
[sorry for the delay, I was busy]
> I'm not sure how to properly send you this information about subject,
> but with a new Acer Desktop I needed to add 0x0968 to the below to
> get the eth0 recognized.
Ok. Can you check the patch below against 2.6.24-rc2 ?
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index 7200883..51bbb60 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -1549,28 +1549,31 @@ static int __devinit sis190_get_mac_addr_from_eeprom(struct pci_dev *pdev,
}
/**
- * sis190_get_mac_addr_from_apc - Get MAC address for SiS965 model
+ * sis190_get_mac_addr_from_apc - Get MAC address for SiS96x model
* @pdev: PCI device
* @dev: network device to get address for
*
- * SiS965 model, use APC CMOS RAM to store MAC address.
+ * SiS96x model, use APC CMOS RAM to store MAC address.
* APC CMOS RAM is accessed through ISA bridge.
* MAC address is read into @net_dev->dev_addr.
*/
static int __devinit sis190_get_mac_addr_from_apc(struct pci_dev *pdev,
struct net_device *dev)
{
+ static const u16 __devinitdata ids[] = { 0x0965, 0x0966, 0x0968 };
struct sis190_private *tp = netdev_priv(dev);
struct pci_dev *isa_bridge;
u8 reg, tmp8;
- int i;
+ unsigned int i;
net_probe(tp, KERN_INFO "%s: Read MAC address from APC.\n",
pci_name(pdev));
- isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0965, NULL);
- if (!isa_bridge)
- isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0966, NULL);
+ for (i = 0; i < ARRAY_SIZE(ids); i++) {
+ isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, ids[i], NULL);
+ if (isa_bridge)
+ break;
+ }
if (!isa_bridge) {
net_probe(tp, KERN_INFO "%s: Can not find ISA bridge.\n",
> While this enables the interface, the performance is horrible as my
> wlan0 if much faster and eth0 frequently hangs. I'm learning about
> drivers, so I could help if there is a need to troubleshoot this type
> of issue.
"hangs" == no network or no computer ?
Please send:
- a complete dmesg (from boot to poor behavior)
- the output of lspci -vvvxxxx
- the output of mii-diag -v ethX
- the content of /proc/interrupts
--
Ueimor
^ permalink raw reply related
* Re: [PATCH] Fix infinite loop on dev_mc_unsync()
From: Joe Perches @ 2007-11-10 0:08 UTC (permalink / raw)
To: Patrick McHardy
Cc: Luis R. Rodriguez, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jeff Garzik, David Miller
In-Reply-To: <4734E962.3010603-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
On Sat, 2007-11-10 at 00:12 +0100, Patrick McHardy wrote:
> This may cause a use-after-free since __dev_addr_delete frees the address
> when all references are gone.
How about a comment then? Perhaps:
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index ae35405..63576aa 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -165,16 +165,23 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
netif_tx_lock_bh(from);
netif_tx_lock_bh(to);
+ /*
+ This while loop can't be written as
+ for (da = from->mc_list; da; da = da->next)
+ da = from->mc_list and __dev_addr_delete can kfree(from->mc_list)
+ which could cause a use-after-free of da->next
+ */
+
da = from->mc_list;
while (da != NULL) {
next = da->next;
- if (!da->da_synced)
- continue;
- __dev_addr_delete(&to->mc_list, &to->mc_count,
- da->da_addr, da->da_addrlen, 0);
- da->da_synced = 0;
- __dev_addr_delete(&from->mc_list, &from->mc_count,
- da->da_addr, da->da_addrlen, 0);
+ if (da->da_synced) {
+ __dev_addr_delete(&to->mc_list, &to->mc_count,
+ da->da_addr, da->da_addrlen, 0);
+ da->da_synced = 0;
+ __dev_addr_delete(&from->mc_list, &from->mc_count,
+ da->da_addr, da->da_addrlen, 0);
+ }
da = next;
}
__dev_set_rx_mode(to);
^ permalink raw reply related
* Re: [PATCH] Fix infinite loop on dev_mc_unsync()
From: Patrick McHardy @ 2007-11-10 0:13 UTC (permalink / raw)
To: Joe Perches
Cc: Luis R. Rodriguez, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jeff Garzik, David Miller
In-Reply-To: <1194653320.19522.28.camel@localhost>
Joe Perches wrote:
> On Sat, 2007-11-10 at 00:12 +0100, Patrick McHardy wrote:
>
>> This may cause a use-after-free since __dev_addr_delete frees the address
>> when all references are gone.
>>
>
> How about a comment then? Perhaps:
>
> diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
> index ae35405..63576aa 100644
> --- a/net/core/dev_mcast.c
> +++ b/net/core/dev_mcast.c
> @@ -165,16 +165,23 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
> netif_tx_lock_bh(from);
> netif_tx_lock_bh(to);
>
> + /*
> + This while loop can't be written as
> + for (da = from->mc_list; da; da = da->next)
> + da = from->mc_list and __dev_addr_delete can kfree(from->mc_list)
> + which could cause a use-after-free of da->next
> + */
>
Seems unnecessary to me, we also don't comment each list_for_each_entry_safe
iteration. I consider the use of a seperate next variable self-explanatory.
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Michael Neuling @ 2007-11-10 0:20 UTC (permalink / raw)
To: Thomas Klein, paulus
Cc: Jeff Garzik, Christoph Raisch, Jan-Bernd Themann, linux-kernel,
linux-ppc, Marcus Eder, netdev, Stefan Roscher, Michael Ellermann
In-Reply-To: <200711091433.51259.osstklei@de.ibm.com>
> To support ehea driver reloading in a kdump kernel the driver has to
> perform firmware handle deregistrations when the original kernel
> crashes. As there's currently no notifier chain for machine crashes
> this patch enables kdump support in the ehea driver by bending the
> ppc_md.machine_crash_shutdown hook to its own machine crash
> handler. The original machine_crash_shutdown() fn is called
> afterwards. This works fine as long as the ehea driver is the only one
> which does so. Problems may occur if other drivers do the same and
> unload regularly . This patch enables 2.6.24-rc2 to use kdump with
> ehea and only puts a very low risk on base kernel. In 2.6.24 we know
> ehea is the only user of this mechanism. The next step for 2.6.25
> would be to add a proper notifier chain. The full solution might be
> that register_reboot_notifier() provides sth like a SYS_CRASH
> action. Please apply.
If we are going to do this workaround, I'd prefer the notifier chain be
done correctly now. The way it's hacked in here, it's more likely to
cause even more issues.
Either way, if this is going to go in, it at least needs to be acked by
Paulus.
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
>
> ---
> drivers/net/ehea/ehea.h | 2 +-
> drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
> index f78e5bf..5935899 100644
> --- a/drivers/net/ehea/ehea.h
> +++ b/drivers/net/ehea/ehea.h
> @@ -40,7 +40,7 @@
> #include <asm/io.h>
>
> #define DRV_NAME "ehea"
> -#define DRV_VERSION "EHEA_0080"
> +#define DRV_VERSION "EHEA_0081"
>
> /* eHEA capability flags */
> #define DLPAR_PORT_ADD_REM 1
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index f0319f1..40a732e 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -37,6 +37,7 @@
> #include <linux/reboot.h>
>
> #include <net/ip.h>
> +#include <asm-powerpc/machdep.h>
>
> #include "ehea.h"
> #include "ehea_qmr.h"
> @@ -98,6 +99,7 @@ static int port_name_cnt = 0;
> static LIST_HEAD(adapter_list);
> u64 ehea_driver_flags = 0;
> struct work_struct ehea_rereg_mr_task;
> +static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
>
> struct semaphore dlpar_mem_lock;
>
> @@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
> .notifier_call = ehea_reboot_notifier,
> };
>
> +void ehea_crash_notifier(struct pt_regs *regs)
> +{
> + ehea_info("Machine crash: freeing all eHEA resources");
> + ibmebus_unregister_driver(&ehea_driver);
> + orig_machine_crash_shutdown(regs);
> +}
> +
> +void ehea_register_crash_notifier(void)
> +{
> +#ifdef CONFIG_KEXEC
> + orig_machine_crash_shutdown =
> + (void*)__xchg_u64((unsigned long*)&ppc_md.machine_crash_shutd
own,
> + (unsigned long)ehea_crash_notifier);
> +#endif
> +}
> +
> +void ehea_unregister_crash_notifier(void)
> +{
> +#ifdef CONFIG_KEXEC
> + ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
> +#endif
> +}
> +
> static int check_module_parm(void)
> {
> int ret = 0;
> @@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
> goto out;
>
> register_reboot_notifier(&ehea_reboot_nb);
> + ehea_register_crash_notifier();
>
> ret = ibmebus_register_driver(&ehea_driver);
> if (ret) {
> @@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
> ehea_error("failed to register capabilities attribute, ret=%d",
> ret);
> unregister_reboot_notifier(&ehea_reboot_nb);
> + ehea_unregister_crash_notifier();
> ibmebus_unregister_driver(&ehea_driver);
> goto out;
> }
> @@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
> driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
> ibmebus_unregister_driver(&ehea_driver);
> unregister_reboot_notifier(&ehea_reboot_nb);
> + ehea_unregister_crash_notifier();
> ehea_destroy_busmap();
> }
>
> --
> 1.5.2
>
^ permalink raw reply
* [PATCH 8/13] tg3: Limit 5784 / 5764 to MAC LED mode
From: Matt Carlson @ 2007-11-10 0:38 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, Michael Chan
Most 5784 / 5764 LED modes do not work as expected because of a hardware
bug. This patch forces the LED mode to be in MAC LED mode.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index b5c4799..bb3b734 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -10610,6 +10610,9 @@ static void __devinit tg3_get_eeprom_hw_cfg(struct tg3 *tp)
tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL)
tp->led_ctrl = LED_CTRL_MODE_PHY_2;
+ if (tp->pci_chip_rev_id == CHIPREV_ID_5784_A0)
+ tp->led_ctrl = LED_CTRL_MODE_MAC;
+
if (nic_cfg & NIC_SRAM_DATA_CFG_EEPROM_WP) {
tp->tg3_flags |= TG3_FLAG_EEPROM_WRITE_PROT;
if ((tp->pdev->subsystem_vendor ==
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox