The network device frontend driver allows the kernel to access network
devices exported exported by a virtual machine containing a physical
network device driver.
Signed-off-by: Ian Pratt [EMAIL PROTECTED]
Signed-off-by: Christian Limpach [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL
On Mon, May 08, 2006 at 06:28:56PM +, Stefan Rompf wrote:
time_after() and friends can handle jiffies wrapping, however they require
the
difference between compared times to be less than 0x8000 jiffies (about
24 days on HZ=1000) to work reliably on 32bit architectures. So if the
Hi Chris:
Chris Wright [EMAIL PROTECTED] wrote:
+/** Send a packet on a net device to encourage switches to learn the
+ * MAC. We send a fake ARP request.
+ *
+ * @param dev device
+ * @return 0 on success, error code otherwise
+ */
+static int send_fake_arp(struct net_device *dev)
I
On Tue, May 09, 2006 at 12:00:34AM -0700, Chris Wright wrote:
The network device frontend driver allows the kernel to access network
devices exported exported by a virtual machine containing a physical
network device driver.
Please don't add procfs code to new network drivers. Especially if
On Tue, May 09, 2006 at 09:55:33PM +1000, Herbert Xu wrote:
Hi Chris:
Chris Wright [EMAIL PROTECTED] wrote:
+/** Send a packet on a net device to encourage switches to learn the
+ * MAC. We send a fake ARP request.
+ *
+ * @param dev device
+ * @return 0 on success, error code
Christian Limpach [EMAIL PROTECTED] wrote:
There's at least two reasons why having it in the driver is preferable:
- synchronizing sending the fake ARP request with when the device is
operational -- you really want to make this well synchronized to keep
unreachability as short as possible,
On Tuesday 09 May 2006 15:01, Herbert Xu wrote:
Christian Limpach [EMAIL PROTECTED] wrote:
There's at least two reasons why having it in the driver is preferable:
- synchronizing sending the fake ARP request with when the device is
operational -- you really want to make this well
On Tue, May 09, 2006 at 11:01:05PM +1000, Herbert Xu wrote:
Christian Limpach [EMAIL PROTECTED] wrote:
There's at least two reasons why having it in the driver is preferable:
- synchronizing sending the fake ARP request with when the device is
operational -- you really want to make this
Christian Limpach [EMAIL PROTECTED] wrote:
Possibly having to page in the process and switching to it would add
to the live migration time. More importantly, having to install an
additional program in the guest is certainly not very convenient.
Sorry I'm still not convinced. What's there
On Mon, 2006-05-08 at 17:29 -0400, James Morris wrote:
On Mon, 8 May 2006, Karl MacMillan wrote:
Something like CONNMARK seems preferable to me (perhaps even allowing
type_transition rules to give the related packets a unique type). This
makes the labeling reflect the real security
Hello,
I see that setting the essid of a wireless card
(by iwconfig eth1 essid homenet)
triggers scanning;
namely , it calls ieee80211softmac_assoc_work() method which in
turn calls ieee80211softmac_start_scan().
I use zd1211 driver which works with the softmac layer
of the last git kernel.
I
On Tue, May 09, 2006 at 11:26:03PM +1000, Herbert Xu wrote:
Christian Limpach [EMAIL PROTECTED] wrote:
Possibly having to page in the process and switching to it would add
to the live migration time. More importantly, having to install an
additional program in the guest is certainly not
[EMAIL PROTECTED] wrote on 05/09/2006 09:00:27 AM:
On Tue, May 09, 2006 at 11:26:03PM +1000, Herbert Xu wrote:
Christian Limpach [EMAIL PROTECTED] wrote:
Possibly having to page in the process and switching to it would add
to the live migration time. More importantly, having to
On Tue, 2006-05-09 at 16:38 +0300, Ian Brown wrote:
Hello,
I see that setting the essid of a wireless card
(by iwconfig eth1 essid homenet)
triggers scanning;
My question is : why is this scanning needed when set essid is called?
and why is the repeatition?
Because the wireless card needs
I'm seeing the crash below using 2.6.16.11 custom based on RedHat FC2.
The main culprit being the r8169+NAPI module, although the it821x module
(with noraid=1) seems to bring out the bug, maybe because it uses the
same interrupt.
The machine is an Athlon 2200+ with 1.5G of ram, NForce2
On Tue, 9 May 2006, Karl MacMillan wrote:
those connection, but my concern is that connection could, through error
or exploit, be passed to another domain that should not receive packets
from that type of connection (see below).
Connection passing or inheritence should be subject to kernel
Richard Gregory [EMAIL PROTECTED] :
I'm seeing the crash below using 2.6.16.11 custom based on RedHat FC2.
The main culprit being the r8169+NAPI module, although the it821x module
(with noraid=1) seems to bring out the bug, maybe because it uses the
same interrupt.
(lot of things to
Am Dienstag 09 Mai 2006 13:26 schrieb Herbert Xu:
The test used in the linkwatch does not handle wrap-arounds correctly.
Since the intention of the code is to eliminate bursts of messages we
can afford to delay things up to a second.
looks good, the code generates only up to 1 second delay
On Tue, 2006-05-09 at 12:40 -0400, James Morris wrote:
On Tue, 9 May 2006, Karl MacMillan wrote:
those connection, but my concern is that connection could, through error
or exploit, be passed to another domain that should not receive packets
from that type of connection (see below).
On Tue, 2006-05-09 at 12:40 -0400, James Morris wrote:
On Tue, 9 May 2006, Karl MacMillan wrote:
those connection, but my concern is that connection could, through error
or exploit, be passed to another domain that should not receive packets
from that type of connection (see below).
On Tue, 9 May 2006 19:39:43 +0200
Angelo P. Castellani [EMAIL PROTECTED] wrote:
I resend the file because I've sent an old (quite identical) copy
Moved discussion over to netdev mailing list..
Could you export symbols in tcp_vegas (and change config dependencies) to
allow code reuse rather
Francois Romieu wrote:
Richard Gregory [EMAIL PROTECTED] :
I'm seeing the crash below using 2.6.16.11 custom based on RedHat FC2.
The main culprit being the r8169+NAPI module, although the it821x module
(with noraid=1) seems to bring out the bug, maybe because it uses the
same interrupt.
On Tue, 09 May 2006 21:51:44 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
Stephen Hemminger [EMAIL PROTECTED] wrote:
I moved iproute2 out of CVS. New home is:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
Thanks Stephen.
BTW, how come there is a checked out
Am Dienstag 09 Mai 2006 20:31 schrieb Stephen Hemminger:
I moved iproute2 out of CVS. New home is:
fixed. stupid git
maybe you should have kept CVS. *Ducks and runs* ;-)
Stefan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
as this patch is use to add a new function but not bug fix
what can i help after i have submit it ??
as i have test it before
i can provide the data that i have tested out ;-)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
On Sun, 2006-05-07 at 15:06 +0200, Michael Buesch wrote:
On Saturday 06 May 2006 20:24, David Woodhouse wrote:
On Fri, 2006-05-05 at 17:38 +0100, David Woodhouse wrote:
I still need this hack to work around the fact that softmac doesn't
attempt to associate when we bring the device up...
On Tue, May 09, 2006 at 12:54:55AM -0400, Pavel Roskin wrote:
On Mon, 2006-05-08 at 10:17 -0700, Jean Tourrilhes wrote:
But shouldn't you trust the drivers using IW_QUAL_DBM, whether the value
is positive or negative?
You can't remove the test, making the rest pointeless. Old
Richard Gregory [EMAIL PROTECTED] :
Francois Romieu wrote:
[...]
Is netconsole enabled ?
It can be. How much output do you need, a single soft lockup?
Nonononono. Keep it disabled.
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
On Tue, 9 May 2006, Karl MacMillan wrote:
Ok - I obviously don't have the expertise to judge how ugly the code to
do this is. It becomes a question of whether the feature is compelling
enough.
Atcually, I think there may be a good way to do this, will investigate.
- James
--
James Morris
Something like this would handle errors better, but introduce possible
problems for drivers that call register_netdevice with irq's disabled.
There was some comment about racing with linkwatch, but don't see how
that could happen during creation.
For 2.6.18?
---
Johannes Berg [EMAIL PROTECTED] :
[...]
I'm thinking this is a hardware failure, is there any reason to believe
otherwise?
It's hard to tell without data. It could be any of the usual suspects
or a genuine bug.
Can you send the complete dmesg from boot + lspci -vvx + /proc/interrupts
of the
Hi,
It's hard to tell without data. It could be any of the usual suspects
or a genuine bug.
Yeah, I realise that. I've tried booting windows which behaves exactly
the same, with the latest realtek driver. I've sent back the machine
today because I need to have this box up fairly soon. Sorry :/
The stuff in /proc could easily just be added attributes to the class_device
kobject
of the net device (and then show up in sysfs).
+
+#define GRANT_INVALID_REF0
+
+#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
+#define NET_RX_RING_SIZE __RING_SIZE((struct
Richard Gregory [EMAIL PROTECTED] :
[...]
Can you send me your drivers/ide/ide-io.o ?
--
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
+static int setup_device(struct xenbus_device *dev, struct
netfront_info *info) +{
+ struct netif_tx_sring *txs;
+ struct netif_rx_sring *rxs;
+ int err;
+ struct net_device *netdev = info-netdev;
+
+ info-tx_ring_ref = GRANT_INVALID_REF;
+ info-rx_ring_ref =
On 9 May 2006, at 21:25, Stephen Hemminger wrote:
+ memcpy(netdev-dev_addr, info-mac, ETH_ALEN);
+ network_connect(netdev);
+ info-irq = bind_evtchn_to_irqhandler(
+ info-evtchn, netif_int, SA_SAMPLE_RANDOM,
netdev-name,
This doesn't look like a real random
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
+ info-irq = bind_evtchn_to_irqhandler(
+ info-evtchn, netif_int, SA_SAMPLE_RANDOM,
netdev-name,
This doesn't look like a real random entropy source. packets
arriving from another domain are easily timed.
Heh, given the path
Keir Where should we get our entropy from in a VM environment?
Keir Leaving the pool empty can cause processes to hang.
You could have something like a virtual HW RNG driver (with a frontend
and backend), which steals from the dom0 /dev/random pool.
- R.
-
To unsubscribe from this list:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 9 May 2006 12:01:07 -0700
Something like this would handle errors better, but introduce possible
problems for drivers that call register_netdevice with irq's disabled.
There was some comment about racing with linkwatch, but don't see how
On Tue, 09 May 2006 14:05:01 -0700 (PDT)
David S. Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 9 May 2006 12:01:07 -0700
Something like this would handle errors better, but introduce possible
problems for drivers that call register_netdevice with
Bringing down a port also masks off the status and other IRQ's
needed for device to function due to missing paren's.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2.orig/drivers/net/sky2.c
+++ sky2/drivers/net/sky2.c
@@ -128,6 +128,7 @@ MODULE_DEVICE_TABLE(pci, sky2_id_table);
/*
While working on the rt2x00 driver, I keep hitting against some problems with
scanning.
Basicly the dscape stack handles scanning in 2 ways, through the
passive_scan() handler in the ieee80211_hw structure, and by calling
the config() handler in the ieee80211_hw stucture.
The usage of the
From: Stefan Rompf [EMAIL PROTECTED]
Date: Sun, 7 May 2006 12:18:59 +0200
seems documentation got lost when the RFC2863-patch was applied. Having
documentation is good, so I resend it ;-)
Signed-off-by: Stefan Rompf [EMAIL PROTECTED]
Applied, thanks Stefan.
-
To unsubscribe from this list:
From: Wei Yongjun [EMAIL PROTECTED]
Date: Fri, 05 May 2006 20:36:14 -0400
I had tested the patch under linux system, maybe this mail is correct.
Fix error point to options in ip_options_fragment(). optptr get a error
pointer to the ipv4 header, correct is pointer to ipv4 options.
From: Samuel Ortiz [EMAIL PROTECTED]
Date: Tue, 9 May 2006 00:23:33 +0300
As agreed with Jean Tourrilhes, I am taking over IrDA
maintainership.
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
Applied, thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
From: Samuel Ortiz [EMAIL PROTECTED]
Date: Tue, 9 May 2006 00:23:44 +0300
This patch removes the following unused EXPORT_SYMBOL's:
- irias_find_attrib
- irias_new_string_value
- irias_new_octseq_value
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Samuel Ortiz [EMAIL
From: Samuel Ortiz [EMAIL PROTECTED]
Date: Tue, 9 May 2006 00:23:59 +0300
Minimal PNP hotplug support for the smsc-ircc2 driver. A modular driver
will be modprobed via hotplug, but still bypasses driver model probing.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Signed-off-by: Samuel
From: Samuel Ortiz [EMAIL PROTECTED]
Date: Tue, 9 May 2006 00:24:10 +0300
Since sir_kthread.c pretty much duplicates the workqueue functionality,
we'd better switch.
The SIR fsm has been merged into sir_dev.c and thus sir_kthread.c is
deleted.
Signed-off-by: Christoph Hellwig [EMAIL
Ian Brown wrote:
My question is : why is this scanning needed when set essid is called?
and why is the repeatition?
ESSID doesn't tell you the channel nummber, so you have to scan
for a beacon containing the ESSID in passive scanning. Even if you
do active scanning you need to check all
From: Stefan Rompf [EMAIL PROTECTED]
Date: Tue, 9 May 2006 18:51:49 +0200
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Acked-by: Stefan Rompf [EMAIL PROTECTED]
Applied, thanks everyone.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Tuesday 09 May 2006 18:01, Ivo van Doorn wrote:
A user on the forums Olivier Cornu (added to the CC list) has done some
investigation into the scanning behaviour of the dscape stack.
Basicly the dscape stack is performing active scanning while the device is
down, but during the active scan
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 9 May 2006 14:40:49 -0700
Agreed, especially since rtnl is now a real mutex. The case, that
I was worried about:
rtnl_lock()
spin_lock_irq(mylock);
x = register_netdevice();
...
Doesn't show up in any current code,
Chris Wright [EMAIL PROTECTED] wrote:
+ netdev-features= NETIF_F_IP_CSUM;
Any reason why IP_CSUM was chosen instead of HW_CSUM? Doing the latter
would seem to be in fact easier for a virtual driver, no?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu
On Tue, 09 May 2006 15:43:22 -0700 (PDT)
David S. Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 9 May 2006 14:40:49 -0700
Agreed, especially since rtnl is now a real mutex. The case, that
I was worried about:
rtnl_lock()
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
On Tue, May 09, 2006 at 12:00:34AM -0700, Chris Wright wrote:
The network device frontend driver allows the kernel to access network
devices exported exported by a virtual machine containing a physical
network device driver.
Please don't add
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
The stuff in /proc could easily just be added attributes to the class_device
kobject
of the net device (and then show up in sysfs).
Agreed, it's on the todo list to drop proc support there. Thought that
was marked in the patch.
+#define
* Herbert Xu ([EMAIL PROTECTED]) wrote:
Chris Wright [EMAIL PROTECTED] wrote:
+ netdev-features= NETIF_F_IP_CSUM;
Any reason why IP_CSUM was chosen instead of HW_CSUM? Doing the latter
would seem to be in fact easier for a virtual driver, no?
That, I really don't know.
This patch is required to get sis900 ethernet working well on a Foxconn
661FX7MI-S motherboard which uses the SiS 661FX chipset. The patch adds
an entry to mii_chip_info for the transceiver.
The PHY ids were found using the sis900_c_122.diff patch from
http://brownhat.org/sis900.html but that
2006/5/10, Michael Wu [EMAIL PROTECTED]:
On Tuesday 09 May 2006 18:01, Ivo van Doorn wrote:
A user on the forums Olivier Cornu (added to the CC list) has done some
investigation into the scanning behaviour of the dscape stack.
Basicly the dscape stack is performing active scanning while the
59 matches
Mail list logo
