On Mon, Feb 25, 2013 at 03:45:07PM -0500, Mark Lord wrote:
> On 13-01-17 08:53 AM, J. Bruce Fields wrote:
> > On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
> >> On 13-01-14 11:17 AM, Mark Lord wrote:
> >>>
> >>> Here's the code with t
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
> On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
>> On 13-01-14 11:17 AM, Mark Lord wrote:
>>>
>>> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>>>
>>> /*
>>&
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
On 13-01-14 11:17 AM, Mark Lord wrote:
Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
/*
* Remove a dead transport
*/
static void svc_delete_xprt(struct svc_xprt
On Mon, Feb 25, 2013 at 03:45:07PM -0500, Mark Lord wrote:
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
On 13-01-14 11:17 AM, Mark Lord wrote:
Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
/*
* Remove
On Sunday 17 of February 2013 10:54:20 J. Bruce Fields wrote:
> On Fri, Feb 15, 2013 at 08:33:14PM +0100, Paweł Sikora wrote:
> > On Tuesday 12 of February 2013 15:52:17 J. Bruce Fields wrote:
> > > On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
> > > > Got it again, this time on a
On Fri, Feb 15, 2013 at 08:33:14PM +0100, Paweł Sikora wrote:
> On Tuesday 12 of February 2013 15:52:17 J. Bruce Fields wrote:
> > On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
> > > Got it again, this time on a different system
> > > running mostly the same software.
> >
> > Mark,
On Sunday 17 of February 2013 10:54:20 J. Bruce Fields wrote:
On Fri, Feb 15, 2013 at 08:33:14PM +0100, Paweł Sikora wrote:
On Tuesday 12 of February 2013 15:52:17 J. Bruce Fields wrote:
On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
Got it again, this time on a different
On Fri, Feb 15, 2013 at 02:42:08PM -0500, Tom Horsley wrote:
> On Fri, 15 Feb 2013 14:22:29 -0500
> J. Bruce Fields wrote:
>
> > Any more reports positive or negative welcome.
>
> Well, I don't have the time or energy to try patches on my
> system at work, but these seem to be concerned with
On Fri, 15 Feb 2013 14:22:29 -0500
J. Bruce Fields wrote:
> Any more reports positive or negative welcome.
Well, I don't have the time or energy to try patches on my
system at work, but these seem to be concerned with terminating
an NFS connection. My aborts all happen at boot when it
is trying
On Tuesday 12 of February 2013 15:52:17 J. Bruce Fields wrote:
> On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
> > Got it again, this time on a different system
> > running mostly the same software.
>
> Mark, Paweł, Tom, could any of you confirm whether this helps?
with this patch i
On Wed, Feb 13, 2013 at 10:00:58AM -0500, Mark Lord wrote:
> On 13-02-12 03:52 PM, J. Bruce Fields wrote:
> > On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
> >> Got it again, this time on a different system
> >> running mostly the same software.
> >
> > Mark, Paweł, Tom, could any of
On Wed, Feb 13, 2013 at 10:00:58AM -0500, Mark Lord wrote:
On 13-02-12 03:52 PM, J. Bruce Fields wrote:
On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
Got it again, this time on a different system
running mostly the same software.
Mark, Paweł, Tom, could any of you confirm
On Tuesday 12 of February 2013 15:52:17 J. Bruce Fields wrote:
On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
Got it again, this time on a different system
running mostly the same software.
Mark, Paweł, Tom, could any of you confirm whether this helps?
with this patch i can
On Fri, 15 Feb 2013 14:22:29 -0500
J. Bruce Fields wrote:
Any more reports positive or negative welcome.
Well, I don't have the time or energy to try patches on my
system at work, but these seem to be concerned with terminating
an NFS connection. My aborts all happen at boot when it
is trying
On Fri, Feb 15, 2013 at 02:42:08PM -0500, Tom Horsley wrote:
On Fri, 15 Feb 2013 14:22:29 -0500
J. Bruce Fields wrote:
Any more reports positive or negative welcome.
Well, I don't have the time or energy to try patches on my
system at work, but these seem to be concerned with terminating
On 13-02-12 03:52 PM, J. Bruce Fields wrote:
> On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
>> Got it again, this time on a different system
>> running mostly the same software.
>
> Mark, Paweł, Tom, could any of you confirm whether this helps?
..
No, I cannot confirm one way or
On 13-02-12 03:52 PM, J. Bruce Fields wrote:
On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
Got it again, this time on a different system
running mostly the same software.
Mark, Paweł, Tom, could any of you confirm whether this helps?
..
No, I cannot confirm one way or the
On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
> Got it again, this time on a different system
> running mostly the same software.
Mark, Paweł, Tom, could any of you confirm whether this helps?
--b.
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index dbf12ac..2d34b6b 100644
---
On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
Got it again, this time on a different system
running mostly the same software.
Mark, Paweł, Tom, could any of you confirm whether this helps?
--b.
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index dbf12ac..2d34b6b 100644
---
On Thu, Feb 07, 2013 at 07:56:51AM -0500, Tom Horsley wrote:
> I noticed some previous messages with this subject, but the
> walkback I'm getting doesn't match exactly the ones shown
> in the threads I saw, so I figured I'd send this in.
>
> This happens on both my Fedora 18 and Fedora 17
On Thu, Feb 07, 2013 at 07:56:51AM -0500, Tom Horsley wrote:
I noticed some previous messages with this subject, but the
walkback I'm getting doesn't match exactly the ones shown
in the threads I saw, so I figured I'd send this in.
This happens on both my Fedora 18 and Fedora 17 partitions
I noticed some previous messages with this subject, but the
walkback I'm getting doesn't match exactly the ones shown
in the threads I saw, so I figured I'd send this in.
This happens on both my Fedora 18 and Fedora 17 partitions
when mounting filesystems from very old servers that
need the
I noticed some previous messages with this subject, but the
walkback I'm getting doesn't match exactly the ones shown
in the threads I saw, so I figured I'd send this in.
This happens on both my Fedora 18 and Fedora 17 partitions
when mounting filesystems from very old servers that
need the
18.01.2013 19:56, J. Bruce Fields пишет:
On Fri, Jan 18, 2013 at 10:48:02AM -0500, Mark Lord wrote:
On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
You have more than one NFS mount in different network namespaces, haven't you?
No, I don't (knowingly) use (multiple) namespaces at all.
18.01.2013 19:56, J. Bruce Fields пишет:
On Fri, Jan 18, 2013 at 10:48:02AM -0500, Mark Lord wrote:
On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
You have more than one NFS mount in different network namespaces, haven't you?
No, I don't (knowingly) use (multiple) namespaces at all.
[ cut here ]
[ 3342.841527] kernel BUG at net/sunrpc/svc_xprt.c:921!
[ 3342.841547] invalid opcode: [#1] PREEMPT SMP
[ 3342.841579] Modules linked in: nfsv3 nfsv4 sha1_generic ppp_mppe ppp_async
crc_ccitt ppp_generic
slhc btusb hid_generic arc4 usbhid hid b43 coretemp kvm_intel kvm mac80211
]
[ 3342.841527] kernel BUG at net/sunrpc/svc_xprt.c:921!
[ 3342.841547] invalid opcode: [#1] PREEMPT SMP
[ 3342.841579] Modules linked in: nfsv3 nfsv4 sha1_generic ppp_mppe ppp_async
crc_ccitt ppp_generic
slhc btusb hid_generic arc4 usbhid hid b43 coretemp kvm_intel kvm mac80211
cfg80211
On Fri, Jan 18, 2013 at 10:48:02AM -0500, Mark Lord wrote:
> On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
> >
> > You have more than one NFS mount in different network namespaces, haven't
> > you?
> >
>
> No, I don't (knowingly) use (multiple) namespaces at all.
Right, I don't think that's
On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
>
> You have more than one NFS mount in different network namespaces, haven't you?
>
No, I don't (knowingly) use (multiple) namespaces at all.
Usually I disable them in the kernel .config,
though it appears the currently running kernel has this:
On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
You have more than one NFS mount in different network namespaces, haven't you?
No, I don't (knowingly) use (multiple) namespaces at all.
Usually I disable them in the kernel .config,
though it appears the currently running kernel has this:
On Fri, Jan 18, 2013 at 10:48:02AM -0500, Mark Lord wrote:
On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
You have more than one NFS mount in different network namespaces, haven't
you?
No, I don't (knowingly) use (multiple) namespaces at all.
Right, I don't think that's necessary.
18.01.2013 03:41, Mark Lord пишет:
On 13-01-17 08:24 AM, Stanislav Kinsbursky wrote:
..
This looks like the old issue I was trying to fix with "SUNRPC: protect service
sockets lists during
per-net shutdown".
So, here is the problem as I see it: there is a transport, which is processed
by
On 13-01-17 08:24 AM, Stanislav Kinsbursky wrote:
..
> This looks like the old issue I was trying to fix with "SUNRPC: protect
> service sockets lists during
> per-net shutdown".
> So, here is the problem as I see it: there is a transport, which is processed
> by service thread and
> it's
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
> On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
>> On 13-01-14 11:17 AM, Mark Lord wrote:
>>>
>>> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>>>
>>> /*
>>&
On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
> On 13-01-14 11:17 AM, Mark Lord wrote:
> >
> > Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
> >
> > /*
> > * Remove a dead transport
> > */
> > stat
earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[] ? svc_recv+0xcc/0x338 [sunrpc]
[] ? nfs_callback_authenticate+0x20/0x20 [nfsv4]
[] ? nfs4_callback_svc+0x1d/0x3c [nfsv4]
[] ? kthread+0x81/0x89
[] ? kthread_freezable_should_stop+0x36/0x36
On 13-01-14 11:17 AM, Mark Lord wrote:
>
> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>
> /*
> * Remove a dead transport
> */
> static void svc_delete_xprt(struct svc_xprt *xprt)
> {
> struct svc_serv *serv = xprt->xpt_server;
>
t;There's this one, posted earlier in the BUG report:
> >
> >kernel BUG at net/sunrpc/svc_xprt.c:921!
> >Call Trace:
> > [] ? svc_recv+0xcc/0x338 [sunrpc]
> > [] ? nfs_callback_authenticate+0x20/0x20 [nfsv4]
> > [] ? nfs4_callback_svc+0x1d/0x3c [nfs
BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[a016a56a] ? svc_recv+0xcc/0x338 [sunrpc]
[a0318bfc] ? nfs_callback_authenticate+0x20/0x20 [nfsv4]
[a0318c19] ? nfs4_callback_svc+0x1d/0x3c [nfsv4]
[810407e6] ? kthread+0x81/0x89
[81040765
On 13-01-14 11:17 AM, Mark Lord wrote:
Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
/*
* Remove a dead transport
*/
static void svc_delete_xprt(struct svc_xprt *xprt)
{
struct svc_serv *serv = xprt-xpt_server;
struct svc_deferred_req *dr
earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[a016a56a] ? svc_recv+0xcc/0x338 [sunrpc]
[a0318bfc] ? nfs_callback_authenticate+0x20/0x20 [nfsv4]
[a0318c19] ? nfs4_callback_svc+0x1d/0x3c [nfsv4]
[810407e6] ? kthread+0x81/0x89
On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
On 13-01-14 11:17 AM, Mark Lord wrote:
Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
/*
* Remove a dead transport
*/
static void svc_delete_xprt(struct svc_xprt *xprt)
{
struct svc_serv
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
On 13-01-14 11:17 AM, Mark Lord wrote:
Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
/*
* Remove a dead transport
*/
static void svc_delete_xprt(struct svc_xprt
On 13-01-17 08:24 AM, Stanislav Kinsbursky wrote:
..
This looks like the old issue I was trying to fix with SUNRPC: protect
service sockets lists during
per-net shutdown.
So, here is the problem as I see it: there is a transport, which is processed
by service thread and
it's processing is
18.01.2013 03:41, Mark Lord пишет:
On 13-01-17 08:24 AM, Stanislav Kinsbursky wrote:
..
This looks like the old issue I was trying to fix with SUNRPC: protect service
sockets lists during
per-net shutdown.
So, here is the problem as I see it: there is a transport, which is processed
by
17.01.2013 02:51, Mark Lord пишет:
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[] ? svc_recv+0xcc/0x338
On 13-01-16 05:51 PM, Mark Lord wrote:
> On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
>>
>> Mark, could you provide any call traces?
>
> Call traces from where/what?
> There's this one, posted earlier in the BUG report:
>
> kernel BUG at net/sunrp
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
>
> Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[] ? svc_recv+0xcc/0x338 [sunrpc]
[] ? nfs_callback_authen
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[a016a56a] ? svc_recv+0xcc/0x338 [sunrpc
On 13-01-16 05:51 PM, Mark Lord wrote:
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[a016a56a
17.01.2013 02:51, Mark Lord пишет:
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[a016a56a] ? svc_recv
16.01.2013 00:56, J. Bruce Fields пишет:
On Mon, Jan 14, 2013 at 11:16:00PM -0500, Mark Lord wrote:
On 13-01-14 03:37 PM, J. Bruce Fields wrote:
Thanks for the report.
On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
On Mon, Jan 14, 2013 at 11:16:00PM -0500, Mark Lord wrote:
> On 13-01-14 03:37 PM, J. Bruce Fields wrote:
> > Thanks for the report.
> >
> > On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
> >> Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
> >
> > It's acting as an
16.01.2013 00:56, J. Bruce Fields пишет:
On Mon, Jan 14, 2013 at 11:16:00PM -0500, Mark Lord wrote:
On 13-01-14 03:37 PM, J. Bruce Fields wrote:
Thanks for the report.
On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
On Mon, Jan 14, 2013 at 11:16:00PM -0500, Mark Lord wrote:
On 13-01-14 03:37 PM, J. Bruce Fields wrote:
Thanks for the report.
On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
It's acting as an NFS client,
On 13-01-14 03:37 PM, J. Bruce Fields wrote:
> Thanks for the report.
>
> On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
>> Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
>
> It's acting as an NFS client, right?
Client and server, with other Linux boxes all running
tached.
Is this easy to reproduce?
--b.
>
> [ cut here ]----
> kernel BUG at net/sunrpc/svc_xprt.c:921!
> invalid opcode: [#1] SMP
> Modules linked in: nfsv4 xt_state xt_tcpudp xt_recent xt_LOG xt_limit
> iptable_mangle iptable_nat
> nf_conntrack_ipv4 nf_def
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
is getting these BUG complaints. The .config file is gzip'd/attached.
[ cut here ]
kernel BUG at net/sunrpc/svc_xprt.c:921!
invalid opcode: [#1] SMP
Modules linked in: nfsv4 xt_state xt_tcpudp xt_recent
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
is getting these BUG complaints. The .config file is gzip'd/attached.
[ cut here ]
kernel BUG at net/sunrpc/svc_xprt.c:921!
invalid opcode: [#1] SMP
Modules linked in: nfsv4 xt_state xt_tcpudp xt_recent
.
Is this easy to reproduce?
--b.
[ cut here ]
kernel BUG at net/sunrpc/svc_xprt.c:921!
invalid opcode: [#1] SMP
Modules linked in: nfsv4 xt_state xt_tcpudp xt_recent xt_LOG xt_limit
iptable_mangle iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
On 13-01-14 03:37 PM, J. Bruce Fields wrote:
Thanks for the report.
On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
It's acting as an NFS client, right?
Client and server, with other Linux boxes all running
61 matches
Mail list logo
