* 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
* Re: [PATCH 3/5] [IrDA] irlmp_unregister_link needs to free lsaps
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.289314655-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Mon, 17 Dec 2007 00:46:51 +0100
> 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>
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 2/5] [IrDA] mcs7780 needs to free allocated rx buffer
From: David Miller @ 2007-12-16 22:08 UTC (permalink / raw)
To: samuel-jcdQHdrhKHMdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20071216234933.121032143-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Mon, 17 Dec 2007 00:46:50 +0100
> 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>
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 1/5] [IrDA] Race between open and disconnect in irda-usb
From: David Miller @ 2007-12-16 22:07 UTC (permalink / raw)
To: samuel; +Cc: netdev, irda-users, oneukum
In-Reply-To: <20071216234932.929834588@sortiz.org>
From: Samuel Ortiz <samuel@sortiz.org>
Date: Mon, 17 Dec 2007 00:46:49 +0100
> 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@suse.de>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
> Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2.6.25] SCTP: Use crc32c library for checksum calculations.
From: David Miller @ 2007-12-16 22:06 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <1197789045-3077-1-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Sun, 16 Dec 2007 02:10:45 -0500
> The crc32c library used an identical table and algorithm
> as SCTP. Switch to using the library instead of carrying
> our own table. Using crypto layer proved to have too
> much overhead compared to using the library directly.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.25, thanks Vlad.
^ permalink raw reply
* Re: [PATCH] SCTP: Flush fragment queue when exiting partial delivery
From: David Miller @ 2007-12-16 22:05 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <1197788916-2969-1-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Sun, 16 Dec 2007 02:08:36 -0500
> At the end of partial delivery, we may have complete messages
> sitting on the fragment queue. These messages are stuck there
> until a new fragment arrives. This can comletely stall a
> given association. When clearing partial delivery state, flush
> any complete messages from the fragment queue and send them on
> their way up.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6, thanks Vlad!
^ permalink raw reply
* Re: [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
From: David Miller @ 2007-12-16 22:04 UTC (permalink / raw)
To: herbert; +Cc: m.kozlowski, akpm, jgarzik, linux-kernel, netdev, den, xemul
In-Reply-To: <20071216034119.GA1491@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 16 Dec 2007 11:41:20 +0800
> [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
>
> The seq_open_net patch changed the meaning of seq->private.
> Unfortunately it missed two spots in AF_PACKET, which still
> used the old way of dereferencing seq->private, thus causing
> weird and wonderful crashes when reading /proc/net/packet.
>
> This patch fixes them.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to net-2.6.25, thanks Herbert.
^ permalink raw reply
* Re: [PATCH take2] [AX25] circular locking with AX25 connection timeout
From: David Miller @ 2007-12-16 22:02 UTC (permalink / raw)
To: jarkao2; +Cc: pidoux, ralf, netdev
In-Reply-To: <20071215101810.GA3143@ami.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Sat, 15 Dec 2007 11:18:10 +0100
> On Fri, Dec 14, 2007 at 11:29:28PM +0100, Bernard Pidoux wrote:
> > Hi,
> >
> > This patch cancels a circular locking conflict that appeared with a timeout
> > of an AX25 connection.
> >
> > signed off by Jarek Poplawski
>
> One spurious space less here, and maybe a few more words to the changelog.
Patch applied, thanks Jarek.
^ permalink raw reply
* Re: [PATCH] [IPV4]: Make tcp_input_metrics() get minimum RTO via tcp_rto_min()
From: David Miller @ 2007-12-16 22:00 UTC (permalink / raw)
To: satoru.satoh; +Cc: netdev
In-Reply-To: <d72b7ace0712141844x6392ceb6y5cb39d9a81f950e6@mail.gmail.com>
From: "Satoru SATOH" <satoru.satoh@gmail.com>
Date: Sat, 15 Dec 2007 11:44:46 +0900
> tcp_input_metrics() refers to the built-time constant TCP_RTO_MIN
> regardless of configured minimum RTO with iproute2.
>
> The following fixes that.
>
>
> Signed-off-by: Satoru SATOH <satoru.satoh@gmail.com>
Thanks for this bug fix, patch applied.
^ permalink raw reply
* Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
From: David Miller @ 2007-12-16 21:59 UTC (permalink / raw)
To: akpm; +Cc: miles.lane, linux-kernel, netdev, mingo, a.p.zijlstra
In-Reply-To: <20071214153633.5d8f609a.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, 14 Dec 2007 15:36:33 -0800
> The networking bug looks to be around sock_i_ino()'s taking of
> sk_callback_lock with softirq's enabled. Perhaps this will fix it.
One should be suspicious of any case where write_lock is performed
on sk->sk_callback_lock in softint context. And that's the only
way this can trigger, so this patch is wrong.
Generally, sock_orphan() and sock_graft() are the only primary
places where sk->sk_callback_lock is acquired as a writer. And
these should be invoked only from process context.
Perhaps there is some exception to this in some specialized layer such
as SUNRPC, which are the only other spots I see potentially doing
sk->sk_callback_lock write acquires in softint context, which as
stated should not be done.
OCFS2 and ISCSI seem to be following the rules in it's write lock
calls on this lock.
^ permalink raw reply
* Re: [PATCH net-2.6.25 8/8] Remove unused IPV4TYPE macros
From: David Miller @ 2007-12-16 21:48 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel
In-Reply-To: <1197589141-7020-8-git-send-email-joe@perches.com>
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.
^ permalink raw reply
* Re: [PATCH net-2.6.25 7/8] drivers/infiniband: Use ipv4_is_<type>
From: David Miller @ 2007-12-16 21:47 UTC (permalink / raw)
To: joe; +Cc: netdev, hal.rosenstock, rolandd, mshefty, general
In-Reply-To: <1197589141-7020-7-git-send-email-joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 13 Dec 2007 15:39:00 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 6/8] sctp: Use ipv4_is_<type>
From: David Miller @ 2007-12-16 21:47 UTC (permalink / raw)
To: joe; +Cc: netdev, sri, vladislav.yasevich, lksctp-developers
In-Reply-To: <1197589141-7020-6-git-send-email-joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 13 Dec 2007 15:38:59 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 5/8] net/netfilter: Use ipv4_is_<type>
From: David Miller @ 2007-12-16 21:46 UTC (permalink / raw)
To: joe; +Cc: netdev, kaber, coreteam, netfilter-devel, netfilter
In-Reply-To: <1197589141-7020-5-git-send-email-joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 13 Dec 2007 15:38:58 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 4/8] net/ipv4: Use ipv4_is_<type>
From: David Miller @ 2007-12-16 21:45 UTC (permalink / raw)
To: joe; +Cc: netdev, pekkas, kuznet, yoshfuji, jmorris, kaber
In-Reply-To: <1197589141-7020-4-git-send-email-joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 13 Dec 2007 15:38:57 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 3/8] net/core: Use ipv4_is_<type>
From: David Miller @ 2007-12-16 21:44 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1197589141-7020-3-git-send-email-joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 13 Dec 2007 15:38:56 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 2/8] include/net: Use ipv4_is_<type>
From: David Miller @ 2007-12-16 21:43 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1197589141-7020-2-git-send-email-joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 13 Dec 2007 15:38:55 -0800
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 1/8] Create ipv4_is_<type>(__be32 addr) functions
From: David Miller @ 2007-12-16 21:42 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel
In-Reply-To: <1197589141-7020-1-git-send-email-joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 13 Dec 2007 15:38:54 -0800
> Change IPV4 specific macros LOOPBACK MULTICAST LOCAL_MCAST BADCLASS and ZERONET
> macros to inline functions ipv4_is_<type>(__be32 addr)
>
> Adds type safety and arguably some readability.
>
> Changes since last submission:
>
> Removed ipv4_addr_octets function
> Used hex constants
> Converted recently added rfc3330 macros
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] tulip: napi full quantum bug
From: David Miller @ 2007-12-16 21:40 UTC (permalink / raw)
To: shemminger; +Cc: kristjan.ugrin, jgarzik, netdev
In-Reply-To: <20071213093545.436b8f8e@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Thu, 13 Dec 2007 09:35:45 -0800
> This should fix the kernel warn/oops reported while routing.
>
> The tulip driver has a fencepost bug with new NAPI in 2.6.24
> It has an off by one bug if a full quantum is reached.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Acked-by: David S. Miller <davem@davemloft.net>
Jeff, please apply if you haven't already.
> --- a/drivers/net/tulip/interrupt.c 2007-12-13 09:20:27.000000000 -0800
> +++ b/drivers/net/tulip/interrupt.c 2007-12-13 09:23:34.000000000 -0800
> @@ -151,7 +151,8 @@ int tulip_poll(struct napi_struct *napi,
> if (tulip_debug > 5)
> printk(KERN_DEBUG "%s: In tulip_rx(), entry %d %8.8x.\n",
> dev->name, entry, status);
> - if (work_done++ >= budget)
> +
> + if (++work_done >= budget)
> goto not_done;
>
> if ((status & 0x38008300) != 0x0300) {
^ permalink raw reply
* Re: [PATCH] IPv6: Fix the return value of ipv6_getsockopt
From: David Miller @ 2007-12-16 21:40 UTC (permalink / raw)
To: yjwei; +Cc: netdev
In-Reply-To: <4760C6A0.4000300@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Thu, 13 Dec 2007 14:44:00 +0900
> If CONFIG_NETFILTER if not selected when compile the kernel source code,
> ipv6_getsockopt will returen an EINVAL error if optname is not supported by
> the kernel. But if CONFIG_NETFILTER is selected, ENOPROTOOPT error will
> be return.
> This patch fix to always return ENOPROTOOPT error if optname argument of
> ipv6_getsockopt is not supported by the kernel.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Patch applied to net-2.6, thanks for this bug fix.
^ permalink raw reply
* Re: [RFT] tehuti: napi fix
From: David Miller @ 2007-12-16 21:38 UTC (permalink / raw)
To: shemminger; +Cc: joonwpark81, netdev, jgarzik, baum, andy
In-Reply-To: <20071212135852.3369c820@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 12 Dec 2007 13:58:52 -0800
> This should fix the tehuti napi fence post problems by getting
> rid of priv->napi_stop, and setting weight to 32 (like other 10G).
>
> Also, used the wierd entry/exit macro's like rest of driver.
It fixes the fench-post problem, but like the comments you
removed explain:
> - /* from time to time we exit to let NAPI layer release
> - * device lock and allow waiting tasks (eg rmmod) to advance) */
> - priv->napi_stop = 0;
> -
We now hang on rmmod during constant packet load.
This change just trades one bug for another, we have to
get the device close issue sorted out before we can go
around removing these things.
^ permalink raw reply
* Re: [PATCH] bridge: assign random address
From: David Miller @ 2007-12-16 21:37 UTC (permalink / raw)
To: shemminger; +Cc: akpm, netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071211154835.75ace6bc@freepuppy.rosehill>
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, "assign random address"
should be capitalized like a proper english sentence with a period at
the end.
These are changelog messages for a mature and professional software
project, not random comments amongst teenagers on an IRC channel.
> Assigning a valid random address to bridge device solves problems
> when bridge device is brought up before adding real device to bridge.
> When the first real device is added to the bridge, it's address
> will overide the bridges random address.
>
> Note: any device added to a bridge must already have a valid
> ethernet address.
> br_add_if -> br_fdb_insert -> fdb_insert -> is_valid_ether_addr
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
From: David Miller @ 2007-12-16 21:35 UTC (permalink / raw)
To: shemminger
Cc: joonwpark81, jesse.brandeburg, netdev, linux-kernel, herbert,
auke-jan.h.kok
In-Reply-To: <20071211154222.0aec68fc@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue, 11 Dec 2007 15:42:22 -0800
> Perhaps we should change the warning to identify the guilty device.
Applied.
Stephen, you often don't supply a proper signoff line
for one-off changes like this and I find it very irritating.
It doesn't cost you anything to hit one or two keys in your
outgoing email editor to include the signoff line.
So please do so, or I'll silently drop patches without them
in the future.
Thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25 7/7] Switch users of ipv4_devconf(_all) to use the pernet one
From: David Miller @ 2007-12-16 21:32 UTC (permalink / raw)
To: xemul; +Cc: netdev, containers, devel
In-Reply-To: <475ED0AA.5080106@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 11 Dec 2007 21:02:18 +0300
> These are scattered over the code, but almost all the
> "critical" places already have the proper struct net
> at hand except for snmp proc showing function and routing
> rtnl handler.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 6/7] Switch users of ipv4_devconf_dflt to use the pernet one
From: David Miller @ 2007-12-16 21:32 UTC (permalink / raw)
To: xemul; +Cc: netdev, containers, devel
In-Reply-To: <475ED01E.5020505@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 11 Dec 2007 20:59:58 +0300
> They are all collected in the net/ipv4/devinet.c file and
> mostly use the IPV4_DEVCONF_DFLT macro.
>
> So I add the net parameter to it and patch users accordingly.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ 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