This is probably a duplicate of bug 196556

possibly but doubtful.

different kernel (SMP kernel vs plain kernel)
different SATA card (Intel vs Promise)
and perhaps importantly, different Drive setup (RAID vs non-RAID, i.e. no 
device-mapper, dm-raid, etc)

It maps to the other bug report on the sole circumstance that it's purely SATA-
related. 

I opened bug 199142, today, but I just realized that it might be a duplicate of
this one.
Although I do not get "pages of errors", the situation seems similar.

Could you confirm this?

Thanks.

I have the same situation here. My boot hangs with message "ata3: disabling
port" in a Seagate SATA non-raid (Promise controller).
My linux Installation is on a normal IDE 133, but I have a SATA with others
partitions in the same machine.

I skipped a couple of Kernel updates, due to being overly busy and finally got 
around to trying out the now current kernel-2.6.17-1.2174_FC5, and can confirm 
that it exhibits the same issues as kernel-2.6.17-1.2139_FC5. I am still 
running kernel-2.6.16-1.2133_FC5. (similar results in bug 196556)

I strongly recommend you look at how the promise SATA driver changed between 
2133 and 2139 as that may help indicate why it's panic-ing so early I can't get 
a dump. 

I haven't yet had the wherewithal to stick a null-modem cable on the box and 
attempt to suck down the dump to another machine (as someone had suggested was 
possible), but I *will* attempt to do this as soon as I am able, (particularly 
if it becomes necessary to do so due to an apparent lack of interest in this 
showstopping bug.) 

I can't update my kernel and I am NOT happy about it. Particularly if some of 
these updates are security related. 

with FC6 right around the corner and using 2.6.17 kernels, I am debating 
changing the severity to Urgent. Thoughts?

Anybody who's having this problem, please test the latest development kernel
(the .fc6 kernels) for this problem.  If we can dupe on fc6, we can mark this
bug as a release blocker.

in a conversation with Jesse on freenode, and noting that currently: 
lsmod |grep -i sata
sata_nv                 9157  0 
sata_promise           11333  3 
libata                 53969  2 sata_nv,sata_promise
scsi_mod              126185  4 sg,sata_promise,libata,sd_mod

He suggested I blacklist the sata_nv driver via /etc/modprobe.d/blacklist (why 
it's loading when my mobo has no SATA ports is a fun exercise in confusion) and 
remove the entry in /etc/modprobe.conf, and then run 

mkinitrd -v -f /boot/initrd-2.6.17-1.2174_FC5.img 2.6.17-1.2174_FC5

rebooting with this initrd resulted in no change (still kernel panics), so it 
does not seem to be an interaction between sata_promise and sata_nv at the 
present moment, for my configuration.

I have a similar issue with an equivalent setup (AXP2500+, MSI MS-6570, same
SATA controller). 

Got the null pointer deferencing oops mentionned in bug #199142. It seems to
happens when the driver is probing the PATA port (ata3) on the controller. I
found an interesting thread on LKML for a similar issue:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0606.1/0230.html

I'm quite new to Fedora, so I don't know if the kernel uses some patches from
the -mm branch. Judging on the thread, a fix might not be available soon...

Anyway, I'm downloading FC6-test2 right now. Will report the behaviour on this
release ASAP.

Created attachment 134325 [details]
Boot log for FC5 with kernel-xen.i686 2.6.17-1.2175

Boot log for kernel-xen0.i686 2.6.17-1.2174_FC5, captured on a serial line.
Reproductible with the latest non-Xen equivalent (kernel.i686
2.6.17-1.2174_FC5).

Created attachment 134328 [details]
Boot log for kernel.i686 2.6.17-1.2517.fc6

Boot log for kernel.i686 2.6.17-1.2517.fc6, captured on a serial line.

This is the result I got after booting the FC6-test2 installation DVD. Note
that I cannot proceed to an installation since my system hard drive is on that
controller.

It's quite similar to the behaviour in the FC5 2.6.17 kernels. It fails on 
pdc_sata_scr_read instead of pdc_sata_scr_write, though. Still, it's still an
issue for the upcoming FC6.

kernel-2.6.17-1.2187_FC5 recently installed on my system still exhibits the 
exact same issue.

HOW many kernel updates have there been since kernel-2.6.16-1.2133_FC5 that I 
cannot take advantage of the security fixes for, because of this issue? 

I'm at least glad this is a show-stopper for FC6, as I'd hate for this to 
continue in a new release. It's bad enough it's gone on this long for FC5. 

What's going on over there? O_o 

This very well may be an upstream issue.  Scott, can you verify with a rawhide
install, since rawhide is using 2.6.18?  If its an upstream issue, getting it
fixed for FC6 is doubtfull.

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

kernel-2.6.18-1.2200.fc5 recently installed on my system still exhibits the 
exact same issue. 

I refuse to scream.

I don't know if this is the same problem or not.

FC6 clean install on ASUS P4C800-E Deluxe refused to see the partitions on the
two SATA drives on the Promise controller.  The drives are seen, but no
partitions in any of the /dev/disk/ directories.  The SATA drives are used as
software raid devices, BIOS Promise raid is not used.

Resolution:  reinstalled with linux nompath.  All SATA partitions seen, are
present in /dev/disk directories and all software raid devices seen and root is
now on an LV over software raid 5.  Life is good with this system.  Now to
resolve some kind of software raid issue with a similar system, but using Intel
SATA as well as Promise SATA.

kernel-2.6.18-1.2257.fc5 that I installed on Tue 19 Dec 2006 08:47:51 PM EST 
according to rpm -qa kernel --last, has resolved the issue to my satisfaction 
in that I am able to boot with it. whether there are still nefarious underlying 
issues I am still unsure, but a month of testing with it has shown no oddities 
with the filesystem, although I've used tune2fs to set
Maximum mount count:      15
and 
Check interval:           604800 (1 week)
so that it gets checked periodically as I boot back and forth from windows to 
linux and vice versa.

FC6 will require a respin with this kernel or later (which I believe is already 
in the works or completed) in order for me to be able to boot with and install 
it, but other than that, I can consider this issue resolved. 

Has anyone else experienced the same ?