Re: [2/2] 2.6.22-rc4: known regressions with patches v3
A Wednesday 13 June 2007 21:35:02, Greg KH escreveu: > On Wed, Jun 13, 2007 at 09:58:05PM +0200, Michal Piotrowski wrote: > > USB > > > > Subject: list_add corruption. prev->next should be next (f7d28794), > > but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33 > > References : http://bugzilla.kernel.org/show_bug.cgi?id=8561 > > Submitter : Paulo Pereira <[EMAIL PROTECTED]> > > Handled-By : Alan Stern <[EMAIL PROTECTED]> > > Patch : http://bugzilla.kernel.org/show_bug.cgi?id=8561#c8 > > Status : patch was suggested > > I'm pretty sure this wasn't a "regression" and was always there, and > that the proposed patch did fix the solution, right Paulo and Alan? > > thanks, > > greg k-h No I haven't fix the problem... I'am waiting for a friend that is in holiday's and work's with linux well. I'am beginer in linux and I can't put the patch to work, because of that I'am waiting for him to see if the patch work. Sorry, the fact I don't say anything about the problem but my friend comes this week and them we put the patch and I will tell something!! Regards, Paulo. - 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
[PATCH] ehea: Whitespace cleanup
This patch fixes several whitespace issues.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index c0f81b5..abaf3ac 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0064"
+#define DRV_VERSION"EHEA_0065"
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -136,10 +136,10 @@ void ehea_dump(void *adr, int len, char *msg);
(0xULL >> ((64 - (mask)) & 0x))
#define EHEA_BMASK_SET(mask, value) \
-((EHEA_BMASK_MASK(mask) & ((u64)(value))) << EHEA_BMASK_SHIFTPOS(mask))
+ ((EHEA_BMASK_MASK(mask) & ((u64)(value))) << EHEA_BMASK_SHIFTPOS(mask))
#define EHEA_BMASK_GET(mask, value) \
-(EHEA_BMASK_MASK(mask) & (((u64)(value)) >> EHEA_BMASK_SHIFTPOS(mask)))
+ (EHEA_BMASK_MASK(mask) & (((u64)(value)) >> EHEA_BMASK_SHIFTPOS(mask)))
/*
* Generic ehea page
@@ -190,7 +190,7 @@ struct ehea_av;
* Queue attributes passed to ehea_create_qp()
*/
struct ehea_qp_init_attr {
-/* input parameter */
+ /* input parameter */
u32 qp_token; /* queue token */
u8 low_lat_rq1;
u8 signalingtype; /* cqe generation flag */
@@ -212,7 +212,7 @@ struct ehea_qp_init_attr {
u64 recv_cq_handle;
u64 aff_eq_handle;
-/* output parameter */
+ /* output parameter */
u32 qp_nr;
u16 act_nr_send_wqes;
u16 act_nr_rwqes_rq1;
@@ -279,12 +279,12 @@ struct ehea_qp {
* Completion Queue attributes
*/
struct ehea_cq_attr {
-/* input parameter */
+ /* input parameter */
u32 max_nr_of_cqes;
u32 cq_token;
u64 eq_handle;
-/* output parameter */
+ /* output parameter */
u32 act_nr_of_cqes;
u32 nr_pages;
};
diff --git a/drivers/net/ehea/ehea_hw.h b/drivers/net/ehea/ehea_hw.h
index 1246757..1af7ca4 100644
--- a/drivers/net/ehea/ehea_hw.h
+++ b/drivers/net/ehea/ehea_hw.h
@@ -211,34 +211,34 @@ static inline void epa_store_acc(struct h_epa epa, u32
offset, u64 value)
}
#define epa_store_eq(epa, offset, value)\
-epa_store(epa, EQTEMM_OFFSET(offset), value)
+ epa_store(epa, EQTEMM_OFFSET(offset), value)
#define epa_load_eq(epa, offset)\
-epa_load(epa, EQTEMM_OFFSET(offset))
+ epa_load(epa, EQTEMM_OFFSET(offset))
#define epa_store_cq(epa, offset, value)\
-epa_store(epa, CQTEMM_OFFSET(offset), value)
+ epa_store(epa, CQTEMM_OFFSET(offset), value)
#define epa_load_cq(epa, offset)\
-epa_load(epa, CQTEMM_OFFSET(offset))
+ epa_load(epa, CQTEMM_OFFSET(offset))
#define epa_store_qp(epa, offset, value)\
-epa_store(epa, QPTEMM_OFFSET(offset), value)
+ epa_store(epa, QPTEMM_OFFSET(offset), value)
#define epa_load_qp(epa, offset)\
-epa_load(epa, QPTEMM_OFFSET(offset))
+ epa_load(epa, QPTEMM_OFFSET(offset))
#define epa_store_qped(epa, offset, value)\
-epa_store(epa, QPEDMM_OFFSET(offset), value)
+ epa_store(epa, QPEDMM_OFFSET(offset), value)
#define epa_load_qped(epa, offset)\
-epa_load(epa, QPEDMM_OFFSET(offset))
+ epa_load(epa, QPEDMM_OFFSET(offset))
#define epa_store_mrmw(epa, offset, value)\
-epa_store(epa, MRMWMM_OFFSET(offset), value)
+ epa_store(epa, MRMWMM_OFFSET(offset), value)
#define epa_load_mrmw(epa, offset)\
-epa_load(epa, MRMWMM_OFFSET(offset))
+ epa_load(epa, MRMWMM_OFFSET(offset))
#define epa_store_base(epa, offset, value)\
-epa_store(epa, HCAGR_OFFSET(offset), value)
+ epa_store(epa, HCAGR_OFFSET(offset), value)
#define epa_load_base(epa, offset)\
-epa_load(epa, HCAGR_OFFSET(offset))
+ epa_load(epa, HCAGR_OFFSET(offset))
static inline void ehea_update_sqa(struct ehea_qp *qp, u16 nr_wqes)
{
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9e13433..bdb5241 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -81,7 +81,7 @@ MODULE_PARM_DESC(use_mcs, " 0:NAPI, 1:Multiple receive
queues, Default = 1 ");
static int port_name_cnt = 0;
static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
-const struct of_device_id *id);
+ const struct of_device_id *id);
static int __devexit ehea_remove(struct ibmebus_dev *dev);
@@ -236,7 +236,7 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
rwqe = ehea_get_next_rwqe(qp, rq_nr);
rwqe->wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE, wqe_type)
- | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
+ | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
rwqe->sg_list[0].l_key = pr->recv_mr.lkey;
rwqe->sg_list
[IPV6] addrconf: Fix IPv6 on tuntap tunnels
Hi Dave:
[IPV6] addrconf: Fix IPv6 on tuntap tunnels
The recent patch that added ipv6_hwtype is broken on tuntap tunnels.
Indeed, it's broken on any device that does not pass the ipv6_hwtype
test.
The reason is that the original test only applies to autoconfiguration,
not IPv6 support. IPv6 support is allowed on any device. In fact,
even with the ipv6_hwtype patch applied you can still add IPv6 addresses
to any interface that doesn't pass thw ipv6_hwtype test provided that
they have a sufficiently large MTU. This is a serious problem because
come deregistration time these devices won't be cleaned up properly.
I've gone back and looked at the rationale for the patch. It appears
that the real problem is that we were creating IPv6 devices even if the
MTU was too small. So here's a patch which fixes that and reverts the
ipv6_hwtype stuff.
Thanks to Kanru Chen for reporting this issue.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5a5f8bd..f96ed76 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2154,6 +2154,15 @@ static void addrconf_dev_config(struct net_device *dev)
ASSERT_RTNL();
+ if ((dev->type != ARPHRD_ETHER) &&
+ (dev->type != ARPHRD_FDDI) &&
+ (dev->type != ARPHRD_IEEE802_TR) &&
+ (dev->type != ARPHRD_ARCNET) &&
+ (dev->type != ARPHRD_INFINIBAND)) {
+ /* Alas, we support only Ethernet autoconfiguration. */
+ return;
+ }
+
idev = addrconf_add_dev(dev);
if (idev == NULL)
return;
@@ -2241,36 +2250,16 @@ static void addrconf_ip6_tnl_config(struct net_device
*dev)
ip6_tnl_add_linklocal(idev);
}
-static int ipv6_hwtype(struct net_device *dev)
-{
- if ((dev->type == ARPHRD_ETHER) ||
- (dev->type == ARPHRD_LOOPBACK) ||
- (dev->type == ARPHRD_SIT) ||
- (dev->type == ARPHRD_TUNNEL6) ||
- (dev->type == ARPHRD_FDDI) ||
- (dev->type == ARPHRD_IEEE802_TR) ||
- (dev->type == ARPHRD_ARCNET) ||
- (dev->type == ARPHRD_INFINIBAND))
- return 1;
-
- return 0;
-}
-
static int addrconf_notify(struct notifier_block *this, unsigned long event,
void * data)
{
struct net_device *dev = (struct net_device *) data;
- struct inet6_dev *idev;
+ struct inet6_dev *idev = __in6_dev_get(dev);
int run_pending = 0;
- if (!ipv6_hwtype(dev))
- return NOTIFY_OK;
-
- idev = __in6_dev_get(dev);
-
switch(event) {
case NETDEV_REGISTER:
- if (!idev) {
+ if (!idev && dev->mtu >= IPV6_MIN_MTU) {
idev = ipv6_add_dev(dev);
if (!idev)
printk(KERN_WARNING "IPv6: add_dev failed for
%s\n",
-
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
Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
Hi, Jamal, Now the genl utility can find the acpi event genetlink family. And a simple user space demo is finished for handling acpi event. I really appreciate your help. :) I think the patch which exposes ACPI events via netlink is ok. But I still have some problems on how to listen to specified genetlink family in user space? I can get the dynamic id for "acpi_event" genl family. But I don't know how to use this to receive messages from specified genl family. It seems that "#genl ctrl monitor" has something to do with this, IMO, rtnl_open_byproto(&rth, nl_mgrp(GENL_ID_CTRL), NETLINK_GENERIC) is used to receive messages from the nlctrl(controller) only, but unfortunately it never works for me. :( Any suggestions? What interfaces should I use? Or where can I find some example code? Attachment is the simple user space demo I made. It receives all the broadcasted genetlink messages and only parses the ones sent by "acpi_event" genl family. Thanks, Rui On Sun, 2007-05-27 at 09:34 -0400, jamal wrote: > On 5/27/07, Zhang Rui <[EMAIL PROTECTED]> wrote: > > > > I need to write a user application to test my patch. > > Netlink messages can be sent/received using the standard socket API. > > sure. > > > But how to receive Genetlink messages from specified genetlink family? > > There is no socket ACPI with such a parameter, right? > > Each module has a unique identifier that it receives dynamically on > insertion at the kernel. > > > Do I have to receive all the genetlink messages first? > > No, just the ones for your dynamic id. Try what i described first for > kernel side on the earlier email. I will repeat it here for clarity. > Then look at genl code and if you have questions i can > help. > Note: You need to discover your dynamic id (the iproute2/genl code has a stub > example code) > As i told you in the earlier email, in your development: > - start first by just writting your kernel side. > - Then use the genl utility - which is part of iproute2 to see if the > kernel side is "discoverable". > > E.g if i wanted to "discover" currently loaded modules on my laptop, i > would do this: > > --- > [EMAIL PROTECTED]:~$ genl ctrl ls > > Name: nlctrl > ID: 0x10 Version: 0x2 header size: 0 max attribs: 6 > commands supported: > #1: ID-0x3 flags-0xe > > > Name: nl80211 > ID: 0x11 Version: 0x1 header size: 0 max attribs: 22 > commands supported: > #1: ID-0x1 flags-0xa > #2: ID-0x6 flags-0xa > #3: ID-0x8 flags-0xa > #4: ID-0x3 flags-0xb > #5: ID-0x4 flags-0xb > #6: ID-0x5 flags-0xb > #7: ID-0xa flags-0xb > #8: ID-0xb flags-0xa > #9: ID-0xf flags-0xb > #10: ID-0x10 flags-0xa > #11: ID-0x12 flags-0xb > #12: ID-0x13 flags-0xa > #13: ID-0x15 flags-0xa > #14: ID-0x19 flags-0xb > #15: ID-0x17 flags-0xb > #16: ID-0x18 flags-0xb > #17: ID-0x1a flags-0xb > #18: ID-0x1b flags-0xa > #19: ID-0xd flags-0xb > > > Name: TASKSTATS > ID: 0x12 Version: 0x1 header size: 0 max attribs: 4 > commands supported: > #1: ID-0x1 flags-0xa > --- > > As you can see, i can see from user space the name of the kernel end > point, its numeric id, what version it is running (so i can make sure > user space is compatible), what extra header it may have, what the > maximum number of attributes it can take. The last thing that gets > listed is the commands, and flags for those commands. > > Lets load tipc kernel module and repeat... > > --- > > [EMAIL PROTECTED]:~$ sudo modprobe tipc > Name: nlctrl > ID: 0x10 Version: 0x2 header size: 0 max attribs: 6 > commands supported: > #1: ID-0x3 flags-0xe > > > [same as before] > > > Name: TIPC > ID: 0x13 Version: 0x1 header size: 8 max attribs: 0 > commands supported: > #1: ID-0x1 flags-0x2 > > === > > > It would be great if there are any examples on user space communication. > > > > Bug Thomas - he has written some simple example. I also have some but i > changed laptops and i have to go and dig it up for you. > I do have plans for making this easier for people - but havent had time. > If there is persistence - or someone out there wants to be a hero email > me privately and i will explain it. > > > Or should I use libnl library instead? > > Why am i answering all these questions if you are fine with using libnl? > Last time you said you couldnt use a library, no? > > cheers, > jamal > > > > Thanks, > > Rui. > > acpi_genl.tgz Description: applicatio
[PATCH] [TCP]: Add missing break to TCP option parsing code
This flaw does not affect any behavior (currently).
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index d506bdc..aaf6f66 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2936,6 +2936,7 @@ void tcp_parse_options(struct sk_buff *skb, struct
tcp_options_received *opt_rx,
opt_rx->sack_ok) {
TCP_SKB_CB(skb)->sacked = (ptr
- 2) - (unsigned char *)th;
}
+ break;
#ifdef CONFIG_TCP_MD5SIG
case TCPOPT_MD5SIG:
/*
--
1.5.0.6
Re: [2/2] 2.6.22-rc4: known regressions v3
Hi All, They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. Regards Mark Fortescue. On Wed, 13 Jun 2007, William Lee Irwin III wrote: On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote: The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Very interesting. Any hints as to how to test or how long to wait before the illegal instructions happen? -- wli - 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
[PATCH]is_power_of_2-net/core/neighbour.c
Replacing (n & (n-1)) in the context of power of 2 checks with is_power_of_2 Signed-off-by: vignesh babu <[EMAIL PROTECTED]> --- diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 6f3bb73..e663999 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -33,6 +33,7 @@ #include #include #include +#include #define NEIGH_DEBUG 1 @@ -311,7 +312,7 @@ static void neigh_hash_grow(struct neigh_table *tbl, unsigned long new_entries) NEIGH_CACHE_STAT_INC(tbl, hash_grows); - BUG_ON(new_entries & (new_entries - 1)); + BUG_ON(!is_power_of_2(new_entries)); new_hash = neigh_hash_alloc(new_entries); if (!new_hash) return; -- Vignesh Babu BM _ "Why is it that every time I'm with you, makes me believe in magic?" - 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
Re: [PATCH 2/2] qdisc_restart - couple of optimizations.
On Wed, Jun 13, 2007 at 02:10:49PM +0530, Krishna Kumar wrote:
>
> - BUG_ON((int) q->q.qlen < 0) was a relic from old times when -1
> meant more packets are available, and __qdisc_run used to loop
> when qdisc_restart() returned -1. During those days, it was
> necessary to make sure that qlen is never less than zero, since
> __qdisc_run would get into an infinite loop if no packets are on
> the queue and this bug in qdisc was there (and worse - no more
> skbs could ever get queue'd as we hold the queue lock too). With
> Herbert's recent change to return values, this check is not
> required. Hopefully Herbert can validate this change. If at all
> this is required, it should be added to skb_dequeue (in failure
> case), and not to qdisc_qlen.
Yes I agree that this check is no longer critical.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
Re: [PATCH 2/2] qdisc_restart - couple of optimizations.
On Wed, Jun 13, 2007 at 10:51:00AM -0700, Waskiewicz Jr, Peter P wrote:
>
> I somewhat disagree here. The underlying driver can conceivably stop
> the device queue even if the stack holds the queue lock during an
> interrupt to clean Tx descriptors, and it finds it's out of them or
> needs to grab the device for whatever reason. Granted this is a corner
> case, and the net effect would be a simple requeue of the skb, but
> checking the status of the queue at the last possible moment before
> entering the driver could alleviate the requeue in the time between
> ->dequeue() from the qdisc, and hard_start_xmit() if an event like I
> mentioned happened.
IMHO this scenario occurs so infrequently that the check isn't worth it
especially since the driver has to be able to deal with us calling it
after netif_stop_queue() anyway.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Thu, 2007-14-06 at 16:59 +0800, Zhang Rui wrote: > Hi, Jamal, > > Now the genl utility can find the acpi event genetlink family. > And a simple user space demo is finished for handling acpi event. > I really appreciate your help. :) np. > I think the patch which exposes ACPI events via netlink is ok. > But I still have some problems on > how to listen to specified genetlink family in user space? > > I can get the dynamic id for "acpi_event" genl family. > But I don't know how to use this to receive messages from > specified genl family. > It seems that "#genl ctrl monitor" has something to do with this, > IMO, rtnl_open_byproto(&rth, nl_mgrp(GENL_ID_CTRL), NETLINK_GENERIC) is > used to receive messages from the nlctrl(controller) only, but > unfortunately it never works for me. :( > I dont have much time to look at your code given travel, but did you try to use your group id instead of the controller's? i.e: rtnl_open_byproto(&rth, nl_mgrp(mydiscoveredacpiid), NETLINK_GENERIC) If this doesnt work, ping me and i will take a look - just expect some latency in response. cheers, jamal - 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
Re: [PATCH] NET: Multiqueue network device support.
Hi Yi, On Thu, 2007-14-06 at 10:44 +0800, Zhu Yi wrote: > On Wed, 2007-06-13 at 08:32 -0400, jamal wrote: > > The key arguement i make (from day one actually) is to leave the > > majority of the work to the driver. > > But it seems not feasible the Qdisc needs to know nothing about the > hardware rings. This discussion is addressing whether it is feasible to do it without the qdisc knowing anything about the hardware ring. > > My view of wireless WMM etc is it is a different media behavior > > (compared to wired ethernet) which means a different view of strategy > > for when it opens the valve to allow in more packets. 802.11 media has > > embedded signalling which is usable. Guy Cohen gave a good use case > > which i responded to. Do you wanna look at that and respond? > > The key to support multi-ring hardware for software is to put packets > into hardware as much/early as possible. Guy gave a good VO vs. BK > example. To achieve this in your model, you have to keep the TX ring > running (in the case of PHL full) and requeue. But when there are only > BK packets coming, you do want to stop the ring, right? AFAICS, the > driver is not the best place to make the decision (it only knows the > current and previous packets, but not the _next_), the Qdisc is the best > place. > I dont have much time to followup for sometime to come. I have left my answer above. To clarify, incase i wasnt clear, I am saying: a) It is better to have the driver change via some strategy of when to open the tx path than trying to be generic. This shifts the burden to the driver. b) given the behavior of wireless media (which is very different from wired ethernet media), you need a different strategy. In response to Guy's question, I gave the example of being able to use management frames to open up the tx path for VO (even when you dont know VO packets are sitting on the qdisc); alternatively you could use a timer etc. Theres many ways to skin the cat (with apologies to cat lovers/owners). i.e you need to look at the media and be creative. Peters DCE for example could also be handled by having a specific strategy. I will try to continue participating in the discussion (if CCed) but much less for about a week. In any case I think i have had the discussion i was hoping for and trust Patrick understands both sides. This thread has run for too long folks, eh? cheers, jamal - 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
Re: [PATCH][RFC] network splice receive v2
On Wed, Jun 13, 2007 at 12:01:04PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > I will rebase my tree, likely something was not merged correctly. Ok, I've just rebased a tree from recent git and pulled from brick - things seems to be settled. I've ran several tests with different filesizes and all files were received correctly without kernel crashes. There is skb leak indeed, and it looks like it is in the __splice_from_pipe() for the last page. Thanks Jens, good work. -- Evgeniy Polyakov - 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
Re: [PATCH][RFC] network splice receive v2
On Thu, Jun 14 2007, Evgeniy Polyakov wrote: > On Wed, Jun 13, 2007 at 12:01:04PM +0400, Evgeniy Polyakov ([EMAIL > PROTECTED]) wrote: > > I will rebase my tree, likely something was not merged correctly. > > Ok, I've just rebased a tree from recent git and pulled from brick - > things seems to be settled. I've ran several tests with different > filesizes and all files were received correctly without kernel crashes. > There is skb leak indeed, and it looks like it is in the > __splice_from_pipe() for the last page. Uh, the leak, right - I had forgotten about that, was working on getting vmsplice into shape the last two days. Interesting that you mention the last page, I'll dig in now! Any more info on this (how did you notice the leak originates from there)? > Thanks Jens, good work. Thanks, you're welcome! -- Jens Axboe - 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
Re: [PATCH]: ps3: gigabit ethernet driver for PS3
Hi Jeff,
Thanks for your comment.
I'll fix coding style issues.
On Wed, 13 Jun 2007 16:27:32 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > --- a/drivers/net/Makefile
> > +++ b/drivers/net/Makefile
> > @@ -60,6 +60,8 @@ obj-$(CONFIG_TIGON3) += tg3.o
> > obj-$(CONFIG_BNX2) += bnx2.o
> > spidernet-y += spider_net.o spider_net_ethtool.o
> > obj-$(CONFIG_SPIDER_NET) += spidernet.o sungem_phy.o
> > +obj-$(CONFIG_GELIC_NET) += ps3_gelic.o
> > +ps3_gelic-objs += gelic_net.o
> > obj-$(CONFIG_TC35815) += tc35815.o
> > obj-$(CONFIG_SKGE) += skge.o
> > obj-$(CONFIG_SKY2) += sky2.o
>
> How about ps3_gige for the driver name. Ditto DaveM's comments about
> cleanups here.
This change was made to work around a module load/unload issue we met.
I'll check again what the issue was and try to avoid the changes here.
ps3_gige.{c,ko} is preferred one than gelic_net.{c,ko}?
> > +static void gelic_net_set_descr_status(struct gelic_net_descr *descr,
> > + enum gelic_net_descr_status status)
> > +{
> > + u32 cmd_status;
> > +
> > + /* read the status */
> > + cmd_status = descr->dmac_cmd_status;
> > + /* clean the upper 4 bits */
> > + cmd_status &= GELIC_NET_DESCR_IND_PROC_MASKO;
> > + /* add the status to it */
> > + cmd_status |= ((u32)status) << GELIC_NET_DESCR_IND_PROC_SHIFT;
> > + /* and write it back */
> > + descr->dmac_cmd_status = cmd_status;
> > + wmb();
>
> does the wmb() actually do anything useful here?
descr points a descriptor that the ethernet hardware checks.
Since dmac_cmd_status is the field that describes the descriptor is free
or invalid etc., the caller of this function usually wants to talk
something to the hardware. So I do the synchronization here.
> > +static int gelic_net_prepare_rx_descr(struct gelic_net_card *card,
> > + struct gelic_net_descr *descr)
> > +{
> > + int offset;
> > + unsigned int bufsize;
> > +
> > + if (gelic_net_get_descr_status(descr) != GELIC_NET_DESCR_NOT_IN_USE) {
> > + dev_info(ctodev(card), "%s: ERROR status \n", __func__);
> > + }
> > + /* we need to round up the buffer size to a multiple of 128 */
> > + bufsize = (GELIC_NET_MAX_MTU + GELIC_NET_RXBUF_ALIGN - 1) &
> > + (~(GELIC_NET_RXBUF_ALIGN - 1));
>
> use ALIGN()?
>
Nice macro! thanks.
> > + /* and we need to have it 128 byte aligned, therefore we allocate a
> > +* bit more */
> > + descr->skb = netdev_alloc_skb(card->netdev,
> > + bufsize + GELIC_NET_RXBUF_ALIGN - 1);
>
> net_device allocation is already rounded. and combined with the above
> code snippet, it appears you're aligning twice
>
Gelic requies buffer whic is both 128 bytes aligned and multiple of 128
bytes in size.
Does netdev_alloc_skb() guarantee to allocate a skb which has 128byte
aligned buffer?
> > +out:
> > + if (!stop && release && netif_queue_stopped(card->netdev))
> > + netif_wake_queue(card->netdev);
>
> shouldn't need to test netif_queued_stopped() before calling
> netif_wake_queue(), as netif_wake_queue() essentially already does this
OK, I'll fix
> > +
> > + /* set multicast address */
> > + for (mc = netdev->mc_list; mc; mc = mc->next) {
> > + addr = 0;
> > + p = mc->dmi_addr;
> > + for (i = 0; i < ETH_ALEN; i++) {
> > + addr <<= 8;
> > + addr |= *p++;
> > + }
> > + status = lv1_net_add_multicast_address(bus_id(card),
> > dev_id(card),
> > + addr, 0);
> > + if (status)
> > + dev_err(ctodev(card),
> > + "lv1_net_add_multicast_address failed, %d\n",
> > + status);
> > + }
>
> this seems not to handle the promisc case
gelic_net driver does not support promisc mode, as the hypervisor does
not support it.
> > +static void gelic_net_disable_txdmac(struct gelic_net_card *card)
> > +{
> > + int status;
> > +
> > + /* this hvc blocks until the DMA in progress really stopped */
> > + status = lv1_net_stop_tx_dma(bus_id(card), dev_id(card), 0);
> > + if (status)
> > + dev_err(ctodev(card),
> > + "lv1_net_stop_tx_dma faild, status=%d\n", status);
> > +}
>
> do we really need all these three-C-statement functions?
Well, lv1_net_zzz_dma() hypervisor calls are self-descriptive. But
considering the future consolidation with spider_net, I think these
symmetry with spider_net would help.
> > +/**
> > + * gelic_net_xmit - transmits a frame over the device
> > + * @skb: packet to send out
> > + * @netdev: interface device structure
> > + *
> > + * returns 0 on success, <0 on failure
> > + */
> > +static int gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev)
> > +{
> > + struct gelic_net_card *card = netdev_priv(netdev);
> > + struct gelic_net_descr *descr = NULL;
> > + int result;
> > + unsigned long flags;
> > +
> > + spin_lock_
Re: [2/2] 2.6.22-rc4: known regressions v3
On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote: > They apear as soon as simpleinit starts up. Somtimes I get to a login > prompt before seeing any. Other times, commands in the simpleinit rc > script fail. > They do apear to be random. If a command failes, you re-run the command > and it is OK. Commands seen to fail are basic (depmod, rm cat ..). > The test I did use the same binaries with both the OK and problem kernels > so it is not a change to the application code, it is definatly a kernel > issue. This sounds like it may be addressed by benh's ptep_set_access_flags() fixes. Those fixes are still in -mm, hopefully to hit mainline by 2.6.22. -- wli - 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
Re: [2/2] 2.6.22-rc4: known regressions v3
Benh's ptep_set_access_flags() patch needs to be applied in order to get anyware with sun4c for all kernels >= linux-2.6.15. If not applied, you will be lucky to get sash running as your init and even that will have very limitit capabilities before it locks up the processor (power up reset required). It has been applied to both the kernels I used for testing so this problem is independent of the ptep_set_access_flags patch but that does not mean that it is not a related issue. I will try to get some testing done over the weekend to narrow down when the random illegal instructions first occour. If I start with 2.6.21 then if that is OK, then I should be able to narow the issue down without too much trouble. If it is between 2.6.20 and 2.6.21 then it will be a right pig as there are a large number of commits that don't compile for sun4c between these two. What I am hoping is that it occours in the 2.6.22-rc2 as per the x86_64. I am going to have to put a 'reset' button onto my test system as power up resets are bad news on this old hardware and almost all kernel failures result in a processor lockup. I have even had to make BUG reports 'panic' as thoes that I have during kernel fault location had are terminal to a sun4c (they cause a processor lockup). Regards Mark Fortescue. On Thu, 14 Jun 2007, William Lee Irwin III wrote: On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote: They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. This sounds like it may be addressed by benh's ptep_set_access_flags() fixes. Those fixes are still in -mm, hopefully to hit mainline by 2.6.22. -- wli - 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
Re: Realtek r8168 slow outbound transfer - potential fix/workaround
What is the value of the MTU for your 8168 device ? Hi Francois, The MTU for the adapter is set at the default of 1500. A bit more background on how I came across this might be in order. I noticed it when performing very simple SQL queries against a postgres database on my server. I captured the traffic on an XP client machine using wireshark and on the linux server with tcpdump. I noticed that although the linux server claimed to have sent 2 reply packets, XP was seeing only the first. What got me thinking was the fact that the time between the first and second response packets from postgres was 0.05 seconds (according to the tcpdump timestamps). Another 0.4 seconds after that a retry was attempted and the packet managed to make it though to the windows client. I started wondering if there might be something going on with tightly spaced packets and that's how I ended up checking the NPQ flag. (I also looked into increasing the default interframe gap between packets, but that didn't seem to help). I'm happy to help with additional information including the packet captures if you'd like to take a look. Also, I realised after I posted that first message that having a minimum udelay of 25us in that delay loop was probably a bit foolish. I guess I was just so happy to have found something that worked for me that I needed to get it off my chest before thinking it through fully. The udelay(25) ends up increasing the minimum inter-frame gap way beyond what should be reasonable.I haven't had a good chance to test this yet, but I tried dropping the udelay(25) and using ndelay(10) instead and it appeared to load the cpu less that way. Regards, Dave. - 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
Re: [2/2] 2.6.22-rc4: known regressions v3
On Thu, Jun 14, 2007 at 03:57:25PM +0100, Mark Fortescue wrote: > Benh's ptep_set_access_flags() patch needs to be applied in order to get > anyware with sun4c for all kernels >= linux-2.6.15. If not applied, you > will be lucky to get sash running as your init and even that will have > very limitit capabilities before it locks up the processor (power up > reset required). > It has been applied to both the kernels I used for testing so this > problem is independent of the ptep_set_access_flags patch but that > does not mean that it is not a related issue. > I will try to get some testing done over the weekend to narrow down > when the random illegal instructions first occour. > If I start with 2.6.21 then if that is OK, then I should be able to narow > the issue down without too much trouble. If it is between 2.6.20 and > 2.6.21 then it will be a right pig as there are a large number of commits > that don't compile for sun4c between these two. What I am hoping is that > it occours in the 2.6.22-rc2 as per the x86_64. Sounds like I'll be digging through my hardware stockpiles this weekend to find a functional sun4c box. -- wli - 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
Re: r8169 tx problem (1s pause with ping)
Francois Romieu wrote: Benjamin LaHaise <[EMAIL PROTECTED]> : [...] I'm seeing something odd with r8169 on FC7: doing a ping -s 1600 alternates between a 1s latency and sub 1ms. Has anyone else seen anything like this? The system in question is an Asus M2A-VM with an onboard RTL8111 (I think). NAPI doesn't seem to make a difference. The kernel in question is currently a vanilla 2.6.21.5. Sub-mtu sized packets behave normally. Same thing here for my 8168 rev 01 (asrock 945G dvi LOM) with 2.6.22-rc4 and 2.6.22-rc3 + r816x patchkit. Wonderful. I've got a modified version of the latest realtek (r8168) driver running here that doesn't seem to exhibit those symptoms. The trouble I have is that I've been playing with multiple sections of the code and I'm not 100% sure what part(s) might impact that particular test. The bits I know I've messed with are the bits that set the First/Last fragment flags and the NPQ flagging section (as described in my previous emails). I know it's not particularly scientific of me to be changing multiple sections of the driver at once and I'm sorry about that but it's fairly late here and I really should get some sleep :). I might do some more thorough testing on the weekend to find out what the minimal changes required are to get things working. In the mean-time I'll attach my patch for the r8168-8.001.00 realtek driver here in case anybody else wants to have a play with it and see if it helps them out. Also, It might be a silly question, but have you tried taking packet captures from the perspective of the box with the realtek chipset & another box during the pinging and comparing the two? Regards, Dave. r8168-8.001.00-dg.patch.gz Description: GNU Zip compressed data
RE: [PATCH 2/2] qdisc_restart - couple of optimizations.
> IMHO this scenario occurs so infrequently that the check > isn't worth it especially since the driver has to be able to > deal with us calling it after netif_stop_queue() anyway. That sounds just fine to me. Thanks Krishna and Herbert for weighing in on this. -PJ Waskiewicz - 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
Re: [PATCH] [TCP]: Add missing break to TCP option parsing code
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Thu, 14 Jun 2007 12:37:22 +0300 (EEST) > This flaw does not affect any behavior (currently). > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Good catch, patch applied. Thanks! - 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
Re: [IPV6] addrconf: Fix IPv6 on tuntap tunnels
From: Herbert Xu <[EMAIL PROTECTED]> Date: Thu, 14 Jun 2007 18:16:07 +1000 > [IPV6] addrconf: Fix IPv6 on tuntap tunnels > > The recent patch that added ipv6_hwtype is broken on tuntap tunnels. > Indeed, it's broken on any device that does not pass the ipv6_hwtype > test. > > The reason is that the original test only applies to autoconfiguration, > not IPv6 support. IPv6 support is allowed on any device. In fact, > even with the ipv6_hwtype patch applied you can still add IPv6 addresses > to any interface that doesn't pass thw ipv6_hwtype test provided that > they have a sufficiently large MTU. This is a serious problem because > come deregistration time these devices won't be cleaned up properly. > > I've gone back and looked at the rationale for the patch. It appears > that the real problem is that we were creating IPv6 devices even if the > MTU was too small. So here's a patch which fixes that and reverts the > ipv6_hwtype stuff. > > Thanks to Kanru Chen for reporting this issue. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Thanks for fixing this up Herbert. Patch applied. - 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
Re: [GIT PATCHES] SCTP bugfixes
From: Vlad Yasevich <[EMAIL PROTECTED]> Date: Wed, 13 Jun 2007 17:23:03 -0400 > Please pull the following SCTP patches from > master.kernel.org:/pub/scm/linux/kernel/git/vxy/lksctp-dev.git Pulled, thanks a lot Vlad. - 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
[PATCH 2.6.22-rc4-git6] forcedeth: use unicast receive mode for WoL
I happened to notice that a system with an NVidia NIC using the
forcedeth driver won't wake-on-LAN if the interface was in promiscuous
mode when you power off. By experiment, it looks like
the hardware needs to have NvRegPacketFilterFlags set to
NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR (i.e., receive unicast packets to my
address) in order for WoL to work.
Jeff Garzik writes: "NVIDIA says the patch looks OK." I didn't venture
to insert a signed-off-by line with his name on it, though.
Signed-off-by: Tim Mann <[EMAIL PROTECTED]>
---
(Jeff, thanks for pointing me to the doc for the proper patch format.)
--- 2.6.22-rc4-git6/drivers/net/forcedeth.c 2007-06-14 12:56:47.078002000
-0700
+++ 2.6.22-rc4-git6-fixed/drivers/net/forcedeth.c 2007-06-14
12:56:21.200146000 -0700
@@ -4825,8 +4825,10 @@
drain_ring(dev);
- if (np->wolenabled)
+ if (np->wolenabled) {
+ writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base +
NvRegPacketFilterFlags);
nv_start_rx(dev);
+ }
/* FIXME: power down nic */
--
Tim Mann work: [EMAIL PROTECTED] home: [EMAIL PROTECTED]
http://www.vmware.com http://tim-mann.org
-
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
Re: [ANNOUNCE] new driver ixgbe for Intel(R) 10GbE PCI Express adapters.
Ayyappan Veeraiyan <[EMAIL PROTECTED]> : [...] > netpoll_send_skb should not deadlock because ixgbe_xmit_frame should > bail out because of this... > > if (!spin_trylock_irqsave(&tx_ring->tx_lock, flags)) > /* Collision - tell upper layer to requeue */ > return NETDEV_TX_LOCKED; > > Right? Yes. -- Ueimor - 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
Re: [2/2] 2.6.22-rc4: known regressions v3
On Wed, 13 Jun 2007 21:57:56 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote: > Hi all, > > Here is a list of some known regressions in 2.6.22-rc4. > > Feel free to add new regressions/remove fixed etc. > http://kernelnewbies.org/known_regressions > > > > Networking > > Subject: commit 9093bbb2d96d0184f037cea9b4e952a44ebe7c32 broke the > bonding driver > References : http://lkml.org/lkml/2007/6/13/65 > Submitter : Dan Aloni <[EMAIL PROTECTED]> > Handled-By : Stephen Hemminger <[EMAIL PROTECTED]> > Status : Unknown > > Patch available (to bonding). - 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
Re: [PATCH 1/15] spidernet: null out skb pointer after its been used.
On Wed, Jun 13, 2007 at 04:10:17PM -0400, Jeff Garzik wrote: > Linas Vepstas wrote: > >Avoid kernel crash in mm/slab.c due to double-free of pointer. > > > >If the ethernet interface is brought down while there is still > >RX traffic in flight, the device shutdown routine can end up > >trying to double-free an skb, leading to a crash in mm/slab.c > >Avoid the double-free by nulling out the skb pointer. > > > >Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > > > > > > drivers/net/spider_net.c |1 + > > 1 file changed, 1 insertion(+) > > applied 1-5, 7 to #upstream-fixes (2.6.22) > > patch #6 was ignored, because it was already upstream Thank you! --linas - 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
Re: r8169 tx problem (1s pause with ping)
David Gundersen <[EMAIL PROTECTED]> : [...] > I might do some more thorough testing on the weekend to find out what > the minimal changes required are to get things working. In your patch, the first chunk of data (which is handed back to the nic outside of rtl8169_xmit_frags) will not have is First fragment bit set when nr_frags != 0. It makes me a bit nervous. The NPQ part of your patch actually forces the start_xmit handler to wait for all previously queued packets to be sent before telling the nic that a packet may be available. I can understand that it will fix the symptoms but it will implicitly shorten the TX queue a lot. A pesky fever apart, I should be able to come with a patch before the week end. -- Ueimor - 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
Re: [Cbe-oss-dev] [PATCH 0/15] spidernet driver bug fixes
On Wed, 2007-06-13 at 11:14 -0500, Linas Vepstas wrote: > Some googling seems to show that "git pull" has a bug/feature of > ignoring the branch that one is working in, and pulling "master" > no matter what. I have no clue why; this seems broken to me. Branches are generally a PITA -- it's probably best just to avoid them entirely. It's not as if it's hard to create separate trees, and even share objects between the trees. -- dwmw2 - 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
Re: [Cbe-oss-dev] [PATCH 12/15] spidernet: increase the NAPI weight
On Wed, Jun 13, 2007 at 10:49:51PM +0200, Arnd Bergmann wrote: > On Wednesday 13 June 2007, Jeff Garzik wrote: > > > +/* We really really want to empty the ring buffer every time, > > > + * so as to avoid the RX ram full bug. So set te napi wieght > > > + * to the ring size. > > > + */ > > > +#define SPIDER_NET_NAPI_WEIGHT SPIDER_NET_RX_DESCRIPTORS_DEFAULT > > > > I don't see why spider_net should have a different NAPI weight from > > other drivers It was a lame attempt to try to trick napi into draining the entire RX queue in one go, with the goal of avoiding the dreaded rx ram full. I'm not sure it made much of a difference, so we can let this slide. > Would it help to do it the other way round, as in No, that would shorten the RX queue, thus making it more likely to overflow. At gigabit speeds, its petty easy to fill this thing up multiple times per jiffy. The driver should continue to operate either way, but the larger queue should keep it from being a busy beaver. --linas - 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
Handling IPv6 RDNSS in RA
[Re-sending an earlier email, this time with a wider distribution and more details.] I'd like to get opinions on how DNS information packaged with IPv6 Router Advertisement packages should be handled. The OLPC project (laptop.org) is currently planning to use this for DNS autoconfiguration. The draft RFC is at: http://tools.ietf.org/html/draft-jeong-dnsop-ipv6-dns-discovery-12 There is already code in radvd to support this. [For reference, the Router Advertisement (RA) option is called RDNSS, for 'Recursive DNS Server'.] Two alternatives seem obvious: 1) Parse the RDNSS option in the kernel. linux/net/ipv6/ndisc.c already parses the other RAdv options; it just need to be extended to parse RDNSS and export the 'last seen DNS conf' in the same way it does the Managed/Other flags at http://lxr.linux.no/source/net/ipv6/ndisc.c?v=2.6.20.1#L1115 [Incidentally, I suspect I can get at the Managed/Other flags via netlink, but would appreciate advice.] 2) Parse the RDNSS information entirely in userspace. The NetworkManager(1) daemon would keep a socket open to listen to all ICMPv6 messages, reparse the RA, and deal with RDNSS information. This has the disadvantage of requiring redundant tracking of RA lifetimes, and would require NetworkManager to send (likely redundant) Router Solicitation messages when/if the RDNSS information expires. Option 2 seems like duplication of work, but arguably keeps the kernel small. Honestly, I'm surprised that IPv6 autoconfiguration is in the kernel at all. But since it's there already, option 1's making RDNSS' 3*(128/8) bytes available via netlink doesn't seem too terrible to me. But if such a patch has no hope of being accepted into the mainline kernel, I'd rather know now than later. Also: are there other implementations which use the RA DNS info? Maybe in fact someone has already written the necessary kernel patch? I always prefer not to reinvent the wheel. --scott -- ( http://cscott.net/ ) - 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
Re: [PATCH 4/15] spidernet: silence the ramfull messages
On Wed, Jun 13, 2007 at 04:12:00PM -0400, Jeff Garzik wrote:
> Linas Vepstas wrote:
> >--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-06-11
> >10:02:34.0 -0500
> >+++ linux-2.6.22-rc1/drivers/net/spider_net.c2007-06-11
> >11:45:25.0 -0500
> >@@ -1172,7 +1172,7 @@ spider_net_decode_one_descr(struct spide
> > goto bad_desc;
> > }
> >
> >-if (hwdescr->dmac_cmd_status & 0xfefe) {
> >+if (hwdescr->dmac_cmd_status & 0xfcf4) {
> > pr_err("%s: bad status, cmd_status=x%08x\n",
> >card->netdev->name,
> >hwdescr->dmac_cmd_status);
>
>
> A follow-up patch needs to remove the above magic numbers (==numeric
> constants), replacing them with named constants
I thought laziness was a virtue ... oh, wait, wrong programming language.
Patch coming shortly.
--linas
-
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
Re: [Cbe-oss-dev] [PATCH 0/15] spidernet driver bug fixes
David Woodhouse wrote: On Wed, 2007-06-13 at 11:14 -0500, Linas Vepstas wrote: Some googling seems to show that "git pull" has a bug/feature of ignoring the branch that one is working in, and pulling "master" no matter what. I have no clue why; this seems broken to me. Branches are generally a PITA -- it's probably best just to avoid them entirely. It's not as if it's hard to create separate trees, and even share objects between the trees. It makes diffing between lines of development more difficult, takes up more overall space, less cache friendly, ... Jeff - 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
Re: [Cbe-oss-dev] [PATCH 0/15] spidernet driver bug fixes
On Thu, 2007-06-14 at 19:01 -0400, Jeff Garzik wrote: > It makes diffing between lines of development more difficult, takes up > more overall space, less cache friendly, ... All of which is much less true if you're sharing object directories or even using alternates. -- dwmw2 - 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
Re: [Cbe-oss-dev] [PATCH 0/15] spidernet driver bug fixes
David Woodhouse wrote: On Thu, 2007-06-14 at 19:01 -0400, Jeff Garzik wrote: It makes diffing between lines of development more difficult, takes up more overall space, less cache friendly, ... All of which is much less true if you're sharing object directories or even using alternates. Think about the actual kernel tree source code, not just the metadata... Jeff - 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
Re: [Cbe-oss-dev] [PATCH 0/15] spidernet driver bug fixes
On Thu, 2007-06-14 at 19:04 -0400, Jeff Garzik wrote: > Think about the actual kernel tree source code, not just the > metadata... Disk is cheap. Waiting for the whole damn thing to rebuild after switching branches and back again is less so. Besides, checking it out is optional. -- dwmw2 - 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
[PATCH] spidernet: Replace literal with const
Replace literal with const; add bit definitions.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
On Wed, Jun 13, 2007 at 04:12:00PM -0400, Jeff Garzik wrote:
> A follow-up patch needs to remove the above magic numbers (==numeric
> constants), replacing them with named constants
Here it is. Lightly stres-tested (about 1/2 hour), as this patch
tests some additonal bits.
drivers/net/spider_net.c |2 +-
drivers/net/spider_net.h | 19 +++
2 files changed, 20 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-06-11
15:39:03.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-06-14 17:23:32.0
-0500
@@ -1235,7 +1235,7 @@ spider_net_decode_one_descr(struct spide
goto bad_desc;
}
- if (hwdescr->dmac_cmd_status & 0xfcf4) {
+ if (hwdescr->dmac_cmd_status & SPIDER_NET_DESCR_BAD_STATUS) {
dev_err(&card->netdev->dev, "bad status, cmd_status=x%08x\n",
hwdescr->dmac_cmd_status);
pr_err("buf_addr=x%08x\n", hw_buf_addr);
Index: linux-2.6.22-rc1/drivers/net/spider_net.h
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.h 2007-06-11
15:39:03.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.h 2007-06-14 17:34:56.0
-0500
@@ -359,6 +359,18 @@ enum spider_net_int2_status {
#define SPIDER_NET_DMAC_UDP0x0003
#define SPIDER_NET_TXDCEST 0x0800
+#define SPIDER_NET_DESCR_RXFDIS0x0001
+#define SPIDER_NET_DESCR_RXDCEIS 0x0002
+#define SPIDER_NET_DESCR_RXDEN0IS 0x0004
+#define SPIDER_NET_DESCR_RXINVDIS 0x0008
+#define SPIDER_NET_DESCR_RXRERRIS 0x0010
+#define SPIDER_NET_DESCR_RXFDCIMS 0x0100
+#define SPIDER_NET_DESCR_RXDCEIMS 0x0200
+#define SPIDER_NET_DESCR_RXDEN0IMS 0x0400
+#define SPIDER_NET_DESCR_RXINVDIMS 0x0800
+#define SPIDER_NET_DESCR_RXRERRMIS 0x1000
+#define SPIDER_NET_DESCR_UNUSED0x077fe0e0
+
#define SPIDER_NET_DESCR_IND_PROC_MASK 0xF000
#define SPIDER_NET_DESCR_COMPLETE 0x /* used in rx and tx
*/
#define SPIDER_NET_DESCR_RESPONSE_ERROR0x1000 /* used in
rx and tx */
@@ -369,6 +381,13 @@ enum spider_net_int2_status {
#define SPIDER_NET_DESCR_NOT_IN_USE0xF000
#define SPIDER_NET_DESCR_TXDESFLG 0x0080
+#define SPIDER_NET_DESCR_BAD_STATUS (SPIDER_NET_DESCR_RXDEN0IS | \
+ SPIDER_NET_DESCR_RXRERRIS | \
+ SPIDER_NET_DESCR_RXDEN0IMS | \
+ SPIDER_NET_DESCR_RXINVDIMS | \
+ SPIDER_NET_DESCR_RXRERRMIS | \
+ SPIDER_NET_DESCR_UNUSED)
+
/* Descriptor, as defined by the hardware */
struct spider_net_hw_descr {
u32 buf_addr;
-
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
Re: [Cbe-oss-dev] [PATCH 0/15] spidernet driver bug fixes
On Fri, 2007-06-15 at 00:07 +0100, David Woodhouse wrote: > On Thu, 2007-06-14 at 19:04 -0400, Jeff Garzik wrote: > > Think about the actual kernel tree source code, not just the > > metadata... > > Disk is cheap. Waiting for the whole damn thing to rebuild after > switching branches and back again is less so. ccache! cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Thu, 2007-06-14 at 07:28 -0400, jamal wrote: > On Thu, 2007-14-06 at 16:59 +0800, Zhang Rui wrote: > > Hi, Jamal, > > > > Now the genl utility can find the acpi event genetlink family. > > And a simple user space demo is finished for handling acpi event. > > I really appreciate your help. :) > > np. > > > I think the patch which exposes ACPI events via netlink is ok. > > But I still have some problems on > > how to listen to specified genetlink family in user space? > > > > I can get the dynamic id for "acpi_event" genl family. > > But I don't know how to use this to receive messages from > > specified genl family. > > It seems that "#genl ctrl monitor" has something to do with this, > > IMO, rtnl_open_byproto(&rth, nl_mgrp(GENL_ID_CTRL), NETLINK_GENERIC) is > > used to receive messages from the nlctrl(controller) only, but > > unfortunately it never works for me. :( > > > > I dont have much time to look at your code given travel, but did you > try to use your group id instead of the controller's? > i.e: > rtnl_open_byproto(&rth, nl_mgrp(mydiscoveredacpiid), NETLINK_GENERIC) > Yes. It doesn't work if I use my group id here. In fact, I'm using rtnl_open_byproto(&rth, 1, NETLINK_GENERIC) now. That's why I said that this demo receives all the broadcasted genetlink messages. > If this doesnt work, ping me and i will take a look - just expect some > latency in response. > That's great. Thanks. Best regards, Rui - 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
Re: [PATCH] NET: Multiqueue network device support.
On Thu, 2007-06-14 at 07:48 -0400, jamal wrote: > I dont have much time to followup for sometime to come. I have left my > answer above. To clarify, incase i wasnt clear, I am saying: > a) It is better to have the driver change via some strategy of when to > open the tx path than trying to be generic. This shifts the burden to > the driver. > b) given the behavior of wireless media (which is very different from > wired ethernet media), you need a different strategy. In response to > Guy's question, I gave the example of being able to use management > frames to open up the tx path for VO (even when you dont know VO > packets > are sitting on the qdisc); alternatively you could use a timer etc. > Theres many ways to skin the cat (with apologies to cat > lovers/owners). > i.e you need to look at the media and be creative. > Peters DCE for example could also be handled by having a specific > strategy. OK. You tried so much to guess the traffic flow pattern in the low level driver, which could be implemented straightforward in the Qdisc. The pro is the Qdisc API is untouched. But the cons are: 1. driver becomes complicated (as it is too elaborate in the queue wakeup strategies design) 2. duplicated code among drivers (otherwise you put all the queue management logics in a new layer?) 3. it's not 100% accurate. there has to be some overhead, more or less depends on the queue wakeup strategy the driver selected. Time for voting? Thanks, -yi - 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
