Bug 197441 - kernel-2.6.17-1.2139_FC5 breaks promise drivers for _non-raid_ SATA
Summary: kernel-2.6.17-1.2139_FC5 breaks promise drivers for _non-raid_ SATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-01 15:29 UTC by Scott R. Godin
Modified: 2013-07-03 02:29 UTC (History)
8 users (show)

Fixed In Version: kernel-2.6.18-1.2257.fc5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-08-14 17:40:29 UTC

Attachments (Terms of Use)
Boot log for FC5 with kernel-xen.i686 2.6.17-1.2175 (15.93 KB, text/plain)
2006-08-16 16:55 UTC, Patrick Clément-Bonhomme
no flags Details
Boot log for kernel.i686 2.6.17-1.2517.fc6 (10.85 KB, text/plain)
2006-08-16 17:12 UTC, Patrick Clément-Bonhomme
no flags Details

Description Scott R. Godin 2006-07-01 15:29:09 UTC
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 
that far. 

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):

How reproducible:
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 :-)
Actual results:
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)

Expected results:
normal boot.

Additional info:

Comment 1 Keith G. Robertson-Turner 2006-07-02 00:47:47 UTC
This is probably a duplicate of bug 196556

Comment 2 Scott R. Godin 2006-07-03 14:53:33 UTC
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-

Comment 3 Josep 2006-07-17 22:58:22 UTC
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?


Comment 4 Jose Cardozo 2006-07-26 13:04:14 UTC
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.

Comment 5 Scott R. Godin 2006-08-14 07:39:46 UTC
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?

Comment 6 Jesse Keating 2006-08-14 12:19:30 UTC
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.

Comment 7 Scott R. Godin 2006-08-14 13:01:53 UTC
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.

Comment 8 Patrick Clément-Bonhomme 2006-08-16 02:44:40 UTC
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:

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.

Comment 9 Patrick Clément-Bonhomme 2006-08-16 16:55:51 UTC
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

Comment 10 Patrick Clément-Bonhomme 2006-08-16 17:12:08 UTC
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.

Comment 11 Scott R. Godin 2006-09-29 10:39:19 UTC
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 

Comment 12 Jesse Keating 2006-09-29 13:28:15 UTC
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.

Comment 13 Dave Jones 2006-10-16 20:13:59 UTC
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.

Comment 14 Scott R. Godin 2006-10-16 23:32:11 UTC
kernel-2.6.18-1.2200.fc5 recently installed on my system still exhibits the 
exact same issue. 

I refuse to scream.

Comment 15 Clyde E. Kunkel 2006-10-24 02:57:50 UTC
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.

Comment 16 Scott R. Godin 2007-01-22 22:06:10 UTC
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 ?

Note You need to log in before you can comment on or make changes to this bug.