Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 172913 - sata_promise broken (kernel-2.6.14-1.1637_FC4)
Summary: sata_promise broken (kernel-2.6.14-1.1637_FC4)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: FCMETA_SATA
TreeView+ depends on / blocked
 
Reported: 2005-11-11 08:19 UTC by Andreas Bierfert
Modified: 2013-07-03 02:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-12-16 01:42:13 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
dmesg of 2.6.14-1.1637_FC4 (deleted)
2005-11-11 08:19 UTC, Andreas Bierfert 		no flags Details
View All

Description Andreas Bierfert 2005-11-11 08:19:45 UTC 
Description of problem:
I have 2 disks attached to my promise sata controler and one of them is not
found anymore with the 2.6.14-1.637_FC4 kernel

Version-Release number of selected component (if applicable):
kernel version: kernel-2.6.14-1.1637_FC4

module info:
filename:       /lib/modules/2.6.14-1.1637_FC4/kernel/drivers/scsi/sata_promise.ko
author:         Jeff Garzik
description:    Promise ATA TX2/TX4/TX4000 low-level driver
license:        GPL
version:        1.02
vermagic:       2.6.14-1.1637_FC4 686 REGPARM 4KSTACKS gcc-4.0

lspci:
00:08.0 RAID bus controller: Promise Technology, Inc. PDC20376 (FastTrak 376)
(rev 02)
	Subsystem: ASUSTeK Computer Inc. A7V8X motherboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 96 (1000ns min, 4500ns max), Cache Line Size 08
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at d400 [size=64]
	Region 1: I/O ports at d000 [size=16]
	Region 2: I/O ports at b800 [size=128]
	Region 3: Memory at e4000000 (32-bit, non-prefetchable) [size=4K]
	Region 4: Memory at e3800000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: <available only to root>


If you take a look at the 2.6.14 dmesg:
sata_promise version 1.02
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ
 10
ata1: SATA max UDMA/133 cmd 0xF8862200 ctl 0xF8862238 bmdma 0x0 irq 10
ata2: SATA max UDMA/133 cmd 0xF8862280 ctl 0xF88622B8 bmdma 0x0 irq 10
input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1
ata1: no device found (phy stat 00000000)
scsi0 : sata_promise
ata2: dev 0 cfg 49:2f00 82:74eb 83:5bea 84:4000 85:7469 86:1802 87:4003 88:203f
ata2: dev 0 ATA, max UDMA/100, 160836480 sectors:
ata2(0): applying bridge limits
ata2: dev 0 configured for UDMA/100
scsi1 : sata_promise
  Vendor: ATA       Model: IC35L080AVVA07-0  Rev: VA4O
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
SCSI device sda: drive cache: write back
 sda: sda1

and compare it to kernel-2.6.13-1.1532_FC4 (and probably before...):

sata_promise PATA port found
ata1: SATA max UDMA/133 cmd 0xF881A200 ctl 0xF881A238 bmdma 0x0 irq 10
ata2: SATA max UDMA/133 cmd 0xF881A280 ctl 0xF881A2B8 bmdma 0x0 irq 10
ata3: PATA max UDMA/133 cmd 0xF881A300 ctl 0xF881A338 bmdma 0x0 irq 10
input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1
ata1: no device found (phy stat 00000000)
scsi0 : sata_promise
ata2: dev 0 cfg 49:2f00 82:74eb 83:5bea 84:4000 85:7469 86:1802 87:4003 88:203f
ata2: dev 0 ATA, max UDMA/100, 160836480 sectors:
ata2(0): applying bridge limits
ata2: dev 0 configured for UDMA/100
scsi1 : sata_promise
ata3: dev 0 cfg 49:0f00 82:346b 83:4301 84:4000 85:3469 86:0001 87:4000 88:203f
ata3: dev 0 ATA, max UDMA/100, 58633344 sectors:
ata3: dev 0 configured for UDMA/100
scsi2 : sata_promise
  Vendor: ATA       Model: IC35L080AVVA07-0  Rev: VA4O
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
SCSI device sda: drive cache: write back
 sda: sda1
