Description of problem: When I'm copying from my dvd/rw to my SATA disc, whole system incredibly slow, besides from that transfer speed is ~1.x mbps. I think the most things is explained in additional info. Version-Release number of selected component (if applicable): 2.6.18-1.2869.fc6xen How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Complete system slow down, to a point where even moving your mouse/touchpad is so slow that cursor twitches. Transfer speed goes to minimum, copying a DVD takes from 15 to 25 min. Expected results: To not even feel any slow down, to have a 5/6.x mbps transfer rate. Additional info: Yesterday I did my first switch to Fedora, before that I was a Slackware user. I had a same problem with Slackware too, which I would solve by recompiling my kernel and adding append="libata.atapi_enabled=1" to my lilo. I tried doing the same thing with grub on Fedora, except I just added it as libata.atapi_enabled=1, but nothing happends. Please also note that with my own compiled kernel on Slackware everything worked right after adding that line to lilo. Also any other distro? I've tried Mandriva 2007.0 Free, that also worked right out of box, without even editting lilo or grub or kernel for that matter. I've also did a full system update, kernel was also updated, but without results.
Hello all. I think I may be suffering from the same problem as Adnan. I recently purchased a Gigabyte GA-965P-S3 and attempted to install FC6 on the system. I found that when connecting the drives to the 2port Intel SATA device, though the drives DO appear as sda, sdb, the installer would crash when it reaches the point of formating the drives. If I connect the two drives to the 4 port intel SATA chipset, I was able to install, however the time it takes to format is excessively long. When the drives are connected to the 4 port chipset, they appear as HD devices as opposed to SD... devices. Once the OS was installed, trying to use the environment is difficult due to the performance, any hard drive access results in the mouse stuttering as you move it across the screen. I have attached the output from lspci -vv, hdparm /dev/hda /dev/hda and dmesg. Please let me know if any more info is required.
Created attachment 145308 [details] LSPCI output Generated with lspci -vv > /tmp/lspci_output.txt
Created attachment 145309 [details] dmesg output generated with demsg > /tmp/dmesg_output.txt
Created attachment 145310 [details] hdparm output Generated with hdparm /dev/hda /dev/hdc > /tmp/hdparm_output.txt
Created attachment 145311 [details] lspci -vv, hdaparm /dev/sad, uname -r If any additional info needed please let me know.
Created attachment 145312 [details] lspci, lspci -vv, hdaparm /dev/sad, uname -r If any additional info needed please let me know.
Bug solved. Instead of libata.atapi_enabled=1 in my grub I used combined_mode=libata line. Also to my /etc/modprobe.conf I added line option libata atapi_enabled=1 I really think you should add this line by default, it cant do that much harm, think about it. Working even the better I expected, transfer speed is 8/9.x mbps. Full report on: http://absinthesyringe.blogspot.com/2007/01/fedora-6-libata-problem_11.html
Unfortunately this solution does not solve my problem with hard drive access.
is there any more information required for this bug's resolution?
I have just tried with the latest kernel for FC6 Updates Testing http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/6/i386/kernel-2.6.19-1.2895.fc6.i686.rpm Now, when I attempt to boot the system, I receive the following errors. hda: maz request size: 512KiB hda: lost interrupt (repeated 4 times) hda: Host Protected area detected. current capacity is 625140335 sextors (320071 MB) native capacity is 625142448 sectors (320072 MB) hda: lost interrupt hda: Host Protected area detected. hda: 625142448 sectors (320072MB) w/ etc... This continues and then moves on to hdc, and repeat's with the same errors. it takes about 5 minutes to work all the way through the above. The system appears to continue to then go through the boot process, repeating the lost interupt for hdc (I don't seem to see any thing for hda), however after another 10 minutes or so, I stopped the boot.
I have this resolved, to the extent that transfer speeds are now fairly normal. Adding hda=noprobe hdc=noprobe to the kernel boot perameters resolved the issue. Drives are now appearing as sda and sdb respectively, and transfer rates are around 50MB. I am not sure what you wish to do with this bug now though, I'm assuming some thing still needs resolving.
adnan, libata.atapi_enabled=1 has been the default for some time now. Douglas, there's been a sizable amount of libata changes in 2.6.20 that may help your situation, and I'll be pushing out another FC6 update rebasing to this hopefully early next week. In the meantime, stick with the noprobe workaround you have. Reopen/file a new bug if it's still problematic after that update.