Description of problem:
I'm running a single seagate 250GB SATA drive as the main boot drive of the
system, non-raid. The motherboard apparently has some sort of deal going that
causes sata_nv to also load, but interestingly there are no ports on the
motherboard for connection. I wound up installing the promise card instead to
use the new hard disk:
$ lspci |grep -i promise
01:08.0 Mass storage controller: Promise Technology, Inc. PDC20575 (SATAII150
TX2plus) (rev 02)
dmidecode shows the motherboard Version: ASUS A7N266-VM ACPI BIOS Rev 1004/AA,
and /proc/cpuinfo shows model name : AMD Athlon(TM) XP 1700+
Upgrading to the kernel-2.6.17-1.2139_FC5 release caused the system to
completely fail to continue booting; I got a long string of error messages that
never get logged because the boot process past the grub bootloader never gets
commenting out the new kernel (or otherwise choosing the previous kernel-2.6.16-
1.2133_FC5 release) returns the boot process to normal and I am able to get in
just fine again. Rushed this one out, did we? :-)
Version-Release number of selected component (if applicable):
boot from kernel-2.6.17-1.2139_FC5 instead of kernel-2.6.16-1.2133_FC5
Steps to Reproduce:
1. yum update kernel :-)
system fails to boot beyond the grub screen, instead issuing pages of kernel
errors. (which unfortunately do not get logged as the boot process never gets
far enough to do so)
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-
I opened bug 199142, today, but I just realized that it might be a duplicate of
Although I do not get "pages of errors", the situation seems similar.
Could you confirm this?
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
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
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
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:
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
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
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
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.
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
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 ?