Bug 2561
Summary: | NFORCE2 PCI code corrupts data | ||
---|---|---|---|
Product: | Drivers | Reporter: | Patola (patolinux) |
Component: | PCI | Assignee: | Greg Kroah-Hartman (greg) |
Status: | REJECTED INVALID | ||
Severity: | high | ||
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.5 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Patola
2004-04-21 19:39:42 UTC
Also, this bug is related to bug 2252. While it is about data corruption, it also seems to lead to lockups. I'll try the temporary solution of 2252 - upgrade to a SMP kernel - to see if this gets any better. Ok, the tests with the SMP kernel failed. SMP doesn't help. As a side note, I made an initrd file without amd74xx and siimage and it boots normally without enabling DMA's for the drives, and as such everything works normal - but with no DMA, that means: sloooooooooooooooooow! I am gonna make it md5sum the same files the whole day to be sure of this. DAMN!
That was too good to be true.
No amd74xx loaded, also not included in the kernel. So this is not a bug of this
module. Yet I still have problems with data corruption:
$ rm a.txt
$ x=0
$ while [ $x -lt 16777216 ]
> do
> let x+=1
> echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >> a.txt
> done
$ grep -nv aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa a.txt
908281:aaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2655130:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaa
4707226:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaa
6425530:aaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
8729120:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaa
10186666:aaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
12751833:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaa
$ grep -nv aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa a.txt
869904:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaa
908281:aaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4685486:aaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4707226:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaa
8521421:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaa
8729120:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaa
12381996:aaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
12751833:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaa
16098328:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaa
$ grep -nv aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa a.txt
908281:aaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
3178221:aaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4707226:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaa
7031297:aaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
8729120:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaa
10908003:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaa
12751833:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaa
14633599:aaaaaaaacaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Additional information... Making the same scripts with 'c' instead of 'a', I could notice that it doesn't flip bits: it just set them, so a file with many 'c's goes on uncorrupted. $ grep -nv cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc c.txt $ grep -nv cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc c.txt $ grep -nv cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc c.txt $ Ok, I just tested it in windows for the fourth time and this time the error happened in that stupid operational system too. So it's a hardware problem. Sorry to waste anybody's time. I am rejecting this bug as invalid. Goodbye and thanks for all the fish. |