Bug 437163

Sorry, I've accidentally added the lsmod twice on my post.

can you attach the dmesg output please?

Created attachment 297824 [details]
dmesg output

I forgot to add the Hardware info:

My motherboard is: MSI RS482M-IL 754 ATI Radeon Xpress 200 Micro ATX AMD Motherboard
Here is more info if you need:
http://www.newegg.com/product/product.aspx?Item=N82E16813130526R


IDE drive: (the troubled one)
hdparm -i /dev/sdb

/dev/sdb:

 Model=Maxtor 6L300R0                          , FwRev=BAH41G10,
SerialNo=L6174YYH            
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0:  ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

SATA drive: (the one that works fine)
hdparm -i /dev/sda

/dev/sda:

 Model=ST3808110AS                             , FwRev=3.AAH   , SerialNo=     
      5LS3YWT0
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

If you need more info, please ask.

Please post boot messages from the older kernel too.

Created attachment 298001 [details]
dmesg output for 2.6.23.1-42.fc8

DMA gets disabled on sdb because of simplex DMA. This doesn't happen on 2.6.23.

2.6.23:
scsi4 : pata_atiixp
scsi5 : pata_atiixp
ata5: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ff00 irq 14
ata6: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ff08 irq 15
ata5.00: ATAPI: _NEC DVD_RW ND-3520A, 1.04, max UDMA/33
ata5.00: configured for UDMA/33
ata6.00: ATA-7: Maxtor 6L300R0, BAH41G10, max UDMA/133
ata6.00: 586114704 sectors, multi 16: LBA48 
ata6.00: configured for UDMA/100
scsi 4:0:0:0: CD-ROM            _NEC     DVD_RW ND-3520A  1.04 PQ: 0 ANSI: 5
scsi 5:0:0:0: Direct-Access     ATA      Maxtor 6L300R0   BAH4 PQ: 0 ANSI: 5


2.6.24:
scsi4 : pata_atiixp
scsi5 : pata_atiixp
ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15
ata5.00: ATAPI: _NEC DVD_RW ND-3520A, 1.04, max UDMA/33
ata5.00: configured for UDMA/33
ata6.00: ATA-7: Maxtor 6L300R0, BAH41G10, max UDMA/133
ata6.00: 586114704 sectors, multi 16: LBA48 
ata6.00: simplex DMA is claimed by other device, disabling DMA
ata6.00: configured for PIO4
scsi 4:0:0:0: CD-ROM            _NEC     DVD_RW ND-3520A  1.04 PQ: 0 ANSI: 5
scsi 5:0:0:0: Direct-Access     ATA      Maxtor 6L300R0   BAH4 PQ: 0 ANSI: 5

The simplex would explain the bug. Quite why atiixp has decided to report
simplex now is a bit unclear. I'll take a look

Nothing obvious - no changes in the official base code that would explain it,
some in 2.6.25-rc are candidates if anyone backported the quirks changes.

Quick fix is to set ATA_FLAG_IGN_SIMPLEX but I would really like to understand
what has changed to trigger this

Interestingly enough, my laptop also uses the atiixp module and has an ide
drive.  It is currently using the 2.6.24 kernel and is working just fine.  The
model of this computer is Fujitsu S2110.

(In reply to comment #9)
> Nothing obvious - no changes in the official base code that would explain it,
> some in 2.6.25-rc are candidates if anyone backported the quirks changes.
> 

Very little change to the libata code in this kernel.
 hpt/serverworks mode masking fix
 disable DMA on ali chipsets for ATAPI

> Quick fix is to set ATA_FLAG_IGN_SIMPLEX but I would really like to understand
> what has changed to trigger this
> 

Same issue here on Asus Pundit-R with pata_atiixp (Fedora 9 Beta live CD, so
it's not fixed there yet...)

ata2.00: ATA-7: SAMSUNG HD160JJ, WU100-33, max UDMA7
ata2.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.00: simplex DMA is claimed by other device, disabling DMA
ata2.00: configured for PIO4

There seems to be a fix, the people at the Ubuntu forums seem to have solved it:
http://ubuntuforums.org/showthread.php?t=678153 by some module blacklisting/loading.

Smolt profile:
http://www.smolts.org/client/show_all/pub_4474aae3-fa6c-45c3-90cb-60aef7c38559

See comment #9 for a fix for the moment. It looks like either those bits are
getting bumped by something else. As the IXP is always fully dual channel the
comment #9 fix should sort Fedora out if pushed into the current kernel.

The Ubuntu thread says that blacklisting ata_generic solves the problem.

So I saw - but ata_generic never touches it and in fact it'll not even call the
probe function for it as there are no PCI ident matches. I'll have a poke around
but I think thats a red herring

I think I've already tried that trick and I remember it not working.  I can try
again if you want me to.

*** Bug 438918 has been marked as a duplicate of this bug. ***

Possible fix went in 2.6.24.4-68:
[PATCH] pata_atiixp: Simplex clear

It's not fixed for me in kernel-2.6.23.15-137.fc8 although it should be:

* Wed Apr 02 2008 Chuck Ebbert <cebbert> 2.6.24.4-68
- libata: clear simplex DMA before probing pata_atiixp devices (#437163)

scsi0 : pata_atiixp
scsi1 : pata_atiixp
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15
ata1.00: ATAPI: Optiarc DVD RW AD-7200A, 1.01, max UDMA/66
ata1.00: configured for UDMA/66
ata2.00: ATA-7: SAMSUNG HD160JJ, WU100-33, max UDMA7
ata2.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.00: simplex DMA is claimed by other device, disabling DMA
ata2.00: configured for PIO4
scsi 0:0:0:0: CD-ROM            Optiarc  DVD RW AD-7200A  1.01 PQ: 0 ANSI: 5
scsi 1:0:0:0: Direct-Access     ATA      SAMSUNG HD160JJ  WU10 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 1:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sda: sda1 sda2
sd 1:0:0:0: [sda] Attached SCSI disk

I mean kernel-2.6.24.4-74.fc8, and not kernel-2.6.23.15-137.fc8 (which is the
one that still works)

This has now been root caused thanks to some debugging and a very helpful email
I received.

There are two parts to the problem

1. Fedora incorrectly loads pata_acpi earlier than many other ATA drivers. It
*must* be loaded along with ata_generic/pata_legacy at the end.

2. When the ATI controller is put into power save and back (which occurs as the
acpi drive probes it) the device helpfully lose some configuration data and will
not let us restore it either.

Bug 1 needs fixing at the distro level and will bite other configurations

Bug 2 is being worked on

Kernel bits are fixed upstream. Assigning over to the anaconda team to fix the
installer

anaconda just uses udev and thus modprobe for loading modules these days --
they'll get loaded with 'modprobe <modalias>'.  So as long as that does the
right thing, then the right thing will occur in the installer

Multiple devices will get loaded for the same alias. Can we make modprobe load
specific devices before generic ones?

pata_acpi has this alias:  pci:v*d*sv*sd*bc01sc01i*

That matches every PCI IDE controller.

I just tested with kernel-2.6.25.4-10.fc8 on Fedora 8, doesn't work yet... Will
the fix be in a later errata update? Is there an update planned for F9? I could
create a respin then on my other machine and install it that way :)

Kernel patch went in 2.6.25.4-18

kernel-2.6.25.6-24.fc8 has been submitted as an update for Fedora 8

I can update module-init-tools wrt. the modalias matching, is this bug still happening on recent kernels?

(this bug was assigned to another account, reassigning to jcm)

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.