* [PATCH] e1000: Add device IDs of blade version of the 82571 quad port
From: Auke Kok @ 2007-08-30 18:23 UTC (permalink / raw)
To: jeff; +Cc: netdev, john.ronciak, auke-jan.h.kok
This blade-specific board form factor is identical to the 82571EB
board.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_ethtool.c | 1 +
drivers/net/e1000/e1000_hw.c | 1 +
drivers/net/e1000/e1000_hw.h | 1 +
drivers/net/e1000/e1000_main.c | 2 ++
4 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index 4c3785c..9ecc3ad 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -1726,6 +1726,7 @@ static int e1000_wol_exclusion(struct e1000_adapter *adapter, struct ethtool_wol
case E1000_DEV_ID_82571EB_QUAD_COPPER:
case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
+ case E1000_DEV_ID_82571PT_QUAD_COPPER:
case E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3:
/* quad port adapters only support WoL on port A */
if (!adapter->quad_port_a) {
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index ba120f7..8604adb 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -387,6 +387,7 @@ e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_82571EB_SERDES_DUAL:
case E1000_DEV_ID_82571EB_SERDES_QUAD:
case E1000_DEV_ID_82571EB_QUAD_COPPER:
+ case E1000_DEV_ID_82571PT_QUAD_COPPER:
case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
hw->mac_type = e1000_82571;
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index fe87146..07f0ea7 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -475,6 +475,7 @@ int32_t e1000_check_phy_reset_block(struct e1000_hw *hw);
#define E1000_DEV_ID_82571EB_FIBER 0x105F
#define E1000_DEV_ID_82571EB_SERDES 0x1060
#define E1000_DEV_ID_82571EB_QUAD_COPPER 0x10A4
+#define E1000_DEV_ID_82571PT_QUAD_COPPER 0x10D5
#define E1000_DEV_ID_82571EB_QUAD_FIBER 0x10A5
#define E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE 0x10BC
#define E1000_DEV_ID_82571EB_SERDES_DUAL 0x10D9
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 4a22595..e7c8951 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -108,6 +108,7 @@ static struct pci_device_id e1000_pci_tbl[] = {
INTEL_E1000_ETHERNET_DEVICE(0x10BC),
INTEL_E1000_ETHERNET_DEVICE(0x10C4),
INTEL_E1000_ETHERNET_DEVICE(0x10C5),
+ INTEL_E1000_ETHERNET_DEVICE(0x10D5),
INTEL_E1000_ETHERNET_DEVICE(0x10D9),
INTEL_E1000_ETHERNET_DEVICE(0x10DA),
/* required last entry */
@@ -1101,6 +1102,7 @@ e1000_probe(struct pci_dev *pdev,
case E1000_DEV_ID_82571EB_QUAD_COPPER:
case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
+ case E1000_DEV_ID_82571PT_QUAD_COPPER:
/* if quad port adapter, disable WoL on all but port A */
if (global_quad_port_a != 0)
adapter->eeprom_wol = 0;
^ permalink raw reply related
* Re: [PATCH 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver
From: Daniel Drake @ 2007-08-30 17:54 UTC (permalink / raw)
To: Jesper Juhl
Cc: Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA,
David S. Miller, Ulrich Kunitz,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d551047daed1cb4d9de1eff956268a468c9837f6.1187912217.git.jesper.juhl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Jesper Juhl wrote:
> Since kmalloc() returns a void pointer there is no reason to cast
> its return value.
> This patch also removes a pointless initialization of a variable.
NAK: adds a sparse warning
zd_chip.c:116:15: warning: implicit cast to nocast type
> Signed-off-by: Jesper Juhl <jesper.juhl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/wireless/zd1211rw/zd_chip.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c b/drivers/net/wireless/zd1211rw/zd_chip.c
> index c39f198..4942e5c 100644
> --- a/drivers/net/wireless/zd1211rw/zd_chip.c
> +++ b/drivers/net/wireless/zd1211rw/zd_chip.c
> @@ -106,8 +106,8 @@ int zd_ioread32v_locked(struct zd_chip *chip, u32 *values, const zd_addr_t *addr
> {
> int r;
> int i;
> - zd_addr_t *a16 = (zd_addr_t *)NULL;
> u16 *v16;
> + zd_addr_t *a16;
> unsigned int count16;
>
> if (count > USB_MAX_IOREAD32_COUNT)
> @@ -115,8 +115,7 @@ int zd_ioread32v_locked(struct zd_chip *chip, u32 *values, const zd_addr_t *addr
>
> /* Allocate a single memory block for values and addresses. */
> count16 = 2*count;
> - a16 = (zd_addr_t *) kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)),
> - GFP_KERNEL);
> + a16 = kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)), GFP_KERNEL);
> if (!a16) {
> dev_dbg_f(zd_chip_dev(chip),
> "error ENOMEM in allocation of a16\n");
^ permalink raw reply
* Re: [PATCH] make _minimum_ TCP retransmission timeout configurable
From: Rick Jones @ 2007-08-30 17:10 UTC (permalink / raw)
To: Krishna Kumar2
Cc: David Miller, ian.mcdonald, ilpo.jarvinen, netdev, netdev-owner
In-Reply-To: <OFD89921DD.675E7B9A-ON65257347.001C5D22-65257347.001D84A0@in.ibm.com>
Krishna Kumar2 wrote:
> Hi Rick,
>
>
>>>From: Rick Jones <rick.jones2@hp.com>
>>>
>>>>The trace I've been sent shows clean RTTs ranging from ~200
>
> milliseconds
>
>>>>to ~7000 milliseconds.
>>>
>>>
>>>Thanks for the info.
>>>
>>>It's pretty easy to generate examples where we might have some sockets
>>>talking over interfaces on such a network and others which are not.
>>>Therefore, if we do this, a per-route metric is probably the best bet.
>>
>>FWIW, the places where I've seen this come-up thusfar are where we have
>>a sort of "gateway" or front-end system which is connected on one side
>>to the cellphone network with the bad delays, and on the other side is
>>connected to an internal network where actual losses leading to RTO's
>>are epsilon. Certainly something which could make a per-route decision
>>would work there and probably quite well, though a simple sysctl does
>>seem to be sufficient and would touch fewer places.
>>
>>Do you think it is still worthwhile for me to rework the initial patch
>>to use CTL_UNNUMBERED?
>
>
> You could add following cleanup:
>
> static int proc_tcp_rto_min(ctl_table *ctl, int write, struct file *filp,
> void __user *buffer, size_t *lenp,
> loff_t *ppos)
> {
> int *valp = ctl->data;
> int oldval = *valp;
> int ret;
>
> ret = proc_dointvec_ms_jiffies(ctl, write, filp, buffer, lenp, ppos);
> if (ret)
> return ret;
>
> /* some bounds checking would be in order */
> if (write && *valp != oldval) {
> if (*valp < (int)TCP_RTO_MIN || *valp > (int)TCP_RTO_MAX) {
> *valp = oldval;
> ret = -EINVAL;
> }
> }
> return ret;
> }
Sure.
> Also, isn't it enough to use u32 for valp/oldval and remove the "(int)"
> typecasts?
I suppose, that was some mimicing of code I'd seen elsewhere but I'll
give it a shot.
rick
^ permalink raw reply
* Re: [PATCH] bridge: fix OOPS when bridging device without ethtool
From: Matthew Wilcox @ 2007-08-30 16:48 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David S. Miller, Johannes Berg, Jochen Voss, linux wireless list,
linville, netdev, bridge
In-Reply-To: <20070830082932.71272c3d@freepuppy.rosehill.hemminger.net>
On Thu, Aug 30, 2007 at 08:29:32AM -0700, Stephen Hemminger wrote:
> Bridge code calls ethtool to get speed. The conversion to using
> only ethtool_ops broke the case of devices without ethtool_ops.
> This is a new regression in 2.6.23.
>
> Rearranged the switch to a logical order, and use gcc initializer.
>
> Ps: speed should have been part of the network device structure from
> the start rather than burying it in ethtool.
Feel free to do the conversion ;-) One of the things I like about the
ethtool framework is it gives us a way to take stuff out of the drivers
and put it in the midlayer without disturbing userspace.
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Acked-by: Matthew Wilcox <matthew@wil.cx>
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: Bug? Realtek RTL-8169 Gigabit Ethernet and High Resolution Timers
From: Satyam Sharma @ 2007-08-30 16:51 UTC (permalink / raw)
To: n; +Cc: Linux Kernel Mailing List, romieu, netdev, tglx
In-Reply-To: <002d01c7eb14$4b18fab0$0100a8c0@hak>
[ Adding relevant Cc:'s ]
On Thu, 30 Aug 2007, n wrote:
> I found a bug when using the Ethernet controller: Realtek Semiconductor Co.,
> Ltd. RTL-8169 Gigabit Ethernet (rev 10) ethernet card and kernel High
> Resolution Timers (menuconfig -> Processor type and features -> High
> Resolution Timer Support )
> after about 20 kernel compiles i finnaly figured out this option was making
> the ethernet card slow
> tested kernels 2.6.22,2.6.22.5, 2.6.23-rc4 (running now)
>
> the cpu is the pc is a p3 667 mhz so its cpu limited i guess and maxes at
> 400mbit~. (without High Resolution Timers )
> with High Resolution Timers off it would only do 50-70mbit.
>
> r8169 (compile as module + napi)
> High Resolution Timer Support (enabled)
> tested with iperf also system is very unresponsive i cant even open a ssh
> session or type a command while the test ran
> [ 5] 0.0-10.0 sec 64.5 MBytes 54.0 Mbits/sec
>
> r8169 (compile as module + napi)
> High Resolution Timer Support (disabled)
> [ 3] 0.0-10.0 sec 552 MBytes 463 Mbits/sec
>
> as you can see with it disabled the speed really improved.
> but im wondering what does High Resolution Timer's do and what does it have to
> do with a pci gigabit ethernet card that would slow it down
> maybe someone else could test and see if they get the same results
>
> this might solve alot of problems with this card since alot of distros compile
> Resolution Timer default to enabled...
^ permalink raw reply
* Re: oops with recent wireless-dev tree
From: Matthew Wilcox @ 2007-08-30 15:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Stephen Hemminger, Jochen Voss, linux wireless list,
linville-2XuSBdqkA4R54TAoqtyWWQ, netdev,
bridge-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <1188486091.3978.32.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
On Thu, Aug 30, 2007 at 05:01:31PM +0200, Johannes Berg wrote:
> Jochen had a patch: http://marc.info/?l=linux-wireless&m=118842715026614&w=2
That's exactly the right patch, please add
Acked-by: Matthew Wilcox <matthew-Ztpu424NOJ8@public.gmane.org>
I just checked over the commit that introduced the bug, and I didn't
make the same mistake anywhere else.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* [PATCH] bridge: fix OOPS when bridging device without ethtool
From: Stephen Hemminger @ 2007-08-30 15:29 UTC (permalink / raw)
To: David S. Miller
Cc: Matthew Wilcox, Johannes Berg, Jochen Voss, linux wireless list,
linville-2XuSBdqkA4R54TAoqtyWWQ, netdev,
bridge-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20070830145840.GU14130-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
Bridge code calls ethtool to get speed. The conversion to using
only ethtool_ops broke the case of devices without ethtool_ops.
This is a new regression in 2.6.23.
Rearranged the switch to a logical order, and use gcc initializer.
Ps: speed should have been part of the network device structure from
the start rather than burying it in ethtool.
Signed-off-by: Stephen Hemminger <shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
--- a/net/bridge/br_if.c 2007-08-30 07:49:01.000000000 -0700
+++ b/net/bridge/br_if.c 2007-08-30 07:48:16.000000000 -0700
@@ -33,17 +33,17 @@
*/
static int port_cost(struct net_device *dev)
{
- if (dev->ethtool_ops->get_settings) {
- struct ethtool_cmd ecmd = { ETHTOOL_GSET };
- int err = dev->ethtool_ops->get_settings(dev, &ecmd);
- if (!err) {
+ if (dev->ethtool_ops && dev->ethtool_ops->get_settings) {
+ struct ethtool_cmd ecmd = { .cmd = ETHTOOL_GSET, };
+
+ if (!dev->ethtool_ops->get_settings(dev, &ecmd)) {
switch(ecmd.speed) {
- case SPEED_100:
- return 19;
- case SPEED_1000:
- return 4;
case SPEED_10000:
return 2;
+ case SPEED_1000:
+ return 4;
+ case SPEED_100:
+ return 19;
case SPEED_10:
return 100;
}
^ permalink raw reply
* Re: oops with recent wireless-dev tree
From: Johannes Berg @ 2007-08-30 15:01 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jochen Voss, linux wireless list, linville-2XuSBdqkA4R54TAoqtyWWQ,
netdev, Matthew Wilcox, bridge-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20070830074949.7cd25b04-s08KbqtN0aBORcJjwVk88+YtYHrY8QCHmKZK+fsXvFM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
On Thu, 2007-08-30 at 07:49 -0700, Stephen Hemminger wrote:
> Devices aren't required to have ethtool_ops. The code there used to
> call ethtool directly, and it would handle the error cases. I'll rollup
> a fix this morning.
Great, thanks.
Jochen had a patch: http://marc.info/?l=linux-wireless&m=118842715026614&w=2
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: oops with recent wireless-dev tree
From: Johannes Berg @ 2007-08-30 14:58 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jochen Voss, linux wireless list, linville-2XuSBdqkA4R54TAoqtyWWQ,
netdev, Matthew Wilcox, bridge-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20070830074949.7cd25b04-s08KbqtN0aBORcJjwVk88+YtYHrY8QCHmKZK+fsXvFM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
On Thu, 2007-08-30 at 07:49 -0700, Stephen Hemminger wrote:
> Devices aren't required to have ethtool_ops. The code there used to
> call ethtool directly, and it would handle the error cases. I'll rollup
> a fix this morning.
Great, thanks.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: oops with recent wireless-dev tree
From: Matthew Wilcox @ 2007-08-30 14:58 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Johannes Berg, Jochen Voss, linux wireless list,
linville-2XuSBdqkA4R54TAoqtyWWQ, netdev,
bridge-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20070830074949.7cd25b04-s08KbqtN0aBORcJjwVk88+YtYHrY8QCHmKZK+fsXvFM@public.gmane.org>
On Thu, Aug 30, 2007 at 07:49:49AM -0700, Stephen Hemminger wrote:
> > > static int port_cost(struct net_device *dev)
> > > {
> > > if (dev->ethtool_ops->get_settings) {
> > > ^^^^
> > >
> > > As far as I can figure out, dev->ethtool_ops is NULL and the crash
> > > happens while trying to derefernce ...->get_settings.
>
> Devices aren't required to have ethtool_ops. The code there used to
> call ethtool directly, and it would handle the error cases. I'll rollup
> a fix this morning.
Yep, clearly my fault; that should read:
if (dev->ethtool_ops && dev->ethtool_ops->get_settings) {
Since Stephen's already bagged fixing this, I shan't send a patch.
But if it includes something like the line above please add:
Acked-by: Matthew Wilcox <matthew-Ztpu424NOJ8@public.gmane.org>
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: oops with recent wireless-dev tree
From: Stephen Hemminger @ 2007-08-30 14:49 UTC (permalink / raw)
To: Johannes Berg
Cc: bridge, Matthew Wilcox, netdev, Jochen Voss, linux wireless list
In-Reply-To: <1188475530.2963.20.camel@johannes.berg>
On Thu, 30 Aug 2007 14:05:30 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi Jochen,
>
> [added CCs since it affects bridge code]
>
> > If I read this correctly, the EIP in the last line corresponds to
> > net/bridge/br_if.c, line 36:
> >
> > static int port_cost(struct net_device *dev)
> > {
> > if (dev->ethtool_ops->get_settings) {
> > ^^^^
> >
> > As far as I can figure out, dev->ethtool_ops is NULL and the crash
> > happens while trying to derefernce ...->get_settings.
> >
> > Is dev->ethtool_ops allowed to be NULL? In this case the appended
> > patch might be the correct fix. At least it makes the oops disappear
> > for me. Another possible fix would be to add an ethtool_ops structure
> > to the device created by b43.
>
> I don't think adding ethtool_ops in mac80211 should be necessary.
> Stephen?
Devices aren't required to have ethtool_ops. The code there used to
call ethtool directly, and it would handle the error cases. I'll rollup
a fix this morning.
The bug was introduced by this:
commit 61a44b9c4b20d40c41fd1b70a4ceb13b75ea79a4
Author: Matthew Wilcox <matthew@wil.cx>
Date: Tue Jul 31 14:00:02 2007 -0700
[NET]: ethtool ops are the only way
During the transition to the ethtool_ops way of doing things, we supported
calling the device's ->do_ioctl method to allow unconverted drivers to
continue working. Those days are long behind us, all in-tree drivers
use the ethtool_ops way, and so we no longer need to support this.
The bonding driver is the biggest beneficiary of this; it no longer
needs to call ioctl() as a fallback if ethtool_ops aren't supported.
Also put a proper copyright statement on ethtool.c.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: David S. Miller <davem@davemloft.net>
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [Lksctp-developers] SCTP: Fix dead loop while received unexpected chunk with length set to zero
From: Vlad Yasevich @ 2007-08-30 13:45 UTC (permalink / raw)
To: Wei Yongjun; +Cc: lksctp-developers, netdev
In-Reply-To: <46D658B8.8070801@cn.fujitsu.com>
Wei Yongjun wrote:
> Vlad Yasevich wrote:
>> Wei Yongjun wrote:
>>
>>> Vlad Yasevich wrote:
>>>
>>>> NACK
>>>>
>>>> Section 8.4:
>>>>
>>>> An SCTP packet is called an "out of the blue" (OOTB) packet if it is
>>>> correctly formed (i.e., passed the receiver's CRC32c check; see
>>>> Section 6.8), but the receiver is not able to identify the
>>>> association to which this packet belongs.
>>>>
>>>>
>>>> I would argue that the packet is not correctly formed in this case
>>>> and deserves a protocol violation ABORT in return.
>>>>
>>>> -vlad
>>>>
>>> As your comment, patch has been changed.
>>> Patch has been split to two, one is resolve this dead loop problem in
>>> this mail.
>>> And the other is come in another mail to discard partial chunk which
>>> chunk length is set to zero.
>>>
>>
>>
>> I am starting to question the entire OOTB packet handling. There are way
>> too many function that do almost the same thing and all handle OOTB a
>> little
>> different.
>>
>> sctp_sf_do_9_2_reshutack() is also called during sctp_sf_do_dupcook_a()
>> processing, so checking for INIT chunk is wrong. Checking for just the
>> chunkhdr_t should be enough.
>>
> This has been changed.
>> sctp_sf_tabort_8_4_8 is used directly as well (not just through the state
>> machine). Not sure if the header verification is appropriate.
>>
> It is needed. Because sctp_sf_tabort_8_4_8() is called to handle OOTB
> packet before check the header length.
But now we are doing the same thing twice (and this is not the only place).
I know I am being really picky here, but I am starting to thing the ootb handling\
is a mess and I really don't want to add to the mess.
Until I (or someone else) prove that it's not a mess or fix it, I am going
to hold off on these patches.
Feel free to go through the spec and fix all the OOTB handling.
Thanks
-vlad
^ permalink raw reply
* Re: [PATCH 4/5] Net: ath5k, license is GPLv2
From: Jarek Poplawski @ 2007-08-30 13:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Jiri Slaby, linville, linux-kernel, linux-wireless, netdev,
Xavier Bestel, Jiri Slaby
In-Reply-To: <20070829204529.66ce1bcb@the-village.bc.nu>
On 30-08-2007 13:59, Johannes Berg wrote:
> On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote:
>
>> How about asking for changes to be dual-licenced too ?
>
> In theory, that could work, but in practice relying on functions that
> the Linux kernel offers in GPLv2-only headers etc. will make the result
> GPLv2 anyway, and disentangling it would be a nightmare.
>
Why?
Very good point, but, in my opinion, it should be still resonable for
both sides: it simply means such changes are mostly unusable for the
other side, but nobody is going to waste time for marking all these
places, or care about suing if accidentally the changes, after some
adaptation, are usable for the other side. Unless you think or know
that "#include xyz" or "print_linux_way()" should add more than these
(maybe unusable) words or lines only?
Jarek P.
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-08-30 13:43 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20070830123751.GA2778@ff.dom.local>
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
Jarek Poplawski пишет:
> On Thu, Aug 30, 2007 at 01:09:11PM +0400, Badalian Vyacheslav wrote:
>
>> Jarek Poplawski ??????????:
>>
> ...
>
>>> On the other hand disabling local interrupts shouldn't be enough here,
>>> so it's really strange... Did you get this remotely? Are you sure LOC
>>> only? (Anyway this 2.6.23-rc4 should be interesting.)
>>>
> ...
>
>> Only LOC changes... icmp answer = 50-70ms... after 1-2 hours traffic
>> level is down and SI on CPU0 and CPU2 change to above 50%. ksoftirqd
>> free CPU usage. I have this bug 3-4 times in week. If you need info what
>> i can see only in bug still processing - i may try get this info for you.
>>
>
> Any additional info could be helpful. I'm not sure if all these
> computers do similar htb processing, or it's another problem?
> As I've written before htb before 2.6.23-rc1 has a problem with
> timer lockup during qdisc_destroy, so softirqs would be hit.
> If it's htb's fault 2.6.23-rc4 or my testing patch should help.
>
> I try to find in htb code another weak points. BTW, if during
> such lockups any processes are killed 'by hand' etc., without
> restarting the whole system, please let us know.
>
>
I will try patch ;)
"CPU Si" is another bug at another computer. - NAT
NAT: simple have iptables rules (NAT) and ipcad to generate netflow.
FW: have iptables rules to close FORWARD access and TC rules for shape.
Scheme of network:
CORE <-> (FW 2.6.22 and FW-BackupLink) <-> NAT <-> OUT_ROUTER =
500mbs/500mbs traffic
FW have kernel panics if i try Delete HTB class (i will try patch)
NAT sometime have "si usage bug" if traffic more what 250mbs.
txt.txt have dmesg and lspci -vv info for NAT
Sorry for my English spell
>> maybe help:
>>
>> 1U server INTEL, mb se7501w2
>>
>> nat-new ~ # lspci
>>
>
> lspci -v (or -vv should be more usable - but with dmesg at least)
>
> Jarek P.
>
>
>
[-- Attachment #2: txt.txt --]
[-- Type: text/plain, Size: 50668 bytes --]
00:00.0 Host bridge: Intel Corporation E7501 Memory Controller Hub (rev 01)
Subsystem: Intel Corporation Unknown device 341a
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [40] Vendor Specific Information
00:00.1 Class ff00: Intel Corporation E7500/E7501 Host RASUM Controller (rev 01)
Subsystem: Intel Corporation Unknown device 341a
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:03.0 PCI bridge: Intel Corporation E7500/E7501 Hub Interface C PCI-to-PCI Bridge (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Bus: primary=00, secondary=02, subordinate=04, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: fe800000-feafffff
Prefetchable memory behind bridge: f8300000-fc5fffff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
00:03.1 Class ff00: Intel Corporation E7500/E7501 Hub Interface C RASUM Controller (rev 01)
Subsystem: Intel Corporation Unknown device 341a
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB Controller #1 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Unknown device 341a
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 4: I/O ports at 3020 [size=32]
00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB Controller #2 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Unknown device 341a
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 20
Region 4: I/O ports at 3000 [size=32]
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 42) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 00001000-00001fff
Memory behind bridge: fc700000-fe7fffff
Prefetchable memory behind bridge: f8200000-f82fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
00:1f.0 ISA bridge: Intel Corporation 82801CA LPC Interface Controller (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:1f.1 IDE interface: Intel Corporation 82801CA Ultra ATA Storage Controller (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Intel Corporation Unknown device 341a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4 [size=1]
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374 [size=1]
Region 4: I/O ports at 03a0 [size=16]
Region 5: Memory at 88000000 (32-bit, non-prefetchable) [size=1K]
00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 02)
Subsystem: Intel Corporation Unknown device 341a
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports at 0580 [size=32]
01:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) (prog-if 00 [VGA])
Subsystem: Intel Corporation Unknown device 341a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Region 1: I/O ports at 1000 [size=256]
Region 2: Memory at fe3f0000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at f8200000 [disabled] [size=128K]
Capabilities: [5c] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
02:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04) (prog-if 20 [IO(X)-APIC])
Subsystem: Intel Corporation Unknown device 341a
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at feae0000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [50] PCI-X non-bridge device
Command: DPERE- ERO- RBC=512 OST=1
Status: Dev=02:1c.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
02:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04) (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, Cache Line Size: 64 bytes
Bus: primary=02, secondary=04, subordinate=04, sec-latency=48
Memory behind bridge: fe900000-fe9fffff
Prefetchable memory behind bridge: 00000000f8400000-00000000fc4fffff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [50] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=02:1d.0 64bit+ 133MHz+ SCD- USC- SCO- SRD-
Upstream: Capacity=65535 CommitmentLimit=65535
Downstream: Capacity=65535 CommitmentLimit=65535
02:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04) (prog-if 20 [IO(X)-APIC])
Subsystem: Intel Corporation Unknown device 341a
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at feaf0000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [50] PCI-X non-bridge device
Command: DPERE- ERO- RBC=512 OST=1
Status: Dev=02:1e.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
02:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, Cache Line Size: 64 bytes
Bus: primary=02, secondary=03, subordinate=03, sec-latency=64
I/O behind bridge: 00002000-00002fff
Memory behind bridge: fe800000-fe8fffff
Prefetchable memory behind bridge: 00000000f8300000-00000000f83fffff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [50] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=100MHz
Status: Dev=02:1f.0 64bit+ 133MHz+ SCD- USC- SCO- SRD-
Upstream: Capacity=65535 CommitmentLimit=65535
Downstream: Capacity=65535 CommitmentLimit=65535
03:07.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
Subsystem: Intel Corporation Unknown device 341a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (63750ns min), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe8c0000 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at 2040 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk+ DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [e4] PCI-X non-bridge device
Command: DPERE- ERO+ RBC=512 OST=1
Status: Dev=03:07.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
03:07.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
Subsystem: Intel Corporation Unknown device 341a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (63750ns min), Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at fe8e0000 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at 2000 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk+ DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [e4] PCI-X non-bridge device
Command: DPERE- ERO+ RBC=512 OST=1
Status: Dev=03:07.1 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
04:08.0 RAID bus controller: Intel Corporation RAID Controller
Subsystem: Intel Corporation SRCZCR
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at fa000000 (32-bit, prefetchable) [size=32M]
[virtual] Expansion ROM at fe9f8000 [disabled] [size=32K]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Linux version 2.6.22-gentoo-r5-nat (root@nat-new) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP Thu Aug 30 06:56:52 MSD 2007
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009a800 (usable)
BIOS-e820: 000000000009a800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
BIOS-e820: 000000007fff0000 - 000000007ffff000 (ACPI data)
BIOS-e820: 000000007ffff000 - 0000000080000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
1151MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
Entering add_active_range(0, 0, 524272) 0 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 229376
HighMem 229376 -> 524272
early_node_map[1] active PFN ranges
0: 0 -> 524272
On node 0 totalpages: 524272
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 1760 pages used for memmap
Normal zone: 223520 pages, LIFO batch:31
HighMem zone: 2303 pages used for memmap
HighMem zone: 292593 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP 000FF9B0, 0014 (r0 INTEL )
ACPI: RSDT 7FFF0000, 0030 (r1 INTEL SWV25 1 MSFT 1000000)
ACPI: FACP 7FFF0030, 0074 (r1 INTEL SWV25 1 MSFT 1000000)
ACPI: DSDT 7FFF0190, 28C4 (r1 INTEL SWV25 100 INTL 20020918)
ACPI: FACS 7FFFF000, 0040
ACPI: APIC 7FFF00B0, 0090 (r1 INTEL SWV25 1 MSFT 1000000)
ACPI: OEMR 7FFF0140, 0050 (r1 INTEL SWV25 1 MSFT 1000000)
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
Processor #6 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
Processor #7 15:2 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x09] address[0xfec81000] gsi_base[24])
IOAPIC[1]: apic_id 9, version 32, address 0xfec81000, GSI 24-47
ACPI: IOAPIC (id[0x0a] address[0xfec81400] gsi_base[48])
IOAPIC[2]: apic_id 10, version 32, address 0xfec81400, GSI 48-71
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 3 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000)
Built 1 zonelists. Total pages: 520177
Kernel command line: BOOT_IMAGE=linux-2.6.22-r5 ro root=802
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
mapped IOAPIC to ffffb000 (fec81000)
mapped IOAPIC to ffffa000 (fec81400)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 2791.139 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2074076k/2097088k available (2347k kernel code, 21856k reserved, 1205k data, 248k init, 1179584k highmem)
virtual kernel memory layout:
fixmap : 0xffe17000 - 0xfffff000 (1952 kB)
pkmap : 0xff800000 - 0xffc00000 (4096 kB)
vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB)
lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
.init : 0xc0480000 - 0xc04be000 ( 248 kB)
.data : 0xc034aca8 - 0xc04782bc (1205 kB)
.text : 0xc0100000 - 0xc034aca8 (2347 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5587.52 BogoMIPS (lpj=9308033)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 14k freed
ACPI: Core revision 20070126
ACPI Warning (dswload-0698): Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [DATA] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [SIO_] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [LEDP] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [GPEN] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [GPST] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [WUES] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [WUSE] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [SBID] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
ACPI Warning (dswload-0698): Type override - [SWCE] had invalid type (String) for Scope operator, changed to (Scope) [20070126]
Parsing all Control Methods:
Table [DSDT](id 0001) - 358 Objects with 28 Devices 95 Methods 25 Regions
tbxface-0587 [02] tb_load_namespace : ACPI Tables successfully acquired
evxfevnt-0091 [02] enable : Transition to ACPI mode successful
CPU0: Intel(R) Xeon(TM) CPU 2.80GHz stepping 05
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 5583.27 BogoMIPS (lpj=9302835)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Xeon(TM) CPU 2.80GHz stepping 05
Booting processor 2/6 eip 2000
Initializing CPU#2
Calibrating delay using timer specific routine.. 5583.29 BogoMIPS (lpj=9302868)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#2.
CPU2: Intel P4/Xeon Extended MCE MSRs (12) available
CPU2: Thermal monitoring enabled
CPU2: Intel(R) Xeon(TM) CPU 2.80GHz stepping 05
Booting processor 3/7 eip 2000
Initializing CPU#3
Calibrating delay using timer specific routine.. 5583.30 BogoMIPS (lpj=9302888)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#3.
CPU3: Intel P4/Xeon Extended MCE MSRs (12) available
CPU3: Thermal monitoring enabled
CPU3: Intel(R) Xeon(TM) CPU 2.80GHz stepping 05
Total of 4 processors activated (22338.39 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
checking TSC synchronization [CPU#0 -> CPU#2]: passed.
checking TSC synchronization [CPU#0 -> CPU#3]: passed.
Brought up 4 CPUs
migration_cost=110,693
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfdb75, last bus=4
PCI: Using configuration type 1
Setting up standard PCI resources
evgpeblk-0952 [04] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs on int 0x9
evgpeblk-0952 [04] ev_create_gpe_block : GPE 10 to 2F [_GPE] 4 regs on int 0x9
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 4 Wake, Enabled 0 Runtime GPEs in this block
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 6 Wake, Enabled 0 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:............................................................................
Initialized 25/25 Regions 8/8 Fields 29/29 Buffers 14/23 Packages (367 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:.
Executed 1 _INI methods requiring 0 _STA executions (examined 34 objects)
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0480-04bf claimed by ICH4 GPIO
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5.P5P6._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5.P5P7._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
pnp: 00:01: ioport range 0x3f0-0x3f1 has been reserved
pnp: 00:01: ioport range 0x400-0x4bf could not be reserved
pnp: 00:01: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:01: ioport range 0x40b-0x40b has been reserved
pnp: 00:01: ioport range 0x4d6-0x4d6 has been reserved
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:02:1d.0
IO window: disabled.
MEM window: fe900000-fe9fffff
PREFETCH window: f8400000-fc4fffff
PCI: Bridge: 0000:02:1f.0
IO window: 2000-2fff
MEM window: fe800000-fe8fffff
PREFETCH window: f8300000-f83fffff
PCI: Bridge: 0000:00:03.0
IO window: 2000-2fff
MEM window: fe800000-feafffff
PREFETCH window: f8300000-fc5fffff
PCI: Bridge: 0000:00:1e.0
IO window: 1000-1fff
MEM window: fc700000-fe7fffff
PREFETCH window: f8200000-f82fffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1572864 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Boot video device is 0000:01:0c.0
Real Time Clock Driver v1.12ac
intel_rng: FWH not detected
Linux agpgart interface v0.102 (c) Dave Jones
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using get_cycles().
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
FDC 0 is a National Semiconductor PC87306
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:03:07.0[A] -> GSI 30 (level, low) -> IRQ 16
e1000: 0000:03:07.0: e1000_probe: (PCI-X:100MHz:64-bit) 00:0e:0c:66:ab:0e
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt 0000:03:07.1[B] -> GSI 31 (level, low) -> IRQ 17
e1000: 0000:03:07.1: e1000_probe: (PCI-X:100MHz:64-bit) 00:0e:0c:66:ab:0f
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH3: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 16 (level, low) -> IRQ 18
ICH3: chipset revision 2
ICH3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x03a0-0x03a7, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x03a8-0x03af, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
Probing IDE interface ide1...
Probing IDE interface ide0...
Probing IDE interface ide1...
megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006)
megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006)
GDT-HA: Storage RAID Controller Driver. Version: 3.05
ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 48 (level, low) -> IRQ 19
GDT-HA: Found 1 PCI Storage RAID Controllers
Configuring GDT-PCI HA at 4/8 IRQ 19
GDT-HA 0: Name: SRCZCR
scsi0 : SRCZCR
scsi 0:0:0:0: Direct-Access Intel Host Drive #00 PQ: 0 ANSI: 2
scsi 0:2:6:0: Processor ESG-SHV SCA HSBP M18 0.07 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 143299800 512-byte hardware sectors (73369 MB)
sd 0:0:0:0: [sda] Assuming Write Enabled
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 143299800 512-byte hardware sectors (73369 MB)
sd 0:0:0:0: [sda] Assuming Write Enabled
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
I2O subsystem v1.325
i2o: max drivers = 8
Fusion MPT base driver 3.04.04
Copyright (c) 1999-2007 LSI Logic Corporation
Fusion MPT SPI Host driver 3.04.04
usbmon: debugfs is not available
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 18, io base 0x00003020
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 20, io base 0x00003000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
usbcore: registered new interface driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 21
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
oprofile: using NMI interrupt.
nf_conntrack version 0.5.0 (8192 buckets, 65536 max)
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
Using IPI Shortcut mode
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 248k freed
EDAC MC: Ver: 2.0.1 Aug 30 2007
EDAC e7xxx: tolm = 80000, remapbase = 4000, remaplimit = 0
EDAC MC0: Giving out device to e7xxx_edac E7501: DEV 0000:00:00.0
EXT3 FS on sda2, internal journal
Adding 3911788k swap on /dev/sda1. Priority:-1 extents:1 across:3911788k
ip_tables: (C) 2000-2006 Netfilter Core Team
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
UDP: bad checksum. From 82.27.165.203:6881 to 87.255.1.89:1024 ulen 282
UDP: bad checksum. From 202.69.162.152:60033 to 87.255.1.89:1024 ulen 282
UDP: bad checksum. From 82.25.94.36:52777 to 87.255.1.43:52907 ulen 285
UDP: short packet: From 219.146.165.98:63467 3849/106 to 87.255.1.39:7903
UDP: bad checksum. From 201.53.114.76:18845 to 87.255.1.59:27212 ulen 276
UDP: short packet: From 209.222.2.2:12043 25649/75 to 87.255.1.43:52907
UDP: bad checksum. From 125.92.10.232:10982 to 87.255.1.6:1352 ulen 145
UDP: bad checksum. From 190.140.147.153:12765 to 87.255.1.43:1288 ulen 68
UDP: short packet: From 222.128.33.233:1924 2065/1480 to 87.255.1.73:18459
UDP: bad checksum. From 61.49.226.238:25333 to 87.255.1.54:7105 ulen 280
UDP: short packet: From 76.172.242.93:10256 58125/10 to 87.255.1.35:59675
UDP: bad checksum. From 68.103.175.217:14262 to 87.255.1.35:59675 ulen 380
UDP: bad checksum. From 68.12.171.227:45609 to 87.255.1.110:22983 ulen 25
UDP: bad checksum. From 68.12.171.227:45609 to 87.255.1.110:22983 ulen 25
UDP: bad checksum. From 68.12.171.227:45609 to 87.255.1.110:22983 ulen 25
UDP: bad checksum. From 88.148.211.148:20152 to 87.255.1.14:47576 ulen 282
UDP: bad checksum. From 222.188.215.87:25546 to 87.255.1.43:1036 ulen 310
UDP: bad checksum. From 75.118.118.25:60111 to 87.255.1.54:1385 ulen 289
UDP: bad checksum. From 72.155.16.125:64718 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 89.40.138.242:12225 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 68.13.132.220:33056 to 87.255.1.45:30568 ulen 33
UDP: bad checksum. From 59.172.152.214:6653 to 87.255.1.75:4672 ulen 210
UDP: bad checksum. From 68.72.231.22:65516 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 221.218.52.175:30997 to 87.255.1.19:1388 ulen 280
UDP: bad checksum. From 59.173.192.113:20318 to 87.255.1.19:1388 ulen 280
UDP: short packet: From 219.146.165.99:32720 1865/106 to 87.255.1.6:242
UDP: bad checksum. From 89.208.32.229:27023 to 87.255.1.106:1382 ulen 282
UDP: bad checksum. From 85.140.101.140:10207 to 87.255.1.6:39724 ulen 315
UDP: bad checksum. From 75.118.114.187:9034 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 125.33.83.127:7808 to 87.255.1.67:1389 ulen 276
UDP: bad checksum. From 62.165.211.135:31276 to 87.255.1.69:6349 ulen 33
UDP: short packet: From 24.192.142.124:8609 58125/10 to 87.255.1.100:1383
UDP: bad checksum. From 80.4.96.108:49152 to 87.255.1.89:1383 ulen 282
UDP: bad checksum. From 222.93.49.206:8301 to 87.255.1.54:7105 ulen 280
UDP: bad checksum. From 87.18.31.216:13100 to 87.255.1.37:25117 ulen 46
UDP: bad checksum. From 68.220.96.97:50001 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 65.6.116.40:62628 to 87.255.1.65:4127 ulen 33
UDP: bad checksum. From 202.44.178.101:28604 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 202.44.178.101:28604 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 59.127.220.134:12590 to 87.255.1.19:1391 ulen 310
UDP: bad checksum. From 122.169.4.72:4273 to 87.255.1.69:6349 ulen 33
UDP: short packet: From 219.146.165.99:28513 14818/106 to 87.255.1.6:52824
UDP: bad checksum. From 65.8.0.232:59928 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 58.64.42.170:11772 to 87.255.1.25:1391 ulen 280
UDP: bad checksum. From 125.127.173.190:1071 to 87.255.1.7:61159 ulen 70
UDP: bad checksum. From 74.103.66.241:60001 to 87.255.1.43:1036 ulen 280
UDP: bad checksum. From 84.236.72.241:6881 to 87.255.1.59:1391 ulen 289
UDP: bad checksum. From 201.45.89.132:11997 to 87.255.1.95:1391 ulen 88
UDP: bad checksum. From 213.118.235.231:58480 to 87.255.1.92:64035 ulen 76
UDP: short packet: From 89.142.143.74:4764 16827/310 to 87.255.1.95:56662
UDP: short packet: From 222.128.33.233:1924 2304/1480 to 87.255.1.73:1391
UDP: bad checksum. From 82.25.27.254:10930 to 87.255.1.6:10261 ulen 315
UDP: bad checksum. From 195.182.8.208:8767 to 87.255.1.43:1774 ulen 190
UDP: bad checksum. From 60.221.172.243:16001 to 87.255.1.90:24094 ulen 70
UDP: bad checksum. From 195.182.8.208:8767 to 87.255.1.43:1774 ulen 190
UDP: bad checksum. From 216.117.225.80:17153 to 87.255.1.100:32104 ulen 33
UDP: bad checksum. From 195.182.8.208:8767 to 87.255.1.43:1774 ulen 190
UDP: bad checksum. From 82.20.112.186:53140 to 87.255.1.5:46615 ulen 285
UDP: bad checksum. From 60.221.172.243:16001 to 87.255.1.90:24094 ulen 70
UDP: bad checksum. From 201.235.3.10:28881 to 87.255.1.60:20475 ulen 36
UDP: bad checksum. From 86.6.19.199:34660 to 87.255.1.89:1391 ulen 315
UDP: bad checksum. From 86.136.199.161:34803 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 196.29.43.198:61239 to 87.255.1.70:10965 ulen 106
UDP: bad checksum. From 58.64.42.170:11772 to 87.255.1.49:8332 ulen 280
UDP: bad checksum. From 89.40.137.76:28986 to 87.255.1.14:7507 ulen 33
UDP: bad checksum. From 80.97.183.220:20764 to 87.255.1.69:56013 ulen 33
UDP: bad checksum. From 122.4.221.21:62420 to 87.255.1.95:63641 ulen 70
UDP: short packet: From 122.5.130.142:16001 0/70 to 87.255.1.5:46615
UDP: bad checksum. From 80.97.183.220:22921 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 125.40.32.216:19948 to 87.255.1.82:8080 ulen 106
UDP: bad checksum. From 151.33.64.18:63598 to 87.255.1.65:1394 ulen 12
UDP: bad checksum. From 60.26.131.200:18938 to 87.255.1.25:8516 ulen 109
UDP: bad checksum. From 219.131.38.89:1542 to 87.255.1.43:1036 ulen 273
UDP: bad checksum. From 75.118.114.187:9034 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 81.106.145.78:16923 to 87.255.1.89:1395 ulen 306
UDP: bad checksum. From 82.39.35.157:49155 to 87.255.1.61:26583 ulen 285
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 100
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 385
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 1207
UDP: bad checksum. From 60.10.201.110:58630 to 87.255.1.43:45981 ulen 112
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 170
UDP: bad checksum. From 59.172.92.39:9796 to 87.255.1.58:36124 ulen 276
UDP: bad checksum. From 82.0.17.204:1828 to 87.255.1.70:1396 ulen 289
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 1316
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 131
UDP: bad checksum. From 60.10.201.110:36000 to 87.255.1.43:45981 ulen 112
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 79
UDP: bad checksum. From 81.100.196.245:49109 to 87.255.1.41:1396 ulen 282
UDP: bad checksum. From 125.40.32.216:19948 to 87.255.1.82:8080 ulen 106
UDP: bad checksum. From 65.82.222.45:58117 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 60.10.201.110:36000 to 87.255.1.43:45981 ulen 112
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 218
UDP: bad checksum. From 125.92.10.232:10982 to 87.255.1.6:39724 ulen 145
conntrack_ftp: partial EPRT 3941011105+1
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 181
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 182
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 193
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 177
UDP: bad checksum. From 70.152.16.84:51130 to 87.255.1.61:11800 ulen 33
UDP: bad checksum. From 124.120.182.165:20000 to 87.255.1.49:1397 ulen 280
UDP: bad checksum. From 218.206.139.231:18137 to 87.255.1.89:1397 ulen 280
UDP: bad checksum. From 219.157.13.224:21814 to 87.255.1.89:1386 ulen 109
UDP: bad checksum. From 82.28.117.13:4667 to 87.255.1.70:10965 ulen 289
UDP: bad checksum. From 122.4.221.21:62420 to 87.255.1.95:63641 ulen 70
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 171
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 435
UDP: short packet: From 60.19.221.226:16001 0/70 to 87.255.1.89:1395
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 388
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 237
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 437
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 313
UDP: short packet: From 24.104.98.2:52014 25649/106 to 87.255.1.50:1397
UDP: bad checksum. From 58.40.148.46:16001 to 87.255.1.73:1397 ulen 291
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 56
UDP: bad checksum. From 62.143.96.142:25646 to 87.255.1.23:1397 ulen 285
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 57
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 119
UDP: bad checksum. From 62.99.150.176:62759 to 87.255.1.89:1397 ulen 282
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 154
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 58
UDP: bad checksum. From 202.69.182.218:1382 to 87.255.1.51:44883 ulen 111
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 173
UDP: bad checksum. From 60.10.201.110:32791 to 87.255.1.43:45981 ulen 109
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 504
UDP: short packet: From 76.208.213.81:61808 25649/111 to 87.255.1.82:1399
UDP: short packet: From 201.43.229.150:20414 1743/1480 to 87.255.1.5:4672
UDP: bad checksum. From 60.10.201.110:32791 to 87.255.1.43:45981 ulen 109
UDP: bad checksum. From 219.156.82.150:21978 to 87.255.1.49:1400 ulen 280
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 59
UDP: bad checksum. From 91.76.96.202:1513 to 87.255.1.42:1513 ulen 40
UDP: bad checksum. From 91.76.96.202:1513 to 87.255.1.42:1513 ulen 40
UDP: bad checksum. From 86.22.10.27:13134 to 87.255.1.70:1400 ulen 280
UDP: bad checksum. From 58.51.76.78:16001 to 87.255.1.43:1036 ulen 70
UDP: bad checksum. From 60.10.201.110:37137 to 87.255.1.43:45981 ulen 109
UDP: bad checksum. From 60.10.201.110:37137 to 87.255.1.43:45981 ulen 112
UDP: bad checksum. From 81.71.46.120:29898 to 87.255.1.50:28320 ulen 76
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 249
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 690
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 398
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 562
UDP: bad checksum. From 81.71.46.120:29898 to 87.255.1.50:28320 ulen 76
UDP: bad checksum. From 59.56.237.120:5153 to 87.255.1.65:20666 ulen 77
UDP: short packet: From 209.222.2.2:60526 25649/106 to 87.255.1.50:1400
UDP: bad checksum. From 81.71.46.120:29898 to 87.255.1.50:28320 ulen 76
UDP: bad checksum. From 72.155.16.125:57262 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 87.18.31.216:13100 to 87.255.1.69:6349 ulen 32
UDP: bad checksum. From 85.53.203.33:27218 to 87.255.1.95:1401 ulen 280
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 252
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 238
UDP: bad checksum. From 189.7.87.142:22118 to 87.255.1.95:1401 ulen 61
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 182
UDP: bad checksum. From 81.71.46.120:29898 to 87.255.1.50:28320 ulen 76
UDP: bad checksum. From 122.168.26.181:18092 to 87.255.1.121:31885 ulen 33
UDP: bad checksum. From 85.232.129.95:50935 to 87.255.1.6:39724 ulen 75
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 345
UDP: bad checksum. From 220.39.18.95:1422 to 87.255.1.43:1036 ulen 280
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 170
UDP: bad checksum. From 219.74.75.48:48586 to 87.255.1.41:10983 ulen 272
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 121
UDP: bad checksum. From 59.56.227.149:61068 to 87.255.1.110:11659 ulen 73
UDP: bad checksum. From 217.150.52.121:38932 to 87.255.1.73:24898 ulen 75
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 1280
UDP: bad checksum. From 76.104.23.107:6885 to 87.255.1.41:10983 ulen 43
UDP: bad checksum. From 81.71.46.120:29898 to 87.255.1.50:28320 ulen 76
UDP: bad checksum. From 222.174.114.242:6881 to 87.255.1.70:1396 ulen 70
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 346
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 60
UDP: bad checksum. From 81.71.46.120:29898 to 87.255.1.50:28320 ulen 76
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 193
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 173
UDP: bad checksum. From 124.125.147.168:13666 to 87.255.1.121:31885 ulen 33
UDP: bad checksum. From 58.247.245.35:10741 to 87.255.1.61:26583 ulen 276
UDP: bad checksum. From 86.6.19.199:34660 to 87.255.1.89:59708 ulen 315
UDP: bad checksum. From 81.100.196.245:49109 to 87.255.1.41:1402 ulen 282
UDP: bad checksum. From 81.71.46.120:29898 to 87.255.1.50:28320 ulen 76
UDP: bad checksum. From 81.71.46.120:29898 to 87.255.1.50:28320 ulen 76
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 297
UDP: bad checksum. From 89.215.181.50:25463 to 87.255.1.45:52103 ulen 121
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 110
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 116
UDP: bad checksum. From 82.12.187.151:54689 to 87.255.1.73:24898 ulen 285
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 346
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 300
UDP: bad checksum. From 75.118.114.187:9034 to 87.255.1.69:6349 ulen 33
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 107
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 314
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 351
UDP: bad checksum. From 58.208.75.165:4711 to 87.255.1.31:4672 ulen 43
UDP: bad checksum. From 86.0.167.3:50213 to 87.255.1.95:35590 ulen 1363
UDP: short packet: From 76.208.213.81:62578 25649/111 to 87.255.1.115:43661
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 368
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 286
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 89
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 91
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 171
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 242
UDP: bad checksum. From 67.101.85.111:61171 to 87.255.1.82:1402 ulen 276
UDP: bad checksum. From 74.235.10.52:60671 to 87.255.1.65:4127 ulen 33
UDP: bad checksum. From 125.127.31.238:25105 to 87.255.1.89:64485 ulen 285
UDP: bad checksum. From 59.172.152.214:6653 to 87.255.1.36:58185 ulen 212
UDP: bad checksum. From 89.179.119.121:27015 to 87.255.1.106:27005 ulen 422
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 191
UDP: bad checksum. From 24.165.7.12:14957 to 87.255.1.41:10983 ulen 195
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 294
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 60
UDP: bad checksum. From 89.41.188.204:26647 to 87.255.1.70:10965 ulen 289
UDP: bad checksum. From 85.232.140.239:52129 to 87.255.1.47:40571 ulen 75
UDP: bad checksum. From 218.166.76.153:19194 to 87.255.1.89:1404 ulen 209
UDP: bad checksum. From 72.153.182.254:59919 to 87.255.1.69:6349 ulen 33
UDP: short packet: From 222.128.33.233:1924 2188/1480 to 87.255.1.73:18459
UDP: short packet: From 125.115.14.182:63201 1761/1480 to 87.255.1.122:29105
UDP: bad checksum. From 89.179.119.121:27015 to 87.255.1.106:27005 ulen 706
UDP: short packet: From 74.212.42.2:15934 38003/71 to 87.255.1.43:51508
UDP: bad checksum. From 82.7.91.66:22831 to 87.255.1.65:1406 ulen 311
UDP: bad checksum. From 81.108.96.240:19343 to 87.255.1.23:1406 ulen 285
UDP: bad checksum. From 203.128.253.26:5191 to 87.255.1.65:4127 ulen 33
UDP: bad checksum. From 72.153.182.254:50288 to 87.255.1.69:6349 ulen 33
UDP: short packet: From 74.212.42.2:37835 25649/111 to 87.255.1.63:44205
UDP: bad checksum. From 217.150.52.121:61373 to 87.255.1.14:7507 ulen 33
UDP: bad checksum. From 222.137.156.201:1501 to 87.255.1.31:22845 ulen 106
UDP: bad checksum. From 219.156.82.150:21978 to 87.255.1.49:1400 ulen 106
UDP: bad checksum. From 121.56.158.2:20461 to 87.255.1.89:63197 ulen 276
UDP: short packet: From 124.120.192.111:17028 266/10 to 87.255.1.65:1401
UDP: bad checksum. From 76.104.23.107:6885 to 87.255.1.41:10983 ulen 39
UDP: bad checksum. From 221.220.217.101:13355 to 87.255.1.65:1406 ulen 306
UDP: bad checksum. From 62.143.93.246:63371 to 87.255.1.49:8332 ulen 117
UDP: bad checksum. From 77.101.2.7:10942 to 87.255.1.14:1406 ulen 311
UDP: bad checksum. From 72.204.240.75:15927 to 87.255.1.60:20475 ulen 71
UDP: bad checksum. From 68.220.96.97:61607 to 87.255.1.61:11800 ulen 33
UDP: short packet: From 220.227.26.141:51338 25649/111 to 87.255.1.89:1406
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 124.120.192.111:17028 to 87.255.1.65:4127 ulen 33
UDP: bad checksum. From 124.120.192.111:17028 to 87.255.1.61:11800 ulen 33
UDP: bad checksum. From 88.27.71.2:29780 to 87.255.1.106:1418 ulen 1328
UDP: bad checksum. From 121.16.230.115:14017 to 87.255.1.43:1420 ulen 73
UDP: bad checksum. From 87.13.134.184:35000 to 87.255.1.43:1420 ulen 288
UDP: short packet: From 222.128.33.233:1924 2432/1480 to 87.255.1.73:1406
UDP: bad checksum. From 60.241.68.45:50403 to 87.255.1.73:24898 ulen 111
UDP: short packet: From 203.101.42.197:51251 25649/111 to 87.255.1.51:44883
UDP: short packet: From 74.212.42.2:15934 38650/71 to 87.255.1.43:1420
UDP: bad checksum. From 74.34.14.208:36128 to 87.255.1.114:10159 ulen 35
UDP: bad checksum. From 74.34.14.208:36128 to 87.255.1.114:10159 ulen 35
UDP: bad checksum. From 74.34.14.208:36128 to 87.255.1.114:10159 ulen 35
UDP: bad checksum. From 74.34.14.208:36128 to 87.255.1.114:10159 ulen 35
UDP: bad checksum. From 203.67.201.93:26261 to 87.255.1.36:44953 ulen 145
UDP: bad checksum. From 68.103.175.217:14262 to 87.255.1.65:1401 ulen 380
UDP: bad checksum. From 24.165.7.12:14957 to 87.255.1.41:1420 ulen 36
UDP: short packet: From 121.16.230.115:13824 669/70 to 87.255.1.43:12424
UDP: bad checksum. From 24.77.131.34:6881 to 87.255.1.122:29105 ulen 99
UDP: bad checksum. From 58.20.75.114:10546 to 87.255.1.60:1422 ulen 306
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 639
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 1316
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 82.200.62.66:9387 to 87.255.1.50:4672 ulen 10
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 1316
UDP: bad checksum. From 213.67.210.17:5444 to 87.255.1.89:41441 ulen 50
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 1316
UDP: bad checksum. From 24.165.7.12:14957 to 87.255.1.41:1420 ulen 132
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 957
UDP: bad checksum. From 87.18.31.216:13100 to 87.255.1.35:10256 ulen 32
UDP: bad checksum. From 24.165.7.12:14957 to 87.255.1.41:1420 ulen 44
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 167
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 193
UDP: bad checksum. From 125.40.114.106:14426 to 87.255.1.36:44953 ulen 109
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 156
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 191
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 86
UDP: bad checksum. From 213.145.133.124:29149 to 87.255.1.65:1424 ulen 127
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 487
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 443
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 301
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 356
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 782
UDP: bad checksum. From 220.141.130.122:52810 to 87.255.1.59:41231 ulen 146
UDP: bad checksum. From 61.146.67.199:65353 to 87.255.1.89:1420 ulen 145
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 60
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 390
UDP: bad checksum. From 69.246.191.217:52967 to 87.255.1.51:44883 ulen 285
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 251
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 188
UDP: bad checksum. From 218.208.196.221:53967 to 87.255.1.41:10983 ulen 1508
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 186
UDP: short packet: From 74.212.42.2:15934 57720/71 to 87.255.1.43:1425
UDP: bad checksum. From 89.208.32.226:28960 to 87.255.1.80:28960 ulen 514
UDP: short packet: From 74.212.42.2:15934 63183/50 to 87.255.1.43:1425
UDP: short packet: From 74.212.42.2:15934 58294/71 to 87.255.1.43:1425
UDP: bad checksum. From 24.165.7.12:14957 to 87.255.1.41:10983 ulen 40
UDP: bad checksum. From 24.65.16.161:61232 to 87.255.1.49:1421 ulen 319
UDP: bad checksum. From 86.9.68.129:65534 to 87.255.1.122:1425 ulen 285
UDP: bad checksum. From 87.13.134.110:45292 to 87.255.1.115:15051 ulen 111
^ permalink raw reply
* Re: ipv4_get_l4proto: Frag of proto 17
From: Meelis Roos @ 2007-08-30 13:04 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, Netfilter Development Mailinglist
In-Reply-To: <46D66D00.7060801@trash.net>
> > Yesterdays git snapsot on a normal home PC spams dmesg with the following
> > line:
> > ipv4_get_l4proto: Frag of proto 17
>
> In what situation does this happen?
It happens some times every hour on the average. Seems to be some UDP
traffic. Firewall allows in any UDP that is ESTABLISHEFD,RELATED, DHCP
(some more UDP rules with counter 0 so not important). Additionally
there is internal netowkr that sometimes has a laptop but usually not
and the messages have appeared also when there is nothin in the internal
network.
Locally mldonkey is probably using UDP, and lsof -i | grep UDP tells
that named, avahi-daemon, dhcpd, chronyd, nmbd and cupsd are listening
on UDP sockets (most of them on internal network).
But I have no idea what application is causing the messages.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH 4/5] Net: ath5k, license is GPLv2
From: David Newall @ 2007-08-30 13:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <9e4733910708291233h3c4022a9n6e46733c5c50e222@mail.gmail.com>
Is it actually necessary to change the license? With the dual-license,
you can keep a single code-base for both BSD and Linux platforms, which
seems terribly important to me. It'd be awful to lose that. It would
be a maintenance nightmare for BSD. Is it even possible--in real life,
I mean--to accept GPLed patches into a BSD project? Nightmare, I tell you!
^ permalink raw reply
* Re: [PATCH 3/5] Net: ath5k, use int as retval
From: John W. Linville @ 2007-08-30 12:40 UTC (permalink / raw)
To: Jiri Slaby
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2440910618305782004-+5AFNAhbZwkm4RdzfppkhA@public.gmane.org>
On Tue, Aug 28, 2007 at 12:00:09PM -0400, Jiri Slaby wrote:
> ath5k, use int as retval
>
> Convert some functions to return int and proper negative return value on
> error as we are used to.
Since I didn't apply 1/5, this one didn't apply either. It seems
fine overall, so if you rediff I'll be happy to apply.
John
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals
From: John W. Linville @ 2007-08-30 12:38 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Christoph Hellwig, Jiri Slaby,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <40f31dec0708291850j2d35db6cu9de7c5f0a91e76f7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Aug 30, 2007 at 04:50:01AM +0300, Nick Kossifidis wrote:
> 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
> > ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
> > most drivers and ath5k_hw_inivals.o mights aswell be something like
> > ath5k_init.o
> If you check out the code you'll see i'm using the same convention
> inside them, ath5k_hw* files contain hw related functions
> (ath5k_hw_<name>) while driver code has ath5k_<name>. Also ath5k_init
> is misleading, file acually includes initial register settings for
I have to agree w/ Christoph -- the extra "_hw" in the names is just
a bit unwieldy.
John
P.S. "ath5k_initvals.c" seems acceptable to me.
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-08-30 12:37 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <46D68937.7030305@bigtelecom.ru>
On Thu, Aug 30, 2007 at 01:09:11PM +0400, Badalian Vyacheslav wrote:
> Jarek Poplawski ??????????:
...
> >On the other hand disabling local interrupts shouldn't be enough here,
> >so it's really strange... Did you get this remotely? Are you sure LOC
> >only? (Anyway this 2.6.23-rc4 should be interesting.)
...
> Only LOC changes... icmp answer = 50-70ms... after 1-2 hours traffic
> level is down and SI on CPU0 and CPU2 change to above 50%. ksoftirqd
> free CPU usage. I have this bug 3-4 times in week. If you need info what
> i can see only in bug still processing - i may try get this info for you.
Any additional info could be helpful. I'm not sure if all these
computers do similar htb processing, or it's another problem?
As I've written before htb before 2.6.23-rc1 has a problem with
timer lockup during qdisc_destroy, so softirqs would be hit.
If it's htb's fault 2.6.23-rc4 or my testing patch should help.
I try to find in htb code another weak points. BTW, if during
such lockups any processes are killed 'by hand' etc., without
restarting the whole system, please let us know.
> maybe help:
>
> 1U server INTEL, mb se7501w2
>
> nat-new ~ # lspci
lspci -v (or -vv should be more usable - but with dmesg at least)
Jarek P.
^ permalink raw reply
* Re: [PATCH 5/5] Net: ath5k, kconfig changes
From: John W. Linville @ 2007-08-30 12:36 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Christoph Hellwig, Jiri Slaby,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <40f31dec0708291838p5d33eb34p3b4432d9d270841a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
> > Also this whole patch seems rather pointless. It saves only
> > very little and turns the driver into a complete ifdef maze.
> Also most
> people will use 5212 code only, 5211 cards are on some old laptops and
> 5210, well i couldn't even find a 5210 for actual testing :P
FWIW, I'd bet dollars to donuts that distros will enable them all
together.
Is saving code space the only reason to turn these off? How much
space do you save?
Is there some way you can isolate and/or limit the number of ifdef
blocks further? If so, we might consider a version of this patch
that depends on EMBEDDED or somesuch...?
John
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH 5/5] Net: ath5k, kconfig changes
From: Christoph Hellwig @ 2007-08-30 12:35 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Christoph Hellwig, Jiri Slaby, linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <40f31dec0708291838p5d33eb34p3b4432d9d270841a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> It saves big chunks of code (not only initial register settings
> arrays) and we'll extend it's use more inside ath5k_hw.c Trust me this
> is a very useful step, eg. check out descriptor processing / setup or
> PHY functions (calibrate/channel set etc). For example AR5210 mac chip
> only comes with RF5110 phy chip so we can get rid of RF5111/RF5112
> code, AR5211 comes with RF5111 so we can get rid of RF5110 and RF5112
> code and AR5212 comes with RF5111 or RF5112 so we get rid of RF5110.
> This thing also saves lots of checks during runtime (some of them
> happen verry frequently, eg. durring descriptor processing). Also most
> people will use 5212 code only, 5211 cards are on some old laptops and
> 5210, well i couldn't even find a 5210 for actual testing :P
If you're doing these checks in a hotpath something is badly wrong with
your architecture.
^ permalink raw reply
* Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
From: OBATA Noboru @ 2007-08-30 12:24 UTC (permalink / raw)
To: rick.jones2; +Cc: davem, shemminger, yoshfuji, netdev
In-Reply-To: <46D59BEB.1080602@hp.com>
Hi Rick,
From: Rick Jones <rick.jones2@hp.com>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Wed, 29 Aug 2007 09:16:43 -0700
> OBATA Noboru wrote:
> > What about another option to let TCP have a notification?
> >
> > Can it be a solution if it is standardized?
>
> It would at best be a partial solution which would only work when the
> link failover/whatnot happened on the same system/node as the TCP
> endpoint. Then it can be some sort of call-back to TCP or the like.
I understood that the IETF document pointed by John has such a
limitation.
> If this failover is out in the middle of the cloud the only way to get a
> notification back to TCP would be by sending it a packet of some sort
> and I don't see that happening.
Agreed.
I learned that, in practice, the route monitoring by probe
packets (ICMP or others) is used to detect a failure along the
route to an important host.
This monitoring apparently doesn't scale and so its use is
limited to the route to an important host, but practices show
that it is quite effective in monitoring.
I am now wondering about a TCP notification mechanism combined
with the route monitoring.
Regards,
--
OBATA Noboru (noboru.obata.ar@hitachi.com)
^ permalink raw reply
* Re: pktgen terminating condition
From: jamal @ 2007-08-30 12:08 UTC (permalink / raw)
To: Robert Olsson
Cc: Mandeep Singh Baines, davem, rick.jones2, msb, netdev, grundler,
robert.olsson, venza
In-Reply-To: <18133.40847.166882.838333@robur.slu.se>
On Wed, 2007-29-08 at 18:32 +0200, Robert Olsson wrote:
> Yes it's synchronization issue... the test is over and we have sent
> all pkts to the device but pktgen cannot free the skb for it still
> has refcounts.
Ok, right.
I was confusing it with another issue where pktgen could send a lot of
packets without waiting for them to be freed; there are some drivers
(10G) which may hold onto 8K skbs. A gazillion ooms start spewing ;-> My
thinking in resolving that was to do something like waht sockets do and
charge pktgen so it doesnt have too many outstanding packets in flight.
> IMO must drivers have provisions to handle situation like.
Mandeep was saying he found less than a handful that didnt conform.
> I'll
> guess we can discuss last-resort timer if it should be us, ms
> or possibly seconds but shouldn't need ping to make this happen.
> If so we probably have a ICMP packet sitting there waiting instead.
I think as long as it doesnt affect throughput calculation (it just adds
to idle time) its fine.
cheers,
jamal
^ permalink raw reply
* Re: oops with recent wireless-dev tree
From: Johannes Berg @ 2007-08-30 12:05 UTC (permalink / raw)
To: Jochen Voss
Cc: linux wireless list, linville-2XuSBdqkA4R54TAoqtyWWQ, netdev,
shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20070829223752.GA6969-52ZyvxujusuELgA04lAiVw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
Hi Jochen,
[added CCs since it affects bridge code]
> If I read this correctly, the EIP in the last line corresponds to
> net/bridge/br_if.c, line 36:
>
> static int port_cost(struct net_device *dev)
> {
> if (dev->ethtool_ops->get_settings) {
> ^^^^
>
> As far as I can figure out, dev->ethtool_ops is NULL and the crash
> happens while trying to derefernce ...->get_settings.
>
> Is dev->ethtool_ops allowed to be NULL? In this case the appended
> patch might be the correct fix. At least it makes the oops disappear
> for me. Another possible fix would be to add an ethtool_ops structure
> to the device created by b43.
I don't think adding ethtool_ops in mac80211 should be necessary.
Stephen?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] Net: ath5k, license is GPLv2
From: Johannes Berg @ 2007-08-30 11:59 UTC (permalink / raw)
To: Xavier Bestel
Cc: Jiri Slaby, linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1188393226.1131.319.camel@frg-rhel40-em64t-04>
[-- Attachment #1: Type: text/plain, Size: 333 bytes --]
On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote:
> How about asking for changes to be dual-licenced too ?
In theory, that could work, but in practice relying on functions that
the Linux kernel offers in GPLv2-only headers etc. will make the result
GPLv2 anyway, and disentangling it would be a nightmare.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ 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