From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310 Description of problem: Kernel oopses while installing `Everything' on an Athlon 1.4GHz box. Installation (in text mode) failed half-way through the 2nd CD. MB is A7V133. The CD-ROM was hdb, whereas the installation disk has hdg. Using two previously-created, but empty ext3 partitions (hdg1 and hdg5), of 32MB and 5GB, respectively, as `/' an `/boot' for this installation. Oh, I used ide0=ata66 and ide1=ata66 as kernel command-line flags when booting. Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: 1.Not sure which of the above would trigger the problem. I'm trying with mem=nopentium now, even though it has never been needed on my 7.2 installation. If this fails, I'll try noathlon. *crosses fingers* Actual Results: Typed in; typos are all mine: Oops: 0002 CPU: 0 EIP: 0010:[<c013383d>] Not tainted EFLAGS: 00010282 EIP is at eax: 00000000 ebx: 00000001 ecx: dc2d7780 edx: c02989b0 esi: 00000001 edi: 00000001 ebp: 00000002 esp: eda23e0c ds: 0018 es: 0018 ss: 0018 Process kjournald (pid: 78, stackpage=eda23000) Stack: dc2d7780 c0134234 dc2d7780 00000001 00000001 00000002 c01815b4 00000001 dc2d7780 00000029 c0134245 dc2d7780 c018174c dc2d7780 d51d9630 00000200 d51d9630 f084ae49 cb17d680 00000003 ef2f9294 ef2f9200 dceeaae0 00000040 Call Trace: [<c0134234>] [<c01815b4>] [<c0134245>] [<c018174c>] [<f084ae49>] [<f084a15e>] [<f084c7f2>] [<f084c6e0>] [<c0106eb2>] [<f084c6f0>] Code: 89 48 20 8b 02 89 48 24 8d 04 9d 00 00 00 00 ff 80 b8 89 29 Expected Results: Successful installation. Additional info:
Hmm... This machine seems to be showing signs of hardware problems. Even with 7.2 it has started corrupting data copied among disks. I thought I had fixed this problem before by canging some BIOS settings, but it seems that the problem is back, and the changes I had made before are still in effect. Uh oh. Time to invoke the warranty for real. FWIW, I've just installed 7.3beta on an identical machine, following an identical procedure, without absolutely any problems. It didn't even give errors about corrupted RPM databases like the broken machine did. I'm closing this bug. Sorry about the noise.
Created attachment 51144 [details] decoded oops
Typical, just once I finish decoding the oops I find the bug closed. :-) Yes, the oops trace is a buffer LRU list corruption, which is a typical indicator of bad hardware.