* Re: Setting TCP_NODELAY doesn't disable Nagle's alg. on loopback
From: David S. Miller @ 2006-05-16 20:53 UTC (permalink / raw)
To: shemminger; +Cc: rmihal, netdev
In-Reply-To: <20060516091606.39d0ecc3@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Tue, 16 May 2006 09:16:06 -0700
> If it is 2.6.5 that is over 2+ years old. Please try with something
> past the Pleistocene era...
R O F L!
If that doesn't belong in a quotes file, I don't know what
does :-)
^ permalink raw reply
* Re: [PATCH 3/6] new pcmcia IDs for hostap
From: Pavel Roskin @ 2006-05-16 21:15 UTC (permalink / raw)
To: Marcin Juszkiewicz; +Cc: netdev, Jeff Garzik, Jouni Malinen, John W. Linville
In-Reply-To: <200605161724.53495.linux-arm@hrw.one.pl>
Hello!
On Tue, 2006-05-16 at 17:24 +0200, Marcin Juszkiewicz wrote:
> root@c7x0:~# pccardctl ident
> Socket 0:
> product info: "D-Link", "DCF-660W", "", ""
> manfid: 0xd601, 0x0005
> function: 6 (network)
This manfid is in the driver already, and it also covers ZCOMAX XI-325HP
200mw cards, according to
http://tinyshell.be/aircrackng/patches/hostap-driver-0.4.7.patch
> One more Prism2 card which works with HostAP.
>
> Platform: Sharp Zaurus SL-5500 running 2.4.18 + hostap_cs 0.4.7
>
> root@collie:~# cardctl ident
> Socket 0:
> product info: "NETGEAR", "MA701 Wireless CF Card", ""
> manfid: 0xd601, 0x0002
> function: 6 (network)
This manfid is in the driver too.
> Platform: Sharp Zaurus SL-C3100 running 2.6.16 + pcmciautils 013
>
> root@spitz:~# pccardctl ident
> Socket 0:
> product info: "HITACHI", "microdrive", "", ""
> manfid: 0x0319, 0x0000
> function: 4 (fixed disk)
> Socket 1:
> product info:"PLANEX COMMUNICATION INC","PLANEX GW-CF11X Wireless CF Card", "", ""
> manfid: 0xd601, 0x0010
> function: 6 ( network )
This manfid is in the driver.
> From: Jochen Friedrich
>
> Yet another card known to work OK with hostap_cs:
>
> # pccardctl ident
> Socket 0:
> no product info available
> Socket 1:
> product info: "U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02", ""
> manfid: 0x0156, 0x0002
> function: 6 (network)
Yes, that's needed. I was thinking maybe we could have a macro to match
manfid and the third string. 0x0156, 0x0002 and "Version 01.02" only
appear for Prism based cards.
> + PCMCIA_DEVICE_PROD_ID1234("ASUS", "802_11B_CF_CARD_25", "Version 01.00", "",
> + 0x78fc06ee, 0x45a50c1e, 0xa57adb8c, 0x00000000),
I think it would be better to omit the empty string. It's mostly a
matter of taste, but if there are cards with the same ID except the
fourth string, they would be almost definitely compatible.
This entry shouldn't be needed because the manfid 0x02aa, 0x0002 is
already in the driver.
> + PCMCIA_DEVICE_PROD_ID12("D-Link", "DCF-660W",
> + 0x1a424a1c, 0xe78b6dcc),
It shouldn't be needed (manfid 0xd601, 0x0005 is in the driver)
> + PCMCIA_DEVICE_PROD_ID12("NETGEAR", "MA701 Wireless CF Card",
> + 0x9aa79dc3, 0xd9ec98e),
Same thing (0xd601, 0x0002)
> + PCMCIA_DEVICE_PROD_ID12("PLANEX COMMUNICATION INC",
> + "PLANEX GW-CF11X Wireless CF Card",
> + 0x4703cf68, 0xfad7318d),
Same thing (0xd601, 0x0010), according to
http://www.oesf.org/forums/index.php?showtopic=14544
> + PCMCIA_DEVICE_PROD_ID123(
> + "Pretec", "CompactWLAN Card 802.11b", "2.5",
> + 0x1cadd3e5, 0xe697636c, 0x7a5bfcf1),
That's a good one.
> + PCMCIA_DEVICE_PROD_ID1234(
> + "U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02", ""
> + 0xc7b8df9d, 0x1700d087, 0x4b74baa0, 0x00000000),
Another useful entry, but please don't match the empty string.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: skge driver oops
From: Stephen Hemminger @ 2006-05-16 21:17 UTC (permalink / raw)
To: David Arnold; +Cc: netdev
In-Reply-To: <861.1147397784@d.0x1.org>
On Fri, 12 May 2006 11:36:24 +1000
"David Arnold" <david@mantara.com> wrote:
> i've been getting semi-regular lockups on my machine over 2.6.16
> series. I recently attached a serial console in an attempt to capture
> an OOPS.
>
> i got one yesterday. it's copied manually from the console, but
> hopefully the values are all accurate. there was more that had scrolled
> off screen above this too (sorry).
>
> oops, lspci, uname -a, .config and dmesg below.
>
> any suggestions for further debugging would be great,
>
> thanks,
I tried reproducing this and can't seem to cause it.
Are you running anything special that could influence this?
bridging, VLAN's, bonding, netfilter, queueing disciplines,
tc filters, ...
What is the output of /proc/interrupts, perhaps the devices don't like
sharing IRQ?
^ permalink raw reply
* Re: skge driver oops
From: David Arnold @ 2006-05-16 21:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Arnold, netdev
In-Reply-To: <20060512085339.72faaa44@localhost.localdomain>
-->"Stephen" == Stephen Hemminger <shemminger@osdl.org> writes:
Stephen> I tried reproducing this and can't seem to cause it.
thanks anyway :-)
Stephen> Are you running anything special that could influence this?
Stephen> bridging, VLAN's, bonding, netfilter, queueing disciplines,
Stephen> tc filters, ...
basic Debian/unstable on a Tyan dual-CPU K7. IPv4/v6. no netfilter,
VLAN, bonding. no QoS/Fair Queuing. BIC, CUBIC and Westwood built in.
eth1 Link encap:Ethernet HWaddr 00:11:95:FF:2B:BD
inet addr:10.0.0.128 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: 2001:388:c003:0:211:95ff:feff:2bbd/64 Scope:Global
inet6 addr: fe80::211:95ff:feff:2bbd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:987231 errors:0 dropped:0 overruns:0 frame:0
TX packets:800360 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:830102720 (791.6 MiB) TX bytes:395871735 (377.5 MiB)
Interrupt:17
Stephen> What is the output of /proc/interrupts, perhaps the devices
Stephen> don't like sharing IRQ?
d@d > cat /proc/interrupts
CPU0 CPU1
0: 22132560 948 IO-APIC-edge timer
1: 119890 8 IO-APIC-edge i8042
2: 0 0 XT-PIC cascade
3: 3010 0 IO-APIC-edge serial
8: 4 0 IO-APIC-edge rtc
12: 1360875 104 IO-APIC-edge i8042
14: 165181 4 IO-APIC-edge ide0
15: 1582736 8 IO-APIC-edge ide1
17: 1436277 0 IO-APIC-level skge
18: 0 0 IO-APIC-level Ensoniq AudioPCI
19: 17673555 44 IO-APIC-level ohci_hcd:usb1
NMI: 0 0
LOC: 22132173 22132577
ERR: 0
MIS: 0
d
^ permalink raw reply
* Re: [PATCH] ipx: correct return type of ipxrtr_delete
From: David S. Miller @ 2006-05-16 22:08 UTC (permalink / raw)
To: adobriyan; +Cc: akpm, acme, netdev
In-Reply-To: <20060516201238.GM10143@mipter.zuzino.mipt.ru>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Wed, 17 May 2006 00:12:38 +0400
> A single caller passes __u32. Inside function "net" is compared with
> __u32 (__be32 really, just wasn't annotated).
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, but I had to fix your changelog, you're fixing the
"argument" type not the "return" type. :)
Thanks.
^ permalink raw reply
* Re: [PATCH] ipx: correct return type of ipx_map_frame_type
From: David S. Miller @ 2006-05-16 22:18 UTC (permalink / raw)
To: adobriyan; +Cc: akpm, acme, netdev
In-Reply-To: <20060516184940.GL10143@mipter.zuzino.mipt.ru>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Tue, 16 May 2006 22:49:40 +0400
> Casting BE16 to int and back may or may not work. Correct, to be sure.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [2.6 patch] net/802/tr.c: remove an unused export
From: David S. Miller @ 2006-05-16 22:23 UTC (permalink / raw)
To: bunk; +Cc: acme, netdev
In-Reply-To: <20060516184843.GP10077@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Tue, 16 May 2006 20:48:43 +0200
> This patch removes the unused EXPORT_SYMBOL(tr_source_route).
>
> (No, the usage in net/llc/llc_output.c can't be modular.)
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: endian fix
From: David S. Miller @ 2006-05-16 22:24 UTC (permalink / raw)
To: adobriyan; +Cc: akpm, netdev
In-Reply-To: <20060516183645.GK10143@mipter.zuzino.mipt.ru>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Tue, 16 May 2006 22:36:46 +0400
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, thanks Alexey.
^ permalink raw reply
* Re: Controlling TCP window size
From: David S. Miller @ 2006-05-16 23:01 UTC (permalink / raw)
To: jheffner; +Cc: lists, netdev
In-Reply-To: <446A19C7.1000302@psc.edu>
From: John Heffner <jheffner@psc.edu>
Date: Tue, 16 May 2006 14:28:23 -0400
> The problem really is that the window_clamp variable is overloaded.
> It's used as a kind of cache for rcvbuf -> window conversion, but also
> as a user-settable bound in window size. On examination, it looks like
> this is also broken (in that window size won't increase) if a user does
> a setsockopt(SO_RCVBUF). Can we make window_clamp a true clamp? Then
> we can get rid of the hack of raising it in tcp_rcv_space_adjust(). I
> can cook up a patch if interested.
The clamp gets moved along also to handle dynamic receive window
sizing. To be honest, a window clamp doesn't have clear semantics
in the presence of dynamic window sizing.
Anyways, I'd like to see your patch. It might make rcvbuf -->
window conversions a bit more expensive, but we'll see.
^ permalink raw reply
* Re: [1/1] connector: export cn_already_initialized.
From: David S. Miller @ 2006-05-16 23:14 UTC (permalink / raw)
To: johnpol; +Cc: netdev
In-Reply-To: <20060506084045.GA16558@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Sat, 6 May 2006 12:40:45 +0400
> Some external patches, which can be built both as static build and as
> module just check that value, and thus will fail with unresolved symbol
> when cn and module are built as modules.
>
> The right set of operations should be following:
> If external module is loaded and cn is not loaded or compiled into the
> kernel, insmod will just fail with unresolved symbol (cn_add_callback and others),
> if cn is already loaded or was built into the tree, then it has been
> initialized already and there is no need to check that value, external
> module should be just loaded.
>
> I think the right solution is to call external init functions after cn
> init function, but it's ordering is not always known.
In-kernel build of connector subsystem can be handled by
making cn_init a "subsystem_init()", it will then be setup
before any possible static or modular reference as long as
those modules use module_init().
For modular case of connector, dependency of module on connector
module should handle all ordering issues, making any ordering
issue take care of itself.
^ permalink raw reply
* Re: [RFC] new qla3xxx NIC Driver v2.02.00k19
From: Francois Romieu @ 2006-05-16 23:23 UTC (permalink / raw)
To: Ron Mercer; +Cc: netdev, linux-driver, Ying Ping Lok, Mike Metskas
In-Reply-To: <0BB3E5E7462EEA4295BC02D49691DC070D32F3@AVEXCH1.qlogic.org>
Ron Mercer <ron.mercer@qlogic.com> :
[...]
> Looking forward to any and all feedback.
First pass:
- please reorder the code so that the forward declarations are not needed
- the typedefs (say PQL3XXX_PORT_REGISTERS) hide pointer information.
They are useless (and capitalized :o/ ). Just say no to typedef.
- the debug functions abuse copy/paste. Please use struct array + loop
if you really want these to stay.
- "return" is not a function. It does not need parenthesis.
- 80 colums disease in ql_link_state_machine. The indentation is terrible.
- label for goto should be at the start of the line.
- acquire_adapter_lock must go. Conditional locking is a pain to maintain.
- the error path in ql3xxx_probe is broken. Use named _and_ numbered
goto if you want to avoid it (i.e. "goto err_undo_something_1" then
"goto err_undo_something_else_2", etc.).
- ql_set_ethtool_ops() is useless bloat. Please remove.
- QL_LOCK_DRVR_WAIT should be a function, not a macro
- the status code should be propagated (request_irq, pci_enable_device,
pci_request_regions, etc.).
- no __iomem, __u32, __le32 ? Seems strange.
- replace return (0) with NETDEV_TX_OK in ql3xxx_send
(and s/send/start_xmit/ ?).
--
Ueimor
^ permalink raw reply
* Fwd:
From: Della Negron @ 2006-05-17 0:21 UTC (permalink / raw)
To: netdev
-S'ensationall revoolution in m'edicine!
-E'n'l'a'r'g'e your p''enis up to 10 cm or up to 4 inches!
-It's herbal solution what hasn't side effect, but has 100% guaranted results!
-Don't lose your chance and but know wihtout doubts, you will be impressed with results!
Clisk here: http://e4fashion.info
upholstery churchyard connivance intoxicate littleton o'er chef dishwater cunard curfew
betsey elevate besmirch ankle mouth pegboard verlag anomie motor
octet domineer conscription freshman sear dwarf bellum agribusiness decibel peep want
rescue frontiersman geopolitic orwell sidle carrie sanctimonious compost
sceptic brainstorm angelic jag artifact hastings focussed rail
rockabye dan equipped inconvenient inclination insolvent segovia multiplicand
^ permalink raw reply
* Re: [PATCH] reno sacked_out count fix
From: David S. Miller @ 2006-05-17 4:40 UTC (permalink / raw)
To: angelo.castellani+lkml; +Cc: netdev, francesco, andrea.baiocchi
In-Reply-To: <8dd26e70605160224i44bbaa8ei93eede75e71f6665@mail.gmail.com>
From: "Angelo P. Castellani" <angelo.castellani+lkml@gmail.com>
Date: Tue, 16 May 2006 11:24:00 +0200
> Using NewReno, if a sk_buff is timed out and is accounted as lost_out,
> it should also be removed from the sacked_out.
>
> This is necessary because recovery using NewReno fast retransmit could
> take up to a lot RTTs and the sk_buff RTO can expire without actually
> being really lost.
>
> left_out = sacked_out + lost_out
> in_flight = packets_out - left_out + retrans_out
>
> Using NewReno without this patch, on very large network losses,
> left_out becames bigger than packets_out + retrans_out (!!).
>
> For this reason unsigned integer in_flight overflows to 2^32 - something.
Thanks for your analysis and fix, I will apply it.
This pseudo-SACK for Reno scheme could probably use some changes. For
example, one idea Herbert Xu had was to maintain the pseudo-SACKs in
the actual TAG bits of the TCP_SKB_CB() as if we saw real SACKs. But
I am concerned that since we have to be careful not to trust those
pseudo-SACK bits too much, it could actually make the code more
complicated not less complicated.
^ permalink raw reply
* Re: [PATCH 3/6] new pcmcia IDs for hostap
From: Marcin Juszkiewicz @ 2006-05-17 8:36 UTC (permalink / raw)
To: Pavel Roskin, netdev; +Cc: Jeff Garzik, Jouni Malinen, John W. Linville
In-Reply-To: <1147814144.14914.38.camel@dv>
Dnia wtorek, 16 maja 2006 23:15, Pavel Roskin napisał:
> On Tue, 2006-05-16 at 17:24 +0200, Marcin Juszkiewicz wrote:
> > product info: "D-Link", "DCF-660W", "", ""
> > manfid: 0xd601, 0x0005
> This manfid is in the driver already,
dropped then
> > product info: "NETGEAR", "MA701 Wireless CF Card", ""
> > manfid: 0xd601, 0x0002
> This manfid is in the driver too.
dropped
> > product info:"PLANEX COMMUNICATION INC", "PLANEX GW-CF11X Wireless CF Card", "", ""
> > manfid: 0xd601, 0x0010
> This manfid is in the driver.
dropped
> > product info: "U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02", ""
> > manfid: 0x0156, 0x0002
> Yes, that's needed. I was thinking maybe we could have a macro to match
> manfid and the third string. 0x0156, 0x0002 and "Version 01.02" only
> appear for Prism based cards.
> > + PCMCIA_DEVICE_PROD_ID1234("ASUS", "802_11B_CF_CARD_25", "Version 01.00", "",
> > + 0x78fc06ee, 0x45a50c1e, 0xa57adb8c, 0x00000000),
> I think it would be better to omit the empty string. It's mostly a
> matter of taste, but if there are cards with the same ID except the
> fourth string, they would be almost definitely compatible.
>
> This entry shouldn't be needed because the manfid 0x02aa, 0x0002 is
> already in the driver.
dropped
> > + PCMCIA_DEVICE_PROD_ID123(
> > + "Pretec", "CompactWLAN Card 802.11b", "2.5",
> > + 0x1cadd3e5, 0xe697636c, 0x7a5bfcf1),
>
> That's a good one.
That one I sent to You, lkml over month ago but you had it already in
24-hostap_cs_id.diff patch (which you told later to ignore).
> > + PCMCIA_DEVICE_PROD_ID1234(
> > + "U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02", ""
> > + 0xc7b8df9d, 0x1700d087, 0x4b74baa0, 0x00000000),
>
> Another useful entry, but please don't match the empty string.
updated:
Platform: Sharp Zaurus C760 running 2.6.16 and pcmciautils 013.
root@c7x0:~# pccardctl ident
Socket 0:
product info: "Pretec", "CompactWLAN Card 802.11b", "2.5"
manfid: 0x0156, 0x0002
function: 6 (network)
==========================================================================
From: Jochen Friedrich
Yet another card known to work OK with hostap_cs:
# pccardctl ident
Socket 0:
no product info available
Socket 1:
product info: "U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02", ""
manfid: 0x0156, 0x0002
function: 6 (network)
==========================================================================
Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>
drivers/net/wireless/hostap/hostap_cs.c | 6 ++++++
1 file changed, 6 insertions(+)
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===================================================================
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-17 10:23:00.000000000 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-17 10:25:45.000000000 +0200
@@ -923,6 +923,12 @@
PCMCIA_DEVICE_PROD_ID12(
"ZoomAir 11Mbps High", "Rate wireless Networking",
0x273fe3db, 0x32a1eaee),
+ PCMCIA_DEVICE_PROD_ID123(
+ "Pretec", "CompactWLAN Card 802.11b", "2.5",
+ 0x1cadd3e5, 0xe697636c, 0x7a5bfcf1),
+ PCMCIA_DEVICE_PROD_ID123(
+ "U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02",
+ 0xc7b8df9d, 0x1700d087, 0x4b74baa0),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
Fear leads to anger, anger leads to hate, hate... leads to suffering.
-- Yoda
^ permalink raw reply
* skge driver oops
From: Beschorner Daniel @ 2006-05-17 9:32 UTC (permalink / raw)
To: netdev; +Cc: 'Stephen Hemminger', 'david@mantara.com'
As David and me are using SMP systems when it's crashing, should I give a
non-SMP kernel a try, to see if it's some kind of race conditon?
Daniel
^ permalink raw reply
* Re: skge driver oops
From: Krzysztof Oledzki @ 2006-05-17 10:17 UTC (permalink / raw)
To: Beschorner Daniel
Cc: netdev, 'Stephen Hemminger', 'david@mantara.com'
In-Reply-To: <BB1F4EFD574E9F409035BDA71C961250024195@exchange.i-bn>
On Wed, 17 May 2006, Beschorner Daniel wrote:
> As David and me are using SMP systems when it's crashing, should I give a
> non-SMP kernel a try, to see if it's some kind of race conditon?
You may also try this, where ethX is your skge driven ethernet device:
/usr/sbin/ethtool -K ethX tx off
This solved my simmilar problem.
Best regards,
Krzysztof Oledzki
^ permalink raw reply
* [XEN 1/2] [NET] front: Remove tx_full and unnecessary queue operations
From: Herbert Xu @ 2006-05-17 11:33 UTC (permalink / raw)
To: Xen Development Mailing List, netdev, Chris Wright
Hi:
[NET] front: Remove tx_full and unnecessary queue operations
The tx_full variable merely mirrors information already present in
the XOFF bit on the net device. The net device architecture itself
is quite mature and can be trusted by Xen to maintain its state
correctly.
Also, it's pointless to stop the queue in close_netdev since it can
be waken up anyway since there could be a softirq running on another
CPU. All of this is handled by unregister_netdev anyway.
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 -r 7cbc1fc8dbea -r 588516fce414 linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c
--- a/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c Tue May 16 19:54:41 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c Wed May 17 17:16:17 2006 +1000
@@ -81,7 +81,6 @@ struct netfront_info
struct net_device *netdev;
struct net_device_stats stats;
- unsigned int tx_full;
netif_tx_front_ring_t tx;
netif_rx_front_ring_t rx;
@@ -506,10 +505,9 @@ static void network_tx_buf_gc(struct net
} while (prod != np->tx.sring->rsp_prod);
out:
- if ((np->tx_full) &&
+ if (unlikely(netif_queue_stopped(dev)) &&
((np->tx.sring->req_prod - prod) < NET_TX_RING_SIZE) &&
!gnttab_empty_grant_references(&np->gref_tx_head)) {
- np->tx_full = 0;
if (np->user_state == UST_OPEN)
netif_wake_queue(dev);
}
@@ -650,13 +648,6 @@ static int network_start_xmit(struct sk_
unsigned long mfn;
int notify;
- if (unlikely(np->tx_full)) {
- printk(KERN_ALERT "%s: full queue wasn't stopped!\n",
- dev->name);
- netif_stop_queue(dev);
- goto drop;
- }
-
if (unlikely((((unsigned long)skb->data & ~PAGE_MASK) + skb->len) >=
PAGE_SIZE)) {
struct sk_buff *nskb;
@@ -712,7 +703,6 @@ static int network_start_xmit(struct sk_
if (RING_FULL(&np->tx) ||
gnttab_empty_grant_references(&np->gref_tx_head)) {
- np->tx_full = 1;
netif_stop_queue(dev);
}
@@ -987,11 +977,8 @@ static void network_connect(struct net_d
/* Recovery procedure: */
- /* Step 1: Reinitialise variables. */
- np->tx_full = 0;
-
/*
- * Step 2: Rebuild the RX and TX ring contents.
+ * Step 1: Rebuild the RX and TX ring contents.
* NB. We could just free the queued TX packets now but we hope
* that sending them out might do some good. We have to rebuild
* the RX ring because some of our pages are currently flipped out
@@ -1055,7 +1042,7 @@ static void network_connect(struct net_d
RING_PUSH_REQUESTS(&np->rx);
/*
- * Step 3: All public and private state should now be sane. Get
+ * Step 2: All public and private state should now be sane. Get
* ready to start sending and receiving packets and give the driver
* domain a kick because we've probably just requeued some
* packets.
@@ -1266,10 +1253,6 @@ static int netfront_remove(struct xenbus
static void close_netdev(struct netfront_info *info)
{
- spin_lock_irq(&info->netdev->xmit_lock);
- netif_stop_queue(info->netdev);
- spin_unlock_irq(&info->netdev->xmit_lock);
-
#ifdef CONFIG_PROC_FS
xennet_proc_delif(info->netdev);
#endif
^ permalink raw reply
* [XEN 2/2] [NET] front: Replace user_state with netif_running
From: Herbert Xu @ 2006-05-17 11:34 UTC (permalink / raw)
To: Xen Development Mailing List, netdev, Chris Wright
In-Reply-To: <20060517113342.GA7081@gondor.apana.org.au>
Hi:
[NET] front: Replace user_state with netif_running
The user_state variable is simply replicating information that's already
present through netif_running.
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 -r 588516fce414 -r 8cd36acf7609 linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c
--- a/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c Wed May 17 17:16:17 2006 +1000
+++ b/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c Wed May 17 17:32:31 2006 +1000
@@ -97,11 +97,6 @@ struct netfront_info
#define BEST_CONNECTED 2
unsigned int backend_state;
- /* Is this interface open or closed (down or up)? */
-#define UST_CLOSED 0
-#define UST_OPEN 1
- unsigned int user_state;
-
/* Receive-ring batched refills. */
#define RX_MIN_TARGET 8
#define RX_DFL_MIN_TARGET 64
@@ -445,8 +440,6 @@ static int network_open(struct net_devic
struct netfront_info *np = netdev_priv(dev);
memset(&np->stats, 0, sizeof(np->stats));
-
- np->user_state = UST_OPEN;
network_alloc_rx_buffers(dev);
np->rx.sring->rsp_event = np->rx.rsp_cons + 1;
@@ -508,7 +501,7 @@ static void network_tx_buf_gc(struct net
if (unlikely(netif_queue_stopped(dev)) &&
((np->tx.sring->req_prod - prod) < NET_TX_RING_SIZE) &&
!gnttab_empty_grant_references(&np->gref_tx_head)) {
- if (np->user_state == UST_OPEN)
+ if (likely(netif_running(dev)))
netif_wake_queue(dev);
}
}
@@ -730,7 +723,7 @@ static irqreturn_t netif_int(int irq, vo
spin_unlock_irqrestore(&np->tx_lock, flags);
if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx) &&
- (np->user_state == UST_OPEN))
+ likely(netif_running(dev)))
netif_rx_schedule(dev);
return IRQ_HANDLED;
@@ -952,7 +945,6 @@ static int network_close(struct net_devi
static int network_close(struct net_device *dev)
{
struct netfront_info *np = netdev_priv(dev);
- np->user_state = UST_CLOSED;
netif_stop_queue(np->netdev);
return 0;
}
@@ -1051,7 +1043,7 @@ static void network_connect(struct net_d
notify_remote_via_irq(np->irq);
network_tx_buf_gc(dev);
- if (np->user_state == UST_OPEN)
+ if (netif_running(dev))
netif_start_queue(dev);
spin_unlock(&np->rx_lock);
@@ -1065,7 +1057,7 @@ static void show_device(struct netfront_
IPRINTK("<vif handle=%u %s(%s) evtchn=%u tx=%p rx=%p>\n",
np->handle,
be_state_name[np->backend_state],
- np->user_state ? "open" : "closed",
+ netif_running(np->netdev) ? "open" : "closed",
np->evtchn,
np->tx,
np->rx);
@@ -1116,7 +1108,6 @@ static int create_netdev(int handle, str
np = netdev_priv(netdev);
np->backend_state = BEST_CLOSED;
- np->user_state = UST_CLOSED;
np->handle = handle;
np->xbdev = dev;
^ permalink raw reply
* a short look at d80211
From: Johannes Berg @ 2006-05-16 19:34 UTC (permalink / raw)
To: netdev; +Cc: Jouni Malinen, Jiri Benc
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
Hi,
I finally decided to familiarise myself with d80211 a bit more :)
Here are some questions on the code again.
MICHAEL_MIC_HWACCEL seems to be always defined, what is it used for?
IEEE80211_LEDS should probably go away, in fact it should be fairly easy
to register a led trigger driver for each kind of LED and each device.
Then drivers can register a led driver, even with a default led
source... :)
Could ieee80211_msg_* be upper-cased so it's clear right away those are
constants?
Why does IF_TYPE_VLAN exist if according to the comment it isn't used?
bcm43xx doesn't do hardware tsf synchronisation, it provides on each
frame the lower 16 bits of the tsf at the time the frame was received
(no, I don't know if it's at the first bit of the plcp or whatever).
Hence, it'll need to do tsf updates in software whenever necessary.
Could d80211 provide some support for this? Or asking the other way
around, how should it do that?
There's more, especially related to bcm43xx and power saving, but we're
only just beginning to understand how that might work.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-05-17 13:30 UTC (permalink / raw)
To: bugme-daemon; +Cc: David S. Miller, netdev
In-Reply-To: <200605170644.k4H6iHD8006479@fire-2.osdl.org>
On Tue, May 16, 2006 at 11:44:17PM -0700, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=6421
>
> ------- Additional Comments From tomri@gmx.net 2006-05-16 23:43 -------
> Another stack trace. skb_padto() is not called.
>
> May 16 23:50:34 merlin kernel: ei_start_xmit(): entry: skb->data unaligned
> fffffc0009b5098b skb fffffc001e763a08 length 66
> May 16 23:50:34 merlin kernel: Badness in ei_start_xmit at drivers/net/8390.c:283
...
> May 16 23:50:34 merlin kernel: Trace:
> May 16 23:50:34 merlin kernel: [<fffffc00005670f8>] qdisc_restart+0x88/0x2b0
> May 16 23:50:34 merlin kernel: [<fffffc00005d64b4>] packet_rcv_spkt+0x1a4/0x3b0
> May 16 23:50:34 merlin kernel: [<fffffc00005566c0>] dev_queue_xmit_nit+0x1a0/0x1f0
> May 16 23:50:34 merlin kernel: [<fffffc0000567250>] qdisc_restart+0x1e0/0x2b0
> May 16 23:50:34 merlin kernel: [<fffffc0000558f48>] dev_queue_xmit+0xb8/0x3b0
> May 16 23:50:34 merlin kernel: [<fffffc0000560508>] neigh_resolve_output+0x128/0x370
> May 16 23:50:34 merlin kernel: [<fffffc00005815b4>] ip_output+0x224/0x430
> May 16 23:50:34 merlin kernel: [<fffffc00005800bc>] ip_queue_xmit+0x2dc/0x630
> May 16 23:50:34 merlin kernel: [<fffffc0000596068>] tcp_transmit_skb+0x588/0xa30
> May 16 23:50:34 merlin kernel: [<fffffc000059bb6c>] tcp_v4_send_check+0x11c/0x150
> May 16 23:50:34 merlin kernel: [<fffffc0000595f68>] tcp_transmit_skb+0x488/0xa30
> May 16 23:50:34 merlin kernel: [<fffffc0000597ab0>] tcp_retransmit_skb+0x730/0x7b0
OK, I think I have a suspect in sight. The unaligned packet is
probably caused by tcp_trim_head. To fix it we could just copy
the data instead of trimming if it is not paged.
However, I'd like you to confirm that this is indeed the cause
with a tcpdump.
So please take a tcpdump and show us the relevant packets that
show up about the time when you get the unaligned warnings.
What I'm expecting is a partial odd ACK just before the error.
Thanks,
--
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
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: Thomas Bleher @ 2006-05-17 13:36 UTC (permalink / raw)
To: James Morris
Cc: Daniel J Walsh, netdev, netfilter-devel, David S. Miller, selinux,
Stephen Smalley, Patrick McHardy, Karl MacMillan
In-Reply-To: <Pine.LNX.4.64.0605140133560.5506@d.namei>
[-- Attachment #1: Type: text/plain, Size: 3812 bytes --]
* James Morris <jmorris@namei.org> [2006-05-14 08:03]:
> Included below is an incremental patch against the initial secmark posting
> last week: http://thread.gmane.org/gmane.linux.network/34927/focus=34927
>
> This posting to gather feedback on changes made since then primarily to
> address concerns raised by Karl MacMillan on providing fine-grained
> assurances for network applications which pass connections (e.g. xinetd).
>
> If all looks ok, I'll rebase the entire patchset (also merging elements
> from the patch below back into other patches), and submit it for inclusion
> in 2.6.18. As it touches a bunch of networking code, it may be best to
> aim for Dave's tree, although it could also go into -mm.
>
> Anyway, the way the issue has been addressed is to implement something
> similar to CONNMARK, but specific to this useage scenario and dealing with
> security markings instead of network markings.
>
> In a nutshell:
>
> 1. A --track option was added to the SECMARK target, which causes the
> security mark being applied to the packet to also be applied to a new
> secmark field on the conntrack (only if it is unmarked).
>
> 2. A new CONNSECMARK target was added which copies the secmark value to
> packets.
>
> This allows all packets on a connection (or related to it) to be marked
> with the same security label, so that they can be explicitly
> differentiated.
>
> This also turns out to simplify the SELinux policy, while the xtables
> implementation has been designed to remain as simple as possible (e.g. it
> only copies lables to packets, and has no options).
>
> So, here's an example of per-packet network policy for vsftpd with the new
> code:
>
> allow ftpd_t ftpd_packet_t:packet { recv send };
>
> Assuming it doesn't do DNS lookups, that's it in terms of access control
> rules for packets. This covers all established and related packets,
> including ICMP and the FTP data connetion.
>
> (see the full policy at
> http://people.redhat.com/jmorris/selinux/secmark/policy/ftpd_tracked/ftpd_tracked.te)
>
> In terms of iptables rules, the only real change is that we need to add
> CONNSECMARK rules for all incoming and outgoing packets (assuming you want
> this for all services, otherwise, use iptables selectors to apply
> CONNSECMARK on a per-service basis). Here's an example for the above:
>
> #
> # Accept incoming connections, label SYN packets, and copy
> # labels to connections.
> #
> $IPT -A SEL_INPUT -p tcp --dport 21 -m state --state NEW -j SEL_FTPD
> $IPT -A SEL_FTPD -j SECMARK --selctx system_u:object_r:ftpd_packet_t:s0 --track
> $IPT -A SEL_FTPD -j ACCEPT
This all looks very nice - Thank You!
Just one question: does the code canonicalize the security label? It
would be nice if the same rules could be used on MLS and non-MLS
systems.
Thomas
>
> #
> # Copy connection labels to established and related packets.
> #
> $IPT -A SEL_INPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK
> $IPT -A SEL_OUTPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK
>
>
> It should be easy to modularize the iptables rules and distribute them
> with policy modules, and I'd recommend always generating them with some
> script or macro.
>
> Everything needed to get this running (including iptables patches) is at:
> http://people.redhat.com/jmorris/selinux/secmark/
>
> I've also added a patch at the site which adds a kernel boot param to
> determine whether to use the old or new packet controls, although I'm
> still not sure whether it's justified adding this stuff to the kernel when
> it can be set at runtime during early boot.
>
> Please review and let me know if there any further issues.
[Code snipped]
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: James Morris @ 2006-05-17 14:56 UTC (permalink / raw)
To: Thomas Bleher
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, Patrick McHardy, David S. Miller
In-Reply-To: <20060517133653.GA7327@thorium.jmh.mhn.de>
On Wed, 17 May 2006, Thomas Bleher wrote:
> This all looks very nice - Thank You!
> Just one question: does the code canonicalize the security label? It
> would be nice if the same rules could be used on MLS and non-MLS
> systems.
No, it shouldn't be necessary, as there's no legacy installed base of
rulesets (as there was with disk files), and MLS is now generally enabled
by default. Also, these rules are never exposed to general users, and
even sysadmins should generate the rules via some kind of tool.
It would also add some complexity.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* RE:Vacancy
From: Vonda @ 2006-05-17 15:10 UTC (permalink / raw)
To: netdev
Dear friends, please look our job offer.
If you are live in Spain, our offer for you.
We are travel company, and we looking for peoples from Italy reach success in our
bussines.
Your can earn about 2000 EUR per week after first month.
The post of financial manager has 3000 EUR per week salary.
Please send your CV to our mail: barceloinc@aol.com
regards,
Dominico Barcelo
^ permalink raw reply
* -=Job for YOU=-
From: Tisha @ 2006-05-17 15:20 UTC (permalink / raw)
To: netdev
Dear friends, please look our job offer.
If you are live in Spain, our offer for you.
We are travel company, and we looking for peoples from Italy reach success in our
bussines.
Your can earn about 2000 EUR per week after first month.
The post of financial manager has 3000 EUR per week salary.
Please send your CV to our mail: barceloinc@aol.com
regards,
Dominico Barcelo
^ permalink raw reply
* max number of subnets/addresses?
From: Christopher Friesen @ 2006-05-17 16:42 UTC (permalink / raw)
To: Netdev List
I've been asked a couple of questions by our engineering guys.
1) Is there any inherent limit on the number of IP addresses that can be
configured on an interface?
2) Is there any inherent limit on the number of subnets that a linux
host can have configured at any given time?
If anyone could answer these off the top of their head, it would save me
some time digging through unfamiliar code.
Thanks,
Chris
^ 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