On Fri, Nov 02, 2007 at 08:56:55PM +0800, Fengguang Wu wrote:
> > > ---
> > > fs/reiserfs/stree.c |3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > --- linux-2.6.24-git17.orig/fs/reiserfs/stree.c
> > > +++ linux-2.6.24-git17/fs/reiserfs/stree.c
> > > @@ -1458,9 +1458,6 @@ static void
On Fri, Nov 02, 2007 at 08:56:55PM +0800, Fengguang Wu wrote:
---
fs/reiserfs/stree.c |3 ---
1 file changed, 3 deletions(-)
--- linux-2.6.24-git17.orig/fs/reiserfs/stree.c
+++ linux-2.6.24-git17/fs/reiserfs/stree.c
@@ -1458,9 +1458,6 @@ static void unmap_buffers(struct
On Fri, Nov 02, 2007 at 09:33:21AM +0800, Fengguang Wu wrote:
> > I will try that with a USB disk - I hope that won't make a difference.
>
> Thank you. I guess a reiserfs on loop file would also be OK.
>
> > > btw, what's the exact kernel version you are running?
> >
> > I noticed it with the
On Thu, Nov 01, 2007 at 09:03:33PM +0800, Fengguang Wu wrote:
> Or will the system or fs size/age make any difference? If you happen
> to have a spare/swap partition, could you make a new reiserfs and
> mount it and copy several less-than-4KB files into it and wait for 30s
> and see what happen to
On Thu, Nov 01, 2007 at 03:15:32PM +0800, Fengguang Wu wrote:
> On Wed, Oct 31, 2007 at 12:53:18PM -0500, Florin Iucha wrote:
> > This patch does not fix anything for me. Even such light use of the
> > reiserfs filesystem as pulling the linux-2.6 git tree updates caused
> >
On Thu, Nov 01, 2007 at 03:15:32PM +0800, Fengguang Wu wrote:
On Wed, Oct 31, 2007 at 12:53:18PM -0500, Florin Iucha wrote:
This patch does not fix anything for me. Even such light use of the
reiserfs filesystem as pulling the linux-2.6 git tree updates caused
one CPU to go to 75% iowait
On Thu, Nov 01, 2007 at 09:03:33PM +0800, Fengguang Wu wrote:
Or will the system or fs size/age make any difference? If you happen
to have a spare/swap partition, could you make a new reiserfs and
mount it and copy several less-than-4KB files into it and wait for 30s
and see what happen to
On Fri, Nov 02, 2007 at 09:33:21AM +0800, Fengguang Wu wrote:
I will try that with a USB disk - I hope that won't make a difference.
Thank you. I guess a reiserfs on loop file would also be OK.
btw, what's the exact kernel version you are running?
I noticed it with the kernel in the
On Wed, Oct 31, 2007 at 07:16:06AM -0500, Florin Iucha wrote:
> On Wed, Oct 31, 2007 at 02:53:25PM +0800, Fengguang Wu wrote:
> > On Tue, Oct 30, 2007 at 10:52:45PM -0500, Florin Iucha wrote:
> > > On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
> > >
On Wed, Oct 31, 2007 at 02:53:25PM +0800, Fengguang Wu wrote:
> On Tue, Oct 30, 2007 at 10:52:45PM -0500, Florin Iucha wrote:
> > On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
> > > I have added the patches and started a linux kernel compilation, and
>
On Wed, Oct 31, 2007 at 02:53:25PM +0800, Fengguang Wu wrote:
On Tue, Oct 30, 2007 at 10:52:45PM -0500, Florin Iucha wrote:
On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
I have added the patches and started a linux kernel compilation, and
something really interesting
On Wed, Oct 31, 2007 at 07:16:06AM -0500, Florin Iucha wrote:
On Wed, Oct 31, 2007 at 02:53:25PM +0800, Fengguang Wu wrote:
On Tue, Oct 30, 2007 at 10:52:45PM -0500, Florin Iucha wrote:
On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
I have added the patches and started
On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
> I have added the patches and started a linux kernel compilation, and
> something really interesting happens. I run the build with the
> equivalent of "make -j3" and in a separate console I am watching th
On Tue, Oct 30, 2007 at 07:49:41PM +0800, Fengguang Wu wrote:
> > > It could be triggered by the more aggressive writeback behavior - the
> > > new code will keep on retrying as long as there are dirty inodes pending.
> > >
> > > Florin, would you try the attached patches against 2.6.24-git?
> >
On Tue, Oct 30, 2007 at 07:49:41PM +0800, Fengguang Wu wrote:
> On Tue, Oct 30, 2007 at 06:42:50AM -0500, Florin Iucha wrote:
> > On Tue, Oct 30, 2007 at 03:54:03PM +0800, Fengguang Wu wrote:
> > > It could be triggered by the more aggressive writeback behavior - the
> &
On Tue, Oct 30, 2007 at 03:54:03PM +0800, Fengguang Wu wrote:
> On Sun, Oct 28, 2007 at 10:24:29AM -0500, Florin Iucha wrote:
> [...]
> >[ 3687.824468]
> >[ 3687.824470] pdflush D 805787c0 0 248 2
> >[ 3687.824473] 81000
On Tue, Oct 30, 2007 at 07:49:41PM +0800, Fengguang Wu wrote:
On Tue, Oct 30, 2007 at 06:42:50AM -0500, Florin Iucha wrote:
On Tue, Oct 30, 2007 at 03:54:03PM +0800, Fengguang Wu wrote:
It could be triggered by the more aggressive writeback behavior - the
new code will keep on retrying
On Tue, Oct 30, 2007 at 03:54:03PM +0800, Fengguang Wu wrote:
On Sun, Oct 28, 2007 at 10:24:29AM -0500, Florin Iucha wrote:
[...]
[ 3687.824468]
[ 3687.824470] pdflush D 805787c0 0 248 2
[ 3687.824473] 810006001d90 0046
On Tue, Oct 30, 2007 at 07:49:41PM +0800, Fengguang Wu wrote:
It could be triggered by the more aggressive writeback behavior - the
new code will keep on retrying as long as there are dirty inodes pending.
Florin, would you try the attached patches against 2.6.24-git?
They may
On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
I have added the patches and started a linux kernel compilation, and
something really interesting happens. I run the build with the
equivalent of make -j3 and in a separate console I am watching the
build with 'top'. The build
On Mon, Oct 29, 2007 at 02:43:32PM -0400, Trond Myklebust wrote:
>
> On Mon, 2007-10-29 at 10:01 -0500, Florin Iucha wrote:
> > On Mon, Oct 29, 2007 at 09:46:59AM -0400, Trond Myklebust wrote:
> > > > What could cause this? I use NFS4 to automount the home directories
On Mon, Oct 29, 2007 at 09:46:59AM -0400, Trond Myklebust wrote:
> > What could cause this? I use NFS4 to automount the home directories
> > from a Solaris10 server, and this box found a few bugs in the NFS4
> > code (fixed in the 2.6.22 kernel).
> >
> > I'll try running with 2.6.23 again for a
On Mon, Oct 29, 2007 at 09:46:59AM -0400, Trond Myklebust wrote:
What could cause this? I use NFS4 to automount the home directories
from a Solaris10 server, and this box found a few bugs in the NFS4
code (fixed in the 2.6.22 kernel).
I'll try running with 2.6.23 again for a few days,
On Mon, Oct 29, 2007 at 02:43:32PM -0400, Trond Myklebust wrote:
On Mon, 2007-10-29 at 10:01 -0500, Florin Iucha wrote:
On Mon, Oct 29, 2007 at 09:46:59AM -0400, Trond Myklebust wrote:
What could cause this? I use NFS4 to automount the home directories
from a Solaris10 server
Hello,
For a week or two I started noticing that some time after I'm logged
in, my keyboard input becomes a bit staggering, there is a small delay
between the keypress and the actual character appearing in the
terminal. This is on a AMD Athlon x2 4200+ with 2 GB RAM and just a
gnome-terminal
Hello,
For a week or two I started noticing that some time after I'm logged
in, my keyboard input becomes a bit staggering, there is a small delay
between the keypress and the actual character appearing in the
terminal. This is on a AMD Athlon x2 4200+ with 2 GB RAM and just a
gnome-terminal
On Tue, Oct 23, 2007 at 07:46:37AM -0500, Florin Iucha wrote:
> [ 60.656136] Unable to handle kernel NULL pointer dereference at
> RIP:
> [ 60.656143] [] blk_rq_map_sg+0x10d/0x17c
> [ 60.656151] PGD 4640067 PUD 46d4067 PMD 0
> [ 60.656154] Oop
Jens,
This is freshly after booting into this morning's kernel:
[ 60.656136] Unable to handle kernel NULL pointer dereference at
RIP:
[ 60.656143] [] blk_rq_map_sg+0x10d/0x17c
[ 60.656151] PGD 4640067 PUD 46d4067 PMD 0
[ 60.656154] Oops: [1] SMP
[ 60.656157]
Jens,
This is freshly after booting into this morning's kernel:
[ 60.656136] Unable to handle kernel NULL pointer dereference at
RIP:
[ 60.656143] [80375553] blk_rq_map_sg+0x10d/0x17c
[ 60.656151] PGD 4640067 PUD 46d4067 PMD 0
[ 60.656154] Oops: [1] SMP
On Tue, Oct 23, 2007 at 07:46:37AM -0500, Florin Iucha wrote:
[ 60.656136] Unable to handle kernel NULL pointer dereference at
RIP:
[ 60.656143] [80375553] blk_rq_map_sg+0x10d/0x17c
[ 60.656151] PGD 4640067 PUD 46d4067 PMD 0
[ 60.656154] Oops: [1] SMP
On Thu, Aug 30, 2007 at 03:18:37PM -0700, Bret Towe wrote:
> > uptime of 3 hours and keyboard is still working fine
> > I'll hopefully get to test this on the mini tomorrow for at least 3 hours
> > also
>
> got 45min on mini before I had to go elsewhere
> the amd64 shutdown fine and has been up
On Thu, Aug 30, 2007 at 03:18:37PM -0700, Bret Towe wrote:
uptime of 3 hours and keyboard is still working fine
I'll hopefully get to test this on the mini tomorrow for at least 3 hours
also
got 45min on mini before I had to go elsewhere
the amd64 shutdown fine and has been up for more
On Tue, Aug 28, 2007 at 09:28:43AM -0400, Trond Myklebust wrote:
> Doh! I see the problem: cancel_delayed_work_sync() shouldn't ever be
> called recursively.
>
> The following patch should be correct. Please just discard the previous
> one...
So far so good. This patch got one hour uptime...
On Tue, Aug 28, 2007 at 09:28:43AM -0400, Trond Myklebust wrote:
Doh! I see the problem: cancel_delayed_work_sync() shouldn't ever be
called recursively.
The following patch should be correct. Please just discard the previous
one...
So far so good. This patch got one hour uptime... I'll
On Mon, Aug 27, 2007 at 06:19:29PM -0700, Bret Towe wrote:
> On 8/27/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > > > this sounds alot like the post i did yesterday titled 'nfs4 hang
> > > > regression'
> > > > i tracked it down to commit 3d39c691ff486142dd9aaeac12f553f4476b7a6
> > >
> > >
On Mon, Aug 27, 2007 at 06:19:29PM -0700, Bret Towe wrote:
On 8/27/07, Trond Myklebust [EMAIL PROTECTED] wrote:
this sounds alot like the post i did yesterday titled 'nfs4 hang
regression'
i tracked it down to commit 3d39c691ff486142dd9aaeac12f553f4476b7a6
Yes, it certainly
On Thu, Aug 23, 2007 at 10:14:38AM -0700, Bret Towe wrote:
> this sounds alot like the post i did yesterday titled 'nfs4 hang regression'
> i tracked it down to commit 3d39c691ff486142dd9aaeac12f553f4476b7a6
Yes, it certainly does -- all the symptoms match!
I'm not [alone in] seeing dead
Trond,
Fess up... I'm closing in:
http://iucha.net/2.6.23-rc3/2.6.23-rc-bisect.png
[Dropping Jiri and linux-usb-devel from future postings. You are
included now just for communicating the conclusion of this thread.]
On Wed, Aug 22, 2007 at 08:22:00AM -0500, Florin Iucha wrote:
> On
Trond,
Fess up... I'm closing in:
http://iucha.net/2.6.23-rc3/2.6.23-rc-bisect.png
[Dropping Jiri and linux-usb-devel from future postings. You are
included now just for communicating the conclusion of this thread.]
On Wed, Aug 22, 2007 at 08:22:00AM -0500, Florin Iucha wrote:
On Tue, Aug
On Thu, Aug 23, 2007 at 10:14:38AM -0700, Bret Towe wrote:
this sounds alot like the post i did yesterday titled 'nfs4 hang regression'
i tracked it down to commit 3d39c691ff486142dd9aaeac12f553f4476b7a6
Yes, it certainly does -- all the symptoms match!
I'm not [alone in] seeing dead
On Tue, Aug 21, 2007 at 03:42:26PM +0200, Jiri Kosina wrote:
> On Tue, 21 Aug 2007, Florin Iucha wrote:
>
> > There is another interesting angle to this: in the past, every time I
> > had keyboard problems, it used to be caused by the VFS and/or NFS...
> > after much wr
On Tue, Aug 21, 2007 at 03:42:26PM +0200, Jiri Kosina wrote:
On Tue, 21 Aug 2007, Florin Iucha wrote:
There is another interesting angle to this: in the past, every time I
had keyboard problems, it used to be caused by the VFS and/or NFS...
after much wrangling, a bunch of bugs were
On Tue, Aug 21, 2007 at 08:17:59AM -0500, Florin Iucha wrote:
> On Tue, Aug 21, 2007 at 03:05:25PM +0200, Jiri Kosina wrote:
> > > I have rebuilt 2.6.23-rc3 with 'CONFIG_USB_EHCI_HCD=m' and
> > > 'CONFIG_USB_SUSPEND is not set' and will use it for a while, to see if
&
On Tue, Aug 21, 2007 at 03:05:25PM +0200, Jiri Kosina wrote:
> > I have rebuilt 2.6.23-rc3 with 'CONFIG_USB_EHCI_HCD=m' and
> > 'CONFIG_USB_SUSPEND is not set' and will use it for a while, to see if
> > the keyboard/usb behaves or not.
>
> Thanks. If this doesn't give us any hint, it would be
On Tue, Aug 21, 2007 at 06:51:15AM -0500, Florin Iucha wrote:
> On Wed, Aug 15, 2007 at 04:58:33PM +0200, Jiri Kosina wrote:
> > On Wed, 15 Aug 2007, Florin Iucha wrote:
> >
> > > [See my message to Alan]: It happened twice, within 15 minutes of
> > > boot+logi
On Tue, Aug 21, 2007 at 02:04:26PM +0200, Jiri Kosina wrote:
> > I have enabled USB debugging and I see a bunch (=46) of these messages:
>
> >[ $timestamp] usb 1-9: usb auto-suspend
> >[ $timestamp] usb 1-9: usb auto-resume
> >[ $timestamp] ehci_hcd :00:02.1: GetStatus port 9
On Wed, Aug 15, 2007 at 04:58:33PM +0200, Jiri Kosina wrote:
> On Wed, 15 Aug 2007, Florin Iucha wrote:
>
> > [See my message to Alan]: It happened twice, within 15 minutes of
> > boot+login, with 2.6.23-rc3-$whatever . I does not happen with
> > 2.6.2[123](-rc*)? Af
On Wed, Aug 15, 2007 at 04:58:33PM +0200, Jiri Kosina wrote:
On Wed, 15 Aug 2007, Florin Iucha wrote:
[See my message to Alan]: It happened twice, within 15 minutes of
boot+login, with 2.6.23-rc3-$whatever . I does not happen with
2.6.2[123](-rc*)? After the two incidents, I rebooted
On Tue, Aug 21, 2007 at 06:51:15AM -0500, Florin Iucha wrote:
On Wed, Aug 15, 2007 at 04:58:33PM +0200, Jiri Kosina wrote:
On Wed, 15 Aug 2007, Florin Iucha wrote:
[See my message to Alan]: It happened twice, within 15 minutes of
boot+login, with 2.6.23-rc3-$whatever . I does
On Tue, Aug 21, 2007 at 02:04:26PM +0200, Jiri Kosina wrote:
I have enabled USB debugging and I see a bunch (=46) of these messages:
[ $timestamp] usb 1-9: usb auto-suspend
[ $timestamp] usb 1-9: usb auto-resume
[ $timestamp] ehci_hcd :00:02.1: GetStatus port 9 status
On Tue, Aug 21, 2007 at 03:05:25PM +0200, Jiri Kosina wrote:
I have rebuilt 2.6.23-rc3 with 'CONFIG_USB_EHCI_HCD=m' and
'CONFIG_USB_SUSPEND is not set' and will use it for a while, to see if
the keyboard/usb behaves or not.
Thanks. If this doesn't give us any hint, it would be useful if
On Tue, Aug 21, 2007 at 08:17:59AM -0500, Florin Iucha wrote:
On Tue, Aug 21, 2007 at 03:05:25PM +0200, Jiri Kosina wrote:
I have rebuilt 2.6.23-rc3 with 'CONFIG_USB_EHCI_HCD=m' and
'CONFIG_USB_SUSPEND is not set' and will use it for a while, to see if
the keyboard/usb behaves
On Wed, Aug 15, 2007 at 04:49:02PM +0200, Jiri Kosina wrote:
> On Wed, 15 Aug 2007, Florin Iucha wrote:
>
> > Today my USB keyboard stopped working in the middle of composing and
> > e-mail. I unplugged it and plugged it back, with no success. I
> > logged in remote
On Wed, Aug 15, 2007 at 10:38:54AM -0400, Alan Stern wrote:
> This patch will get rid of the annoying error messages. It won't do
> anything about your keyboard's tendency to spontaneously stop working,
> alas.
My keyboard works fine for days, with kernels up to and including
2.6.23-rc2 . I
Today my USB keyboard stopped working in the middle of composing and
e-mail. I unplugged it and plugged it back, with no success. I
logged in remotely and found this lovely message:
[ 1301.567351] usb 1-4: USB disconnect, address 3
[ 1301.567356] usb 1-4.2: USB disconnect, address 5
[
Today my USB keyboard stopped working in the middle of composing and
e-mail. I unplugged it and plugged it back, with no success. I
logged in remotely and found this lovely message:
[ 1301.567351] usb 1-4: USB disconnect, address 3
[ 1301.567356] usb 1-4.2: USB disconnect, address 5
[
On Wed, Aug 15, 2007 at 10:38:54AM -0400, Alan Stern wrote:
This patch will get rid of the annoying error messages. It won't do
anything about your keyboard's tendency to spontaneously stop working,
alas.
My keyboard works fine for days, with kernels up to and including
2.6.23-rc2 . I have
On Wed, Aug 15, 2007 at 04:49:02PM +0200, Jiri Kosina wrote:
On Wed, 15 Aug 2007, Florin Iucha wrote:
Today my USB keyboard stopped working in the middle of composing and
e-mail. I unplugged it and plugged it back, with no success. I
logged in remotely and found this lovely message
Hello,
I am writing a USB driver for some custom hardware, and I need to
synchronize between the user-space and the USB subsystem. Can I
create a semaphore and "down" it in the reader then "up" it in the
completion handler?
I know the completion handler runs in interrupt context so you are not
Hello,
I am writing a USB driver for some custom hardware, and I need to
synchronize between the user-space and the USB subsystem. Can I
create a semaphore and down it in the reader then up it in the
completion handler?
I know the completion handler runs in interrupt context so you are not
On Fri, Jun 08, 2007 at 09:55:58PM +0900, Tejun Heo wrote:
> Florin Iucha wrote:
> >> It means the drive reported command tags were completed that were not
> >> outstanding. What kind of drive is this?
> >
> > [ 29.033142] ata1.00: ata_hpa_resize 1: sectors =
On Fri, Jun 08, 2007 at 09:55:58PM +0900, Tejun Heo wrote:
Florin Iucha wrote:
It means the drive reported command tags were completed that were not
outstanding. What kind of drive is this?
[ 29.033142] ata1.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors
= 156
301488
On Wed, Jun 06, 2007 at 08:28:07AM -0600, Robert Hancock wrote:
> >This is on a Thinkpad T60 with 2 GB RAM, running Ubuntu 7.04 (kernel
> >2.6.20-16-generic). No proprietary drivers (ok, maybe the Intel
> >Wi-Fi - but that should not count).
> >
> >The laptop came with Windows but I blew that
On Wed, Jun 06, 2007 at 08:28:07AM -0600, Robert Hancock wrote:
This is on a Thinkpad T60 with 2 GB RAM, running Ubuntu 7.04 (kernel
2.6.20-16-generic). No proprietary drivers (ok, maybe the Intel
Wi-Fi - but that should not count).
The laptop came with Windows but I blew that away - did I
Hello,
I was working on a I/O heavy workload (parsing 100K spam messages to
extract certain structures) when I got this in the kernel log:
[ 2320.132893] ata1.00: exception Emask 0x2 SAct 0x701f SErr 0x0 action 0x2
frozen
[ 2320.132899] ata1.00: (spurious completions during NCQ issue=0x0
Hello,
I was working on a I/O heavy workload (parsing 100K spam messages to
extract certain structures) when I got this in the kernel log:
[ 2320.132893] ata1.00: exception Emask 0x2 SAct 0x701f SErr 0x0 action 0x2
frozen
[ 2320.132899] ata1.00: (spurious completions during NCQ issue=0x0
//lkml.org/lkml/2007/5/22/4
> > Submitter : Florin Iucha <[EMAIL PROTECTED]>
> > Status : Unknown
> Actually, the bug seems to be unreproducible and it has probably been a
> 1-bit flip. So I'd be reluctant to call it a regression...
I agree with this statement. I'll ping Michal
: Florin Iucha [EMAIL PROTECTED]
Status : Unknown
Actually, the bug seems to be unreproducible and it has probably been a
1-bit flip. So I'd be reluctant to call it a regression...
I agree with this statement. I'll ping Michal and Jan if the oops
resurfaces.
florin
--
Bruce Schneier expects
On Tue, May 22, 2007 at 11:57:11AM +0200, Jan Kara wrote:
> > I was running a multithreaded perl application that leaks some memory
> > so it gets to eat up a significant chunk of my 2 GB and even push a
> > bit into swap. I left it running before going out for a walk.
> Hmm, what seems
On Tue, May 22, 2007 at 11:57:11AM +0200, Jan Kara wrote:
I was running a multithreaded perl application that leaks some memory
so it gets to eat up a significant chunk of my 2 GB and even push a
bit into swap. I left it running before going out for a walk.
Hmm, what seems suspitious is,
I was running a multithreaded perl application that leaks some memory
so it gets to eat up a significant chunk of my 2 GB and even push a
bit into swap. I left it running before going out for a walk.
When I got back, I found this in the log:
[28818.103829] Unable to handle kernel paging request
I was running a multithreaded perl application that leaks some memory
so it gets to eat up a significant chunk of my 2 GB and even push a
bit into swap. I left it running before going out for a walk.
When I got back, I found this in the log:
[28818.103829] Unable to handle kernel paging request
Kernel: v2.6.22-rc1-g0479ea0
Got this in the logs:
[ 8314.672340] BUG: at fs/inotify.c:172 set_dentry_child_flags()
[ 8314.672345]
[ 8314.672346] Call Trace:
[ 8314.672353] [] _spin_lock+0x9/0xb
[ 8314.672361] [] set_dentry_child_flags+0x6d/0x14f
[ 8314.672366] []
Kernel: v2.6.22-rc1-g0479ea0
Got this in the logs:
[ 8314.672340] BUG: at fs/inotify.c:172 set_dentry_child_flags()
[ 8314.672345]
[ 8314.672346] Call Trace:
[ 8314.672353] [8054a44c] _spin_lock+0x9/0xb
[ 8314.672361] [8029fc0f] set_dentry_child_flags+0x6d/0x14f
[ 8314.672366]
I just pulled the current git (de5603748af8bf7deac403e6ba92887f8d18e812)
and tried to compile it on my AMD64 box, to test Chuck's RPC fix. It
fails:
arch/x86_64/kernel/head64.c: In function ‘x86_64_start_kernel’:
arch/x86_64/kernel/head64.c:70: error: size of array ‘type name’ is negative
I just pulled the current git (de5603748af8bf7deac403e6ba92887f8d18e812)
and tried to compile it on my AMD64 box, to test Chuck's RPC fix. It
fails:
arch/x86_64/kernel/head64.c: In function ‘x86_64_start_kernel’:
arch/x86_64/kernel/head64.c:70: error: size of array ‘type name’ is negative
Hello,
This morning I updated the kernel on my workstation to the current git
tree (62ea6d80211ecc88ef516927ecebf64cb505be3f). Upon reboot, I
cannot change file access permissions of files in a directory that is
nfs mounted (using NFS4):
$ chmod 0600 $path
chmod: Changing permissions of
Hello,
This morning I updated the kernel on my workstation to the current git
tree (62ea6d80211ecc88ef516927ecebf64cb505be3f). Upon reboot, I
cannot change file access permissions of files in a directory that is
nfs mounted (using NFS4):
$ chmod 0600 $path
chmod: Changing permissions of
On Fri, Apr 20, 2007 at 04:03:58PM -0400, Trond Myklebust wrote:
> I've split the issues introduced by the 2.6.21-rcX write code up into 4
> subproblems.
[snip]
> My thanks to the various patient victim^Wpeople who helped with extensive
> testing.
I've pulled the tree this morning
On Fri, Apr 20, 2007 at 04:03:58PM -0400, Trond Myklebust wrote:
I've split the issues introduced by the 2.6.21-rcX write code up into 4
subproblems.
[snip]
My thanks to the various patient victim^Wpeople who helped with extensive
testing.
I've pulled the tree this morning
On Fri, Apr 20, 2007 at 09:37:30AM -0400, Trond Myklebust wrote:
> Thanks! Did you ever find out what had happened to the test that hung
> last night?
Nope. I could not ssh into it and the machine was needed for some
windows duty before I got home ;) I'll try again this coming week-end
and let
On Thu, Apr 19, 2007 at 04:49:31PM -0500, Florin Iucha wrote:
> On Thu, Apr 19, 2007 at 05:30:42PM -0400, Trond Myklebust wrote:
> > > I'm far from the machine right now, so I will do some more tests
> > > tonight, but right now, the new patchset is not good. What is the
>
On Thu, Apr 19, 2007 at 04:49:31PM -0500, Florin Iucha wrote:
On Thu, Apr 19, 2007 at 05:30:42PM -0400, Trond Myklebust wrote:
I'm far from the machine right now, so I will do some more tests
tonight, but right now, the new patchset is not good. What is the
difference between reverting
On Fri, Apr 20, 2007 at 09:37:30AM -0400, Trond Myklebust wrote:
Thanks! Did you ever find out what had happened to the test that hung
last night?
Nope. I could not ssh into it and the machine was needed for some
windows duty before I got home ;) I'll try again this coming week-end
and let
On Thu, Apr 19, 2007 at 05:30:42PM -0400, Trond Myklebust wrote:
> > I'm far from the machine right now, so I will do some more tests
> > tonight, but right now, the new patchset is not good. What is the
> > difference between reverting the patch you sent yesterday and your
> > current fifth
On Thu, Apr 19, 2007 at 12:09:42PM -0400, Trond Myklebust wrote:
> See
>http://client.linux-nfs.org/Linux-2.6.x/2.6.21-rc7/
>
> I'm giving the first 5 patches of that series (i.e.
> linux-2.6.21-001-cleanup_unstable_write.dif to
> linux-2.6.21-005-fix_nfsv4_resend.dif) an extra beating since
On Thu, Apr 19, 2007 at 11:17:28AM -0400, Trond Myklebust wrote:
> On Thu, 2007-04-19 at 11:12 -0400, Chuck Lever wrote:
> > Perhaps instead of looking at the number of bytes sent, the logic in the
> > last hunk of this patch should check which queue the request is sitting on.
>
> ??? It would
On Thu, Apr 19, 2007 at 11:17:28AM -0400, Trond Myklebust wrote:
On Thu, 2007-04-19 at 11:12 -0400, Chuck Lever wrote:
Perhaps instead of looking at the number of bytes sent, the logic in the
last hunk of this patch should check which queue the request is sitting on.
??? It would be a bug
On Thu, Apr 19, 2007 at 12:09:42PM -0400, Trond Myklebust wrote:
See
http://client.linux-nfs.org/Linux-2.6.x/2.6.21-rc7/
I'm giving the first 5 patches of that series (i.e.
linux-2.6.21-001-cleanup_unstable_write.dif to
linux-2.6.21-005-fix_nfsv4_resend.dif) an extra beating since those
On Thu, Apr 19, 2007 at 05:30:42PM -0400, Trond Myklebust wrote:
I'm far from the machine right now, so I will do some more tests
tonight, but right now, the new patchset is not good. What is the
difference between reverting the patch you sent yesterday and your
current fifth patch? I
On Wed, Apr 18, 2007 at 10:45:13PM -0400, Trond Myklebust wrote:
> On Wed, 2007-04-18 at 20:52 -0500, Florin Iucha wrote:
> > It seems that my original problem report had a big mistake! There is
> > no hang, but at some point the write slows down to a trickle (from
> >
On Wed, Apr 18, 2007 at 10:11:46AM -0400, Trond Myklebust wrote:
> Do you have a copy of wireshark or ethereal on hand? If so, could you
> take a look at whether or not any NFS traffic is going between the
> client and server once the hang happens?
I used the following command
tcpdump -w
On Wed, Apr 18, 2007 at 10:11:46AM -0400, Trond Myklebust wrote:
> On Wed, 2007-04-18 at 08:42 -0500, Florin Iucha wrote:
> > Could the port in CLOSE_WAIT state be the culprit? (FWIW
> > the server has been up for 38 days and subjected to
> > this nfs test quite a bit witho
On Wed, Apr 18, 2007 at 08:42:25AM -0500, Florin Iucha wrote:
> On Wed, Apr 18, 2007 at 09:15:31AM -0400, Trond Myklebust wrote:
> The netstat outputs are stable (not changed in 5 minutes):
>
>http://iucha.net/nfs/21-rc7-nfs3/netstat-server :
>
> tcp1 0 he
On Wed, Apr 18, 2007 at 09:15:31AM -0400, Trond Myklebust wrote:
> There is only one request on the 'pending' queue. That would usually
> indicate that the connection to the server is down. Can you check using
> "netstat -t" whether or not there is a connection in the 'ESTABLISHED'
> state to the
On Tue, Apr 17, 2007 at 10:37:38PM -0700, Andrew Morton wrote:
> Florin, can we please see /proc/meminfo as well?
http://iucha.net/nfs/21-rc7-nfs2/meminfo
> Also the result of `echo m > /proc/sysrq-trigger'
http://iucha.net/nfs/21-rc7-nfs2/big-copy
This has 'echo m >
On Tue, Apr 17, 2007 at 10:37:38PM -0700, Andrew Morton wrote:
Florin, can we please see /proc/meminfo as well?
http://iucha.net/nfs/21-rc7-nfs2/meminfo
Also the result of `echo m /proc/sysrq-trigger'
http://iucha.net/nfs/21-rc7-nfs2/big-copy
This has 'echo m /proc/sysrq-trigger',
On Wed, Apr 18, 2007 at 09:15:31AM -0400, Trond Myklebust wrote:
There is only one request on the 'pending' queue. That would usually
indicate that the connection to the server is down. Can you check using
netstat -t whether or not there is a connection in the 'ESTABLISHED'
state to the
On Wed, Apr 18, 2007 at 08:42:25AM -0500, Florin Iucha wrote:
On Wed, Apr 18, 2007 at 09:15:31AM -0400, Trond Myklebust wrote:
The netstat outputs are stable (not changed in 5 minutes):
http://iucha.net/nfs/21-rc7-nfs3/netstat-server :
tcp1 0 hermes.iucha.org:nfs
On Wed, Apr 18, 2007 at 10:11:46AM -0400, Trond Myklebust wrote:
On Wed, 2007-04-18 at 08:42 -0500, Florin Iucha wrote:
Could the port in CLOSE_WAIT state be the culprit? (FWIW
the server has been up for 38 days and subjected to
this nfs test quite a bit without showing any stress
1 - 100 of 142 matches
Mail list logo