Attached scsi disk sda at scsi1, channel 0, id 0, lun 0
  Vendor: ATA       Model: QUANTUM FIREBALL  Rev: APL.
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sdb: 58633344 512-byte hdwr sectors (30020 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 58633344 512-byte hdwr sectors (30020 MB)
SCSI device sdb: drive cache: write back
 sdb: sdb1 sdb2 sdb3 sdb4

You see that sdb is missing from the 2.6.14 dmesg (which is attached as a whole)
Comment 1 Andreas Bierfert 2005-11-11 08:19:45 UTC 
Created attachment 120921 [details]
dmesg of 2.6.14-1.1637_FC4
Comment 2 Andreas Bierfert 2005-11-14 07:24:08 UTC 
Hm, upon further investigation this might not be a sata_promise issue but a
libata issue related to the recent changes...

but adding 'options libata atapi_enabled=1' to modprobe.conf sadly does not do
the trick... :/
Comment 3 Dave Jones 2005-11-14 19:26:13 UTC 
ATAPI is for CD-ROMs and such, and should have nothing to do with your missing disk.
Comment 4 Andreas Bierfert 2005-11-14 21:19:22 UTC 
OK the little voice in my head was not wrong then ^^ good to know... I just
figured because it was the only visible change that I could find (by just
looking at the module version and parameters and such...) and since the drive is
attached to the 3rd port of the sata controler which actually is a PATA port I
tought it might have something to do with this...

If you need more info or you want me to try out something just yell +)
Comment 5 Andreas Bierfert 2005-11-15 13:12:31 UTC 
same with 1640_FC4
Comment 6 Andreas Bierfert 2005-11-23 21:40:46 UTC 
same with 1641_FC4
Comment 7 Andreas Bierfert 2005-11-28 22:47:59 UTC 
same with 1644_FC4
Comment 8 Need Real Name 2005-11-30 00:30:09 UTC 
I have the same problem, with a FastTrak 376 which has only PATA ports. I can
confirm that the problem still exists with kernel 2.6.15-rc2, which I built from
sources using "make oldconfig" with the config from 1644_FC4.
Comment 9 Roland Wintgen 2005-11-30 20:52:12 UTC 
I can confirm the same problem using an onboard FastTrak 378 controller (Promise
PDC 20378) on a ASUS P4C800-E Deluxe motherboard.
The SATA ports work in all kernel versions whereas the PATA port doesn't
recognize an attached HD using kernel-smp-2.6.14-1.1637_FC4 or
kernel-smp-2.6.14-1.1644_FC4. As a workaround I switched back to
kernel-smp-2.6.13-1.1532_FC4
Comment 10 Need Real Name 2005-12-06 06:02:59 UTC 
The problem goes away, i.e. the behavior reverts to that of 2.6.13-1.1532_FC4,
when I use kernel 2.6.15-rc5-mm1. Perhaps there was some code from the mm-
series enabled in the 2.6.13 FC4 kernels that disappeared in the 2.6.14 FC4 kernels.
Comment 11 Andreas Bierfert 2005-12-08 07:48:27 UTC 
Seems like mm adds support for the PATA ports of some controllers with some
patches (see the new compile options and changes in libata... probably from 
git-libata-all.patch or something...)

Coule somebody rh please respond? Dave maybe put this in your FC4 kernel dir for
the people subscribed here to test?
Comment 12 Dave Jones 2005-12-10 05:01:13 UTC 
afaik, those patches are for using older PATA chipsets (currently supported by
drivers/ide/) with the libata core.  They don't add PATA-on-SATA support.

However, I just checked something in that *should* fix this. I hope.
Test out 1649 when it hits people.redhat.com/davej/kernels/Fedora/FC4/ in a few
hours.
Comment 13 Andreas Bierfert 2005-12-10 10:15:22 UTC 
Ok, with 1649 I get a crash at boot time (sry):

[<c01d92a6>] pci_register_driver+0x89/0xa9
[<c0134238>] sys_init_module+0xbb/0x1b5
[<c0102ea1>] syscall_call+0x7/0xb
Code: 60 45 61 00 89 c1 b8 ff ff ff ff 83 fa 02 77 0a 8d 04 12 01 c0 03 41 58 8b
00 c3 53 89 c3 83 fa 02 77 0a 8d 04 12 01 c0 03 43 58 <89> 08 5b c3 55 57 56 53
89 c3 8b 10 8b ba c4 05 00 00 0f b6 40
Error: /bin/insmod exited abnormally with value 0 ! (pid 347)

Sorry this i all I got typed up from the screen. I suspect that it is trying to
insert the sata modules and crashs while detecting the drives.

Hope that helps if you need further infos let me know...
Comment 14 Andreas Bierfert 2005-12-11 22:03:53 UTC 
Same, as you might have guessed, with 1650... ;)
Comment 15 Dave Jones 2005-12-12 22:58:17 UTC 
can you boot with vga=791 (Which gets  you more lines of text on the screen)
and see if you can get some of the earlier lines ?
Comment 16 Andreas Bierfert 2005-12-12 23:25:59 UTC 
[<c01d90c7>] __pci_device_probe+0x36/0x42
[<c01d90f1>] pci_device_probe+0x1e/0x35
[<c0238ba1>] driver_probe_device+-0x35/0x98
[<c0238cb6>] __driver_attach+0x45/0x47
[<c023843b>] bus_for_each_dev+0x39/0x47
[<c0238cce>] driver_attach+0x16/0x1a
[<c0238c71>] __driver_attach+0x0/0x47
[<c02387f5>] bus_add_driver+0x63/0xa9

There is still something missing at the top but at least a bit more...
Comment 17 Dave Jones 2005-12-13 03:16:23 UTC 
I just pushed out another test kernel (-1651) at
http://people.redhat.com/davej/kernels/Fedora/FC4 , can you try that ?
Comment 18 Andreas Bierfert 2005-12-13 08:17:17 UTC 
:) Works again with 1651. Thank you.
Comment 19 Dave Jones 2005-12-13 08:36:20 UTC 
awesome, thanks for testing. This will go out as a proper update in a day or so.
Comment 20 Andreas Bierfert 2005-12-13 09:18:54 UTC 
No Problem... sounds great :)
Note You need to log in before you can comment on or make changes to this bug.