* Re: 2.5.70-mm9
2003-06-13 8:33 2.5.70-mm9 Andrew Morton
@ 2003-06-13 9:17 ` Andrew Morton
2003-06-13 10:50 ` Bug in 2.5.70-mm9: df: `/': Value too large for defined data type Thomas Schlichter
` (3 subsequent siblings)
4 siblings, 0 replies; 18+ messages in thread
From: Andrew Morton @ 2003-06-13 9:17 UTC (permalink / raw)
To: linux-kernel, linux-mm
Andrew Morton <akpm@digeo.com> wrote:
>
> +mark-inode-dirty-debug.patch
This will print "__mark_inode_dirty: this cannot happen" when the machine
first starts to swap. Please ignore it.
^ permalink raw reply [flat|nested] 18+ messages in thread* Bug in 2.5.70-mm9: df: `/': Value too large for defined data type
2003-06-13 8:33 2.5.70-mm9 Andrew Morton
2003-06-13 9:17 ` 2.5.70-mm9 Andrew Morton
@ 2003-06-13 10:50 ` Thomas Schlichter
2003-06-13 20:09 ` Andrew Morton
2003-06-13 17:57 ` 2.5.70-mm9 Brandon Low
` (2 subsequent siblings)
4 siblings, 1 reply; 18+ messages in thread
From: Thomas Schlichter @ 2003-06-13 10:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 756 bytes --]
Hi!
When I enter 'df' in my bash with -mm9 I get following:
Filesystem 1k-blocks Used Available Use% Mounted on
df: `/': Value too large for defined data type
/dev/hda3 7776 5718 1657 78% /boot
instead of:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda5 7421764 7296016 125748 99% /
/dev/hda3 7776 5718 1657 78% /boot
-mm8 worked without this problem.
Here is what 'mount' says:
/dev/hda5 on / type reiserfs (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/sys on /sys type sysfs (rw)
/dev/hda3 on /boot type ext3 (rw)
I use fileutils 4.1
Best regards
Thomas Schlichter
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: 2.5.70-mm9
2003-06-13 8:33 2.5.70-mm9 Andrew Morton
2003-06-13 9:17 ` 2.5.70-mm9 Andrew Morton
2003-06-13 10:50 ` Bug in 2.5.70-mm9: df: `/': Value too large for defined data type Thomas Schlichter
@ 2003-06-13 17:57 ` Brandon Low
2003-06-14 7:51 ` 2.5.70-mm9 Mingming Cao
2003-06-15 1:14 ` 2.5.70-mm9 Diego Calleja García
4 siblings, 0 replies; 18+ messages in thread
From: Brandon Low @ 2003-06-13 17:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
I tried to compile this drivre and got a ton of undefined references to
psmouse_command ... haven't looked at the code yet, but I'd guess it
only works when builtin, not as a module? Need an export symbol
somewhere?
--Brandon Low
Gentoo Dork/Dev :)
On Fri, 06/13/03 at 01:33:37 -0700, Andrew Morton wrote:
> +synaptics.patch
> +synaptics-cleanup.patch
>
> Synaptics driver (one flavour thereof)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-13 8:33 2.5.70-mm9 Andrew Morton
` (2 preceding siblings ...)
2003-06-13 17:57 ` 2.5.70-mm9 Brandon Low
@ 2003-06-14 7:51 ` Mingming Cao
2003-06-14 8:01 ` 2.5.70-mm9 Andrew Morton
2003-06-15 1:14 ` 2.5.70-mm9 Diego Calleja García
4 siblings, 1 reply; 18+ messages in thread
From: Mingming Cao @ 2003-06-14 7:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm9/
>
>
> Lots of fixes, lots of new things.
>
Good news, Andrew. I run 50 fsx tests on ext3 filesystems on 2.5.70-mm9.
The hang problem I used seen on 2.5.70-mm6 kernel is gone. The tests
runs fine for more than 9 hours. (Normally the problem will occur after
7 hours run on 2.5.70-mm6 kernel).
I am running the tests on 8 way PIII 700MHz, 4G memory, with
elevator=deadline.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: 2.5.70-mm9
2003-06-14 7:51 ` 2.5.70-mm9 Mingming Cao
@ 2003-06-14 8:01 ` Andrew Morton
2003-06-15 0:41 ` 2.5.70-mm9 Mingming Cao
0 siblings, 1 reply; 18+ messages in thread
From: Andrew Morton @ 2003-06-14 8:01 UTC (permalink / raw)
To: Mingming Cao; +Cc: linux-kernel, linux-mm
Mingming Cao <cmm@us.ibm.com> wrote:
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm9/
> >
> >
> > Lots of fixes, lots of new things.
> >
>
> Good news, Andrew. I run 50 fsx tests on ext3 filesystems on 2.5.70-mm9.
> The hang problem I used seen on 2.5.70-mm6 kernel is gone. The tests
> runs fine for more than 9 hours. (Normally the problem will occur after
> 7 hours run on 2.5.70-mm6 kernel).
OK. I'm no statistician, but I'd be more comfortable with 24 hours..
> I am running the tests on 8 way PIII 700MHz, 4G memory, with
> elevator=deadline.
>
Was elevator=deadline observed to fail in earlier kernels? If not then it
may be an anticipatory scheduler bug. It certainly had all the appearances
of that.
So once you're really sure that elevator=deadline isn't going to fail,
could you please test elevator=as?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-14 8:01 ` 2.5.70-mm9 Andrew Morton
@ 2003-06-15 0:41 ` Mingming Cao
2003-06-15 4:14 ` 2.5.70-mm9 Nick Piggin
2003-06-15 6:20 ` 2.5.70-mm9 Andrew Morton
0 siblings, 2 replies; 18+ messages in thread
From: Mingming Cao @ 2003-06-15 0:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Sat, 2003-06-14 at 01:01, Andrew Morton wrote:
> Was elevator=deadline observed to fail in earlier kernels? If not then it
> may be an anticipatory scheduler bug. It certainly had all the appearances
> of that.
Yes, with elevator=deadline the many fsx tests failed on 2.5.70-mm5.
> So once you're really sure that elevator=deadline isn't going to fail,
> could you please test elevator=as?
>
Ok, the deadline test was run for 10 hours then I stopped it (for the
elevator=as test).
But the test on elevator=as (2.5.70-mm9 kernel) still failed, same
problem. Some fsx tests are sleeping on io_schedule().
Next I think I will re-run test on elevator=deadline for 24 hours, to
make sure the problem is really gone there. After that maybe try a
different Qlogic Driver, currently I am using the driver from Qlogic
company(QLA2XXX V8).
Thanks,
Mingming
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-15 0:41 ` 2.5.70-mm9 Mingming Cao
@ 2003-06-15 4:14 ` Nick Piggin
2003-06-16 16:25 ` 2.5.70-mm9 Mingming Cao
2003-06-15 6:20 ` 2.5.70-mm9 Andrew Morton
1 sibling, 1 reply; 18+ messages in thread
From: Nick Piggin @ 2003-06-15 4:14 UTC (permalink / raw)
To: Mingming Cao; +Cc: Andrew Morton, linux-kernel, linux-mm
Mingming Cao wrote:
>On Sat, 2003-06-14 at 01:01, Andrew Morton wrote:
>
>
>>Was elevator=deadline observed to fail in earlier kernels? If not then it
>>may be an anticipatory scheduler bug. It certainly had all the appearances
>>of that.
>>
>Yes, with elevator=deadline the many fsx tests failed on 2.5.70-mm5.
>
>
>>So once you're really sure that elevator=deadline isn't going to fail,
>>could you please test elevator=as?
>>
>>
>Ok, the deadline test was run for 10 hours then I stopped it (for the
>elevator=as test).
>
>But the test on elevator=as (2.5.70-mm9 kernel) still failed, same
>problem. Some fsx tests are sleeping on io_schedule().
>
So by failed, you just mean stuck in io_schedule? Are you sure
they are permanently stuck there? Is any progress being made?
I have tried this test, and often some or most of the processes
wait in io_schedule for a while, but do get woken.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-15 4:14 ` 2.5.70-mm9 Nick Piggin
@ 2003-06-16 16:25 ` Mingming Cao
0 siblings, 0 replies; 18+ messages in thread
From: Mingming Cao @ 2003-06-16 16:25 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, linux-kernel, linux-mm
On Sat, 2003-06-14 at 21:14, Nick Piggin wrote:
>
>
> Mingming Cao wrote:
>
> >But the test on elevator=as (2.5.70-mm9 kernel) still failed, same
> >problem. Some fsx tests are sleeping on io_schedule().
> >
>
> So by failed, you just mean stuck in io_schedule? Are you sure
> they are permanently stuck there? Is any progress being made?
> I have tried this test, and often some or most of the processes
> wait in io_schedule for a while, but do get woken.
>
Yes, I mean they are permanetly hang there with Status D. No progress
were made.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-15 0:41 ` 2.5.70-mm9 Mingming Cao
2003-06-15 4:14 ` 2.5.70-mm9 Nick Piggin
@ 2003-06-15 6:20 ` Andrew Morton
2003-06-16 15:59 ` 2.5.70-mm9 Mingming Cao
2003-06-18 7:13 ` 2.5.70-mm9 Mingming Cao
1 sibling, 2 replies; 18+ messages in thread
From: Andrew Morton @ 2003-06-15 6:20 UTC (permalink / raw)
To: Mingming Cao; +Cc: linux-kernel, linux-mm
Mingming Cao <cmm@us.ibm.com> wrote:
>
> On Sat, 2003-06-14 at 01:01, Andrew Morton wrote:
>
> > Was elevator=deadline observed to fail in earlier kernels? If not then it
> > may be an anticipatory scheduler bug. It certainly had all the appearances
> > of that.
> Yes, with elevator=deadline the many fsx tests failed on 2.5.70-mm5.
>
> > So once you're really sure that elevator=deadline isn't going to fail,
> > could you please test elevator=as?
> >
> Ok, the deadline test was run for 10 hours then I stopped it (for the
> elevator=as test).
>
> But the test on elevator=as (2.5.70-mm9 kernel) still failed, same
> problem. Some fsx tests are sleeping on io_schedule().
>
> Next I think I will re-run test on elevator=deadline for 24 hours, to
> make sure the problem is really gone there. After that maybe try a
> different Qlogic Driver, currently I am using the driver from Qlogic
> company(QLA2XXX V8).
Martin has just observed what appears to be the same failure on
2.5.71-mjb1, which is the deadline scheduler, using qlogicisp.
Again, some IO appears to have been submitted but it never came back.
It could be a bug in the requests queueing code somewhere, or in the device
driver.
So a good thing to do now would be to find the workload+IO
scheduler+filesystem which triggers it most easily, and run that with a
different device driver. The feral driver (drivers/scsi/isp/ in -mm)
should be suitable for that test.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-15 6:20 ` 2.5.70-mm9 Andrew Morton
@ 2003-06-16 15:59 ` Mingming Cao
2003-06-18 7:13 ` 2.5.70-mm9 Mingming Cao
1 sibling, 0 replies; 18+ messages in thread
From: Mingming Cao @ 2003-06-16 15:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Sat, 2003-06-14 at 23:20, Andrew Morton wrote:
> Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > On Sat, 2003-06-14 at 01:01, Andrew Morton wrote:
> >
> > > Was elevator=deadline observed to fail in earlier kernels? If not then it
> > > may be an anticipatory scheduler bug. It certainly had all the appearances
> > > of that.
> > Yes, with elevator=deadline the many fsx tests failed on 2.5.70-mm5.
> >
> > > So once you're really sure that elevator=deadline isn't going to fail,
> > > could you please test elevator=as?
> > >
> > Ok, the deadline test was run for 10 hours then I stopped it (for the
> > elevator=as test).
> >
> > But the test on elevator=as (2.5.70-mm9 kernel) still failed, same
> > problem. Some fsx tests are sleeping on io_schedule().
> >
> > Next I think I will re-run test on elevator=deadline for 24 hours, to
> > make sure the problem is really gone there. After that maybe try a
> > different Qlogic Driver, currently I am using the driver from Qlogic
> > company(QLA2XXX V8).
>
> Martin has just observed what appears to be the same failure on
> 2.5.71-mjb1, which is the deadline scheduler, using qlogicisp.
>
> Again, some IO appears to have been submitted but it never came back.
>
> It could be a bug in the requests queueing code somewhere, or in the device
> driver.
>
> So a good thing to do now would be to find the workload+IO
> scheduler+filesystem which triggers it most easily, and run that with a
> different device driver. The feral driver (drivers/scsi/isp/ in -mm)
> should be suitable for that test.
>
I re-run the tests on the deadline scheduler on 2.5.70-mm9 kernel for 24
hours, serveral fsx tests failed as before, same as as scheduler. So
the problem is not gone on deadline scheduler, it shows up on both
deadline and as scheduler when running fsx tests on exts3 filesystem.
It's easy to reproduce: fsx tests +ext3 + deadline/as scheduler + with
QLA2xxx v8 driver.
Now I am going to run the same test with feral driver. Will let you
know.
Mingming
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-15 6:20 ` 2.5.70-mm9 Andrew Morton
2003-06-16 15:59 ` 2.5.70-mm9 Mingming Cao
@ 2003-06-18 7:13 ` Mingming Cao
2003-06-18 7:38 ` 2.5.70-mm9 Andrew Morton
1 sibling, 1 reply; 18+ messages in thread
From: Mingming Cao @ 2003-06-18 7:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Sat, 2003-06-14 at 23:20, Andrew Morton wrote:
> Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > On Sat, 2003-06-14 at 01:01, Andrew Morton wrote:
> >
> > > Was elevator=deadline observed to fail in earlier kernels? If not then it
> > > may be an anticipatory scheduler bug. It certainly had all the appearances
> > > of that.
> > Yes, with elevator=deadline the many fsx tests failed on 2.5.70-mm5.
> >
> > > So once you're really sure that elevator=deadline isn't going to fail,
> > > could you please test elevator=as?
> > >
> > Ok, the deadline test was run for 10 hours then I stopped it (for the
> > elevator=as test).
> >
> > But the test on elevator=as (2.5.70-mm9 kernel) still failed, same
> > problem. Some fsx tests are sleeping on io_schedule().
> >
> > Next I think I will re-run test on elevator=deadline for 24 hours, to
> > make sure the problem is really gone there. After that maybe try a
> > different Qlogic Driver, currently I am using the driver from Qlogic
> > company(QLA2XXX V8).
>
> Martin has just observed what appears to be the same failure on
> 2.5.71-mjb1, which is the deadline scheduler, using qlogicisp.
>
> Again, some IO appears to have been submitted but it never came back.
>
> It could be a bug in the requests queueing code somewhere, or in the device
> driver.
>
> So a good thing to do now would be to find the workload+IO
> scheduler+filesystem which triggers it most easily, and run that with a
> different device driver. The feral driver (drivers/scsi/isp/ in -mm)
> should be suitable for that test.
>
>
I re-run the many fsx tests with feral driver on 2.5.70mm9, ext3
fileystems, on deadline scheduler and as scheduler respectively. Both
tests passed. They were running for more than 24 hours without any
problems. So it could be a bug in the device driver that I used
before(QLA2xxx V8). Before the fsx tests failed on ext3 on either
deadline scheduler or as scheduler.
Thanks for your time and help on tracing down this problem. :)
Mingming
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-18 7:13 ` 2.5.70-mm9 Mingming Cao
@ 2003-06-18 7:38 ` Andrew Morton
2003-06-18 13:54 ` 2.5.70-mm9 James Bottomley
0 siblings, 1 reply; 18+ messages in thread
From: Andrew Morton @ 2003-06-18 7:38 UTC (permalink / raw)
To: Mingming Cao; +Cc: linux-kernel, linux-mm, James Bottomley
Mingming Cao <cmm@us.ibm.com> wrote:
>
> I re-run the many fsx tests with feral driver on 2.5.70mm9, ext3
> fileystems, on deadline scheduler and as scheduler respectively. Both
> tests passed. They were running for more than 24 hours without any
> problems. So it could be a bug in the device driver that I used
> before(QLA2xxx V8). Before the fsx tests failed on ext3 on either
> deadline scheduler or as scheduler.
Well it could be a bug in the driver, or it could be a bug in the generic
block/iosched area which was just triggered by the particular way in which
that driver exercises the core code.
James, do we have the latest-and-greatest version of the qlogic driver
in-tree? ISTR that there's an update out there somewhere?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-18 7:38 ` 2.5.70-mm9 Andrew Morton
@ 2003-06-18 13:54 ` James Bottomley
0 siblings, 0 replies; 18+ messages in thread
From: James Bottomley @ 2003-06-18 13:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Mingming Cao, Linux Kernel, linux-mm
On Wed, 2003-06-18 at 02:38, Andrew Morton wrote:
> Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > I re-run the many fsx tests with feral driver on 2.5.70mm9, ext3
> > fileystems, on deadline scheduler and as scheduler respectively. Both
> > tests passed. They were running for more than 24 hours without any
> > problems. So it could be a bug in the device driver that I used
> > before(QLA2xxx V8). Before the fsx tests failed on ext3 on either
> > deadline scheduler or as scheduler.
>
> Well it could be a bug in the driver, or it could be a bug in the generic
> block/iosched area which was just triggered by the particular way in which
> that driver exercises the core code.
>
> James, do we have the latest-and-greatest version of the qlogic driver
> in-tree? ISTR that there's an update out there somewhere?
I'm still currently keeping the qlogic and feral drivers out of tree.
Feral because Matthew Jacob thinks its not ready yet and Qlogic because
I was waiting for the must-fix list (I'll prod hch again for this).
You can get the current qlogic driver at
http://sourceforge.net/projects/linux-qla2xxx/
And I will update the BK tree at linux-scsi.bkbits.net
James
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-13 8:33 2.5.70-mm9 Andrew Morton
` (3 preceding siblings ...)
2003-06-14 7:51 ` 2.5.70-mm9 Mingming Cao
@ 2003-06-15 1:14 ` Diego Calleja García
2003-06-15 7:58 ` 2.5.70-mm9 Felipe Alfaro Solana
4 siblings, 1 reply; 18+ messages in thread
From: Diego Calleja García @ 2003-06-15 1:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Fri, 13 Jun 2003 01:33:37 -0700
Andrew Morton <akpm@digeo.com> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm9/
I had the following messages: (ide, ext3 without any option, SMP, AS, JBD
debugging enabled):
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 6Y060L0, ATA DISK drive
anticipatory scheduling elevator
[...]
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
[...]
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on hda5, internal journal
[...]
__mark_inode_dirty: this cannot happen
__mark_inode_dirty: this cannot happen
__mark_inode_dirty: this cannot happen
__mark_inode_dirty: this cannot happen
PPP: VJ decompression error
PPP: VJ decompression error
PPP: VJ decompression error
__mark_inode_dirty: this cannot happen
__mark_inode_dirty: this cannot happen
__mark_inode_dirty: this cannot happen
__mark_inode_dirty: this cannot happen
__mark_inode_dirty: this cannot happen
__mark_inode_dirty: this cannot happen
invalid via82xx_cur_ptr, using last valid pointer
invalid via82xx_cur_ptr, using last valid pointer
invalid via82xx_cur_ptr, using last valid pointer
PPP: VJ decompression error
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: 2.5.70-mm9
2003-06-15 1:14 ` 2.5.70-mm9 Diego Calleja García
@ 2003-06-15 7:58 ` Felipe Alfaro Solana
2003-06-15 11:22 ` 2.5.70-mm9 Diego Calleja García
0 siblings, 1 reply; 18+ messages in thread
From: Felipe Alfaro Solana @ 2003-06-15 7:58 UTC (permalink / raw)
To: Diego Calleja García; +Cc: Andrew Morton, LKML
On Sun, 2003-06-15 at 03:14, Diego Calleja García wrote:
> On Fri, 13 Jun 2003 01:33:37 -0700
> Andrew Morton <akpm@digeo.com> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm9/
>
>
> I had the following messages: (ide, ext3 without any option, SMP, AS, JBD
> debugging enabled):
>
> VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
> hda: Maxtor 6Y060L0, ATA DISK drive
> anticipatory scheduling elevator
> [...]
> kjournald starting. Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
> [...]
> EXT3 FS 2.4-0.9.16, 02 Dec 2001 on hda5, internal journal
> [...]
>
> __mark_inode_dirty: this cannot happen
> __mark_inode_dirty: this cannot happen
> __mark_inode_dirty: this cannot happen
> __mark_inode_dirty: this cannot happen
> PPP: VJ decompression error
> PPP: VJ decompression error
> PPP: VJ decompression error
> __mark_inode_dirty: this cannot happen
> __mark_inode_dirty: this cannot happen
> __mark_inode_dirty: this cannot happen
> __mark_inode_dirty: this cannot happen
> __mark_inode_dirty: this cannot happen
> __mark_inode_dirty: this cannot happen
> invalid via82xx_cur_ptr, using last valid pointer
> invalid via82xx_cur_ptr, using last valid pointer
> invalid via82xx_cur_ptr, using last valid pointer
> PPP: VJ decompression error
The "__mark_inode_dirty" message is a deugging leftofer from Andrew that
is spit out the first time the machine starts swapping out. You can
safely ignore it.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 2.5.70-mm9
2003-06-15 7:58 ` 2.5.70-mm9 Felipe Alfaro Solana
@ 2003-06-15 11:22 ` Diego Calleja García
0 siblings, 0 replies; 18+ messages in thread
From: Diego Calleja García @ 2003-06-15 11:22 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: akpm, linux-kernel
On 15 Jun 2003 09:58:29 +0200
Felipe Alfaro Solana <felipe_alfaro@linuxmail.org> wrote:
> The "__mark_inode_dirty" message is a deugging leftofer from Andrew that
> is spit out the first time the machine starts swapping out. You can
> safely ignore it.
>
Happy to hear that :)
It happened in the init scripts, so it seems coherent.
Anyway, i rebooted to fsck the root filesystem and it found a error (i
don't remember what though) and it fixed it.
^ permalink raw reply [flat|nested] 18+ messages in thread