* Re: [PATCH net-2.6.25 8/8] Remove unused IPV4TYPE macros
From: Joe Perches @ 2007-12-17 4:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20071216.134825.261226998.davem@davemloft.net>
On Sun, 2007-12-16 at 13:48 -0800, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Thu, 13 Dec 2007 15:39:01 -0800
> > Signed-off-by: Joe Perches <joe@perches.com>
> Applied, thanks for doing this work Joe.
I broke the parisc build. Bad Joe...
Here's the patch:
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/drivers/parisc/led.c b/drivers/parisc/led.c
index a6d6b24..703b85e 100644
--- a/drivers/parisc/led.c
+++ b/drivers/parisc/led.c
@@ -364,7 +364,7 @@ static __inline__ int led_get_net_activity(void)
struct in_device *in_dev = __in_dev_get_rcu(dev);
if (!in_dev || !in_dev->ifa_list)
continue;
- if (LOOPBACK(in_dev->ifa_list->ifa_local))
+ if (ipv4_is_loopback(in_dev->ifa_list->ifa_local))
continue;
stats = dev->get_stats(dev);
rx_total += stats->rx_packets;
^ permalink raw reply related
* Re: [PATCH] bridge: assign random address
From: Andrew Morton @ 2007-12-17 2:55 UTC (permalink / raw)
To: Jeff Garzik
Cc: David Miller, shemminger, netdev, bugme-daemon, berrange, herbert,
rjw
In-Reply-To: <4765D4F0.5040202@garzik.org>
On Sun, 16 Dec 2007 20:46:24 -0500 Jeff Garzik <jeff@garzik.org> wrote:
> David Miller wrote:
> > From: Andrew Morton <akpm@linux-foundation.org>
> > Date: Sun, 16 Dec 2007 14:29:15 -0800
> >
> >> On Sun, 16 Dec 2007 13:37:17 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> >>
> >>> From: Stephen Hemminger <shemminger@linux-foundation.org>
> >>> Date: Tue, 11 Dec 2007 15:48:35 -0800
> >>>
> >>>> Subject: Re: [PATCH] bridge: assign random address
> >>> "bridge" should all-caps and in brackets,
> >> No, "bridge" should not be in []. Lots of people's patch-receiving scripts
> >> assume that any text in [] is to be removed as the patch is committed. It
> >> contains text which is only relevant to the particular email which carried
> >> the patch. Stuff like "patch" and "4/5" and "linux-2.6.23", etc.
> >
> > I don't use scripts, I edit it by hand. And when I do ever use
> > scripts I will make sure they accomodate "[$SUBSYSTEM]" format
> > subject lines, you can be sure.
> >
> > And you can even make those scripts happy by doing:
> >
> > [Patch 1/7] [SUBSYSTEM]: Foo bar baz...
>
> The most popular tool is git-am, which I and many others use.
>
> git-am will snip "[SUBSYSTEM]" in the example that you give.
>
> Until Linus's official mail import tool (git-am) changes, I agree with
> Andrew -- since Andrew is simply describing the de facto standard as it
> exists today: [] gets eaten.
I didn't know that.
> That's why documentation like Documentation/SubmittingPatches and
> http://linux.yyz.us/patch-format.html indicate "subsystem: " rather than
> "[SUBSYSTEM]": it's compatible with Linus's widely used mail import tool.
>
People are tossing all sorts of metadata into [] nowadays...
grep '^Subject:' lkmo-folder | grep '\[.*\[' | grep -v Re:
says stuff like
Subject: [PATCH 5/7] Security: Change current->fs[ug]id to current_fs[ug]id()
Subject: [PATCH 00/28] Permit filesystem local caching [try #2]
Subject: [PATCH 04/28] KEYS: Add keyctl function to get a security label [try
Subject: [PATCH 05/28] Security: Change current->fs[ug]id to
Subject: [PATCH 02/28] KEYS: Check starting keyring as part of search [try #2]
Subject: [PATCH 21/28] NFS: Display local caching state [try #2]
Subject: [PATCH 17/28] CacheFiles: Export things for CacheFiles [try #2]
Subject: [PATCH 13/28] CacheFiles: Add missing copy_page export for ia64 [try
Subject: [PATCH 19/28] NFS: Use local caching [try #2]
Subject: [PATCH 12/28] FS-Cache: Generic filesystem caching facility [try #2]
Subject: [PATCH 23/28] AFS: Add TestSetPageError() [try #2]
Subject: [PATCH 22/28] fcrypt endianness misannotations [try #2]
Subject: [PATCH 26/28] AF_RXRPC: Save the operation ID for debugging [try #2]
Subject: [PATCH 25/28] AFS: Improve handling of a rejected writeback [try #2]
Subject: [PATCH 27/28] AFS: Implement shared-writable mmap [try #2]
Subject: [PATCH 28/28] FS-Cache: Make kAFS use FS-Cache [try #2]
Subject: [RFC] [PATCH] A clean approach to writeout throttling
Subject: [RFC][POWERPC] Provide a way to protect 4k subpages when
Subject: [PATCH 2/3] [PATCH] unify common parts of segment.h
Subject: [PATCH 1/3] [PATCH] put get_kernel_rpl in a common location
Subject: [PATCH 3/3] [PATCH] remove arch specific segment headers
Subject: [patch 2.6.24-rc4-mm 1/6] gpiolib: add gpio_desc[]
Subject: [PATCH][SCSI] hptiop: add more adapter models and other fixes
Subject: [PATCH][for -mm] fix accounting in vmscan.c for memory controller
Subject: [DOC][for -mm] update Documentation/controller/memory.txt
Subject: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
Subject: RE: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
Subject: RE: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
Subject: [PATCH 7/7] [NETDEV]: myri10ge Fix possible causing oops of net_rx_action
Subject: [PATCH 4/7] [NETDEV]: ixgbe Fix possible causing oops of net_rx_action
Subject: [PATCH 5/7] [NETDEV]: e100 Fix possible causing oops of net_rx_action
Subject: [PATCH 3/7] [NETDEV]: ixgb Fix possible causing oops of net_rx_action
Subject: [PATCH 1/7] [NETDEV]: e1000 Fix possible causing oops of net_rx_action
Subject: [PATCH 2/7] [NETDEV]: e1000e Fix possible causing oops of net_rx_action
Subject: [PATCH 6/7] [NETDEV]: tehuti Fix possible causing oops of net_rx_action
Subject: [PATCH][SCSI] resend: hptiop: add more adapter models and other fixes
Subject: [PATCH/RFC] [POWERPC] Add fixed-phy support for fs_enet
Subject: [PATCH][NETDEV]: remove netif_running() check from myri10ge_poll()
Subject: [RFC] [PATCH -mm] agp: remove uid comparison as security check
Subject: [RFC] [PATCH -mm] agp: remove uid comparison as security check
Subject: [RFC] [PATCH -mm] reiser4: replace uid==0 check with capability
Subject: [RFC] [PATCH -mm] reiser4: replace uid==0 check with capability
Subject: [RFC] [PATCH -mm] oom_kill: remove uid==0 checks
Subject: [RFC] [PATCH -mm] oom_kill: remove uid==0 checks
Subject: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
Subject: [PATCH] x86: move interrupts[] to .rodata/.init.data
Subject: RE: [PATCH 1/7] [NETDEV]: e1000 Fix possible causing oops of net_rx_action
Subject: [PATCH][KJ] 8250: remove unnecessary variable tmout from wait_for_xmitr()
Subject: [PATCH][rewrite with goto error handling] Bluetooth: hci_sysfs
Subject: [RFC][PATCH] fix bus error when trying to access anon & shared page created by mremap()[BUG:8691]
Subject: [RFC] [patch 2/2] Refuse kprobe insertion on __init section code
Subject: [RFC] [patch 1/2] add non_init_kernel_text_address
Subject: [PATCH] [TCP]: Fix fack_count miscountings (multiple places)
Subject: RE: [i2c] [PATCH 2.6.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander[
Subject: [PATCH][RT] 2.6.24-rc5-rt1 drivers/dma/ioat_dma.c compile fix
Kinda funny. I (and I bet lots of others) spend a lot of time fixing,
cleaning up and totally rewriting patch titles.
^ permalink raw reply
* Re: [PATCH] bridge: assign random address
From: Jeff Garzik @ 2007-12-17 1:46 UTC (permalink / raw)
To: David Miller
Cc: akpm, shemminger, netdev, bugme-daemon, berrange, herbert, rjw
In-Reply-To: <20071216.152606.35263254.davem@davemloft.net>
David Miller wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Sun, 16 Dec 2007 14:29:15 -0800
>
>> On Sun, 16 Dec 2007 13:37:17 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>>
>>> From: Stephen Hemminger <shemminger@linux-foundation.org>
>>> Date: Tue, 11 Dec 2007 15:48:35 -0800
>>>
>>>> Subject: Re: [PATCH] bridge: assign random address
>>> "bridge" should all-caps and in brackets,
>> No, "bridge" should not be in []. Lots of people's patch-receiving scripts
>> assume that any text in [] is to be removed as the patch is committed. It
>> contains text which is only relevant to the particular email which carried
>> the patch. Stuff like "patch" and "4/5" and "linux-2.6.23", etc.
>
> I don't use scripts, I edit it by hand. And when I do ever use
> scripts I will make sure they accomodate "[$SUBSYSTEM]" format
> subject lines, you can be sure.
>
> And you can even make those scripts happy by doing:
>
> [Patch 1/7] [SUBSYSTEM]: Foo bar baz...
The most popular tool is git-am, which I and many others use.
git-am will snip "[SUBSYSTEM]" in the example that you give.
Until Linus's official mail import tool (git-am) changes, I agree with
Andrew -- since Andrew is simply describing the de facto standard as it
exists today: [] gets eaten.
That's why documentation like Documentation/SubmittingPatches and
http://linux.yyz.us/patch-format.html indicate "subsystem: " rather than
"[SUBSYSTEM]": it's compatible with Linus's widely used mail import tool.
Jeff
^ permalink raw reply
* Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: Herbert Xu @ 2007-12-17 1:26 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Andrew Morton, David Miller, netdev
In-Reply-To: <47656931.1040309@gmail.com>
On Sun, Dec 16, 2007 at 07:06:41PM +0100, Jarek Poplawski wrote:
>
> It seemed to exist a few days ago:
> http://kerneltrap.org/mailarchive/linux-netdev/2007/12/4/473123
>
> Btw., I don't know which of the patches: Eric's or yours will be chosen,
> but, IMHO, there is no reason to remove rtnl_trylock(), which can be still
> useful, just like mutex_trylock() is.
Doh! Andrew was too convincing :) I misread the grep result on
in_interrupt. Of course that function returns true if we're
either in an IRQ handler or have BH off.
I retract what I've said in this thread and continue to oppose
this change without a might_sleep.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* net-2.6.25 rebased...
From: David Miller @ 2007-12-17 0:21 UTC (permalink / raw)
To: netdev; +Cc: ilpo.jarvinen, kaber
I needed to rebase for two reasons:
1) Ilpo asked me to revert a lot of TCP stuff and the
easiest way to do that was during a rebase.
2) Patrick McHardy needs some of the pending net-2.6
bug fixes in there in order to send me patches
for some netfilter compat stuff.
It's all there in the usual spot:
kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.25.git
I'm still doing build tests with various configurations on my
Niagara-2 box.
Let me know if I screwed up anything, thanks!
^ permalink raw reply
* Re: [PATCH] bridge: assign random address
From: Andrew Morton @ 2007-12-16 23:46 UTC (permalink / raw)
To: David Miller
Cc: shemminger, netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071216.154018.156758308.davem@davemloft.net>
On Sun, 16 Dec 2007 15:40:18 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Sun, 16 Dec 2007 15:34:42 -0800
>
> > Take a look at the git logs, see what most other people are doing.
>
> You're talking bucking a convention that has been used
> for all networking changes since we starting using real
> revision control.
>
> I've shown how the subject lines can be done in a way
> that both satisfies the scripts you're worried about
> and keeps the networking changes looking the way they
> have for 5+ years.
>
> What's the reason to change again?
I see no particular reason to change - it's just one of those things.
Two third of commits don't use [subsystem] and 90% don't use trailing
period. Reasons to change would be a) consistency and b) the time it takes
to occasionally fix up patches which use [subsystem] as I earlier
described.
I don't think these are terribly important, really.
^ permalink raw reply
* [PATCH 4/5] [IrDA] stir4200 fixes
From: Samuel Ortiz @ 2007-12-16 23:46 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20071216234648.774780960@sortiz.org>
[-- Attachment #1: stir4200.patch --]
[-- Type: text/plain, Size: 1741 bytes --]
The attached patch observes the stir4200 fifo size and will clear the fifo, if
the size is increasing, while it should be transmitting bytes
From: Olaf Hartmann <olaf.hartmann-kAcfE3m5wwkaBlGTGt4zH4SGEyLTKazZ@public.gmane.org>
Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
---
drivers/net/irda/stir4200.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Index: net-2.6/drivers/net/irda/stir4200.c
===================================================================
--- net-2.6.orig/drivers/net/irda/stir4200.c 2007-11-25 05:53:43.000000000 +0100
+++ net-2.6/drivers/net/irda/stir4200.c 2007-11-26 02:16:12.000000000 +0100
@@ -142,9 +142,6 @@
};
enum StirFifoCtlMask {
- FIFOCTL_EOF = 0x80,
- FIFOCTL_UNDER = 0x40,
- FIFOCTL_OVER = 0x20,
FIFOCTL_DIR = 0x10,
FIFOCTL_CLR = 0x08,
FIFOCTL_EMPTY = 0x04,
@@ -594,9 +591,10 @@
{
int err;
unsigned long count, status;
+ unsigned long prev_count = 0x1fff;
/* Read FIFO status and count */
- for(;;) {
+ for (;; prev_count = count) {
err = read_reg(stir, REG_FIFOCTL, stir->fifo_status,
FIFO_REGS_SIZE);
if (unlikely(err != FIFO_REGS_SIZE)) {
@@ -629,6 +627,10 @@
if (space >= 0 && STIR_FIFO_SIZE - 4 > space + count)
return 0;
+ /* queue confused */
+ if (prev_count < count)
+ break;
+
/* estimate transfer time for remaining chars */
msleep((count * 8000) / stir->speed);
}
--
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply
* [PATCH 3/5] [IrDA] irlmp_unregister_link needs to free lsaps
From: Samuel Ortiz @ 2007-12-16 23:46 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20071216234648.774780960@sortiz.org>
[-- Attachment #1: irlmp-delete-lsaps-hashbin.diff --]
[-- Type: text/plain, Size: 1178 bytes --]
While testing the mcs7780 based IrDA USB dongle I've stumbled upon
memory leak in irlmp_unregister_link(). Hashbin for lsaps is created in
irlmp_register_link and should probably be freed in irlmp_unregister_link().
Signed-off-by: Hinko Kocevar <hinko.kocevar-oztQky9TsV0CZtS6sZ44uQ@public.gmane.org>
Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
---
net/irda/irlmp.c | 1 +
1 file changed, 1 insertion(+)
Index: net-2.6/net/irda/irlmp.c
===================================================================
--- net-2.6.orig/net/irda/irlmp.c 2007-11-25 05:54:02.000000000 +0100
+++ net-2.6/net/irda/irlmp.c 2007-11-25 07:12:13.000000000 +0100
@@ -353,6 +353,7 @@
/* Final cleanup */
del_timer(&link->idle_timer);
link->magic = 0;
+ hashbin_delete(link->lsaps, (FREE_FUNC) __irlmp_close_lsap);
kfree(link);
}
}
--
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply
* [PATCH 2/5] [IrDA] mcs7780 needs to free allocated rx buffer
From: Samuel Ortiz @ 2007-12-16 23:46 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20071216234648.774780960@sortiz.org>
[-- Attachment #1: mcs7780-free-rx_buff.diff --]
[-- Type: text/plain, Size: 1244 bytes --]
While testing the mcs7780 based IrDA USB dongle I've stumbled upon
memory leak in mcs_net_close(). Patch below fixes it.
From: Hinko Kocevar <hinko.kocevar-oztQky9TsV0CZtS6sZ44uQ@public.gmane.org>
Signed-off-by: Hinko Kocevar <hinko.kocevar-oztQky9TsV0CZtS6sZ44uQ@public.gmane.org>
Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
---
drivers/net/irda/mcs7780.c | 2 ++
1 file changed, 2 insertions(+)
Index: net-2.6/drivers/net/irda/mcs7780.c
===================================================================
--- net-2.6.orig/drivers/net/irda/mcs7780.c 2007-11-25 05:53:43.000000000 +0100
+++ net-2.6/drivers/net/irda/mcs7780.c 2007-11-25 07:12:11.000000000 +0100
@@ -677,6 +677,8 @@
/* Stop transmit processing */
netif_stop_queue(netdev);
+ kfree_skb(mcs->rx_buff.skb);
+
/* kill and free the receive and transmit URBs */
usb_kill_urb(mcs->rx_urb);
usb_free_urb(mcs->rx_urb);
--
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply
* [PATCH 1/5] [IrDA] Race between open and disconnect in irda-usb
From: Samuel Ortiz @ 2007-12-16 23:46 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20071216234648.774780960@sortiz.org>
[-- Attachment #1: irda-usb.patch --]
[-- Type: text/plain, Size: 1944 bytes --]
It seems to me that irda_usb_net_open() must set self->netopen
under spinlock or disconnect() may fail to kill all URBs, if it is called
while an interface is opened.
From: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Signed-off-by: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
---
drivers/net/irda/irda-usb.c | 5 +++++
1 file changed, 5 insertions(+)
Index: net-2.6/drivers/net/irda/irda-usb.c
===================================================================
--- net-2.6.orig/drivers/net/irda/irda-usb.c 2007-11-25 05:53:43.000000000 +0100
+++ net-2.6/drivers/net/irda/irda-usb.c 2007-11-25 07:12:09.000000000 +0100
@@ -1168,6 +1168,7 @@
static int irda_usb_net_open(struct net_device *netdev)
{
struct irda_usb_cb *self;
+ unsigned long flags;
char hwname[16];
int i;
@@ -1177,13 +1178,16 @@
self = (struct irda_usb_cb *) netdev->priv;
IRDA_ASSERT(self != NULL, return -1;);
+ spin_lock_irqsave(&self->lock, flags);
/* Can only open the device if it's there */
if(!self->present) {
+ spin_unlock_irqrestore(&self->lock, flags);
IRDA_WARNING("%s(), device not present!\n", __FUNCTION__);
return -1;
}
if(self->needspatch) {
+ spin_unlock_irqrestore(&self->lock, flags);
IRDA_WARNING("%s(), device needs patch\n", __FUNCTION__) ;
return -EIO ;
}
@@ -1198,6 +1202,7 @@
/* To do *before* submitting Rx urbs and starting net Tx queue
* Jean II */
self->netopen = 1;
+ spin_unlock_irqrestore(&self->lock, flags);
/*
* Now that everything should be initialized properly,
--
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply
* [PATCH 0/5] [IrDA] IrDA net-2.6 fixes
From: Samuel Ortiz @ 2007-12-16 23:46 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi Dave,
Here goes a batch of 5 IrDA patches against your latest net-2.6 tree.
Cheers,
Samuel.
--
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply
* Re: [PATCH] PS3: gelic: Add wireless support for PS3
From: Jouni Malinen @ 2007-12-16 23:42 UTC (permalink / raw)
To: Dan Williams
Cc: Masakazu Mokuno, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
geoffrey.levand-mEdOJwZ7QcZBDgjK7y7TUQ, Geert Uytterhoeven
In-Reply-To: <1197846610.7302.1.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Sun, Dec 16, 2007 at 06:10:10PM -0500, Dan Williams wrote:
> On Sun, 2007-12-16 at 10:11 -0800, Jouni Malinen wrote:
> > It is a new key type regardless of whether it is PSK or passphrase. The
> > current key types (IW_AUTH_CIPHER_*) are WEP40, TKIP, CCMP, and WEP104..
> Ah, it's a different key because it's not set _during_ the 4-way
> handshake, but just sent to the fw directly and the fw handles it,
> right?
There are two cases here, but in both of them, them PMK (i.e., PSK for
WPA-Personal) needs to be set just before the 4-way handshake would
start. When using WPA-Personal, the PSK would be set just before (or as
part of) association request. When using WPA-Enterprise (WPA-EAP), the
PMK would be set after having completed IEEE 802.1X/EAP authentication
(and the driver/firmware would then take care of 4-way handshake). Both
cases will end up disabling the user space supplicant from taking part
in 4-way handshake, i.e., it will ignore EAPOL-Key frames should they be
delivered through the netdev and expects the driver/firmware to process
them.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] bridge: assign random address
From: David Miller @ 2007-12-16 23:40 UTC (permalink / raw)
To: akpm; +Cc: shemminger, netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071216153442.a11e2e1f.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Sun, 16 Dec 2007 15:34:42 -0800
> Take a look at the git logs, see what most other people are doing.
You're talking bucking a convention that has been used
for all networking changes since we starting using real
revision control.
I've shown how the subject lines can be done in a way
that both satisfies the scripts you're worried about
and keeps the networking changes looking the way they
have for 5+ years.
What's the reason to change again?
^ permalink raw reply
* Re: [PATCH] bridge: assign random address
From: Randy Dunlap @ 2007-12-16 23:37 UTC (permalink / raw)
To: David Miller
Cc: akpm, shemminger, netdev, bugme-daemon, berrange, jeff, herbert,
rjw
In-Reply-To: <20071216.152606.35263254.davem@davemloft.net>
On Sun, 16 Dec 2007 15:26:06 -0800 (PST) David Miller wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Sun, 16 Dec 2007 14:29:15 -0800
>
> > On Sun, 16 Dec 2007 13:37:17 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> >
> > > From: Stephen Hemminger <shemminger@linux-foundation.org>
> > > Date: Tue, 11 Dec 2007 15:48:35 -0800
> > >
> > > > Subject: Re: [PATCH] bridge: assign random address
> > >
> > > "bridge" should all-caps and in brackets,
> >
> > No, "bridge" should not be in []. Lots of people's patch-receiving scripts
> > assume that any text in [] is to be removed as the patch is committed. It
> > contains text which is only relevant to the particular email which carried
> > the patch. Stuff like "patch" and "4/5" and "linux-2.6.23", etc.
>
> I don't use scripts, I edit it by hand. And when I do ever use
> scripts I will make sure they accomodate "[$SUBSYSTEM]" format
> subject lines, you can be sure.
>
> And you can even make those scripts happy by doing:
>
> [Patch 1/7] [SUBSYSTEM]: Foo bar baz...
>
> And if you haven't noticed over the past few years, this is
> is the convention we've been using in the networking.
>
> I munge every one of your (and everyone else's) changelog entry
> headers this way. Without exception, every single one.
>
> So when you don't follow this convention, you make more typing
> and more work for me. The more patches I get from someone
> the more important it is for this convention to be followed.
>
> I find it very hard to believe that you haven't once looked
> at the hundreds of patches I've applied of your's and not
> noticed how I reformat everything.
I have noticed the difference in networking vs. rest-of-kernel.
Rest-of-kernel generally follows the canonical format in
Documentation/SubmittingPatches:
14) The canonical patch format
The canonical patch subject line is:
Subject: [PATCH 001/123] subsystem: summary phrase
---
~Randy
^ permalink raw reply
* Re: [PATCH] bridge: assign random address
From: Andrew Morton @ 2007-12-16 23:34 UTC (permalink / raw)
To: David Miller
Cc: shemminger, netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071216.152606.35263254.davem@davemloft.net>
On Sun, 16 Dec 2007 15:26:06 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Sun, 16 Dec 2007 14:29:15 -0800
>
> > On Sun, 16 Dec 2007 13:37:17 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> >
> > > From: Stephen Hemminger <shemminger@linux-foundation.org>
> > > Date: Tue, 11 Dec 2007 15:48:35 -0800
> > >
> > > > Subject: Re: [PATCH] bridge: assign random address
> > >
> > > "bridge" should all-caps and in brackets,
> >
> > No, "bridge" should not be in []. Lots of people's patch-receiving scripts
> > assume that any text in [] is to be removed as the patch is committed. It
> > contains text which is only relevant to the particular email which carried
> > the patch. Stuff like "patch" and "4/5" and "linux-2.6.23", etc.
>
> I don't use scripts, I edit it by hand. And when I do ever use
> scripts I will make sure they accomodate "[$SUBSYSTEM]" format
> subject lines, you can be sure.
>
> And you can even make those scripts happy by doing:
>
> [Patch 1/7] [SUBSYSTEM]: Foo bar baz...
>
> And if you haven't noticed over the past few years, this is
> is the convention we've been using in the networking.
>
> I munge every one of your (and everyone else's) changelog entry
> headers this way. Without exception, every single one.
>
> So when you don't follow this convention, you make more typing
> and more work for me. The more patches I get from someone
> the more important it is for this convention to be followed.
>
> I find it very hard to believe that you haven't once looked
> at the hundreds of patches I've applied of your's and not
> noticed how I reformat everything.
Of course I have. And I believe it to be incorrect for the reasons
which I clearly stated.
Take a look at the git logs, see what most other people are doing.
^ permalink raw reply
* Re: [PATCH] bridge: assign random address
From: David Miller @ 2007-12-16 23:26 UTC (permalink / raw)
To: akpm; +Cc: shemminger, netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071216142915.c120d25c.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Sun, 16 Dec 2007 14:29:15 -0800
> On Sun, 16 Dec 2007 13:37:17 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> > From: Stephen Hemminger <shemminger@linux-foundation.org>
> > Date: Tue, 11 Dec 2007 15:48:35 -0800
> >
> > > Subject: Re: [PATCH] bridge: assign random address
> >
> > "bridge" should all-caps and in brackets,
>
> No, "bridge" should not be in []. Lots of people's patch-receiving scripts
> assume that any text in [] is to be removed as the patch is committed. It
> contains text which is only relevant to the particular email which carried
> the patch. Stuff like "patch" and "4/5" and "linux-2.6.23", etc.
I don't use scripts, I edit it by hand. And when I do ever use
scripts I will make sure they accomodate "[$SUBSYSTEM]" format
subject lines, you can be sure.
And you can even make those scripts happy by doing:
[Patch 1/7] [SUBSYSTEM]: Foo bar baz...
And if you haven't noticed over the past few years, this is
is the convention we've been using in the networking.
I munge every one of your (and everyone else's) changelog entry
headers this way. Without exception, every single one.
So when you don't follow this convention, you make more typing
and more work for me. The more patches I get from someone
the more important it is for this convention to be followed.
I find it very hard to believe that you haven't once looked
at the hundreds of patches I've applied of your's and not
noticed how I reformat everything.
^ permalink raw reply
* Re: sockets affected by IPsec always block (2.6.23)
From: David Miller @ 2007-12-16 23:22 UTC (permalink / raw)
To: davidsen; +Cc: herbert, simon, linux-kernel, netdev
In-Reply-To: <4765AAFC.3040406@tmr.com>
From: Bill Davidsen <davidsen@tmr.com>
Date: Sun, 16 Dec 2007 17:47:24 -0500
> David Miller wrote:
> > From: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Wed, 5 Dec 2007 11:12:32 +1100
> >
> >> [INET]: Export non-blocking flags to proto connect call
> >>
> >> Previously we made connect(2) block on IPsec SA resolution. This is
> >> good in general but not desirable for non-blocking sockets.
> >>
> >> To fix this properly we'd need to implement the larval IPsec dst stuff
> >> that we talked about. For now let's just revert to the old behaviour
> >> on non-blocking sockets.
> >>
> >> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> >
> > We made an explicit decision not to do things this way.
> >
> > Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
> > setting, and this is across the board. If xfrm_larval_drop is zero,
> > non-blocking semantics do not extend to IPSEC route resolution,
> > otherwise it does.
> >
> > If he sets this sysctl to "1" as I detailed in my reply, he'll
> > get the behavior he wants.
> >
> I think you for the hint, but I would hardly call this sentence
> "detailed" in terms of being a cookbook solution to the problem.
I guess "echo '1' >/proc/sys/net/core/xfrm_larval_drop" is not
explicit enough? What more would you like me to say?
^ permalink raw reply
* Re: [PATCH] PS3: gelic: Add wireless support for PS3
From: Dan Williams @ 2007-12-16 23:10 UTC (permalink / raw)
To: Jouni Malinen
Cc: Masakazu Mokuno, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
geoffrey.levand-mEdOJwZ7QcZBDgjK7y7TUQ, Geert Uytterhoeven
In-Reply-To: <20071216181159.GP5698-mgr6C1c9aYeHXe+LvDLADg@public.gmane.org>
On Sun, 2007-12-16 at 10:11 -0800, Jouni Malinen wrote:
> On Sun, Dec 16, 2007 at 12:49:14PM -0500, Dan Williams wrote:
>
> > Yeah, I was going to propose that on Friday but got side-tracked. What
> > would require a new key type? Are there some firmwares that _only_
> > accept the WPA passphrase? Because if there aren't (PS3 accepts WPA hex
> > keys too) then the supplicant could just pass the hex key. Not quite
> > sure what you mean here with "new key type".
>
> It is a new key type regardless of whether it is PSK or passphrase. The
> current key types (IW_AUTH_CIPHER_*) are WEP40, TKIP, CCMP, and WEP104..
Ah, it's a different key because it's not set _during_ the 4-way
handshake, but just sent to the fw directly and the fw handles it,
right?
> I don't know whether there are any Linux drivers that would use WPA
> passphrase, but at least the Mac OS X driver interface seems to only use
> passphrase for WPA-Personal, so it is apparently possible to design such
> a architecture ;-). Anyway, I would be fine with just adding
> IW_AUTH_CIPHER_PMK for now (and the new capability to figure out whether
> this is needed). That PMK would be PSK for WPA-Personal, but it could
> also be used as PMK for WPA-Enterprise, so the more generic PMK name.
Sounds good.
Dan
^ permalink raw reply
* Re: [PATCH] bridge: assign random address
From: Andrew Morton @ 2007-12-16 22:29 UTC (permalink / raw)
To: David Miller
Cc: shemminger, netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071216.133717.202852113.davem@davemloft.net>
On Sun, 16 Dec 2007 13:37:17 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Tue, 11 Dec 2007 15:48:35 -0800
>
> > Subject: Re: [PATCH] bridge: assign random address
>
> "bridge" should all-caps and in brackets,
No, "bridge" should not be in []. Lots of people's patch-receiving scripts
assume that any text in [] is to be removed as the patch is committed. It
contains text which is only relevant to the particular email which carried
the patch. Stuff like "patch" and "4/5" and "linux-2.6.23", etc.
> "assign random address"
> should be capitalized like a proper english sentence with a period at
> the end.
Actually I usually remove the caps and the waste-of-space period, but
that's much less important than the brackets abuse. The bracket convention
is quite useful and I've often wondered why I need to edit the patch title
when I merge up patches from net developers ;)
^ permalink raw reply
* Re: sockets affected by IPsec always block (2.6.23)
From: Bill Davidsen @ 2007-12-16 22:47 UTC (permalink / raw)
To: David Miller; +Cc: herbert, simon, linux-kernel, netdev
In-Reply-To: <20071204.223023.262159049.davem@davemloft.net>
David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Wed, 5 Dec 2007 11:12:32 +1100
>
>> [INET]: Export non-blocking flags to proto connect call
>>
>> Previously we made connect(2) block on IPsec SA resolution. This is
>> good in general but not desirable for non-blocking sockets.
>>
>> To fix this properly we'd need to implement the larval IPsec dst stuff
>> that we talked about. For now let's just revert to the old behaviour
>> on non-blocking sockets.
>>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> We made an explicit decision not to do things this way.
>
> Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
> setting, and this is across the board. If xfrm_larval_drop is zero,
> non-blocking semantics do not extend to IPSEC route resolution,
> otherwise it does.
>
> If he sets this sysctl to "1" as I detailed in my reply, he'll
> get the behavior he wants.
>
I think you for the hint, but I would hardly call this sentence
"detailed" in terms of being a cookbook solution to the problem.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
^ permalink raw reply
* Re: Fw: [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
From: Andrew Morton @ 2007-12-16 22:23 UTC (permalink / raw)
To: Miles Lane; +Cc: Herbert Xu, netdev, linux-kernel
In-Reply-To: <a44ae5cd0712161210h4908f39coe3b5cdb346b8d632@mail.gmail.com>
On Sun, 16 Dec 2007 15:10:14 -0500 "Miles Lane" <miles.lane@gmail.com> wrote:
> On Dec 16, 2007 3:19 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > On Sat, Dec 15, 2007 at 11:56:04PM -0800, Andrew Morton wrote:
> > > On Sun, 16 Dec 2007 01:37:01 -0500 "Miles Lane" <miles.lane@gmail.com> wrote:
> > >
> > > > > On Sun, Dec 16, 2007 at 11:07:07AM +0800, Herbert Xu wrote:
> >
> > So I posted this patch after 19:00 PST on 15 Dec.
> >
> > > > Dec 15 13:44:39 syntropy kernel: #0: (&p->lock){--..}, at:
> > > > [crypto_algapi:seq_read+0x25/0x191c1] seq_read+0x25/0x26f
> > >
> > > So your kernel is still feeding garbage into lockdep.
> > >
> > > Are you really really sure that kernel had Herbert's patch applied?
> >
> > The above log message is stamped as 13:44 PST. I gotta say
> > this doesn't look good :)
>
> Yes, I did have the patch applied, but I had reenabled LOCKDEP_DEBUG.
> I just tried with the LOCKDEP_DEBUG stuff turned off, and with this
> configuration, the problem is resolved. It seems that the patch
> you made does fix the problem with /proc/net/packet. This new issue
> seems to be a different problem.
>
> So, I tried building another kernel with LOCKDEP enabled (.config attached):
> With this kernel, I got:
>
> Dec 16 11:21:39 syntropy kernel: [ 278.723108] process `tail' is
> using deprecated sysctl (syscall) net.ipv6.neigh.default.retrans_time;
> Use net.ipv6.neigh.default.retrans_time_ms instead.
> Dec 16 11:21:40 syntropy kernel: [ 279.226103] in_atomic():1, irqs_disabled():0
> Dec 16 11:21:40 syntropy kernel: [ 279.226106] no locks held by tail/6208.
> Dec 16 11:21:40 syntropy kernel: [ 279.226109] Pid: 6208, comm: tail
> Not tainted 2.6.24-rc5-mm1 #5
> Dec 16 11:21:40 syntropy kernel: [ 279.226112]
> [show_trace_log_lvl+0x12/0x25] show_trace_log_lvl+0x12/0x25
> Dec 16 11:21:40 syntropy kernel: [ 279.226121] [show_trace+0xd/0x10]
> show_trace+0xd/0x10
> Dec 16 11:21:40 syntropy kernel: [ 279.226126]
> [sbp2:dump_stack+0x57/0x17c1] dump_stack+0x57/0x5f
> Dec 16 11:21:40 syntropy kernel: [ 279.226130]
> [firewire_core:__might_sleep+0xd7/0x29a] __might_sleep+0xd7/0xde
> Dec 16 11:21:40 syntropy kernel: [ 279.226136]
> [parport:copy_to_user+0x32/0xd13f] copy_to_user+0x32/0x47
> Dec 16 11:21:40 syntropy kernel: [ 279.226141]
> [add_to_pagemap+0x29/0x56] add_to_pagemap+0x29/0x56
> Dec 16 11:21:40 syntropy kernel: [ 279.226147]
> [pagemap_pte_range+0x74/0xb1] pagemap_pte_range+0x74/0xb1
> Dec 16 11:21:40 syntropy kernel: [ 279.226151]
> [walk_page_range+0x115/0x1dc] walk_page_range+0x115/0x1dc
> Dec 16 11:21:40 syntropy kernel: [ 279.226157]
> [pagemap_read+0x154/0x1e8] pagemap_read+0x154/0x1e8
> Dec 16 11:21:40 syntropy kernel: [ 279.226161] [vfs_read+0xa2/0x11e]
> vfs_read+0xa2/0x11e
> Dec 16 11:21:40 syntropy kernel: [ 279.226166] [sys_read+0x3b/0x60]
> sys_read+0x3b/0x60
> Dec 16 11:21:40 syntropy kernel: [ 279.226170]
> [sysenter_past_esp+0x6b/0xc1] sysenter_past_esp+0x6b/0xc1
(Can you find a way to fix that wordwrapping please?)
Yes, this is a different bug - the pagemap stuff is doing userspace access
under kmap_atomic() - we discovered this a couple of days ago and Matt has
been informed.
It's relatively harmless and if that's the only problem you're observing
then I think we're OK here.
^ permalink raw reply
* Re: [PATCH net-2.6.25] Revert recent TCP work
From: David Miller @ 2007-12-16 22:21 UTC (permalink / raw)
To: ilpo.jarvinen
Cc: akpm, clg, linux-kernel, netdev, reuben-linuxkernel, kamalesh,
riel, dhaval
In-Reply-To: <Pine.LNX.4.64.0712141946060.1400@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Fri, 14 Dec 2007 22:14:29 +0200 (EET)
> Could you either drop my recent patches (+one fix to them from Herbert
> Xu == "[TCP]: Fix crash in tcp_advance_send_head"), all mine after "[TCP]:
> Abstract tp->highest_sack accessing & point to next skb" from net-2.6.25
> or just apply the revert from below and do the removal during next rebase.
> I think it could even be automated by something like this (untested):
> for i in $(cat commits | cut -d ' ' -f 1); do git-rebase --onto $i^ $i; done
> (I've attached the commits list).
I'll take care of this when I rebase the net-2.6.25 tree later
today.
Thanks Ilpo.
^ permalink raw reply
* Re: [PATCH 5/5] [IrDA] irda parameters warning fixes.
From: David Miller @ 2007-12-16 22:11 UTC (permalink / raw)
To: samuel-jcdQHdrhKHMdnm+yROfE0A
Cc: ricknu-0-oe7qfRrRQfd5oVVtFh8HQg, netdev-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20071216234933.666730217-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Mon, 17 Dec 2007 00:46:53 +0100
> This patch fixes:
> CHECK /home/kernel/src/net/irda/parameters.c
> /home/kernel/src/net/irda/parameters.c:466:2: warning: Using plain integer as NULL pointer
> /home/kernel/src/net/irda/parameters.c:520:2: warning: Using plain integer as NULL pointer
> /home/kernel/src/net/irda/parameters.c:573:2: warning: Using plain integer as NULL pointer
>
> From: Richard Knutsson <ricknu-0-oe7qfRrRQfd5oVVtFh8HQg@public.gmane.org>
> Signed-off-by: Richard Knutsson <ricknu-0-oe7qfRrRQfd5oVVtFh8HQg@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Applied.
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply
* Re: [PATCH 4/5] [IrDA] stir4200 fixes
From: David Miller @ 2007-12-16 22:09 UTC (permalink / raw)
To: samuel-jcdQHdrhKHMdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20071216234933.459646638-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Mon, 17 Dec 2007 00:46:52 +0100
> The attached patch observes the stir4200 fifo size and will clear the fifo, if
> the size is increasing, while it should be transmitting bytes
>
> From: Olaf Hartmann <olaf.hartmann-kAcfE3m5wwkaBlGTGt4zH4SGEyLTKazZ@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Applied.
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply
* Re: oops with 2.6.23.1, marvel, software raid, reiserfs and samba
From: Andrew Morton @ 2007-12-16 22:09 UTC (permalink / raw)
To: jeffunit; +Cc: linux-kernel, netdev
In-Reply-To: <20071216145557.RTSZ20056.mta15.adelphia.net@dual-xeon.jeffunit.com>
On Sun, 16 Dec 2007 06:55:51 -0800 jeffunit <jeff@jeffunit.com> wrote:
> At 03:05 AM 12/16/2007, Andrew Morton wrote:
> >On Fri, 07 Dec 2007 19:49:52 -0800 jeffunit <jeff@jeffunit.com> wrote:
> >
> > > I am running linux kernel 2.6.23.1, which I compiled.
> > > The base system was mandriva 2008.
> > >
> > > I have a dual processor pentium III 933 system.
> > > It has 3gb of ram, an intel stl-2 motherboard.
> > > It also has a promise 100 tx2 pata controller,
> > > a supermicro marvell based 8 port pcix sata controller,
> > > and a nvidia pci based video card.
> > >
> > > I have the os on a pata drive, and have made a software raid array
> > > consisting of 4 sata drives attached to the pcix sata controller.
> > > I created the array, and formatted with reiserfs 3.6
> > > I have run bonnie++ (filesystem benchmark) on the array without incident.
> > > When I use samba-3.0.25b-4.3 and copy files from a windows machine to
> > > the fileserver,
> > > every so often, the fileserver crashes or hangs. It seems to happen
> > > more often under heavy samba traffic.
> > > Enclosed is the oops from syslog.
> > > I also have a 'kernel bug' from syslog if that would be helpful.
> > >
>
> ...
>
> >
> >(Please try to avoid the wordwrapping).
(you didn't)
> >That's a networking crash. Do the oops traces which you're getting all look
> >like this one?
> >
> >Pentium III's are getting a bit old (resistive connections, drooping
> >power supplies, etc) so there's a decent chance that you're seeing
> >hardware failures here.
>
> The other trace is a kernel bug. lt is included below.
>
> It is true the hardware is a bit old, but I freshly assembled the system.
> The power supply is new, everything has been re-seated.
> I will be updating the hardware eventually, but I picked this hardware
> because it is low power (@120watts), server grade, has ecc memory,
> and has pcix- slots, which my ethernet card and 8 port sata controller need.
>
> For what it is worth, the ethernet card is an intel pro1000-mt.
>
> Dec 3 15:44:50 sata_fileserver kernel: ------------[ cut here ]------------
> Dec 3 15:44:50 sata_fileserver kernel: Kernel BUG at c0167b30
> [verbose debug info unavailable]
I'd suggest that you enable CONFIG_DEBUG_BUGVERBOSE, especially when the
system is having trouble. It's worth it.
> Dec 3 15:44:50 sata_fileserver kernel: invalid opcode: 0000 [#1]
> Dec 3 15:44:51 sata_fileserver kernel: SMP
> Dec 3 15:44:51 sata_fileserver kernel: Modules linked in:
> iptable_raw xt_comment xt_policy xt_multiport ipt_ULOG ipt_TTL
> ipt_ttl ipt_TOS ipt_tos ipt_SAME ipt_REJECT ipt_REDIRECT ipt_recent
> ipt_owner ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_iprange ipt_ECN
> ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp
> nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
> nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda
> nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp
> nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
> nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323
> nf_conntrack_ftp xt_tcpmss xt_pkttype xt_physdev xt_NFQUEUE xt_NFLOG
> xt_MARK xt_mark xt_mac xt_limit xt_length xt_helper xt_hashlimit
> ip6_tables xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY
> xt_tcpudp nfsd xt_state iptable_nat nf_nat nf_conntrack_ipv4 exportfs
> auth_rpcgss nf_conntrack iptable_mangle nfnetlink nfs lockd nfs_acl
> sunrpc iptable_filter ip_tables x_tables af_packet ipv6 snd_seq_dummy snd_
> Dec 3 15:44:51 sata_fileserver kernel: eq_oss snd_seq_midi_event
> snd_seq snd_pcm_oss snd_mixer_oss ipmi_si ipmi_msghandler binfmt_misc
> loop nls_utf8 ntfs raid456 async_xor async_memcpy async_tx xor dm_mod
> usb_storage sg sd_mod sata_mv libata scsi_mod video output thermal
> sbs processor fan container button dock battery ac floppy snd_emu10k1
> snd_rawmidi snd_ac97_codec ac97_bus snd_pcm ide_cd snd_seq_device
> snd_timer snd_page_alloc i2c_piix4 snd_util_mem ohci_hcd uhci_hcd
> i2c_core ehci_hcd snd_hwdep e1000 snd sworks_agp agpgart soundcore
> usbcore emu10k1_gp gameport tsdev evdev reiserfs ide_disk serverworks
> pdc202xx_new ide_core
> Dec 3 15:44:51 sata_fileserver kernel: CPU: 1
> Dec 3 15:44:51 sata_fileserver kernel:
> EIP: 0060:[<c0167b30>] Not tainted VLI
> Dec 3 15:44:51 sata_fileserver kernel: EFLAGS: 00210246 (2.6.23.1 #1)
> Dec 3 15:44:51 sata_fileserver kernel: EIP is at set_page_address+0x170/0x180
> Dec 3 15:44:51 sata_fileserver kernel: eax: ffbff000 ebx:
> ffbff000 ecx: c0005ffc edx: ffbff000
> Dec 3 15:44:51 sata_fileserver kernel: esi: c17d6c60 edi:
> c0443ec0 ebp: ea139c88 esp: ea139c74
> Dec 3 15:44:51 sata_fileserver kernel: ds: 007b es: 007b fs:
> 00d8 gs: 0033 ss: 0068
> Dec 3 15:44:52 sata_fileserver kernel: Process smbd (pid: 6132,
> ti=ea138000 task=f139c000 task.ti=ea138000)
> Dec 3 15:44:52 sata_fileserver kernel: Stack: ffbff000 00200286
> ffbff000 c17d6c60 3eb63163 ea139cb4 c0167ed2 ea139ca8
> Dec 3 15:44:52 sata_fileserver kernel: ea138000 804cbe2c
> 804cce2c ea139cac c0125248 c17d6c60 804cbe2c 804cce2c
> Dec 3 15:44:52 sata_fileserver kernel: ea139cc0 c01209b0
> 00000000 ea139cec f8aa86b5 0000000f 00000002 00000000
> Dec 3 15:44:52 sata_fileserver kernel: Call Trace:
> Dec 3 15:44:52 sata_fileserver kernel: [<c010542a>]
> show_trace_log_lvl+0x1a/0x30
> Dec 3 15:44:52 sata_fileserver kernel: [<c01054eb>]
> show_stack_log_lvl+0xab/0xd0
> Dec 3 15:44:52 sata_fileserver kernel: [<c01056e1>]
> show_registers+0x1d1/0x2d0
> Dec 3 15:44:52 sata_fileserver kernel: [<c01058f6>] die+0x116/0x250
> Dec 3 15:44:53 sata_fileserver kernel: [<c0105ac1>] do_trap+0x91/0xc0
> Dec 3 15:44:53 sata_fileserver kernel: [<c0105dd8>] do_invalid_op+0x88/0xa0
> Dec 3 15:44:53 sata_fileserver kernel: [<c030938a>] error_code+0x72/0x78
> Dec 3 15:44:53 sata_fileserver kernel: [<c0167ed2>] kmap_high+0x152/0x1b0
> Dec 3 15:44:53 sata_fileserver kernel: [<c01209b0>] kmap+0x50/0x80
> Dec 3 15:44:53 sata_fileserver kernel: [<f8aa86b5>]
> reiserfs_copy_from_user_to_file_region+0xa5/0xf0 [reiserfs]
> Dec 3 15:44:53 sata_fileserver kernel: [<f8aa9c06>]
> reiserfs_file_write+0x746/0x1dd0 [reiserfs]
> Dec 3 15:44:53 sata_fileserver kernel: [<c017e2c5>] vfs_write+0xb5/0x140
> Dec 3 15:44:53 sata_fileserver kernel: [<c017ea43>] sys_pwrite64+0x63/0x80
> Dec 3 15:44:54 sata_fileserver kernel: [<c01042fe>]
> sysenter_past_esp+0x6b/0xa1
This is a totally different crash and I don't think I've ever before seen a
crash in kmap()->set_page_address(). I'm suspecting hardware problems.
Can you run memtest86 on that box for a day or so?
^ 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