ototype, make the code more
> future-proof by using the standard irq_handler_t typedef.
>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
>
Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> arch/sparc/kernel/irq.c |4 ++--
> arch/x86/xen/
Keep tx and rx elements separate on different cachelines to prevent
bouncing.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Stephen Hemminger <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
---
drivers/net/xen-netfront.c | 37 ++
This patch removes some residual dead code left over from removing the
"flip" receive mode. This patch doesn't change the generated output
at all, since gcc already realized it was dead.
This resolves the "regression" reported by Adrian.
Signed-off-by: Jeremy Fitzhardin
Jeff Garzik wrote:
> ACK but does not apply to jgarzik/netdev-2.6.git#upstream nor
> davem/net-2.6.24.git
OK, looks like you don't have the other two patches. Will post in a sec.
J
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECT
Jeff Garzik wrote:
> Jeremy Fitzhardinge wrote:
>> Keep tx and rx elements separate on different cachelines to prevent
>> bouncing.
>>
>> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>> Cc: Stephen Hemminger <[EMAIL PROTECTED]&g
Keep tx and rx elements separate on different cachelines to prevent
bouncing.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Stephen Hemminger <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
---
drivers/net/xen-netfront.c | 37 ++
Jeff Garzik wrote:
> drivers/net/xen-netfront.c | 26 +++
>
Hey, look, its identical to the patch I have here.
Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
J
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messa
Jesper Juhl wrote:
> This moves the updating of both tx_bytes and tx_packets inside the
> spinlock, but as far as I can see we only _really_ need to move the
> tx_bytes update. Considering that we generally want to do as little
> work as possible while holding a lock, wouldn't the following be
xennet_tx_bug_gc can free the skb before we use it, so make sure we don't.
Jeff, this is -rc material.
Signed-off-by: Keir Fraser <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
diff -r 8bfc43f6d1b0 drivers/n
Jeff Garzik wrote:
> Yes. It's in my pending-for-2.6.24 folder, since it's not a bug fix.
Great, thanks.
J
-
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
Jeff Garzik wrote:
> Please send drivers/net/* through me and netdev...
Sure. Did you pick this patch up?
Thanks,
J
-
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
This patch removes some residual dead code left over from removing the
"flip" receive mode. This patch doesn't change the generated output
at all, since gcc already realized it was dead.
This resolves the "regression" reported by Adrian.
Signed-off-by: Jeremy Fitzhardin
Adrian Bunk wrote:
> The Coverity checker spotted the following bogus code
> in drivers/net/xen-netfront.c:
>
> <-- snip -->
>
> ...
> static void xennet_alloc_rx_buffers(struct net_device *dev)
> {
> ...
> for (nr_flips = i = 0; ; i++) {
> skb = __skb_dequeue(&np->rx_batc
Rusty Russell wrote:
> The default function points to the internal stats...
>
Right you are.
J
-
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
Stephen Hemminger wrote:
>> +struct netfront_info {
>> +struct list_head list;
>> +struct net_device *netdev;
>> +
>> +struct net_device_stats stats;
>>
>
> There is now a net_device_stats element inside net_device on
> 2.6.21 or later.
>
Ah, OK. Should I just do a s/stats/net
Jeff Garzik wrote:
> Look at the function argument...
Yes, it's void *. But my point is that C requires the ?: to evaluate to
some specific type, so if you have different types on each side of the :
the compiler can be legitimately upset. The fact that the whole thing
gets cast to void * is som
Jeff Garzik wrote:
>>
>> +t3_intr_handler(adapter, qs->rspq.polling) (0,
>> +(adapter->flags & USING_MSIX) ?
>> +(void *)qs : (void *)adapter);
>
> Remove needless casts to void*
The two branches of ?: need to have the same type; without the casts
the
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: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Ian P
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: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Ian P
David Miller wrote:
> I'm not so certain now that we know it's the jiffies wrap point :-)
>
> The fixes in question are attached below and they were posted and
> discussed on netdev:
>
Yep, this patch gets rid of my spinning thread. I can't find this patch
or any discussion on marc.info; is th
Andrew Morton wrote:
> Five minutes after boot is when jiffies wraps. Are you sure it's
> a list-screwup rather than a jiffy-wrap screwup?
>
Hm, its suggestive, isn't it? Apparently they've already fixed this in
the sekret networking clubhouse, so I'll need to track it down.
J
-
To unsu
David Miller wrote:
> From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Date: Thu, 10 May 2007 15:00:05 -0700
>
>
>> Herbert Xu wrote:
>>
>>> [NET] link_watch: Move link watch list into net_device
>>>
>>> These days the link watch mech
Herbert Xu wrote:
> [NET] link_watch: Move link watch list into net_device
>
> These days the link watch mechanism is an integral part of the
> network subsystem as it manages the carrier status. So it now
> makes sense to allocate some memory for it in net_device rather
> than allocating it on de
e
networking to not delay an initial down->up transition, and so the
timing concern has been solved.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PROTECTED]>
Cc: Keir Fraser <[EMAIL PROTECTED]>
diff -r 282bef511e66 drivers/net/xen-netfront.c
--
Rusty Russell wrote:
> Looks good, you can slightly improve it to be the model use of new
> module_param types by calling your functions param_set_rx_mode and
> param_get_rx_mode, then simply using "module_param(rx_mode, rx_mode,
> 0400)"
>
Cute. I tried it out, but it doesn't yield an obvious
Herbert Xu wrote:
> On Sat, May 05, 2007 at 03:05:07AM -0700, Jeremy Fitzhardinge wrote:
>
>> Sorry, I forgot about it. I was waiting to hear back from network
>> people about what this is actually for, and whether we really need it.
>>
>
> We
Christoph Hellwig wrote:
> On Fri, May 04, 2007 at 04:21:16PM -0700, Jeremy Fitzhardinge wrote:
>
>> +/*
>> + * Mutually-exclusive module options to select receive data path:
>> + * rx_copy : Packets are copied by network backend into local memory
>> + * rx_flip
Christoph Hellwig wrote:
> There only seems to be a module description but no actual paramter for
> this. I wish people would have listened to me back then and made the
> description part of the modular_param statement..
>
Uh, what did I miss? Oh, I see, I need a module_param(rx_mode, int,
06
x_lock can also be taken in softirq context, so it should be taken/released
with spin_(un)lock_bh.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Ian Pratt <[EMAIL PROTECTED]>
Cc: Christian Limpach <[EMAIL PROTECTE
Gerd Hoffmann wrote:
> Drawback is that the guest kernel wouldn't work with older xen
> versions (dom0 netback driver to be exact) any more. Probably
> wouldn't be a showstopper though, given that xen 3.0.3 probably is
> almost one year out by the time 2.6.22 will be released ...
I don't think we
Gerd Hoffmann wrote:
>> Gerd, in change 11196:b85da7cd9ea5 "front: Fix rx buffer leak when
>> tearing down an interface." you added a call to
>> "add_id_to_freelist(np->rx_skbs, id);". However, rx_skbs doesn't have
>> an extra entry for the list head, and there's never any corresponding
>> get_id_
(Gerd, Herbert: there's some questions directed to you down there.)
Rusty Russell wrote:
>> /*
>> * {tx,rx}_skbs store outstanding skbuffs. The first entry in tx_skbs
>> * is an index into a chain of free entries.
>> */
>> struct sk_buff *tx_skbs[NET_TX_RING_SIZE+1];
>>
Rusty Russell wrote:
> On Tue, 2007-05-01 at 17:08 -0700, Jeremy Fitzhardinge wrote:
>
>> Add the Xen virtual network device driver.
>>
>
> (Herbert: there's a question for you: grep for Herbert)
>
> OK, this is a remarkably non-trivial driver. If the v
Christoph Hellwig wrote:
> On Sun, Apr 29, 2007 at 10:29:02AM -0700, Jeremy Fitzhardinge wrote:
>
>> +#include
>>
>
> not needed.
>
Yup.
>> +#include
>> +#include
>> +#include
>> +#ifdef CONFIG_XEN_BALLOON
>> +#include
>
ight <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: netdev@vger.kernel.org
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/Kconfig| 12
drivers/net/Makefile |2
ight <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: netdev@vger.kernel.org
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/Kconfig| 12
drivers/net/Makefile |2
Herbert Xu wrote:
> I've had a look at now and you can just stuff it into one of the other
> pointers that's still there. We just need to make sure that it is
> reset properly before we feed the packet into the stack. The pointer
> skb->dev is one candidate but there are plenty of others.
>
H
Hi Herbert,
I wonder if you've got a chance to look at netfront in light of the new
stuff in davem's network tree (the stuff that's in
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.22.git).
In particular, struct sk_buff has been changed so that "nh" has gone,
and the replacement can be
Matt Mackall wrote:
> On Tue, Mar 20, 2007 at 09:31:58AM -0700, Jeremy Fitzhardinge wrote:
>
>> Linus Torvalds wrote:
>>
>>> On Tue, 20 Mar 2007, Eric W. Biederman wrote:
>>>
>>>
>>>> If that is the case. In the normal
Zachary Amsden wrote:
> I think Jeremy's idea was to have interrupt handlers leave interrupts
> disabled on exit if pda.intr_mask was set. In which case, they would
> bypass all work and we could never get preempted.
Yes, I was worried that if we left the isr without actually handling the
interru
Linus Torvalds wrote:
> On Tue, 20 Mar 2007, Eric W. Biederman wrote:
>
>> If that is the case. In the normal kernel what would
>> the "the oops, we got an interrupt code do?"
>> I assume it would leave interrupts disabled when it returns?
>> Like we currently do with the delayed disable of nor
Eric W. Biederman wrote:
> Looking at the above code snippet. I guess it is about time to
> merge our per_cpu and pda variables...
Rusty has a nice patch series to do just that; I think he's still
looking for a taker.
J
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
t
Zachary Amsden wrote:
> For VMI, the default clobber was "cc", and you need a way to allow at
> least that, because saving and restoring flags is too expensive on x86.
According to lore (Andi, I think), asm() always clobbers cc.
> I still don't think this was a good trade. The primary motivatio
Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
>> If we then work out in each direction and see matched push/pops,
>> then we know what registers can be trashed in the call. This also
>> allows us to determine the callsite size, and therefore how much space
&g
David Miller wrote:
> Another point worth making is that for function calls you
> can fix things up lazily if you want.
> [...]
> In fact forget I mentioned this idea :)
>
OK :) I think we'll only ever want to bind to a hypervisor once, since
the underlying hypervisor can't change on the fly (
Linus Torvalds wrote:
> On Mon, 19 Mar 2007, Eric W. Biederman wrote:
>
>> True. You can use all of the call clobbered registers.
>>
>
> Quite often, the biggest single win of inlining is not so much the code
> size (although if done right, that will be smaller too), but the fact that
>
Eric W. Biederman wrote:
> Rusty Russell <[EMAIL PROTECTED]> writes:
>
>
>> On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
>>
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use th
Andi Kleen wrote:
>>
>> push %eax
>> push %ecx
>> push %edx
>> call paravirt_cli
>> pop %edx
>> pop %ecx
>> pop %eax
>>
>
> This cannot right now be expressed as inline assembly in the unwinder at all
> because there is no way to inject the push/pops into the compi
Andi Kleen wrote:
> Yes. All inline assembly tells gcc what registers are clobbered
> and it fills in the tables. Hand clobbering in inline assembly cannot
> be expressed with the current toolchain, so we moved all those
> out of line.
>
> But again I'm not sure it will work anyways. For once you w
Andi Kleen wrote:
> You could use the dwarf2 unwind tables. They have exact information
> what register has what. But it would likely get complicated.
Yes. And would they be accurate for hand-written asm, which is where we
have this problem?
J
-
To unsubscribe from this list: send the line "
Andi Kleen wrote:
>> The idea is _NOT_ that you go look for references to the paravirt_ops
>> members structure, that would be stupid and you wouldn't be able to
>> use the most efficient addressing mode on a given cpu, you'd be
>> patching up indirect calls and crap like that. Just say no...
>>
David Miller wrote:
> The idea is _NOT_ that you go look for references to the paravirt_ops
> members structure, that would be stupid and you wouldn't be able to
> use the most efficient addressing mode on a given cpu, you'd be
> patching up indirect calls and crap like that. Just say no...
>
> In
David Miller wrote:
> Perhaps the problem can be dealt with using ELF relocations.
>
> There is another case, discussed yesterday on netdev, where run-time
> resolution of ELF relocations would be useful (for
> very-very-very-read-only variables) so if it can solve this problem
> too it would be ni
Stephen Hemminger wrote:
> This adds another inet device option to enable gratuitous ARP
> when device is brought up or address change. This is handy for
> clusters or virtualization.
>
Thanks Stephen. Haven't tested this yet, but it definitely cleans up a
warty corner of netfront.
J
-
To
Stephen Hemminger wrote:
> On Thu, 01 Mar 2007 15:25:09 -0800
> Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>
>> The network device frontend driver allows the kernel to access network
>> devices exported exported by a virtual machine containing a phy
ight <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: netdev@vger.kernel.org
Cc: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/net/Kconfig| 12
drivers/net/Makefile |2
drivers/net/xen-netfront.c | 2066 +++
ight <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: netdev@vger.kernel.org
Cc: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/net/Kconfig| 12
drivers/net/Makefile |2
drivers/net/xen-netfront.c | 2066 +++
ight <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: netdev@vger.kernel.org
---
drivers/net/Kconfig| 12
drivers/net/Makefile |2
drivers/net/xen-netfront.c | 2066
include/xen/events.
Andrew Morton wrote:
Jeremy reported that a while back too. I do not know what is causing it
and as far as I know no net developers have yet looked into it.
It went away with -rc4-mm[23] for me...
J
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
Arjan van de Ven wrote:
and you're also sure this is not your userspace using interface
renaming...
(could be an initscripts bug for name-by-MAC ethernet device naming)
It's definitely in-kernel, since its specific to this version. And it
seems to have gone away since I turned on slab debugg
Arjan van de Ven wrote:
Jeremy Fitzhardinge wrote:
Andrew Morton wrote:
e1000 seems OK here. Don't know, sorry.
It's happening to all my ethernet-like devices: the Atheros wireless
comes up as a mess too. It's different each time, so it looks like
random uninitializ
Andrew Morton wrote:
e1000 seems OK here. Don't know, sorry.
It's happening to all my ethernet-like devices: the Atheros wireless
comes up as a mess too. It's different each time, so it looks like
random uninitialized crud.
I did a clean rebuild, but it still happens. I guess I'll hav
Auke Kok wrote:
x60 bios upgrade 1.06 is here: (found by typing "x60 bios" in the
search bar on the same website)
http://www-307.ibm.com/pc/support/site.wss/license.do?filename=mobiles/7buj04uc.iso
unfortunately the changelog for this BIOS upgrade doesn't tell us much
if the DSPD feature w
Auke Kok wrote:
See:
http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-63027
links to the latest .iso image.
Note: I haven't tried the 1.07 update myself. I had to *downgrade* our
test system to actually expose the bug.
This appears to be a link to the T60 1.06 update. Do
Auke Kok wrote:
Sorry for the long wait, there's some new information on this that
just this morning arrived.
Thanks for the update.
The latest EEPROM's from Lenovo (obtainable from their websites as
.iso) seem to have this feature turned off, which resolves the issue.
Do you have a specific
the device queue is stopped.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
diff -r 0b8d3d4ee182 net/core/netpoll.c
--- a/net/core/netpoll.cMon Jun 12 13:46:23 2006 -0700
+++ b/net/core/netpoll.cMon Jun 12 13:48:34 2006 -0700
@@ -279,14 +279,10 @@ static void netpoll
Andi Kleen wrote:
On Monday 12 June 2006 17:38, Mark Lord wrote:
Okay, so I'm daft. But.. *what* is "it" ??
We have two machines: target (being debugged), and host (anything).
Sure, the target has to have ohci1394 loaded, and firescope running.
But what about the *other* end of the connect
Matt Mackall wrote:
On Thu, Jun 08, 2006 at 07:15:50PM -0700, Jeremy Fitzhardinge wrote:
Here's a patch. I haven't tested it beyond compiling it, and I don't
know if it is actually correct. In this case, it seems pointless to
spin waiting for an even which will never
Auke Kok wrote:
netconsole should retry. There is no timeout programmed here since
that might
lose important information, and you rather want netconsole to survive
an odd
unplugged cable then to lose vital debugging information when the
system is
busy for instance. (losing link will cause the i
to not even
bother trying to send? netif_poll_disable seems mysteriously simple to me.
J
--
Subject: netpoll: don't spin forever sending to stopped queues
When transmitting a skb in netpoll_send_skb(), only retry a limited
number of times if the device queue is stopped.
Signed-off-by: Jerem
Rafael J. Wysocki wrote:
Please try doing "echo 8 > /proc/sys/kernel/printk" before suspend.
Um, why? That would increase the amount of log output, but I don't see
how it would help with netconsole preventing suspend, or not being able
to see console messages on a blank screen after resume.
Matt Mackall wrote:
That's odd. Netpoll holds a reference to the device, of course, but so
does a normal "up" interface. So that shouldn't be the problem.
Another possibility is that outgoing packets from printks in the
driver are causing difficulty. Not sure what can be done about that.
I onl
I've been trying to get suspend/resume working well on my new laptop.
In general, netconsole has been pretty useful for extracting oopses and
other messages, but it is of more limited help in debugging the actual
suspend/resume cycle. The problem looks like the e1000 driver won't
suspend whil
With 2.6.17-rc5-mm2 (and other kernels), the e1000 fails to load
sometimes, with the message:
Intel(R) PRO/1000 Network Driver - version 7.0.38-k4-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
PCI: Setting latency timer of de
74 matches
Mail list logo
