corruption

I reported both cases. That is, I started seeing it a few days ago. (But there is no problem during daily work. Also for example a diff between two kernel trees never gave corruption so far. It was only with diff between trees several GB in size, and I don't do that very often.)

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I wasn't trying to imply that you hadn't reported them well.

It's just that I was born with a highly developed case of Altzheimers, and I have trouble keeping details around in my head for more than about five minutes.

I'm half serious, btw. It's not that I don't have a good memory, but I tend to remember patterns and how things work, and I'm _really_ bad at keeping track of details. This is why I absolutely depend on people like Alan Cox etc who maintain lists of problems, and who are good at gathering reports on what kinds of machines see it etc. I just suck at it. I really do.

Anyway, it tentatively sounds like it might have been request corruption by the new re-merge code. It fits the details, you having IDE and all. I see that you can't at least easily reproduce it in pre3 any more, but if it turns out later that you still can, please holler. Loudly.

That still leaves the SCSI corruption, which could not have been due to the request issue. What's the pattern there for people?

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Linus, I confess that at the time (when I reproduced this problem on my SCSI-only 4way/6G machine) I did not realize the importance of observing the pattern or even just saving the log. No, I was _not_ just being stupid but rather it was _so_ easy to panic Linux at the time (for various reasons) that this one looked like just "yet another panic" somewhere.

Now, I am trying hard (lots of kernel compiles, bonnies, diff -urN between linux trees, cp -a linuxA linuxB etc etc) to reproduce it and I can't.

All I remember from memory was those messages about "freeing stuff not in datazone" etc. They were the same messages as I had on an IDE system and the same as Mohammad and others reported on the list recently.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

one more thing I remember when this happened:

a) lots of ld processes from kernel compilation were failing with ENOSPC although df(1) was showing plenty of memory and I could manually "touch ok" in the same filesystem just fine.

b) immediately restarting "make -j4 bzImage" would go on for quite a bit and then hit the same set of .c files and "run out of space" again.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

                                       ~~~~~~

space, I meant. *blush*

Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Consistent with bitmap corruption - counters are out of sync with the block/inode bitmaps.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Ehh, this is a stupid question, but I've had that happen too, and it turned out my /tmp filesystem was full, and it runs out of space only with certain large link cases (never anything else, because all the other stages of compilation are done with -pipe and do not use /tmp files).

I'm embarrassed to even mention this, but I'v ebeen confused myself.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

No, I did check my /tmp, I can assure you. Well, no, I did _not_ but I do not have a separate /tmp. I like huge root filesystems (until recently, when I realized that I most often corrupt/work in /usr/src so it's now separate and there are multiple roots for disaster recovery) so checking that root was OK implied /tmp was OK.

Also, running out of space in /tmp can hardly cause a bunch of ext2 messages about freeing blocks not in datazone etc.

Regards,
Tigran

PS. I do have another filesystem which is separate from root, i.e. /boot, again shared amongst all roots but I doubt ld(1) is storing anything in /boot :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I'm seeing this kind of corruption during the tar zxf.

$ tar zxf linux-2.4.0-test11.tar.gz 

gzip: stdin: invalid compressed data--format violated
tar: Unexpected EOF in archive
tar: Child returned status 1
tar: Error exit delayed from previous errors

Currently running kernel is 2.4.0-test11-ac4 and the file is correct. After the reboot there is no problem with uncompressing this file. It possible that this problem is fixed with test12-pre3, but in case its not I'm reporting this now (this already happend to me at least three times with this kernel - also there are no messages in the kernel log.

             There are three types of people in the world:
               those who can count, and those who can't.
  Zdenek Kabelac  http://i.am/kabi/ [email protected] {debian.org; fi.muni.cz}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/