From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Description of problem: anaconda is throwing an unhandled error and asking me to report it to you. It looks to me like a hardware compatibility problem, but it doesn't look like anything specific to anaconda. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Tried to install, several different ways, gui, text, expert, different package combos, and as simple as possible. There are already 2 os's on the machine, the swap is going in as hda4 and the root as hda2, swap is 512mb root is 6100mb, all < 1024 cylinders. 2. After anaconda says it's copying the image to the drive, it hangs loose for about 1 minute and then throws the exception. Actual Results: Unable to install Expected Results: should be able to install Additional info: I have an FIC SD11 w/ Athlon 700, 256mb, Maxtor UDMA/66 40gb 7200rpm. This motherboard's IDE controller is not quite 100% - after I put the system together I found out they have a known problem with this particular maxtor drive - the latest BIOS patch is installed which essentially disables UDMA/66. Various Windows OS's (95, NT, 2K) install and run fine. I think the redhat ide driver is trying to do something that locks up the hardware. After the problem occurs, the machine has to be powered off before the drive is accessible - if rebooted warm, it just hangs waiting for the drive. Maybe there is an option for disabling UDMA in the disk driver? * It seems to me that anaconda should do something with hardware failure other than just dump a traceback. * Here's some slices out of the dump: ... File "/usr/lib/anaconda/packages.py", line 459, in doPreInstall File "/usr/lib/anaconda/fsset.py", line 631, in write ([ f = open(prefix+"/etc/fstab","w") ]) IOError: [Errno 2] No such file or directory: '/mnt/sysimage/etc/fstab' ... <6>Journalled Block Device driver loaded <6>cdrom: open failed. <6> hda: hda1 hda2 hda3 < hda5 hda6 > hda4 <6>Adding Swap: 522104k swap-space (priority -1) <4>hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } <4>hda: dma_intr: error=0x84 { DriveStatusError BadCRC } [(previous 2 Error lines repeat 5 more times)] <4>hda: timeout waiting for DMA <4>ide_dmaproc: chipset supported ide_dma_timeout func only: 14 <4>hda: status timeout: status=0xd1 { Busy } <4>hda: drive not ready for command <4>ide0: reset timed-out, status=0x80 <4>hda: status timeout: status=0x80 { Busy } <4>hda: drive not ready for command 4 <4>end_request: I/O error, dev 03:02 (hda), sector 48552 <4>end_request: I/O error, dev 03:02 (hda), sector 48560 <4>end_request: I/O error, dev 03:02 (hda), sector 48568 [(repeats 1000+ times, sectors increasing)] Dump attachment to follow.
Created attachment 35722 [details] the dump from anaconda
I think UDMA should be disabled by default. Just to be sure, though, you can boot the installer with 'linux ide=nodma'. However, I suspect that you might have a bad cd. Did you check the md5sums of the ISOs before using them?
I've looked and haven't found any information on how to check the cd. Do you have a link with a tool and/or the correct sums? I don't normally test a brand new cd before using it...
Nevermind...the kernel messages were for hda...which is the hard drive. My fault. We get so many bad burned cd reports that it's always my first reaction. Did you try booting with 'linux ide=nodma'? Does that help?
Yep, that did it, thanks. Installed and came up, no problems. I guess that's one for the knowledge base. The installed kernel seems to run fine without the ide=nodma parameter; maybe I've just been lucky so far?
I'm not a kernel hacker, so I can't say for sure why the installed kernel works with DMA on, but the boot kernel doesn't. The boot disks do use a stripped down kernel (so it can fit on a floppy), and for whatever reason it looks like it doesn't fall back to non-DMA mode for certain hard drives. That's just a guess. You could probably leave DMA on in the installed system and be just fine. I would turn it off if you see problems, but otherwise, I'd leave it. Of course, if you are running a mission critical machine, then maybe you want to be on the safe side...but that's up to you. I'm going to change the component to the kernel. The kernel guys will probably be interested in this.
DMA in the BOOT and normal kernel is the same for disks; for CDROM drives we disable DMA in the -BOOT kernel though. So I can't really explain why the normal kernel works for you.....