In the kernel file siimage.c a new function has been added to test whether you have one of the older and somewhat defective seagate drives that require that hwif->rqsize be set to 15 rather than the much faster 128 which would suit all other drives. Unfortunately this test called "is_dev_seagate_sata", doesn't work properly for me (possibly due to my BIOS) and consequently any significant writes to the drive result in the entire drive becoming inaccessible. My workaround has been to remove this test which restores kernel 2.6.3 behaviour (which was to treat all sata drives as defective) which is fine for me, but does not suit others as it will halve their hard drive data transfer rates. Reproducible: Always Steps to Reproduce: 1. Mount a seagate drive eg. model ST380023AS on /dev/hdg1 2. Write to it. E.g. "mkreiserfs /dev/hdg1" and wait ages longer than normal 3. "cfdisk /dev/hdg" reports a failure Actual Results: I lost the ability to access the entire drive but for a reboot Expected Results: The filesystem would have been written and cfdisk would have worked afterwards. I have an Abit NF7-SV2.0 with the latest BIOS. Two seagate ST380023AS Serial ATA hard disk drives (one for windows, the other for media). It is the media drive I wish to access. Also hosting the main linux system I have a parallel ATA disk drive, which works fine.
Created attachment 29812 [details] More detailed information.
Created attachment 29891 [details, diff] This patch makes sure that problem seagate sata drives are checked for if the initial hardware probe failed To install this patch "cd" into the base directory of your kernel source tree and type # patch -p1 -i /path/to/recheck-seagate-sata.patch n.b. Replace /path/to with the actual path to your patch.
I have the same drive and siimage. This is not a problem with just your bios, siimage + seagate has been broken badly since 2.6.3. Ive worked very heavily with ide maintainer and libata maintainer. Libata seems to be working better for now. i really cant remember if i hacked it for 15k rqsize on last build or not though.
This is an upstream issue. Make sure the problem is still present in 2.6.7, and if so, please file a bug at bugzilla.kernel.org.
