* Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals
From: Nick Kossifidis @ 2007-09-01 3:12 UTC (permalink / raw)
To: John W. Linville
Cc: Christoph Hellwig, Jiri Slaby,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070830123849.GB5140-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2007/8/30, John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>:
> On Thu, Aug 30, 2007 at 04:50:01AM +0300, Nick Kossifidis wrote:
> > 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
>
> > > ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
> > > most drivers and ath5k_hw_inivals.o mights aswell be something like
> > > ath5k_init.o
>
> > If you check out the code you'll see i'm using the same convention
> > inside them, ath5k_hw* files contain hw related functions
> > (ath5k_hw_<name>) while driver code has ath5k_<name>. Also ath5k_init
> > is misleading, file acually includes initial register settings for
>
> I have to agree w/ Christoph -- the extra "_hw" in the names is just
> a bit unwieldy.
>
> John
>
> P.S. "ath5k_initvals.c" seems acceptable to me.
ACK, i'll remove _hw ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: zd1211rw regression, device does not enumerate
From: Daniel Drake @ 2007-09-01 3:21 UTC (permalink / raw)
To: Oliver Neukum; +Cc: netdev, Michal Piotrowski, linux-usb-devel, John W.Linville
In-Reply-To: <200708310958.38132.oliver@neukum.org>
Oliver Neukum wrote:
> after bisection it boils down to this patch:
>
> oliver@oenone:/home/olli2/Trees/linux-2.6> git bisect bad
> 74553aedd46b3a2cae986f909cf2a3f99369decc is first bad commit
> commit 74553aedd46b3a2cae986f909cf2a3f99369decc
> Author: Daniel Drake <dsd@gentoo.org>
> Date: Sun Jul 1 18:22:32 2007 +0100
>
> [PATCH] zd1211rw: Defer firmware load until first ifup
>
> that plugging in my device I get an error:
> Aug 16 13:17:11 oenone kernel: zd1211rw 3-4.3:1.0: zd1211b chip 0ace:1215 v4810 high 00-02-72 AL2230_RF pa0 g--NS
> Aug 16 13:17:12 oenone ifup: Cannot enable interface eth2.
Can you enable CONFIG_ZD1211RW_DEBUG and post new logs?
Would also be nice to have a bug on the kernel bugzilla to track this.
Thanks,
Daniel
-------------------------------------------------------------------------
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/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* borkage in 2.6.23-rc4-mm1
From: Andrew Morton @ 2007-09-01 4:16 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev
Am seeing random crap like this:
Aug 31 20:57:46 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 31 20:57:51 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 31 20:57:56 sony dhclient: dhclient(4537) is already running - exiting.
Aug 31 20:57:56 sony dhclient: exiting.
Aug 31 20:58:05 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
Aug 31 20:58:07 sony kernel: ipw2200: Firmware error detected. Restarting.
Aug 31 20:58:09 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Aug 31 20:58:16 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
Aug 31 20:58:16 sony dhclient: DHCPOFFER from 192.168.2.1
Aug 31 20:58:16 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 31 20:58:20 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 31 20:58:20 sony dhclient: DHCPACK from 192.168.2.1
Aug 31 20:58:20 sony NET[4946]: /sbin/dhclient-script : updated /etc/resolv.conf
Aug 31 20:58:20 sony dhclient: bound to 192.168.2.5 -- renewal in 125513 seconds.
Aug 31 20:59:45 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
Aug 31 20:59:51 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
Aug 31 20:59:52 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
Aug 31 21:01:31 sony kernel: ipw2200: Firmware error detected. Restarting.
Aug 31 21:01:54 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
Aug 31 21:01:59 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
Aug 31 21:02:02 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
Aug 31 21:04:04 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
Aug 31 21:04:05 sony kernel: ipw2200: Firmware error detected. Restarting.
Aug 31 21:04:07 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
Aug 31 21:04:12 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
Aug 31 21:05:21 sony kernel: ipw2200: Firmware error detected. Restarting.
when trying to use ssh on the current rc4-mm1 lineup.
^ permalink raw reply
* Re: ipv4_get_l4proto: Frag of proto 17
From: Patrick McHardy @ 2007-09-01 5:28 UTC (permalink / raw)
To: Meelis Roos; +Cc: netdev, Netfilter Development Mailinglist
In-Reply-To: <Pine.SOC.4.64.0708301557400.9520@math.ut.ee>
Meelis Roos wrote:
>>> Yesterdays git snapsot on a normal home PC spams dmesg with the following
>>> line:
>>> ipv4_get_l4proto: Frag of proto 17
>> In what situation does this happen?
>
> It happens some times every hour on the average. Seems to be some UDP
> traffic. Firewall allows in any UDP that is ESTABLISHEFD,RELATED, DHCP
> (some more UDP rules with counter 0 so not important). Additionally
> there is internal netowkr that sometimes has a laptop but usually not
> and the messages have appeared also when there is nothin in the internal
> network.
>
> Locally mldonkey is probably using UDP, and lsof -i | grep UDP tells
> that named, avahi-daemon, dhcpd, chronyd, nmbd and cupsd are listening
> on UDP sockets (most of them on internal network).
>
> But I have no idea what application is causing the messages.
I'm guessing that its ICMP errors containing UDP fragments.
Could you add a WARN_ON(1) to ipv4_get_l4proto() in
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c to verify
this?
^ permalink raw reply
* Re: [PATCH 5/5] Net: ath5k, kconfig changes
From: Nick Kossifidis @ 2007-09-01 5:58 UTC (permalink / raw)
To: John W. Linville
Cc: Christoph Hellwig, Jiri Slaby,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <40f31dec0708301518u5ef32d13jfe1cce09656bf77d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007/8/31, Nick Kossifidis <mickflemm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 2007/8/30, John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>:
> > On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> > > 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
> >
> > > > Also this whole patch seems rather pointless. It saves only
> > > > very little and turns the driver into a complete ifdef maze.
> >
> > > Also most
> > > people will use 5212 code only, 5211 cards are on some old laptops and
> > > 5210, well i couldn't even find a 5210 for actual testing :P
> >
> > FWIW, I'd bet dollars to donuts that distros will enable them all
> > together.
> >
> > Is saving code space the only reason to turn these off? How much
> > space do you save?
> >
> > Is there some way you can isolate and/or limit the number of ifdef
> > blocks further? If so, we might consider a version of this patch
> > that depends on EMBEDDED or somesuch...?
> >
> > John
>
> O.K. as a first step i'll limit 5210 code only then, just an option
> like "support older 5210 chipsets" which is going to be off by default
> instead of 3 options. It's not just saving space, it's also saving
> some runtime checks. It's not really a gain in performance though,
> most checks are done during initialization and dfs setup, i just
> thought it would be usefull to save as much cpu as possible.
>
Well after some thought i removed them all, there is no real gain from
this in most cases (that ppl will use newer 5212 chips and
combatibles).
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* [PATCH] skge: unbalanced parenthesis fix
From: Mariusz Kozlowski @ 2007-09-01 6:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Andrew Morton, lkml, netdev
Hello,
This patch fixes unbalanced parenthesis.
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
drivers/net/skge.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.23-rc4-mm1-a/drivers/net/skge.h 2007-09-01 07:23:52.000000000 +0200
+++ linux-2.6.23-rc4-mm1-b/drivers/net/skge.h 2007-09-01 07:37:55.000000000 +0200
@@ -1351,7 +1351,7 @@ enum {
PHY_M_PC_EN_DET_PLUS = 3<<8, /* Energy Detect Plus (Mode 2) */
};
-#define PHY_M_PC_MDI_XMODE(x) ((((u16)(x)<<5) & PHY_M_PC_MDIX_MSK)
+#define PHY_M_PC_MDI_XMODE(x) (((u16)(x)<<5) & PHY_M_PC_MDIX_MSK)
enum {
PHY_M_PC_MAN_MDI = 0, /* 00 = Manual MDI configuration */
^ permalink raw reply
* Re: 2.6.23-rc4-mm1
From: Andrew Morton @ 2007-09-01 6:58 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linux-kernel, Herbert Xu, netdev
In-Reply-To: <20070901155353.8a09db69.kamezawa.hiroyu@jp.fujitsu.com>
> On Sat, 1 Sep 2007 15:53:53 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> I met 2 troubles while I compiled rc4-mm1 on x86/UP system,
>
> One on pcnet32.c (patch is attaced below).
> One on crypto CONFIG.
>
> == compile log ==
> drivers/net/pcnet32.c: In function 'pcnet32_netif_stop':
> drivers/net/pcnet32.c:445: warning: unused variable 'lp'
> drivers/net/pcnet32.c: In function 'pcnet32_netif_start':
> drivers/net/pcnet32.c:455: warning: unused variable 'lp'
> drivers/net/pcnet32.c: In function 'pcnet32_interrupt':
> drivers/net/pcnet32.c:2622: error: 'struct net_device' has no member named 'napi'
Only git-net touches pcnet32.c
> crypto/built-in.o: In function `update2':
> digest.c:(.text+0x94a): undefined reference to `crypto_km_types'
> digest.c:(.text+0x9bf): undefined reference to `crypto_km_types'
>
> digest.c (CONFIG_CRYPTO) uses crypto/scatterwalk.c's object (CONFIG_CRYPTO_ALGAPI)
> I meet this when CONFIG_CRYPTO_ALGAPI=m. I need to make CONFIG_CRYPTO_ALGAPI=y.
cc herbert..
> Regards,
> -Kame.
> == cut from here ==
>
> tiny bug fix for pcnet32.c (maybe works well. please confirm.)
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> drivers/net/pcnet32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: devel-2.6.23-rc4-mm1/drivers/net/pcnet32.c
> ===================================================================
> --- devel-2.6.23-rc4-mm1.orig/drivers/net/pcnet32.c
> +++ devel-2.6.23-rc4-mm1/drivers/net/pcnet32.c
> @@ -2619,7 +2619,7 @@ pcnet32_interrupt(int irq, void *dev_id)
> break;
> }
> #else
> - pcnet32_rx(dev, dev->napi.weight);
> + pcnet32_rx(dev, lp->napi.weight);
> if (pcnet32_tx(dev)) {
> /* reset the chip to clear the error condition, then restart */
> lp->a.reset(ioaddr);
cc netdev, thanks.
^ permalink raw reply
* Re: [PATCH 1/2]: [NET_SCHED]: Make all rate based scheduler work with TSO.
From: Patrick McHardy @ 2007-09-01 7:09 UTC (permalink / raw)
To: jdb; +Cc: netdev@vger.kernel.org, David S. Miller
In-Reply-To: <1188562975.18622.11.camel@localhost.localdomain>
Jesper Dangaard Brouer wrote:
> commit 6fdc0f061be94f5e297650961360fb7a9d1cc85d
> Author: Jesper Dangaard Brouer <hawk@comx.dk>
> Date: Thu Aug 30 17:53:42 2007 +0200
>
> [NET_SCHED]: Make all rate based scheduler work with TSO.
>
> Change L2T (length to time) macros, in all rate based schedulers, to
> call a common function qdisc_l2t() that does the rate table lookup.
> This function handles if the packet size lookup is larger than the
> rate table, which often occurs with TSO enabled.
It still won't work properly with TSO (TBF for example already drops
oversized packets during ->enqueue), but its a good cleanup anyway.
> +#define L2T(p,L) ((p)->tcfp_R_tab, L)
> +#define L2T_P(p,L) ((p)->tcfp_P_tab, L)
I'd prefer to get rid of these L2T macros completely.
^ permalink raw reply
* Re: [PATCH 2/2]: [NET_SCHED]: Making rate table lookups more flexible.
From: Patrick McHardy @ 2007-09-01 7:10 UTC (permalink / raw)
To: jdb; +Cc: netdev@vger.kernel.org, David S. Miller
In-Reply-To: <1188562978.18622.13.camel@localhost.localdomain>
Jesper Dangaard Brouer wrote:
> commit ac093f5c2f1160ece72a6fef5c779c1892fc3152
> Author: Jesper Dangaard Brouer <hawk@comx.dk>
> Date: Fri Aug 31 11:53:35 2007 +0200
>
> [NET_SCHED]: Making rate table lookups more flexible. Extend the
> tc_ratespec struct, with two parameters: 1) "cell_align" that allow
> adjusting the alignment of the rate table. 2) "overhead" that allow
> adding a packet overhead before the lookup.
Am I guessing right that the intention is to resurrect the ATM patch?
^ permalink raw reply
* Re: [ANNOUNCE] iproute2-2.6.23-rc3
From: Patrick McHardy @ 2007-09-01 7:12 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Stephen Hemminger, netdev
In-Reply-To: <46D7FEC2.4010902@openvz.org>
Pavel Emelyanov wrote:
> Patrick McHardy wrote:
>> On Fri, 31 Aug 2007, Pavel Emelyanov wrote:
>>
>>>> Why does this add a new ip subcommand instead and uses genetlink
>>>> instead of the rtnl_link API, which was introduced exactly for
>>>> this stuff?
>>>>
>>> Hm... It does not, it just adds a parser for veth commands that
>>> generic layer isn't aware of.
>>
>> It does, you have "ip veth add", "ip veth del", ...
>>
>> Didn't you already sent a patch that used "ip link add ..."?
>
> The patch I sent last used "ip link add" and "ip link del".
> The link_veth.c file only parses all the extra arguments.
Thats what I thought. I seems Stephen applied an old version of
the patch that still uses genetlink.
^ permalink raw reply
* Re: [PATCH] [NET_SCHED] sch_prio.c: remove duplicate call of tc_classify()
From: Patrick McHardy @ 2007-08-31 6:04 UTC (permalink / raw)
To: Lucas Nussbaum; +Cc: netdev
In-Reply-To: <20070830072817.GA9617@xanadu.blop.info>
On Thu, 30 Aug 2007, Lucas Nussbaum wrote:
> When CONFIG_NET_CLS_ACT is enabled, tc_classify() is called twice in
> prio_classify(). This causes "interesting" behaviour: with the setup
> below, packets are duplicated, sent twice to ifb0, and then loop in and
> out of ifb0.
>
> The patch uses the previously calculated return value in the switch,
> which is probably what Patrick had in mind in commit
> bdba91ec70fb5ccbdeb1c7068319adc6ea9e1a7d -- maybe Patrick can
> double-check this?
> err = tc_classify(skb, q->filter_list, &res);
> #ifdef CONFIG_NET_CLS_ACT
> - switch (tc_classify(skb, q->filter_list, &res)) {
> + switch (err) {
Indeed, thats what I intended to do, thanks Lucas.
^ permalink raw reply
* Re: 2.6.23-rc4-mm1
From: Herbert Xu @ 2007-09-01 8:54 UTC (permalink / raw)
To: Andrew Morton
Cc: KAMEZAWA Hiroyuki, linux-kernel, netdev,
Linux Crypto Mailing List
In-Reply-To: <20070831235815.a09c7865.akpm@linux-foundation.org>
On Fri, Aug 31, 2007 at 11:58:15PM -0700, Andrew Morton wrote:
>
> > crypto/built-in.o: In function `update2':
> > digest.c:(.text+0x94a): undefined reference to `crypto_km_types'
> > digest.c:(.text+0x9bf): undefined reference to `crypto_km_types'
> >
> > digest.c (CONFIG_CRYPTO) uses crypto/scatterwalk.c's object (CONFIG_CRYPTO_ALGAPI)
> > I meet this when CONFIG_CRYPTO_ALGAPI=m. I need to make CONFIG_CRYPTO_ALGAPI=y.
>
> cc herbert..
Sorry, only tested on x86-64 which doesn't have HIGHMEM.
I've just pushed the following fix into cryptodev-2.6.
commit 25531e010a2a1d0099b62d473244d09e72402ce5
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat Sep 1 16:52:13 2007 +0800
[CRYPTO] api: Kill crypto_km_types
When scatterwalk is built as a module digest.c was broken because it
requires the crypto_km_types structure which is in scatterwalk. This
patch removes the crypto_km_types structure by encoding the logic into
crypto_kmap_type directly.
In fact, this even saves a few bytes of code (not to mention the data
structure itself) on i386 which is about the only place where it's
needed.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/crypto/internal.h b/crypto/internal.h
index 60acad9..abb01f7 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -50,11 +50,16 @@ extern struct list_head crypto_alg_list;
extern struct rw_semaphore crypto_alg_sem;
extern struct blocking_notifier_head crypto_chain;
-extern enum km_type crypto_km_types[];
-
static inline enum km_type crypto_kmap_type(int out)
{
- return crypto_km_types[(in_softirq() ? 2 : 0) + out];
+ enum km_type type;
+
+ if (in_softirq())
+ type = out * (KM_SOFTIRQ1 - KM_SOFTIRQ0) + KM_SOFTIRQ0;
+ else
+ type = out * (KM_USER1 - KM_USER0) + KM_USER0;
+
+ return type;
}
static inline void *crypto_kmap(struct page *page, int out)
^ permalink raw reply related
* Re: borkage in 2.6.23-rc4-mm1
From: Johannes Berg @ 2007-09-01 9:02 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Zhu Yi
In-Reply-To: <20070831211603.083dfed2.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
On Fri, 2007-08-31 at 21:16 -0700, Andrew Morton wrote:
> Am seeing random crap like this:
> Aug 31 20:58:07 sony kernel: ipw2200: Firmware error detected. Restarting.
> Aug 31 21:01:31 sony kernel: ipw2200: Firmware error detected. Restarting.
> when trying to use ssh on the current rc4-mm1 lineup.
Very odd. I don't recall any patches touching the ieee80211 code though
I'm not entirely sure (last I saw was DIV_ROUND_UP from net-2.6.24). Are
you using WPA/RSN? ISTR I posted about a bug in the ieee80211 code a
while ago but I don't think it should make the ipw2200 firmware upset.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: borkage in 2.6.23-rc4-mm1
From: Jeff Garzik @ 2007-09-01 9:47 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070831211603.083dfed2.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Andrew Morton wrote:
> Am seeing random crap like this:
>
> Aug 31 20:57:46 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
> Aug 31 20:57:51 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
> Aug 31 20:57:56 sony dhclient: dhclient(4537) is already running - exiting.
> Aug 31 20:57:56 sony dhclient: exiting.
> Aug 31 20:58:05 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
> Aug 31 20:58:07 sony kernel: ipw2200: Firmware error detected. Restarting.
> Aug 31 20:58:09 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
> Aug 31 20:58:16 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
> Aug 31 20:58:16 sony dhclient: DHCPOFFER from 192.168.2.1
> Aug 31 20:58:16 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
> Aug 31 20:58:20 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
> Aug 31 20:58:20 sony dhclient: DHCPACK from 192.168.2.1
> Aug 31 20:58:20 sony NET[4946]: /sbin/dhclient-script : updated /etc/resolv.conf
> Aug 31 20:58:20 sony dhclient: bound to 192.168.2.5 -- renewal in 125513 seconds.
> Aug 31 20:59:45 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
> Aug 31 20:59:51 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
> Aug 31 20:59:52 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
> Aug 31 21:01:31 sony kernel: ipw2200: Firmware error detected. Restarting.
> Aug 31 21:01:54 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
> Aug 31 21:01:59 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
> Aug 31 21:02:02 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
> Aug 31 21:04:04 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
> Aug 31 21:04:05 sony kernel: ipw2200: Firmware error detected. Restarting.
> Aug 31 21:04:07 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
> Aug 31 21:04:12 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
> Aug 31 21:05:21 sony kernel: ipw2200: Firmware error detected. Restarting.
I see this on my Sony Vaio with older, non-mm kernels too. Incredibly
frustrating, as it seems to be related to the phase of the moon.
Sometimes a reboot gets my wireless working, sometimes it doesn't.
Jeff
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: slavon @ 2007-09-01 10:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <20070831215850.zf2xi256o00owk4s@mail.himki.net>
> Hi All!
> I found another bugs in HTB
>
> 1. HTB Wrong calculate LEVELS.
> - try run "./create_nodes.sh" in archive and do "tc -d class show dev eth0"
Hm.. i read
http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm
I understand that if Level calculation broken - HTB wrong work! I try
to see sch_htb.c but i not see simple fix to this. Maybe anyone with
expirince try to look sch_htb.c?
>
> 2. HTB miss qdisc what i add. (it's not added)
> - try run ./create_nodes.sh; sh tc_rules_last2 2>/dev/null
> - I add my output of "tc -d class show dev eth0" for you look
> (tc_class.txt in archive)
Not correct info.
"tc -d class show dev eth0 | grep -v leaf" ask many rules without
leaf, but QDISC for this casses is created. How filter add packer to
filter where not have LEAF?
I think HTB not property work.
Thanks.
Badalian Vyacheslav
>
> Anyone! I want test any patches to fix all HTB problems!
>
> Thanks
>
>
>> I found that bug in this place
>>
>> (gdb) l *0xc01c8973
>> 0xc01c8973 is in rb_insert_color (lib/rbtree.c:80).
>> 75
>> 76 while ((parent = rb_parent(node)) && rb_is_red(parent))
>> 77 {
>> 78 gparent = rb_parent(parent);
>> 79
>> 80 if (parent == gparent->rb_left)
>> 81 {
>> 82 {
>> 83 register struct rb_node *uncle
>> = gparent->rb_right;
>> 84 if (uncle && rb_is_red(uncle))
>>
>>
>> if i not wrong understand message "unable to handle kernel NULL pointer
>> dereference at virtual address 00000008" its was known that "gparent ==
>> Null"?
>> Or i hope or i try find a mare's-nest?
>>
>>> Ok =) I hope in next week you found bug place and fix it!
>>>
>>> PS. if you ask where i can read "kernel panic dump logic"
>>> literature and try find bugline in code.
>>> I read dump and see that bug in function "rb_insert_color" + some
>>> shift (in asm?) that called from htb_dequeue? But in htb_dequeue
>>> not have calling rb_insert_color =( Or some nodes in trace was
>>> skipped?
>>>
>>> Its for change up my education ;)
>>>> I'll not be able to assist you until monday (but I'll try to look
>>>> into the code and maybe to prepare some new patch - but it needs
>>>> a lot of checking to not add too much of this locking as well).
>>>>
>>>> I think you can stay with a kernel whichever you like - I'm not sure
>>>> any config changes or even more debugging can change much, but maybe
>>>> I'm wrong. It looks to me like some locking is missing or interrupted.
>>>> If you are working weekends and find something new, don't wait: maybe
>>>> somebody else here could be interested too.
>>>> Cheers,
>>>> Jarek P.
>>>>
>>>
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: pktgen terminating condition
From: Daniele Venzano @ 2007-09-01 10:47 UTC (permalink / raw)
To: hadi
Cc: Mandeep Baines, davem, rick.jones2, msb, netdev, grundler,
robert.olsson, jeff, nhorman
----- Message d'origine -----
De: jamal <hadi@cyberus.ca>
Date: Fri, 31 Aug 2007 09:50:03 -0400
Sujet: Re: Re: pktgen terminating condition
>I dont know if you followed the discussion - by defering the freeing of
>skbs, you will be slowing down socket apps sending from the local
>machine. It may be ok if the socket buffers were huge, but that comes at
>the cost of system memory (which may not be a big deal)
>Do you by any chance recall why you used the idle interupt instead of
>txok to kick the prunning of tx descriptors?
That should be asked to the original author of the driver, that I wasn't able to contact when I took over the maintainership several years ago.
I think that since this chip is usually used on cheap/low performance (relatively speaking) devices it was felt that generating an interrupt for each transmitted packet was going to affect the performance of the system too much. At the start, if I remember correctly, this was a chip thought for consumer use, where transmissions won't happen continuously for long periods of time. Then the sis900 started to get used everywhere, from embedded systems to (cheap) server motherboards and the usage scenario changed.
--
Daniele Venzano
venza@brownhat.org
^ permalink raw reply
* Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
From: Robert P. J. Day @ 2007-09-01 10:44 UTC (permalink / raw)
To: Randy Dunlap
Cc: Simon Arlott, Sam Ravnborg, Linux Kernel Mailing List,
Stefan Richter, Adrian Bunk, Jeff Garzik, Gabriel C, netdev
In-Reply-To: <20070831102527.09fb42c0.rdunlap@xenotime.net>
On Fri, 31 Aug 2007, Randy Dunlap wrote:
> On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:
> > What about something like this? I'm not sure if the addition to
> > sym_init is desirable... I also had to prefix _ to the name for
> > now otherwise it conflicts badly with the current symbols. It
> > probably should stop "depends on _BROKEN" etc. too.
>
> Hi Simon,
>
> (sorry for the delay)
>
> I like this patch very much... I just can't get it to build (on
> 2.6.23-rc4).
i got a patch from simon a while back, and it failed with
"shift/reduce" conflicts. is that what you're seeing?
> > while (1) {
> > printf("%*s%s ", indent - 1, "", menu->prompt->text);
> > + switch (sym->maturity) {
> > + case M_EXPERIMENTAL:
> > + printf("(EXPERIMENTAL) ");
> > + break;
> > + case M_DEPRECATED:
> > + printf("(DEPRECATED) ");
> > + break;
> > + case M_OBSOLETE:
> > + printf("(OBSOLETE) ");
> > + break;
> > + case M_BROKEN:
> > + printf("(BROKEN) ");
> > + break;
> > + default:
> > + break;
> > + }
> > if (sym->name)
> > printf("(%s) ", sym->name);
> > type = sym_get_type(sym);
for now, simon, why not just reduce this to supporting only DEPRECATED
and OBSOLETE so that it can be at least tested as "proof of concept?"
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* Re: 2.6.23-rc4-mm1
From: Kamalesh Babulal @ 2007-09-01 11:55 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: Andrew Morton, linux-kernel, Herbert Xu, netdev
In-Reply-To: <20070831235815.a09c7865.akpm@linux-foundation.org>
Andrew Morton wrote:
>> On Sat, 1 Sep 2007 15:53:53 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>> I met 2 troubles while I compiled rc4-mm1 on x86/UP system,
>>
>> One on pcnet32.c (patch is attaced below).
>> One on crypto CONFIG.
>>
>> == compile log ==
>> drivers/net/pcnet32.c: In function 'pcnet32_netif_stop':
>> drivers/net/pcnet32.c:445: warning: unused variable 'lp'
>> drivers/net/pcnet32.c: In function 'pcnet32_netif_start':
>> drivers/net/pcnet32.c:455: warning: unused variable 'lp'
>> drivers/net/pcnet32.c: In function 'pcnet32_interrupt':
>> drivers/net/pcnet32.c:2622: error: 'struct net_device' has no member named 'napi'
>>
>
> Only git-net touches pcnet32.c
>
>
<snip>
Hi Kamezawa,
I got the pcnet32.c compile failure and after applying the patch compile
does not fails.
Thanks & Regards,
Kamalesh Babulal.
^ permalink raw reply
* Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
From: Sam Ravnborg @ 2007-09-01 12:49 UTC (permalink / raw)
To: Robert P. J. Day
Cc: Randy Dunlap, Simon Arlott, Linux Kernel Mailing List,
Stefan Richter, Adrian Bunk, Jeff Garzik, Gabriel C, netdev
In-Reply-To: <Pine.LNX.4.64.0709010641540.31472@localhost.localdomain>
On Sat, Sep 01, 2007 at 06:44:06AM -0400, Robert P. J. Day wrote:
>
> > > while (1) {
> > > printf("%*s%s ", indent - 1, "", menu->prompt->text);
> > > + switch (sym->maturity) {
> > > + case M_EXPERIMENTAL:
> > > + printf("(EXPERIMENTAL) ");
> > > + break;
> > > + case M_DEPRECATED:
> > > + printf("(DEPRECATED) ");
> > > + break;
> > > + case M_OBSOLETE:
> > > + printf("(OBSOLETE) ");
> > > + break;
> > > + case M_BROKEN:
> > > + printf("(BROKEN) ");
> > > + break;
> > > + default:
> > > + break;
> > > + }
> > > if (sym->name)
> > > printf("(%s) ", sym->name);
> > > type = sym_get_type(sym);
>
> for now, simon, why not just reduce this to supporting only DEPRECATED
> and OBSOLETE so that it can be at least tested as "proof of concept?"
The principle with letting a dependency add text to the promts are good.
But the implementation done by Simon with a language extension is not good.
A simple and better approach would be to use the newly added option
support for this and let the backend generate the promtps.
I have not yet tried to cook up a patch for it, but it should be
quite generaic and doable.
config EXPERIMENTAL
option appendprompt=" (EXPERIMENTAL)
config DEPRECATED
option appendprompt=" (DEPRECATED)
Then the dependency added will automatically append to the prompt.
It would probarly have be done in two steps. One that introduce a helper
function to retreive the prompt text and introduce it. And next a patch to
add a text if a symbol has a dependency on a symbol with a specific option
assigned.
Sam
^ permalink raw reply
* Re: [PATCH] skge: unbalanced parenthesis fix
From: Stephen Hemminger @ 2007-09-01 12:55 UTC (permalink / raw)
To: Mariusz Kozlowski; +Cc: Andrew Morton, lkml, netdev
In-Reply-To: <200709010810.12798.m.kozlowski@tuxland.pl>
On Sat, 1 Sep 2007 08:10:12 +0200
Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
> Hello,
>
> This patch fixes unbalanced parenthesis.
>
> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
>
> drivers/net/skge.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.23-rc4-mm1-a/drivers/net/skge.h 2007-09-01 07:23:52.000000000 +0200
> +++ linux-2.6.23-rc4-mm1-b/drivers/net/skge.h 2007-09-01 07:37:55.000000000 +0200
> @@ -1351,7 +1351,7 @@ enum {
> PHY_M_PC_EN_DET_PLUS = 3<<8, /* Energy Detect Plus (Mode 2) */
> };
>
> -#define PHY_M_PC_MDI_XMODE(x) ((((u16)(x)<<5) & PHY_M_PC_MDIX_MSK)
> +#define PHY_M_PC_MDI_XMODE(x) (((u16)(x)<<5) & PHY_M_PC_MDIX_MSK)
>
> enum {
> PHY_M_PC_MAN_MDI = 0, /* 00 = Manual MDI configuration */
Since the macro is unused, I would rather just drop it.
^ permalink raw reply
* Re: [ANNOUNCE] iproute2-2.6.23-rc3
From: Stephen Hemminger @ 2007-09-01 12:56 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Pavel Emelyanov, netdev
In-Reply-To: <46D910E9.1040909@trash.net>
On Sat, 01 Sep 2007 09:12:41 +0200
Patrick McHardy <kaber@trash.net> wrote:
> Pavel Emelyanov wrote:
> > Patrick McHardy wrote:
> >> On Fri, 31 Aug 2007, Pavel Emelyanov wrote:
> >>
> >>>> Why does this add a new ip subcommand instead and uses genetlink
> >>>> instead of the rtnl_link API, which was introduced exactly for
> >>>> this stuff?
> >>>>
> >>> Hm... It does not, it just adds a parser for veth commands that
> >>> generic layer isn't aware of.
> >>
> >> It does, you have "ip veth add", "ip veth del", ...
> >>
> >> Didn't you already sent a patch that used "ip link add ..."?
> >
> > The patch I sent last used "ip link add" and "ip link del".
> > The link_veth.c file only parses all the extra arguments.
>
>
> Thats what I thought. I seems Stephen applied an old version of
> the patch that still uses genetlink.
>
Send me a new one, and I'll revert the old one.
^ permalink raw reply
* Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
From: Robert P. J. Day @ 2007-09-01 12:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Randy Dunlap, Simon Arlott, Linux Kernel Mailing List,
Stefan Richter, Adrian Bunk, Jeff Garzik, Gabriel C, netdev
In-Reply-To: <20070901124901.GA2935@uranus.ravnborg.org>
On Sat, 1 Sep 2007, Sam Ravnborg wrote:
> On Sat, Sep 01, 2007 at 06:44:06AM -0400, Robert P. J. Day wrote:
> >
> > > > while (1) {
> > > > printf("%*s%s ", indent - 1, "", menu->prompt->text);
> > > > + switch (sym->maturity) {
> > > > + case M_EXPERIMENTAL:
> > > > + printf("(EXPERIMENTAL) ");
> > > > + break;
> > > > + case M_DEPRECATED:
> > > > + printf("(DEPRECATED) ");
> > > > + break;
> > > > + case M_OBSOLETE:
> > > > + printf("(OBSOLETE) ");
> > > > + break;
> > > > + case M_BROKEN:
> > > > + printf("(BROKEN) ");
> > > > + break;
> > > > + default:
> > > > + break;
> > > > + }
> > > > if (sym->name)
> > > > printf("(%s) ", sym->name);
> > > > type = sym_get_type(sym);
> >
> > for now, simon, why not just reduce this to supporting only DEPRECATED
> > and OBSOLETE so that it can be at least tested as "proof of concept?"
>
> The principle with letting a dependency add text to the promts are good.
> But the implementation done by Simon with a language extension is not good.
> A simple and better approach would be to use the newly added option
> support for this and let the backend generate the promtps.
>
> I have not yet tried to cook up a patch for it, but it should be
> quite generaic and doable.
>
> config EXPERIMENTAL
> option appendprompt=" (EXPERIMENTAL)
>
> config DEPRECATED
> option appendprompt=" (DEPRECATED)
but this is deviating from the basic principle that these things are
not regular Kconfig "config" settings -- they are a new beast
entirely, and need a new infrastructure to support them.
put another way, they are not a normal kernel feature to be selected
or deselected. they are, rather, *attributes* that can be *applied*
to kernel features, in the same way as is done with "bool" or
"string". making these things regular config directives defeats the
whole purpose.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* Re: borkage in 2.6.23-rc4-mm1
From: John W. Linville @ 2007-09-01 13:12 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Morton, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, yi.zhu-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <46D9352B.4060606-o2qLIJkoznsdnm+yROfE0A@public.gmane.org>
On Sat, Sep 01, 2007 at 05:47:23AM -0400, Jeff Garzik wrote:
> Andrew Morton wrote:
> >Aug 31 20:58:07 sony kernel: ipw2200: Firmware error detected. Restarting.
> I see this on my Sony Vaio with older, non-mm kernels too. Incredibly
> frustrating, as it seems to be related to the phase of the moon.
> Sometimes a reboot gets my wireless working, sometimes it doesn't.
There have been a few random reports of firmware restarts with ipw2x00
for a long time. Unfortunately, only Intel has any visibility into
that firmware. Do make sure you have the latest firmware released
from Intel (you probably do already, but it's worth checking).
Yi, any thoughts?
John
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* UDP broadcast packets not looped back
From: Benoit PAPILLAULT @ 2007-09-01 14:30 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]
Hi there,
I've already sent this email to lkml (see
http://lkml.org/lkml/2007/8/13/1144) and got no feedback so far. I was
told that netdev might be a more appropriate list, so here I am!
I wrote a small C program using the BSD socket API to send a UDP
broadcast packet to all interfaces on my machine. To do so, i sendto()
it to 255.255.255.255 after using setsockopt(SO_BINDTODEVICE) on the
correct interface. It works perfectly.
However, in the same program, either using the same socket or another on
the same UDP port, I found out that I just received packets i'm sending
as well. And do not want it. I perfectly understand that some program
might be interested in broadcast packets they sent, but i don't.
I have seen that in the multicast world, every program can choose this
behaviour throught the setsockopt IP_MULTICAST_LOOP. I do not want to
use multicast since I don't want my packets to be routed (if there was
ever a multicast router on the link). But I admit I could use a TTL=1
packet in this case.
Anyway, I dig five minutes into the kernel source code I have at hand
and wrote a small patch to add IP_MULTICAST_LOOP to broadcast packets.
Since it might be interesting to other people, I just submit it here. It
has been testing on Ubuntu and kernel 2.6.23-rc1 from the wireless.git
repository. It should be very easy to adapt to other kernel version.
I have not seen this feature as being standard throught the OpenGroup
specification
(http://www.opengroup.org/onlinepubs/009695399/functions/setsockopt.html),
but it might be usefull anyway.
Comments welcome,
Benoit
[-- Attachment #2: wireless-dev-udp-broadcast.diff --]
[-- Type: text/x-patch, Size: 805 bytes --]
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index c9e2b5e..1052a6e 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -232,6 +232,9 @@ int ip_mc_output(struct sk_buff *skb)
skb->dev = dev;
skb->protocol = htons(ETH_P_IP);
+ printk("rt->rt_flags = %x mc_loop=%d\n",
+ rt->rt_flags, sk ? inet_sk(sk)->mc_loop : 0);
+
/*
* Multicasts are looped back for other local users
*/
@@ -266,10 +269,12 @@ int ip_mc_output(struct sk_buff *skb)
}
if (rt->rt_flags&RTCF_BROADCAST) {
+ if (!sk || inet_sk(sk)->mc_loop) {
struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
if (newskb)
NF_HOOK(PF_INET, NF_IP_POST_ROUTING, newskb, NULL,
newskb->dev, ip_dev_loopback_xmit);
+ }
}
return NF_HOOK_COND(PF_INET, NF_IP_POST_ROUTING, skb, NULL, skb->dev,
^ permalink raw reply related
* Re: ipv4_get_l4proto: Frag of proto 17
From: Meelis Roos @ 2007-09-01 15:04 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, Netfilter Development Mailinglist
In-Reply-To: <46D8F87A.1080604@trash.net>
> I'm guessing that its ICMP errors containing UDP fragments.
>
> Could you add a WARN_ON(1) to ipv4_get_l4proto() in
> net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c to verify
> this?
Yes, it seems to be an ICMP error:
WARNING: at net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:93 ipv4_get_l4proto()
[<c0103447>] show_trace_log_lvl+0x1a/0x2f
[<c0103f2e>] show_trace+0x12/0x14
[<c0103f45>] dump_stack+0x15/0x17
[<f8cc60fc>] ipv4_get_l4proto+0x78/0xc0 [nf_conntrack_ipv4]
[<f8d14fc4>] nf_ct_get_tuplepr+0x45/0xae [nf_conntrack]
[<f8cc6777>] icmp_error+0x185/0x1f6 [nf_conntrack_ipv4]
[<f8d1548f>] nf_conntrack_in+0xc0/0x409 [nf_conntrack]
[<f8cc6251>] ipv4_conntrack_in+0x11/0x13 [nf_conntrack_ipv4]
[<c028f16e>] nf_iterate+0x36/0x67
[<c028f519>] nf_hook_slow+0x57/0xd6
[<c0294a97>] ip_rcv+0x1d9/0x489
[<c027a38e>] netif_receive_skb+0x2c9/0x34a
[<f88ca79d>] rtl8139_poll+0x2a5/0x410 [8139too]
[<c027bfa4>] net_rx_action+0x56/0xd5
[<c011af47>] __do_softirq+0x38/0x7a
[<c01048e5>] do_softirq+0x41/0x91
=======================
ipv4_get_l4proto: Frag of proto 17
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
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