Hi,
mysql doesn't start on this kernel. This is a x86, preempt, ext2/3, UP
system. I get this in the mysql error log,
030802 20:01:17 mysqld started
030802 20:01:18 InnoDB: Error: the OS said file flush did not succeed
030802 20:01:18 InnoDB: Operating system error number 5 in a file
operation.
InnoDB: See http://www.innodb.com/ibman.html for installation help.
InnoDB: Look from section 13.2 at http://www.innodb.com/ibman.html
InnoDB: what the error number means or use the perror program of MySQL.
InnoDB: Cannot continue operation.
030802 20:01:18 mysqld ended
I also did an strace of mysql trying to start and when I tried to copy
the strace file to root's home I got some sort of IO error. I don't
remember the error exactly but I decided to run at that point and
rebooted. The file did seem to copy ok according to diff.
http://zeke.yi.org/linux/2.6.0-test2-mm3.strace.mysql
http://zeke.yi.org/linux/2.6.0-test2-mm3-config
BTW, CONFIG_DEBUG_INFO=y seems to make this kernel huge. I couldn't even
install the sucker because I didn't have enough space for the modules.
35 MB wasn't enough.
One last thing, I have started seeing mysql database corruption
recently. I am not sure it is a kernel problem. And I don't know the
exact steps to reproduce it, but I think I started seeing it with
-test2-mm2. I haven't ever seen db corruption in the 8-12 months I have
being playing with mysql/php.
None of these problems is critical for me (and they could be pilot
error) but I thought I should point them out.
Regards,
Shane
Shane Shrybman <[email protected]> wrote:
>
> mysql doesn't start on this kernel.
That's because I'm an idiot.
--- 25/fs/mpage.c~awe-use-gfp_flags-braino Sat Aug 2 18:03:01 2003
+++ 25-akpm/fs/mpage.c Sat Aug 2 18:03:01 2003
@@ -568,7 +568,7 @@ confused:
*/
if (*ret == -ENOSPC)
set_bit(AS_ENOSPC, &mapping->flags);
- else
+ else if (*ret)
set_bit(AS_EIO, &mapping->flags);
out:
return bio;
@@ -673,7 +673,7 @@ mpage_writepages(struct address_space *m
ret = (*writepage)(page, wbc);
if (ret == -ENOSPC)
set_bit(AS_ENOSPC, &mapping->flags);
- else
+ else if (ret)
set_bit(AS_EIO, &mapping->flags);
} else {
bio = mpage_writepage(bio, page, get_block,
diff -puN mm/vmscan.c~awe-use-gfp_flags-braino mm/vmscan.c
--- 25/mm/vmscan.c~awe-use-gfp_flags-braino Sat Aug 2 18:03:01 2003
+++ 25-akpm/mm/vmscan.c Sat Aug 2 18:03:01 2003
@@ -254,7 +254,7 @@ static void handle_write_error(struct ad
if (page->mapping == mapping) {
if (error == -ENOSPC)
set_bit(AS_ENOSPC, &mapping->flags);
- else
+ else if (error)
set_bit(AS_EIO, &mapping->flags);
}
unlock_page(page);
_
> One last thing, I have started seeing mysql database corruption
> recently. I am not sure it is a kernel problem. And I don't know the
> exact steps to reproduce it, but I think I started seeing it with
> -test2-mm2. I haven't ever seen db corruption in the 8-12 months I have
> being playing with mysql/php.
hm, that's a worry. No additional info available?
On Sun, 3 Aug 2003 11:04, Andrew Morton wrote:
> Shane Shrybman <[email protected]> wrote:
> > mysql doesn't start on this kernel.
[snip self abuse...]
Would this also be why I get lots of this error on this kernel?
diff: standard output: Input/output error
Con
Con Kolivas <[email protected]> wrote:
>
> On Sun, 3 Aug 2003 11:04, Andrew Morton wrote:
> > Shane Shrybman <[email protected]> wrote:
> > > mysql doesn't start on this kernel.
> [snip self abuse...]
>
> Would this also be why I get lots of this error on this kernel?
>
> diff: standard output: Input/output error
>
Yes. Silly last-minute thing. Sorry about that.
I'll remove 2.6.0-test2-mm3 and will upload a 2.6.0-test2-mm3-1
On Sat, 2003-08-02 at 21:04, Andrew Morton wrote:
> Shane Shrybman <[email protected]> wrote:
> >
> > mysql doesn't start on this kernel.
>
> That's because I'm an idiot.
Ah.. thats good 8) For once its not me. :)
>
> --- 25/fs/mpage.c~awe-use-gfp_flags-braino Sat Aug 2 18:03:01 2003
> +++ 25-akpm/fs/mpage.c Sat Aug 2 18:03:01 2003
> @@ -568,7 +568,7 @@ confused:
> */
> if (*ret == -ENOSPC)
> set_bit(AS_ENOSPC, &mapping->flags);
> - else
> + else if (*ret)
> set_bit(AS_EIO, &mapping->flags);
> out:
> return bio;
> @@ -673,7 +673,7 @@ mpage_writepages(struct address_space *m
> ret = (*writepage)(page, wbc);
> if (ret == -ENOSPC)
> set_bit(AS_ENOSPC, &mapping->flags);
> - else
> + else if (ret)
> set_bit(AS_EIO, &mapping->flags);
> } else {
> bio = mpage_writepage(bio, page, get_block,
> diff -puN mm/vmscan.c~awe-use-gfp_flags-braino mm/vmscan.c
> --- 25/mm/vmscan.c~awe-use-gfp_flags-braino Sat Aug 2 18:03:01 2003
> +++ 25-akpm/mm/vmscan.c Sat Aug 2 18:03:01 2003
> @@ -254,7 +254,7 @@ static void handle_write_error(struct ad
> if (page->mapping == mapping) {
> if (error == -ENOSPC)
> set_bit(AS_ENOSPC, &mapping->flags);
> - else
> + else if (error)
> set_bit(AS_EIO, &mapping->flags);
> }
> unlock_page(page);
>
> _
>
> > One last thing, I have started seeing mysql database corruption
> > recently. I am not sure it is a kernel problem. And I don't know the
> > exact steps to reproduce it, but I think I started seeing it with
> > -test2-mm2. I haven't ever seen db corruption in the 8-12 months I have
> > being playing with mysql/php.
>
> hm, that's a worry. No additional info available?
>
The db corruption hit again on test2-mm2. I am on -test1-mm1 trying to
reproduce it there. I don't now what little query or update is the
problem. There is nothing in the system logs. I went through everything
that I thought might have been happening at the time and the tables came
up clean with the "check tables" command. Then it happened a bit later.
There is a cron job doing a query every minute, but it doesn't happen
all the time. I don't know, its probably some config change I made to
mysql.
I am still backing out the 64 bit devt bit, I assume that is still
needed. The db and mysql binaries are on, respectively:
/dev/vg02/varlv /var ext3 rw,noatime,nosuid,nodev 0 0
/dev/vg02/usrlv /usr ext3 rw,noatime,nodev 0 0
mysql version
mysql Ver 12.12 Distrib 4.0.3-beta, for pc-linux-gnu (i686)
dmesg
http://zeke.yi.org/linux/2.6.0-test2-mm2.dmesg
Shane
Shane Shrybman <[email protected]> wrote:
>
> The db corruption hit again on test2-mm2.
How do you know it is "db corruption"?
>
> I am still backing out the 64 bit devt bit
why?
On Sat, 2003-08-02 at 22:08, Andrew Morton wrote:
> Shane Shrybman <[email protected]> wrote:
> >
> > The db corruption hit again on test2-mm2.
>
> How do you know it is "db corruption"?
I haven't been able to get an exact recipe for producing this but I have
posted a couple of the mysql corruption messages.
I still haven't been able to make it appear in 2.6.0-test1-mm1, but once
when I rebooted from -test1-mm1 to -test2-mm3 the tables had problems
immediately, when they came up clean in -test1-mm1 right before. When I
ran the mysql repair tables command it fixed them up and did not delete
any rows from the corrupted table, (or only very few). The repair
command usually deletes thousands of rows in order to repair the table.
http://zeke.yi.org/linux/mysql.tables.corrupt
I haven't found any info on this error message but maybe someone has
seen it before?
BTW: I am using myisam table type in mysql.
I will let you know if I find the exact way to reproduce this problem.
Regards,
Shane
Hello Andrew,
On Sunday 03 August 2003 05:04, Andrew Morton wrote:
> Shane Shrybman <[email protected]> wrote:
<cut>
>
> > One last thing, I have started seeing mysql database corruption
> > recently. I am not sure it is a kernel problem. And I don't know the
> > exact steps to reproduce it, but I think I started seeing it with
> > -test2-mm2. I haven't ever seen db corruption in the 8-12 months I have
> > being playing with mysql/php.
>
> hm, that's a worry. No additional info available?
>
I also suffer from this problem (I'm speaking about heavy InnoDB corruption
here), but with vanilla 2.6.0-test2. I can't blame MySQL/InnoDB because
there are a lot of MySQL boxes around of me with the same (in fact the box
wich failed is replication slave) or allmost the same database setup.
All other boxes (2.4 kernel) works fine up to now.
Sorry but I can't provide additional info. There was no messages in kernel log.
All I have is mysql error logs. But I'm afraid they are not very helpfull
for kernel developers.
http://sysadminday.org.ru/linux-2.6.0-test2_InnoDB_crash
System is x86 UP PIII 500, 1Gb RAM with software RAID1 over two scsi disks.
--
Best regards,
Sergey S. Kostyliov <[email protected]>
Public PGP key: http://sysadminday.org.ru/rathamahata.asc
Shane Shrybman <[email protected]> wrote:
>
> I still haven't been able to make it appear in 2.6.0-test1-mm1, but once
> when I rebooted from -test1-mm1 to -test2-mm3 the tables had problems
> immediately
Sorry, test2-mm3 was a disaster. I replaced it with test3-mm3-1, which
should be better.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test2/2.6.0-test2-mm3/2.6.0-test2-mm3-1.bz2
On Sun, Aug 03, 2003 at 10:58:17PM +0400, Sergey S. Kostyliov wrote:
> Hello Andrew,
>
> On Sunday 03 August 2003 05:04, Andrew Morton wrote:
> > Shane Shrybman <[email protected]> wrote:
>
> >
> > > One last thing, I have started seeing mysql database corruption
> > > recently. I am not sure it is a kernel problem. And I don't know the
> > > exact steps to reproduce it, but I think I started seeing it with
> > > -test2-mm2. I haven't ever seen db corruption in the 8-12 months I have
> > > being playing with mysql/php.
> >
> > hm, that's a worry. No additional info available?
>
> I also suffer from this problem (I'm speaking about heavy InnoDB corruption
> here), but with vanilla 2.6.0-test2. I can't blame MySQL/InnoDB because
> there are a lot of MySQL boxes around of me with the same (in fact the box
> wich failed is replication slave) or allmost the same database setup.
> All other boxes (2.4 kernel) works fine up to now.
All Linux kernels prior to 2.6.0-test2-mm3-1 would silently fail to
complete fsync() and msync() operations if they encountered an I/O
error, resulting in corruption. If a particular disk subsystem was
producing these errors, the symptoms would likely be:
- no error reported
- no messages in logs
- independent of kernel version, etc.
- suddenly appear at some point in drive life
- works flawlessly on other machines
If you can reproduce this corruption, please try running against mm3-1
and seeing if it reports problems (both to fsync and in logs).
--
Matt Mackall : http://www.selenic.com : of or relating to the moon
On Monday 04 August 2003 04:05, Matt Mackall wrote:
> On Sun, Aug 03, 2003 at 10:58:17PM +0400, Sergey S. Kostyliov wrote:
> > Hello Andrew,
> >
> > On Sunday 03 August 2003 05:04, Andrew Morton wrote:
> > > Shane Shrybman <[email protected]> wrote:
> > > > One last thing, I have started seeing mysql database corruption
> > > > recently. I am not sure it is a kernel problem. And I don't know the
> > > > exact steps to reproduce it, but I think I started seeing it with
> > > > -test2-mm2. I haven't ever seen db corruption in the 8-12 months I
> > > > have being playing with mysql/php.
> > >
> > > hm, that's a worry. No additional info available?
> >
> > I also suffer from this problem (I'm speaking about heavy InnoDB
> > corruption here), but with vanilla 2.6.0-test2. I can't blame
> > MySQL/InnoDB because there are a lot of MySQL boxes around of me with the
> > same (in fact the box wich failed is replication slave) or allmost the
> > same database setup. All other boxes (2.4 kernel) works fine up to now.
>
> All Linux kernels prior to 2.6.0-test2-mm3-1 would silently fail to
> complete fsync() and msync() operations if they encountered an I/O
> error, resulting in corruption. If a particular disk subsystem was
> producing these errors, the symptoms would likely be:
>
> - no error reported
> - no messages in logs
> - independent of kernel version, etc.
> - suddenly appear at some point in drive life
> - works flawlessly on other machines
>
> If you can reproduce this corruption, please try running against mm3-1
> and seeing if it reports problems (both to fsync and in logs).
I've just got another one InnoDB crash with 2.6.0-test4.
As in previous case there was no messages in kernel log.
You can find mysql error log here.
http://sysadminday.org.ru/linux-2.6.0-test4_InnoDB_crash
It's a development server, so this isn't a big problem.
I do understand that this can easily be a hardware problem,
but the kernel silence is really sad in such case.
Memory is fine (at least according to memtest 3.0).
Any hints will be appreciated.
--
Best regards,
Sergey S. Kostyliov <[email protected]>
Public PGP key: http://sysadminday.org.ru/rathamahata.asc
Hello all,
On Wednesday 27 August 2003 19:52, Sergey S. Kostyliov wrote:
> On Monday 04 August 2003 04:05, Matt Mackall wrote:
<cut>
> > All Linux kernels prior to 2.6.0-test2-mm3-1 would silently fail to
> > complete fsync() and msync() operations if they encountered an I/O
> > error, resulting in corruption. If a particular disk subsystem was
> > producing these errors, the symptoms would likely be:
> >
> > - no error reported
> > - no messages in logs
> > - independent of kernel version, etc.
> > - suddenly appear at some point in drive life
> > - works flawlessly on other machines
> >
> > If you can reproduce this corruption, please try running against mm3-1
> > and seeing if it reports problems (both to fsync and in logs).
>
> I've just got another one InnoDB crash with 2.6.0-test4.
> As in previous case there was no messages in kernel log.
> You can find mysql error log here.
> Re: 2.6.0-test2-mm3 and mysql
And here is another one InnoDB crash I've just got with 2.6.0-test4.
http://sysadminday.org.ru/linux-2.6.0-test4_InnoDB_crash-20030828
No messages in kernel log :((
>
> It's a development server, so this isn't a big problem.
> I do understand that this can easily be a hardware problem,
> but the kernel silence is really sad in such case.
> Memory is fine (at least according to memtest 3.0).
>
> Any hints will be appreciated.
--
Best regards,
Sergey S. Kostyliov <[email protected]>
Public PGP key: http://sysadminday.org.ru/rathamahata.asc
"Sergey S. Kostyliov" <[email protected]> wrote:
>
> And here is another one InnoDB crash I've just got with 2.6.0-test4.
Which filesystem?
What sort of I/O system?
Please grab http://www.zip.com.au/~akpm/linux/patches/stuff/fsx-linux.c
and run
./fsx-linux foo -s <physmem-in-bytes> foo
on that machine for 12 hours or so. Where <physmem-in-bytes> is (say)
256000000 on a 256-MB machine.
If the machine has more than a couple of gigabytes you'll need to run
multiple instances, against different files.
Make sure that a decent amount of I/O is happening during the run.
Hi Andrew,
On Thursday 28 August 2003 23:50, Andrew Morton wrote:
> "Sergey S. Kostyliov" <[email protected]> wrote:
> > And here is another one InnoDB crash I've just got with 2.6.0-test4.
>
> Which filesystem?
It's a reiserfs (v3.6)
/dev/md/2 on /var/lib type reiserfs (rw,noatime,nodiratime,notail)
>
> What sort of I/O system?
It's a software raid1 over two scsi discs attached to
00:06.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891
Host: scsi0 Channel: 00 Id: 08 Lun: 00
Vendor: QUANTUM Model: ATLAS10K2-TY734L Rev: DDD6
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 09 Lun: 00
Vendor: QUANTUM Model: ATLAS10K2-TY734L Rev: DDD6
Type: Direct-Access ANSI SCSI revision: 03
>
> Please grab http://www.zip.com.au/~akpm/linux/patches/stuff/fsx-linux.c
>
> and run
>
> ./fsx-linux foo -s <physmem-in-bytes> foo
>
> on that machine for 12 hours or so. Where <physmem-in-bytes> is (say)
> 256000000 on a 256-MB machine.
>
> If the machine has more than a couple of gigabytes you'll need to run
> multiple instances, against different files.
>
> Make sure that a decent amount of I/O is happening during the run.
Ok, will do this evening. Thank you.
--
Best regards,
Sergey S. Kostyliov <[email protected]>
Public PGP key: http://sysadminday.org.ru/rathamahata.asc
Hello Andrew,
On Friday 29 August 2003 12:12, Sergey S. Kostyliov wrote:
> Hi Andrew,
>
> On Thursday 28 August 2003 23:50, Andrew Morton wrote:
> > "Sergey S. Kostyliov" <[email protected]> wrote:
> > > And here is another one InnoDB crash I've just got with 2.6.0-test4.
> >
> > Which filesystem?
>
> It's a reiserfs (v3.6)
> /dev/md/2 on /var/lib type reiserfs (rw,noatime,nodiratime,notail)
>
> > What sort of I/O system?
>
> It's a software raid1 over two scsi discs attached to
> 00:06.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891
>
> Host: scsi0 Channel: 00 Id: 08 Lun: 00
> Vendor: QUANTUM Model: ATLAS10K2-TY734L Rev: DDD6
> Type: Direct-Access ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 09 Lun: 00
> Vendor: QUANTUM Model: ATLAS10K2-TY734L Rev: DDD6
> Type: Direct-Access ANSI SCSI revision: 03
>
> > Please grab http://www.zip.com.au/~akpm/linux/patches/stuff/fsx-linux.c
> >
> > and run
> >
> > ./fsx-linux foo -s <physmem-in-bytes> foo
Sorry, this options doesn't work for me.
Perhaps `./fsx-linux -l <physmem-in-bytes> foo`
are the right one? (It least it is what I'm using right now)
> >
> > on that machine for 12 hours or so. Where <physmem-in-bytes> is (say)
> > 256000000 on a 256-MB machine.
> >
> > If the machine has more than a couple of gigabytes you'll need to run
> > multiple instances, against different files.
> >
> > Make sure that a decent amount of I/O is happening during the run.
>
> Ok, will do this evening. Thank you.
fsx-linux hasn't been producing any error messages or logs since Friday.
But I've got an oops. Here it is.
ksymoops 2.4.9 on i686 2.6.0-test4. Options used
-V (default)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.6.0-test4/ (default)
-m /proc/kallsyms (specified)
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
0000:00:0c.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xb800. Vers LK1.1.19
kernel BUG at mm/filemap.c:336!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c01324f0>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000 ebx: c1577e70 ecx: 00000016 edx: 00000001
esi: c1a00448 edi: d5f3e820 ebp: e7147858 esp: c1bbbd34
ds: 007b es: 007b ss: 0068
Stack: c1577e70 00000286 00000000 c0191a4e c1577e70 eb14fde0 d5f3e850 c1577e70
00000000 00000000 00000000 e7147904 c1577e70 c1bbbe64 e71478e4 c013c294
c1577e70 c1bbbdac c1bba000 c1bba000 c1bba000 c1bba000 c1bba000 c1bba000
Call Trace:
[<c0191a4e>] reiserfs_write_full_page+0xee/0x3a0
[<c013c294>] shrink_list+0x394/0x5f0
[<c013afe8>] __pagevec_release+0x28/0x40
[<c013c6a7>] shrink_cache+0x1b7/0x350
[<c013d267>] balance_pgdat+0x187/0x220
[<c013d443>] kswapd+0x143/0x150
[<c01183b0>] autoremove_wake_function+0x0/0x50
[<c0109232>] ret_from_fork+0x6/0x14
[<c01183b0>] autoremove_wake_function+0x0/0x50
[<c013d300>] kswapd+0x0/0x150
[<c0107215>] kernel_thread_helper+0x5/0x10
Code: 0f 0b 50 01 0b e8 2c c0 eb c6 8d b6 00 00 00 00 89 1c 24 e8
>>EIP; c01324f0 <end_page_writeback+70/90> <=====
Trace; c0191a4e <reiserfs_write_full_page+ee/3a0>
Trace; c013c294 <shrink_list+394/5f0>
Trace; c013afe8 <__pagevec_release+28/40>
Trace; c013c6a7 <shrink_cache+1b7/350>
Trace; c013d267 <balance_pgdat+187/220>
Trace; c013d443 <kswapd+143/150>
Trace; c01183b0 <autoremove_wake_function+0/50>
Trace; c0109232 <ret_from_fork+6/14>
Trace; c01183b0 <autoremove_wake_function+0/50>
Trace; c013d300 <kswapd+0/150>
Trace; c0107215 <kernel_thread_helper+5/10>
Code; c01324f0 <end_page_writeback+70/90>
00000000 <_EIP>:
Code; c01324f0 <end_page_writeback+70/90> <=====
0: 0f 0b ud2a <=====
Code; c01324f2 <end_page_writeback+72/90>
2: 50 push %eax
Code; c01324f3 <end_page_writeback+73/90>
3: 01 0b add %ecx,(%ebx)
Code; c01324f5 <end_page_writeback+75/90>
5: e8 2c c0 eb c6 call c6ebc036 <_EIP+0xc6ebc036>
Code; c01324fa <end_page_writeback+7a/90>
a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
Code; c0132500 <end_page_writeback+80/90>
10: 89 1c 24 mov %ebx,(%esp,1)
Code; c0132503 <end_page_writeback+83/90>
13: e8 00 00 00 00 call 18 <_EIP+0x18>
--
Best regards,
Sergey S. Kostyliov <[email protected]>
Public PGP key: http://sysadminday.org.ru/rathamahata.asc
"Sergey S. Kostyliov" <[email protected]> wrote:
>
> fsx-linux hasn't been producing any error messages or logs since Friday.
> But I've got an oops. Here it is.
>
> ksymoops 2.4.9 on i686 2.6.0-test4. Options used
> -V (default)
> -K (specified)
> -l /proc/modules (default)
> -o /lib/modules/2.6.0-test4/ (default)
> -m /proc/kallsyms (specified)
>
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> 3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
> 0000:00:0c.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xb800. Vers LK1.1.19
> kernel BUG at mm/filemap.c:336!
> invalid operand: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c01324f0>] Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010246
> eax: 00000000 ebx: c1577e70 ecx: 00000016 edx: 00000001
> esi: c1a00448 edi: d5f3e820 ebp: e7147858 esp: c1bbbd34
> ds: 007b es: 007b ss: 0068
> Stack: c1577e70 00000286 00000000 c0191a4e c1577e70 eb14fde0 d5f3e850 c1577e70
> 00000000 00000000 00000000 e7147904 c1577e70 c1bbbe64 e71478e4 c013c294
> c1577e70 c1bbbdac c1bba000 c1bba000 c1bba000 c1bba000 c1bba000 c1bba000
> Call Trace:
> [<c0191a4e>] reiserfs_write_full_page+0xee/0x3a0
> [<c013c294>] shrink_list+0x394/0x5f0
> [<c013afe8>] __pagevec_release+0x28/0x40
> [<c013c6a7>] shrink_cache+0x1b7/0x350
> [<c013d267>] balance_pgdat+0x187/0x220
> [<c013d443>] kswapd+0x143/0x150
> [<c01183b0>] autoremove_wake_function+0x0/0x50
> [<c0109232>] ret_from_fork+0x6/0x14
> [<c01183b0>] autoremove_wake_function+0x0/0x50
> [<c013d300>] kswapd+0x0/0x150
You need this:
diff -puN fs/reiserfs/inode.c~reiserfs-writepage-fix fs/reiserfs/inode.c
--- 25/fs/reiserfs/inode.c~reiserfs-writepage-fix 2003-08-26 10:12:14.000000000 -0700
+++ 25-akpm/fs/reiserfs/inode.c 2003-08-26 10:12:14.000000000 -0700
@@ -2048,8 +2048,8 @@ static int reiserfs_write_full_page(stru
last_offset = inode->i_size & (PAGE_CACHE_SIZE - 1) ;
/* no file contents in this page */
if (page->index >= end_index + 1 || !last_offset) {
- error = 0 ;
- goto done ;
+ unlock_page(page);
+ return 0;
}
kaddr = kmap_atomic(page, KM_USER0);
memset(kaddr + last_offset, 0, PAGE_CACHE_SIZE-last_offset) ;
_