* Re: (2nd attempt) Please pull 'upstream-davem' branch of wireless-2.6
From: David Miller @ 2007-12-25 4:57 UTC (permalink / raw)
To: linville; +Cc: netdev, linux-wireless
In-Reply-To: <20071221140527.GA19874@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 21 Dec 2007 09:05:27 -0500
> These are destined for 2.6.25. The patches fall mostly into two
> categories: a new rate control algorithm for mac80211, and some
> cfg80211 enhancements (including mac80211 patches to use them).
>
> Also there are some small hits in the iwlwifi drivers related to
> rate control. I'll CC Jeff since his tree has a lot of iwlwifi symbol
> renames and those patches will conflict (or break the build, or both)
> when your tree and his finally come together.
>
> Let me know if there are any problems!
Pulled, thanks a lot!
^ permalink raw reply
* Re: [PATCH] TUNTAP: Fix wrong debug message
From: Toyo Abe @ 2007-12-25 3:27 UTC (permalink / raw)
To: joe; +Cc: netdev, maxk
In-Reply-To: <1198550928.19504.1.camel@localhost>
[-- Attachment #1: Type: Text/Plain, Size: 396 bytes --]
--- Original Messsage ---
From: Joe Perches <joe@perches.com>
Subject: Re: [PATCH] TUNTAP: Fix wrong debug message
Date: Mon, 24 Dec 2007 18:48:48 -0800
Message-ID: <1198550928.19504.1.camel@localhost>
> More readable to reverse the strings
>
> tun->dev->name, arg ? "enabled" : "disabled");
>
Hello Joe,
Thanks for your advice.
This is the more readable version.
Best Regards,
-toyo
[-- Attachment #2: TUNTAP-Fix-wrong-debug-message.patch --]
[-- Type: Text/Plain, Size: 673 bytes --]
This is a trivial fix of debug message.
When a persist flag is set, the message should say "enabled".
Signed-off-by: Toyo Abe <tabe@miraclelinux.com>
---
drivers/net/tun.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 1f76446..f8b8c71 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -610,7 +610,7 @@ static int tun_chr_ioctl(struct inode *inode, struct file *file,
tun->flags &= ~TUN_PERSIST;
DBG(KERN_INFO "%s: persist %s\n",
- tun->dev->name, arg ? "disabled" : "enabled");
+ tun->dev->name, arg ? "enabled" : "disabled");
break;
case TUNSETOWNER:
--
1.5.3.6
^ permalink raw reply related
* [PATCH] TUNTAP: Fix wrong debug message
From: Toyo Abe @ 2007-12-25 1:53 UTC (permalink / raw)
To: netdev; +Cc: vtun, maxk
This is a trivial fix of debug message.
When a persist flag is set, the message should say "enabled".
Signed-off-by: Toyo Abe <tabe@miraclelinux.com>
---
drivers/net/tun.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 1f76446..e5a3f5d 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -610,7 +610,7 @@ static int tun_chr_ioctl(struct inode *inode, struct file *file,
tun->flags &= ~TUN_PERSIST;
DBG(KERN_INFO "%s: persist %s\n",
- tun->dev->name, arg ? "disabled" : "enabled");
+ tun->dev->name, (!arg) ? "disabled" : "enabled");
break;
case TUNSETOWNER:
--
1.5.3.6
^ permalink raw reply related
* Re: [patch 3/6] netxen: improve MSI interrupt handling
From: Dhananjay Phadke @ 2007-12-25 0:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <476DDB6E.8050700@garzik.org>
Supposedly I had 2.6.24-rc2 as base for the patchset, but looks like it
had some stale code. I'll regenrate series on a fresh checkout.
-Dhananjay
On Sat, 22 Dec 2007, Jeff Garzik wrote:
> Patch does not apply to 2.6.24-rc.
>
> Was this "bug fix" series meant for 2.6.25?
>
> Jeff
>
>
>
>
>
^ permalink raw reply
* Re: "ip neigh show" not showing arp cache entries?
From: Herbert Xu @ 2007-12-25 1:06 UTC (permalink / raw)
To: Chris Friesen; +Cc: yoshfuji, dada1, netdev, linux-kernel
In-Reply-To: <47692AA1.20902@mail.usask.ca>
On Wed, Dec 19, 2007 at 08:28:49AM -0600, Chris Friesen wrote:
>
> I've included the traces below, they're pretty long. I don't know
> enough about the netlink format to trace the responses, but I did notice
> one interesting thing.
>
> In the "ip neigh show" case the "bond2" entry isn't printed out, but I
> can see the string "bond2" in the recvmsg() call so it looks like the
Actually bond2 isn't in the recvmsg, it's just that strace is
printing out the complete content of the buffer which happenes
to include bond2.
I've verified that the first recvmsg indeed does not contain the
bond2 address at all. Instead of the first 3 IPv4 records it has
3 IPv6 records. So we seem to have a kernel problem here.
However, too many changes have been made in this area since 2.6.14
for it to be worthwhile for me to debug this any further until you
manage to reproduce it with the current kernel.
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
^ permalink raw reply
* Re: [RFC] potential bugs in nexten
From: Dhananjay Phadke @ 2007-12-25 1:04 UTC (permalink / raw)
To: Al Viro; +Cc: jgarzik, netdev
In-Reply-To: <E1J6X0S-0007Sb-AQ@ZenIV.linux.org.uk>
Probably I need to clean up much more junk like that from days before I
took over. I recently cleaned up a bit of rx and tx code, which is more
frequently executed.
The last one (byte swapping) is serious and I am gonna take care of that
in next patch.
Thanks,
-Dhananjay
On Sun, 23 Dec 2007, Al Viro wrote:
>
> * what are default: doing in netxen_nic_hw_write_wx()/netxen_nic_hw_read_wx()?
> Unlike all other cases they do iomem->iomem copying and AFAICS they are never
> actually triggered.
>
> * netxen_nic_flash_print() reads the entire user_info from card *in* *host-endian*,
> then uses user_info.serial_number[].
> a) do we need to read the rest?
> b) more interesting question, don't we need cpu_to_le32() here? After
> all, that sucker is an array of char, so we want it in the same order regardless
> of the host...
>
> * in netxen_nic_xmit_frame() we do
> hw->cmd_desc_head[saved_producer].flags_opcode =
> cpu_to_le16(hw->cmd_desc_head[saved_producer].flags_opcode);
> hw->cmd_desc_head[saved_producer].num_of_buffers_total_length =
> cpu_to_le32(hw->cmd_desc_head[saved_producer].
> num_of_buffers_total_length);
> Huh? Everything that modifies either of those does so in little-endian already.
> This code appeared in commit 6c80b18df3537d1221ab34555c150bccbfd90260 (NetXen:
> Port swap feature for multi port cards); what's going on there?
>
>
^ permalink raw reply
* Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
From: Herbert Xu @ 2007-12-25 0:53 UTC (permalink / raw)
To: jamal; +Cc: David Shwatrz, yoshfuji, davem, netdev
In-Reply-To: <1198507860.9642.53.camel@localhost>
On Mon, Dec 24, 2007 at 09:50:59AM -0500, jamal wrote:
>
> Herbert, i agree with you that userspace is the best spot for this[1];
> we unfortunately have precedence already on the kernel sending arps with
> bonding when link status changes (that was added recently).
> So it sounds reasonable to have this patch in the kernel as well.
Well just because we've made a mistake in the past does not mean
that we should repeat it over and over again. If we keep doing
this the kernel will soon end up as a whole heap of junk.
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
^ permalink raw reply
* [RFC] old stuff - Kernel Bug Tracker Bug 7398
From: Andreas Henriksson @ 2007-12-25 0:27 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Pierre Ynard, 394780
Hello!
While looking over the old remaining bugs reported against iproute in
Debian I came across http://bugs.debian.org/394780 which has also been
reported as http://bugzilla.kernel.org/show_bug.cgi?id=7398 (please see
the old comments here).
As there seems to be a question remaining which still hasn't been
answered (read: shot down), I thought I'd try to give this a push a last
time.
The bugs last comment was from Pierre asking about a patch he provided:
> I am sorry, I didn't mean to break anything... What about a sysctl option, to
> give the user the possibility to disable the hack? See attached patch. I can't
> really see any drawback to that. Please review and consider re-opening the bug.
The patch (which probably doesn't even apply anymore) is available from
http://andrea.via.ecp.fr/mc-src-strict.patch but also quoted below for
your convenience...
It would be nice to have some comments on this so we can put this issue
to rest without leaving any loose ends.
(Btw, I'm a bit surprised by the comment about backwards compatability
before proper functionality. If this hack has been in the kernel for 11
years, isn't it soon time to say that the applications has been given
enough time to fix their problems and remove it? I thought thats how it
usually worked around here.... I guess I was wrong.)
diff -urNp linux-2.6.18/Documentation/filesystems/proc.txt linux-2.6.18/Documentation/filesystems/proc.txt
--- linux-2.6.18/Documentation/filesystems/proc.txt 2006-09-19 20:42:06.000000000 -0700
+++ linux-2.6.18/Documentation/filesystems/proc.txt 2006-10-26 05:13:15.000000000 -0700
@@ -1758,6 +1758,15 @@ max_delay, min_delay
Delays for flushing the routing cache.
+mc_src_strict
+-------------
+
+There is a hack in the kernel router which provides compatibility for old
+multicast applications such as vic, vat and friends. Unfortunately, this
+hack also breaks normal behavior of preferred source address selection
+(iproute2 "src" field) with multicast and limited broadcast. Enabling this
+option disables this hack and restores normal (strict) behavior.
+
redirect_load, redirect_number
------------------------------
diff -urNp linux-2.6.18/include/linux/sysctl.h linux-2.6.18/include/linux/sysctl.h
--- linux-2.6.18/include/linux/sysctl.h 2006-09-19 20:42:06.000000000 -0700
+++ linux-2.6.18/include/linux/sysctl.h 2006-10-26 04:25:00.000000000 -0700
@@ -433,6 +433,7 @@ enum {
NET_IPV4_ROUTE_MIN_ADVMSS=17,
NET_IPV4_ROUTE_SECRET_INTERVAL=18,
NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS=19,
+ NET_IPV4_ROUTE_MC_SRC_STRICT=20,
};
enum
diff -urNp linux-2.6.18/net/ipv4/route.c linux-2.6.18/net/ipv4/route.c
--- linux-2.6.18/net/ipv4/route.c 2006-09-19 20:42:06.000000000 -0700
+++ linux-2.6.18/net/ipv4/route.c 2006-10-26 05:11:00.000000000 -0700
@@ -132,6 +132,7 @@ static int ip_rt_mtu_expires = 10 * 60
static int ip_rt_min_pmtu = 512 + 20 + 20;
static int ip_rt_min_advmss = 256;
static int ip_rt_secret_interval = 10 * 60 * HZ;
+static int ip_rt_mc_src_strict = 0;
static unsigned long rt_deadline;
#define RTprint(a...) printk(KERN_DEBUG a)
@@ -2416,7 +2417,7 @@ static int ip_route_output_slow(struct r
of another iface. --ANK
*/
- if (oldflp->oif == 0
+ if (!ip_rt_mc_src_strict && oldflp->oif == 0
&& (MULTICAST(oldflp->fl4_dst) || oldflp->fl4_dst == 0xFFFFFFFF)) {
/* Special hack: user can direct multicasts
and limited broadcast via necessary interface
@@ -2431,6 +2432,12 @@ static int ip_route_output_slow(struct r
cannot know, that ttl is zero, so that packet
will not leave this host and route is valid).
Luckily, this hack is good workaround.
+
+ Unfortunately, it also breaks normal behavior of
+ source address preference, so I added a sysctl option
+ to let the user disable this hack and restore normal
+ behavior. By default, the hack is still enabled (old
+ compatibility behavior). -- PY
*/
fl.oif = dev_out->ifindex;
@@ -3057,6 +3064,15 @@ ctl_table ipv4_route_table[] = {
.proc_handler = &proc_dointvec_jiffies,
.strategy = &sysctl_jiffies,
},
+ {
+ .ctl_name = NET_IPV4_ROUTE_MC_SRC_STRICT,
+ .procname = "mc_src_strict",
+ .data = &ip_rt_mc_src_strict,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &ipv4_doint_and_flush,
+ .strategy = &ipv4_doint_and_flush_strategy,
+ },
{ .ctl_name = 0 }
};
#endif
--
Regards,
Andreas Henriksson
^ permalink raw reply
* Re: [XFRM]: Fix outbound statistics.
From: David Miller @ 2007-12-25 0:00 UTC (permalink / raw)
To: nakam; +Cc: herbert, netdev, usagi-core
In-Reply-To: <1198247100998-git-send-email-nakam@linux-ipv6.org>
From: Masahide NAKAMURA <nakam@linux-ipv6.org>
Date: Fri, 21 Dec 2007 23:25:00 +0900
> Hello David,
>
> I'm sorry, the previous mail contains wrong code:
...
> Please apply the below patch instead of the previous.
>
> Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-2.6.25 2/2][NETNS] net: Add a helper function neigh_param_default_alloc
From: David Miller @ 2007-12-24 23:56 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, den, benjamin.thery
In-Reply-To: <20071221131606.284066116@ICON-9-164-138-215.megacenter.de.ibm.com>
From: Eric.W.Biederman" <ebiederm@xmission.com>"@fr.ibm.com
Date: Fri, 21 Dec 2007 14:02:25 +0100
> In the presence of multiple network namespaces the logic needed
> to allocate the a default parameter table is just barely non-trivial.
> So add a function to automate it to make everyone's life easier.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Please submit this patch with the patch set that starts
to use the new interface.
There is no need to add it now, thanks.
^ permalink raw reply
* Re: [patch net-2.6.25 1/2][NETNS] net: Modify the neighbour table code so it handles multiple network namespaces
From: David Miller @ 2007-12-24 23:56 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, den, benjamin.thery
In-Reply-To: <20071221131601.818555294@ICON-9-164-138-215.megacenter.de.ibm.com>
From: Eric.W.Biederman" <ebiederm@xmission.com>"@fr.ibm.com
Date: Fri, 21 Dec 2007 14:02:24 +0100
> I'm actually surprised at how much was involved. At first glance it appears
> that the neighbour table data structures are already split by network device
> so all that should be needed is to modify the user interface commands
> to filter the set of neighbours by the network namespace of their devices.
>
> However a couple things turned up while I was reading through the code.
> The proxy neighbour table allows entries with no network device, and
> the neighbour parms are per network device (except for the defaults)
> so they now need a per network namespace default.
>
> So I updated the two structures (which surprised me) with their very
> own network namespace parameter. Updated the relevant lookup and
> destroy routines with a network namespace parameter and modified
> the code that interacts with users to filter out neighbour
> table entries for devices of other namespaces.
>
> I'm a little concerned that we can modify and display the global
> table configuration and from all network namespaces. But
> this appears good enough for now.
>
> I keep thinking modifying the neighbour table to have per network
> namespace instances of each table type would should be cleaner. The
> hash table is already dynamically sized so there are it is not a limiter.
> The default parameter would be straight forward to take care of. However
> when I look at the how the network table is built and used I still find
> some assumptions that there is only a single neighbour table for each
> type of table in the kernel. The netlink operations, neigh_seq_start,
> the non-core network users that call neigh_lookup. So while it might
> be doable it would require more refactoring than my current approach
> of just doing a little extra filtering in the code.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: Strange Panic (Deadlock)
From: Jarek Poplawski @ 2007-12-24 20:23 UTC (permalink / raw)
To: slavon; +Cc: netdev, Thomas Gleixner, Ingo Molnar, linux-kernel
In-Reply-To: <20071224211819.e1ebeicf0ggoo08s@mail.bigtelecom.ru>
slavon@bigtelecom.ru wrote, On 12/24/2007 07:18 PM:
> Hello again.
> Its bug depend to
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4aae07025265151e3f7041dfbf0f529e122de1d8
> ?
Hello Vyacheslav!
I wonder why do you think there is such a dependency, and why do you report
timer.c bug to netdev after all? I added some CCs here, but IMHO you would
better open a new bug at bugzilla.kernel.org, adding some more details like
.config, and reply back to this thread with the bug's number. BTW, if it's
patched by Gentoo or otherwise, you should try and report on 'vanilla' one
only.
Regards,
Jarek P.
> Its very critical bug to us. This PC must be HA. Server place so far
> for me to go and reboot server. I go to it 1-3 times in week =(
> Please help to fix it =)
>
>> Hello all. Some time machine freeze. No information on monitor. No
>> rebooting on sysctl "kernel.panic".
>> Any idea?
>>
>> Catched by netconsole:
>> [91922.085864] ------------[ cut here ]------------
>> [91922.085975] kernel BUG at kernel/timer.c:606!
>> [91922.086058] invalid opcode: 0000 [#1]
>> [91922.086127] SMP
>> [91922.086201] Modules linked in: netconsole cls_u32 sch_sfq sch_htb
>> xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core
>> [91922.086386] CPU: 1
>> [91922.086387] EIP: 0060:[<c0127387>] Not tainted VLI
>> [91922.086389] EFLAGS: 00010087 (2.6.23-gentoo-r4-fw #4)
>> [91922.086600] EIP is at cascade+0x34/0x4f
>> [91922.086669] eax: c0452200 ebx: f450408c ecx: 00000022 edx: f3c6e08c
>> [91922.086740] esi: 00000022 edi: c21ce000 ebp: 00000001 esp: c21c3ef8
>> [91922.086815] ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
>> [91922.086885] Process swapper (pid: 0, ti=c21c2000 task=c21af000
>> task.ti=c21c2000)
>> [91922.086954] Stack: f3c6e08c c21bfb74 00000000 c21ce000 0000000a
>> c012767a c21af000 00000001
>> [91922.087119] c21c3f18 c0106963 c21c3f68 00000001 00000021
>> c03c0b08 0000000a c0124556
>> [91922.087285] 00000046 00000000 c21c2008 00000000 c01245ec
>> c2015120 c0114a11 00000046
>> [91922.087451] Call Trace:
>> [91922.087586] [<c012767a>] run_timer_softirq+0x51/0x154
>> [91922.087669] [<c0106963>] profile_pc+0x21/0x46
>> [91922.087752] [<c0124556>] __do_softirq+0x5d/0xc1
>> [91922.087833] [<c01245ec>] do_softirq+0x32/0x36
>> [91922.087915] [<c0114a11>] smp_apic_timer_interrupt+0x74/0x80
>> [91922.087997] [<c010484c>] apic_timer_interrupt+0x28/0x30
>> [91922.088076] [<c0102255>] mwait_idle_with_hints+0x3b/0x3f
>> [91922.088162] [<c0102259>] mwait_idle+0x0/0xa
>> [91922.088237] [<c0102398>] cpu_idle+0x91/0xaa
>> [91922.088319] =======================
>> [91922.088390] Code: 08 8d 04 ca 8b 10 89 62 04 89 14 24 8b 50 04 89 22
>> 89 00 89 54 24 04 8b 14 24 89 40 04 8b 1a eb 19 8b 42 14 83 e0 fe 39 f8
>> 74 04 <0f> 0b eb fe 89 f8 e8 d8 fe ff ff 89 da 8b 1b 39 e2 75 e3 59 89
>> [91922.088864] EIP: [<c0127387>] cascade+0x34/0x4f SS:ESP 0068:c21c3ef8
>>
>> --
>> 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.
>
> --
> 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
>
^ permalink raw reply
* Re: [RFC] skge csum problems
From: Stephen Hemminger @ 2007-12-24 19:36 UTC (permalink / raw)
To: Al Viro; +Cc: netdev
In-Reply-To: <20071224183950.GA5024@ZenIV.linux.org.uk>
On Mon, 24 Dec 2007 18:39:50 +0000
Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Mon, Dec 24, 2007 at 02:15:40PM +0100, Andi Kleen wrote:
> > Al Viro <viro@ftp.linux.org.uk> writes:
> > >
> > > Checksum is fixed-endian and we want it that way; IOW, what we end up
> > > storing in skb->csum should be fixed-endian as well.
> >
> > AFAIK skb->csum is always native endian because it normally
> > needs to be manipulated further even for RX.
>
> No. It needs to be manipulated, but that's exactly why it can't be
> (and isn't) kept host-endian. Large part of the reason why checksums are
> done the way they are done (operations mod 0xffff, etc.) is that
> they can be implemented via native arithmetics without any conversions;
> e.g. if you do
>
> add(u8 a[2], u8 b[2], u8 sum[2])
> {
> u32 x = *(u16 *)a + *(u16 *)b;
> if (x > 0xffff)
> x -= 0xffff;
> *(u16 *)sum = x;
> }
>
> you will get the same behaviour on big- and little-endian boxen, even though
> the intermediate integer values will be of course different.
>
> skb->csum *must* be stored in the same order on l-e and b-e boxen; that
> way you don't need to convert it or raw data when updating the sucker [*].
>
> [*] it's slightly more complicated since skb->csum is 4-byte, not 2-byte
> and the real invariant is "checksum of 4-octet array at &skb->csum must
> not depend on host" (so e.g XX YY 00 00 and 00 00 XX YY are equivalent -
> checksum doesn't change from reordering octet pairs; XX YY 00 00 and
> 00 00 YY XX are very definitely *NOT* equivalent; odd and even bytes
> can't be exchanged).
Did you test this on real hardware?
^ permalink raw reply
* Re: [RFC] skge csum problems
From: Al Viro @ 2007-12-24 19:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071224113638.0de0f189@speedy>
On Mon, Dec 24, 2007 at 11:36:38AM -0800, Stephen Hemminger wrote:
> > you will get the same behaviour on big- and little-endian boxen, even though
> > the intermediate integer values will be of course different.
> >
> > skb->csum *must* be stored in the same order on l-e and b-e boxen; that
> > way you don't need to convert it or raw data when updating the sucker [*].
> >
> > [*] it's slightly more complicated since skb->csum is 4-byte, not 2-byte
> > and the real invariant is "checksum of 4-octet array at &skb->csum must
> > not depend on host" (so e.g XX YY 00 00 and 00 00 XX YY are equivalent -
> > checksum doesn't change from reordering octet pairs; XX YY 00 00 and
> > 00 00 YY XX are very definitely *NOT* equivalent; odd and even bytes
> > can't be exchanged).
>
> Did you test this on real hardware?
Test _what_ on real hardware? That kernel expects skb->csum fixed-endian?
That csum_add() and friends work? Yes to both.
If you are asking whether I'd tested what skge does to csum in its rx
descriptors when asked to byteswap - as I've said, all skge-handled stuff
I have is on-board in little-endian boxen. Thus asking for folks who
could test it on big-endian and see what does that sucker actually do...
^ permalink raw reply
* Re: [RFC] skge csum problems
From: Al Viro @ 2007-12-24 18:39 UTC (permalink / raw)
To: Andi Kleen; +Cc: Al Viro, netdev
In-Reply-To: <p73sl1sp72b.fsf@bingen.suse.de>
On Mon, Dec 24, 2007 at 02:15:40PM +0100, Andi Kleen wrote:
> Al Viro <viro@ftp.linux.org.uk> writes:
> >
> > Checksum is fixed-endian and we want it that way; IOW, what we end up
> > storing in skb->csum should be fixed-endian as well.
>
> AFAIK skb->csum is always native endian because it normally
> needs to be manipulated further even for RX.
No. It needs to be manipulated, but that's exactly why it can't be
(and isn't) kept host-endian. Large part of the reason why checksums are
done the way they are done (operations mod 0xffff, etc.) is that
they can be implemented via native arithmetics without any conversions;
e.g. if you do
add(u8 a[2], u8 b[2], u8 sum[2])
{
u32 x = *(u16 *)a + *(u16 *)b;
if (x > 0xffff)
x -= 0xffff;
*(u16 *)sum = x;
}
you will get the same behaviour on big- and little-endian boxen, even though
the intermediate integer values will be of course different.
skb->csum *must* be stored in the same order on l-e and b-e boxen; that
way you don't need to convert it or raw data when updating the sucker [*].
[*] it's slightly more complicated since skb->csum is 4-byte, not 2-byte
and the real invariant is "checksum of 4-octet array at &skb->csum must
not depend on host" (so e.g XX YY 00 00 and 00 00 XX YY are equivalent -
checksum doesn't change from reordering octet pairs; XX YY 00 00 and
00 00 YY XX are very definitely *NOT* equivalent; odd and even bytes
can't be exchanged).
^ permalink raw reply
* Re: Strange Panic (Deadlock)
From: slavon @ 2007-12-24 18:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <476FCC41.8070202@bigtelecom.ru>
Hello again.
Its bug depend to
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4aae07025265151e3f7041dfbf0f529e122de1d8
?
Its very critical bug to us. This PC must be HA. Server place so far
for me to go and reboot server. I go to it 1-3 times in week =(
Please help to fix it =)
> Hello all. Some time machine freeze. No information on monitor. No
> rebooting on sysctl "kernel.panic".
> Any idea?
>
> Catched by netconsole:
> [91922.085864] ------------[ cut here ]------------
> [91922.085975] kernel BUG at kernel/timer.c:606!
> [91922.086058] invalid opcode: 0000 [#1]
> [91922.086127] SMP
> [91922.086201] Modules linked in: netconsole cls_u32 sch_sfq sch_htb
> xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core
> [91922.086386] CPU: 1
> [91922.086387] EIP: 0060:[<c0127387>] Not tainted VLI
> [91922.086389] EFLAGS: 00010087 (2.6.23-gentoo-r4-fw #4)
> [91922.086600] EIP is at cascade+0x34/0x4f
> [91922.086669] eax: c0452200 ebx: f450408c ecx: 00000022 edx: f3c6e08c
> [91922.086740] esi: 00000022 edi: c21ce000 ebp: 00000001 esp: c21c3ef8
> [91922.086815] ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
> [91922.086885] Process swapper (pid: 0, ti=c21c2000 task=c21af000
> task.ti=c21c2000)
> [91922.086954] Stack: f3c6e08c c21bfb74 00000000 c21ce000 0000000a
> c012767a c21af000 00000001
> [91922.087119] c21c3f18 c0106963 c21c3f68 00000001 00000021
> c03c0b08 0000000a c0124556
> [91922.087285] 00000046 00000000 c21c2008 00000000 c01245ec
> c2015120 c0114a11 00000046
> [91922.087451] Call Trace:
> [91922.087586] [<c012767a>] run_timer_softirq+0x51/0x154
> [91922.087669] [<c0106963>] profile_pc+0x21/0x46
> [91922.087752] [<c0124556>] __do_softirq+0x5d/0xc1
> [91922.087833] [<c01245ec>] do_softirq+0x32/0x36
> [91922.087915] [<c0114a11>] smp_apic_timer_interrupt+0x74/0x80
> [91922.087997] [<c010484c>] apic_timer_interrupt+0x28/0x30
> [91922.088076] [<c0102255>] mwait_idle_with_hints+0x3b/0x3f
> [91922.088162] [<c0102259>] mwait_idle+0x0/0xa
> [91922.088237] [<c0102398>] cpu_idle+0x91/0xaa
> [91922.088319] =======================
> [91922.088390] Code: 08 8d 04 ca 8b 10 89 62 04 89 14 24 8b 50 04 89 22
> 89 00 89 54 24 04 8b 14 24 89 40 04 8b 1a eb 19 8b 42 14 83 e0 fe 39 f8
> 74 04 <0f> 0b eb fe 89 f8 e8 d8 fe ff ff 89 da 8b 1b 39 e2 75 e3 59 89
> [91922.088864] EIP: [<c0127387>] cascade+0x34/0x4f SS:ESP 0068:c21c3ef8
>
> --
> 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.
^ permalink raw reply
* Re: [PATCH] [IPROUTE2] IPT action compatibility with iptables 1.4.0
From: jamal @ 2007-12-24 17:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Denys Fedoryshchenko, netdev, Pablo Neira Ayuso
In-Reply-To: <20071224094807.060e604f@deepthought>
On Mon, 2007-24-12 at 09:48 -0800, Stephen Hemminger wrote:
> On Mon, 24 Dec 2007 11:55:05 -0500
> Is this backwards compatible with older kernels?
Yes.
Denys change adds forward compat (although iptables in 1.4 is not fully
backward compatible).
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] [IPROUTE2] IPT action compatibility with iptables 1.4.0
From: Stephen Hemminger @ 2007-12-24 17:48 UTC (permalink / raw)
To: hadi; +Cc: Denys Fedoryshchenko, netdev, Pablo Neira Ayuso
In-Reply-To: <1198515305.4427.12.camel@localhost>
On Mon, 24 Dec 2007 11:55:05 -0500
jamal <hadi@cyberus.ca> wrote:
>
> Stephen,
>
> Please apply this patch from Denys Fedoryshchenko to make the ipt action
> work with latest iptables.
>
> cheers,
> jamal
>
Is this backwards compatible with older kernels?
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH] [IPROUTE2] Compatibility with iptables 1.4.0
From: jamal @ 2007-12-24 16:57 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev, Pablo Neira Ayuso
In-Reply-To: <1198513837.4427.8.camel@localhost>
I just submitted a tested, slightly reduced patch (example we dont need
to register matches) and it works as expected now. Thanks for the
excellent work Denys.
Pablo, below looks an oversight.
I think there are some libraries like the mark target need also to be
backward compatible.
cheers,
jamal
On Mon, 2007-24-12 at 11:30 -0500, jamal wrote:
> Grr. I tested with a different iptables target and thought the rest work
> in the same manner. iptables needs to be consistent.
>
> -----
> lilsol:~# export IPTABLES_LIB_DIR=/root/iptables-1.4.0/extensions/
> lilsol:~# tc actions add action ipt -j TOS --set-tos
> Maximize-Reliability
> tablename: mangle hook: NF_IP_POST_ROUTING
> target: TOS set Maximize-Reliability index 0
> lilsol:~# tc actions ls action ipt
>
> action order 0: tablename: mangle hook: NF_IP_POST_ROUTING
> target TOS set Maximize-Reliability
> index 2 ref 1 bind 0
> // the above is what i tested
> // below is what you did
> lilsol:~# tc actions add action ipt -j mark --set-mark 3
> /root/iptables-1.4.0/extensions/: cannot read file data: Is a directory
> failed to find target mark
>
> bad action parsing
> parse_action: bad value (5:ipt)!
> Illegal "action"
> Command "add" is unknown, try "tc actions help".
> lilsol:~#
> ------------
>
> Applying your patch ....
> Seems corrupt; let me fix it up, test it and resend it to Stephen.
>
> cheers,
> jamal
>
^ permalink raw reply
* [PATCH] [IPROUTE2] IPT action compatibility with iptables 1.4.0
From: jamal @ 2007-12-24 16:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Denys Fedoryshchenko, netdev, Pablo Neira Ayuso
[-- Attachment #1: Type: text/plain, Size: 127 bytes --]
Stephen,
Please apply this patch from Denys Fedoryshchenko to make the ipt action
work with latest iptables.
cheers,
jamal
[-- Attachment #2: ipt-p1 --]
[-- Type: text/plain, Size: 1796 bytes --]
New iptables 1.4.0 has some library names changed from libipt to libxt.
It is prefferable also to open libxt_ first, as newer "style".
Signed-off-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
commit fe7b0dd9c19451019494d834c631c045e75e2b05
tree 452a75a6ec17d63832b03972ec9059b5cf9d8cfe
parent 235ac6a41d9d0439cce4eca8acdd31cac28605fc
author Denys Fedoryshchenko <nuclearcat@nuclearcat.com> Mon, 24 Dec 2007 11:51:11 -0500
committer Jamal Hadi Salim <hadi@cyberus.ca> Mon, 24 Dec 2007 11:51:11 -0500
tc/m_ipt.c | 24 ++++++++++++++++++++++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/tc/m_ipt.c b/tc/m_ipt.c
index acbb8d2..f2a9305 100644
--- a/tc/m_ipt.c
+++ b/tc/m_ipt.c
@@ -69,6 +69,13 @@ register_target(struct iptables_target *me)
}
void
+xtables_register_target(struct iptables_target *me)
+{
+ me->next = t_list;
+ t_list = me;
+}
+
+void
exit_tryhelp(int status)
{
fprintf(stderr, "Try `%s -h' or '%s --help' for more information.\n",
@@ -248,11 +255,24 @@ get_target_name(const char *name)
}
}
- sprintf(path, "%s/libipt_%s.so",lib_dir, new_name);
+ /* try libxt_xx first */
+ sprintf(path, "%s/libxt_%s.so", lib_dir, new_name);
handle = dlopen(path, RTLD_LAZY);
if (!handle) {
- sprintf(path, lib_dir, "/libipt_%s.so", lname);
+ /* try libipt_xx next */
+ sprintf(path, "%s/libipt_%s.so", lib_dir, new_name);
handle = dlopen(path, RTLD_LAZY);
+
+ if (!handle) {
+ sprintf(path, "%s/libxt_%s.so", lib_dir , lname);
+ handle = dlopen(path, RTLD_LAZY);
+ }
+
+ if (!handle) {
+ sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
+ handle = dlopen(path, RTLD_LAZY);
+ }
+ /* ok, lets give up .. */
if (!handle) {
fputs(dlerror(), stderr);
printf("\n");
^ permalink raw reply related
* Re: [PATCH] [IPROUTE2] Compatibility with iptables 1.4.0
From: jamal @ 2007-12-24 16:30 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev, Pablo Neira Ayuso
In-Reply-To: <20071224160739.M84357@visp.net.lb>
On Mon, 2007-24-12 at 18:07 +0200, Denys Fedoryshchenko wrote:
> Hi, probably like this will be better?
> Previous patch was not backward compatible.
>
> Btw i checked twice, name is changed from libipt_MARK to libxt_MARK. So
> probably when you have tested this, your iproute2 was looking to old
> libipt_MARK (iptables is not deleting old libraries on make install).
>
Grr. I tested with a different iptables target and thought the rest work
in the same manner. iptables needs to be consistent.
-----
lilsol:~# export IPTABLES_LIB_DIR=/root/iptables-1.4.0/extensions/
lilsol:~# tc actions add action ipt -j TOS --set-tos
Maximize-Reliability
tablename: mangle hook: NF_IP_POST_ROUTING
target: TOS set Maximize-Reliability index 0
lilsol:~# tc actions ls action ipt
action order 0: tablename: mangle hook: NF_IP_POST_ROUTING
target TOS set Maximize-Reliability
index 2 ref 1 bind 0
// the above is what i tested
// below is what you did
lilsol:~# tc actions add action ipt -j mark --set-mark 3
/root/iptables-1.4.0/extensions/: cannot read file data: Is a directory
failed to find target mark
bad action parsing
parse_action: bad value (5:ipt)!
Illegal "action"
Command "add" is unknown, try "tc actions help".
lilsol:~#
------------
Applying your patch ....
Seems corrupt; let me fix it up, test it and resend it to Stephen.
cheers,
jamal
^ permalink raw reply
* [PATCH] [IPROUTE2] Compatibility with iptables 1.4.0
From: Denys Fedoryshchenko @ 2007-12-24 16:07 UTC (permalink / raw)
To: hadi; +Cc: netdev
Hi, probably like this will be better?
Previous patch was not backward compatible.
Btw i checked twice, name is changed from libipt_MARK to libxt_MARK. So
probably when you have tested this, your iproute2 was looking to old
libipt_MARK (iptables is not deleting old libraries on make install).
-------------------------
New iptables 1.4.0 need additional dummy functions, and some library names is
changed from libipt to libxt.
It is prefferable also to open libxt_ first, as newer "style".
Signed-off-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
---
drivers/watchdog/w83697hf_wdt.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff -Naur iproute2/tc/m_ipt.c iproute2-new/tc/m_ipt.c
--- iproute2/tc/m_ipt.c 2007-12-24 16:59:19.000000000 +0200
+++ iproute2-new/tc/m_ipt.c 2007-12-24 17:46:14.000000000 +0200
@@ -69,6 +69,27 @@
}
void
+xtables_register_target(struct iptables_target *me)
+{
+ me->next = t_list;
+ t_list = me;
+}
+
+
+void
+xtables_register_match(struct iptables_target *me)
+{
+ me->next = t_list;
+ t_list = me;
+}
+
+void
exit_tryhelp(int status)
{
fprintf(stderr, "Try `%s -h' or '%s --help' for more information.\n",
@@ -248,16 +269,25 @@
}
}
- sprintf(path, "%s/libipt_%s.so",lib_dir, new_name);
+ sprintf(path, "%s/libxt_%s.so",lib_dir, new_name);
handle = dlopen(path, RTLD_LAZY);
if (!handle) {
- sprintf(path, lib_dir, "/libipt_%s.so", lname);
+ sprintf(path, "%s/libipt_%s.so", lib_dir , new_name);
handle = dlopen(path, RTLD_LAZY);
- if (!handle) {
- fputs(dlerror(), stderr);
- printf("\n");
- return NULL;
- }
+ }
+ if (!handle) {
+ sprintf(path, "%s/libxt_%s.so", lib_dir , lname);
+ handle = dlopen(path, RTLD_LAZY);
+ }
+ if (!handle) {
+ sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
+ handle = dlopen(path, RTLD_LAZY);
+ }
+ if (!handle) {
+ sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
+ fputs(dlerror(), stderr);
+ printf("\n");
+ return NULL;
}
m = dlsym(handle, new_name);
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: iproute2 action ipt + iptables 1.4.0
From: jamal @ 2007-12-24 15:25 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <20071224151147.M93927@visp.net.lb>
Denys,
Looks reasonable to check for libxt as well.
Please add a signed-off and append mine as well then send to Stephen.
BTW, I just finished compiling iptables 1.4.0 and _it is_ backward
compatible - you just have to point to the correct
environment variable IPTABLES_LIB_DIR; it seems to work.
In any case, your patch is better.
cheers,
jamal
On Mon, 2007-24-12 at 17:11 +0200, Denys Fedoryshchenko wrote:
> Hi again :-)
>
> Happy holidays :-)
>
> It seems there is serious break in compatibility, but can be fixed by ugly
> way. Maybe just to add patch below, and to search libipt AND libxt (for my
> case i just edit and change libipt to libxt, but it can be handled in more
> smart way.
> After i apply all this - it seems working fine.
>
> iff -Naur iproute2-git/tc/m_ipt.c iproute2-new/tc/m_ipt.c
> --- iproute2-git/tc/m_ipt.c 2007-12-24 16:59:19.000000000 +0200
> +++ iproute2-new/tc/m_ipt.c 2007-12-24 17:07:11.000000000 +0200
> @@ -69,6 +69,27 @@
> }
>
> void
> +xtables_register_target(struct iptables_target *me)
> +{
> +/* fprintf(stderr, "\nDummy register_target %s \n", me->name);
> +*/
> + me->next = t_list;
> + t_list = me;
> +
> +}
> +
> +
> +void
> +xtables_register_match(struct iptables_target *me)
> +{
> +/* fprintf(stderr, "\nDummy register_target %s \n", me->name);
> +*/
> + me->next = t_list;
> + t_list = me;
> +
> +}
> +
> +void
> exit_tryhelp(int status)
> {
> fprintf(stderr, "Try `%s -h' or '%s --help' for more information.\n",
>
> There is trivial patch also, for bug (IMHO bug) in searching lowercased
> library. If patch not applied - second time it will try to open lib_dir by
> dlopen:-)
>
> --- iproute2-git/tc/m_ipt.c 2007-12-24 16:59:19.000000000 +0200
> +++ iproute2/tc/m_ipt.c 2007-12-24 17:00:41.000000000 +0200
> @@ -251,7 +251,7 @@
> sprintf(path, "%s/libipt_%s.so",lib_dir, new_name);
> handle = dlopen(path, RTLD_LAZY);
> if (!handle) {
> - sprintf(path, lib_dir, "/libipt_%s.so", lname);
> + sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
> handle = dlopen(path, RTLD_LAZY);
> if (!handle) {
> fputs(dlerror(), stderr);
>
> Sorry for probably bad style/code, i am not programmer at all.
>
>
> --
> Denys Fedoryshchenko
> Technical Manager
> Virtual ISP S.A.L.
>
> --
> 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
^ permalink raw reply
* iproute2 action ipt + iptables 1.4.0
From: Denys Fedoryshchenko @ 2007-12-24 15:11 UTC (permalink / raw)
To: netdev
Hi again :-)
Happy holidays :-)
It seems there is serious break in compatibility, but can be fixed by ugly
way. Maybe just to add patch below, and to search libipt AND libxt (for my
case i just edit and change libipt to libxt, but it can be handled in more
smart way.
After i apply all this - it seems working fine.
iff -Naur iproute2-git/tc/m_ipt.c iproute2-new/tc/m_ipt.c
--- iproute2-git/tc/m_ipt.c 2007-12-24 16:59:19.000000000 +0200
+++ iproute2-new/tc/m_ipt.c 2007-12-24 17:07:11.000000000 +0200
@@ -69,6 +69,27 @@
}
void
+xtables_register_target(struct iptables_target *me)
+{
+/* fprintf(stderr, "\nDummy register_target %s \n", me->name);
+*/
+ me->next = t_list;
+ t_list = me;
+
+}
+
+
+void
+xtables_register_match(struct iptables_target *me)
+{
+/* fprintf(stderr, "\nDummy register_target %s \n", me->name);
+*/
+ me->next = t_list;
+ t_list = me;
+
+}
+
+void
exit_tryhelp(int status)
{
fprintf(stderr, "Try `%s -h' or '%s --help' for more information.\n",
There is trivial patch also, for bug (IMHO bug) in searching lowercased
library. If patch not applied - second time it will try to open lib_dir by
dlopen:-)
--- iproute2-git/tc/m_ipt.c 2007-12-24 16:59:19.000000000 +0200
+++ iproute2/tc/m_ipt.c 2007-12-24 17:00:41.000000000 +0200
@@ -251,7 +251,7 @@
sprintf(path, "%s/libipt_%s.so",lib_dir, new_name);
handle = dlopen(path, RTLD_LAZY);
if (!handle) {
- sprintf(path, lib_dir, "/libipt_%s.so", lname);
+ sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
handle = dlopen(path, RTLD_LAZY);
if (!handle) {
fputs(dlerror(), stderr);
Sorry for probably bad style/code, i am not programmer at all.
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Strange Panic (Deadlock)
From: Badalian Vyacheslav @ 2007-12-24 15:12 UTC (permalink / raw)
To: netdev
Hello all. Some time machine freeze. No information on monitor. No
rebooting on sysctl "kernel.panic".
Any idea?
Catched by netconsole:
[91922.085864] ------------[ cut here ]------------
[91922.085975] kernel BUG at kernel/timer.c:606!
[91922.086058] invalid opcode: 0000 [#1]
[91922.086127] SMP
[91922.086201] Modules linked in: netconsole cls_u32 sch_sfq sch_htb
xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core
[91922.086386] CPU: 1
[91922.086387] EIP: 0060:[<c0127387>] Not tainted VLI
[91922.086389] EFLAGS: 00010087 (2.6.23-gentoo-r4-fw #4)
[91922.086600] EIP is at cascade+0x34/0x4f
[91922.086669] eax: c0452200 ebx: f450408c ecx: 00000022 edx: f3c6e08c
[91922.086740] esi: 00000022 edi: c21ce000 ebp: 00000001 esp: c21c3ef8
[91922.086815] ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
[91922.086885] Process swapper (pid: 0, ti=c21c2000 task=c21af000
task.ti=c21c2000)
[91922.086954] Stack: f3c6e08c c21bfb74 00000000 c21ce000 0000000a
c012767a c21af000 00000001
[91922.087119] c21c3f18 c0106963 c21c3f68 00000001 00000021
c03c0b08 0000000a c0124556
[91922.087285] 00000046 00000000 c21c2008 00000000 c01245ec
c2015120 c0114a11 00000046
[91922.087451] Call Trace:
[91922.087586] [<c012767a>] run_timer_softirq+0x51/0x154
[91922.087669] [<c0106963>] profile_pc+0x21/0x46
[91922.087752] [<c0124556>] __do_softirq+0x5d/0xc1
[91922.087833] [<c01245ec>] do_softirq+0x32/0x36
[91922.087915] [<c0114a11>] smp_apic_timer_interrupt+0x74/0x80
[91922.087997] [<c010484c>] apic_timer_interrupt+0x28/0x30
[91922.088076] [<c0102255>] mwait_idle_with_hints+0x3b/0x3f
[91922.088162] [<c0102259>] mwait_idle+0x0/0xa
[91922.088237] [<c0102398>] cpu_idle+0x91/0xaa
[91922.088319] =======================
[91922.088390] Code: 08 8d 04 ca 8b 10 89 62 04 89 14 24 8b 50 04 89 22
89 00 89 54 24 04 8b 14 24 89 40 04 8b 1a eb 19 8b 42 14 83 e0 fe 39 f8
74 04 <0f> 0b eb fe 89 f8 e8 d8 fe ff ff 89 da 8b 1b 39 e2 75 e3 59 89
[91922.088864] EIP: [<c0127387>] cascade+0x34/0x4f SS:ESP 0068:c21c3ef8
^ 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