Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.)

[Steven Cole]

On Friday 14 May 2004 10:53 am, Andy Isaacson wrote:

> So, in the oddball config department, you've got a ISAPnP modem over
> which you're running PPP; CONFIG_PREEMPT is on.
> 
> That corruption size really does make me think of network packets, so
> I'm tempted to blame it on PPP.  Can you find out the MTU of your PPP
> link?  "ifconfig ppp0" or something like that.

ppp0      Link encap:Point-to-Point Protocol
          inet addr:216.31.65.245  P-t-P:216.31.65.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:123 errors:0 dropped:0 overruns:0 frame:0
          TX packets:152 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:77312 (75.5 Kb)  TX bytes:8212 (8.0 Kb)
> 
> Can you try doing something like
> 
> #!/bin/sh
> x=0
> while true; do
> 	bk clone -qlr40514130hBbvgP4CvwEVEu27oxm46w testing-2.6 foo
> 	(cd foo; bk pull -q)
> 	rm -rf foo
> 	x=`expr $x + 1`
> 	echo -n "$x "
> done
> 
> (I just pulled that key at random out of the kernel repository; there's
> nothing special about it except that it's far enough back for the revert
> and pull to be very involved operations.)
> 
> That ought to do a nice test of the CPU, memory, disk, and kernel sans
> PPP.  If that loop runs for, say, 10 iterations without errors, keep it
> running and try doing some non-BK network IO for a half hour (or two
> iterations of the clone/pull loop, whichever is longer) and see if it
> fails.  You might want to increase the runtimes, say, overnight and two
> hours of network activity, if you don't see any failures.
> 
> This test is designed to check the theory that in your config, PPP
> somehow corrupts random buffer cache pages.

It didn't need PPP to fail.
It looks like it failed on the 7th iteration of the script supplied by Andy.

[snipped list of files]
sound/core/SCCS/s.Kconfig
Your repository should be back to where it was before undo started
We are running a consistency check to verify this.
check passed
Undo failed, repository left locked.
WARNING: deleting orphan file /home/steven/tmp/bk_clone2_mVmrsk
Entire repository is locked by:
        RESYNC directory.
ERROR-Unable to lock repository for update.
6

[steven@spc BK]$ ls -ls foo/RESYNC/SCCS/*
40048 -r--r--r--  1 steven steven 41007273 May 14 18:08 foo/RESYNC/SCCS/s.ChangeSet
   68 -r--r--r--  1 steven steven    67791 May 14 18:11 foo/RESYNC/SCCS/s.CREDITS
   76 -r--r--r--  1 steven steven    75264 May 14 18:11 foo/RESYNC/SCCS/s.MAINTAINERS
  124 -r--r--r--  1 steven steven   124747 May 14 18:11 foo/RESYNC/SCCS/s.Makefile
  
Let me know if you want any of these files.  I can compress them and send them
the usual way.

The kernel was 2.6.6 plus whatever is in Linus' tree, and bk was 3.0.4.

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/