Bug 247768 - [PATCH] libata pata_sis speed negotiation issue
[PATCH] libata pata_sis speed negotiation issue
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Alan Cox
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-11 07:37 EDT by Jeff Layton
Modified: 2014-06-18 03:36 EDT (History)
4 users (show)

See Also:
Fixed In Version: 2.6.22.9-91.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-03 20:13:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg after boot to 2.6.22.5-76.fc7 (41.42 KB, text/plain)
2007-09-20 18:08 EDT, Jeff Layton
no flags Details
lspci -vvxxx after boot (17.38 KB, text/plain)
2007-09-20 18:09 EDT, Jeff Layton
no flags Details
dmesg from boot to fc6 installer image (15.00 KB, text/plain)
2007-09-20 18:39 EDT, Jeff Layton
no flags Details
patch to fix this problem (1.04 KB, text/plain)
2007-09-21 10:53 EDT, Chuck Ebbert
no flags Details

  None (edit)
Description Jeff Layton 2007-07-11 07:37:17 EDT
I just updated one of my older laptops to F7. It seems to be having issues
negotiating speeds for the hard disk. Here's what shows up in the ring buffer
during boot:

ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011100 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011108 irq 15
scsi0 : pata_sis
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: ATA-5: TOSHIBA MK2017GAP, A5.04 H, max UDMA/100
ata1.00: 39070080 sectors, multi 16: LBA 
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: configured for UDMA/100
scsi1 : pata_sis
ata2.00: ATAPI, max UDMA/33
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access     ATA      TOSHIBA MK2017GA A5.0 PQ: 0 ANSI: 5
SCSI device sda: 39070080 512-byte hdwr sectors (20004 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
SCSI device sda: 39070080 512-byte hdwr sectors (20004 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: limiting speed to UDMA/66:PIO4
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080
ata1.00: configured for UDMA/66
ata1: EH complete


...so it looks like it starts out trying UDMA/100, and then falls back to
UDMA/66 when it sees errors. The issue is that it takes a very long time to boot
(several minutes) since it spends so much time trying UDMA/100. Is there a way
to force it down to UDMA/66 initially and speed up booting?

A bit of info, more available upon request:

# uname -a
Linux ginaz 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686 i686 i386
GNU/Linux

# grep 'model name' /proc/cpuinfo 
model name      : Pentium III (Coppermine)

# lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 31)
00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Bridge)
00:01.1 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast
Ethernet (rev 82)
00:01.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
00:01.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
00:01.4 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS PCI
Audio Accelerator (rev 02)
00:01.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)
00:02.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
00:0a.0 CardBus bridge: Texas Instruments PCI4410 PC card Cardbus Controller
(rev 02)
00:0a.1 FireWire (IEEE 1394): Texas Instruments PCI4410 FireWire Controller (rev 02)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 630/730
PCI/AGP VGA Display Adapter (rev 31)
Comment 1 Christopher Brown 2007-09-18 10:43:52 EDT
Hello Jeff,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris
Comment 2 Jeff Layton 2007-09-20 15:13:13 EDT
Just retested on 2.6.22.5-76.fc7 and the problem still exists there. I also
tested  2.6.23-0.187.rc6.git7 from rawhide and it also has the same issue.
Comment 3 Christopher Brown 2007-09-20 16:30:09 EDT
Okay, thanks for the info Jeff. I'm re-assigning this to the relevant maintainer
who may wish to review it further and add comment. You might want to try:

ide=nodma

as a boot parameter as I think this should speed the initial negotiation process
up. Running:

hdparm /dev/sda

before and after will give some idea of the change in throughput.

Cheers
Chris
Comment 4 Jeff Layton 2007-09-20 16:53:08 EDT
Thanks, ide=nodma didn't seem to make any difference on 2.6.22.5-76.fc7. Running
hdparm -i against the drive seemed to show that it was still using udma4 even
with that option.

I'll plan to test it on a rawhide kernel a little later, but it sort of looks
like that parameter might have been for the old PATA ide subsystem and not for
the new one based on libata....
Comment 5 Chuck Ebbert 2007-09-20 17:24:07 EDT
ide=nodma doesn't work with the new libata drivers. The latest kernel in testing
(2.6.22.6-something) has a "pata_dma" option but it needs to be added to
modprobe.conf:

options libata pata_dma=N

N =
0 off
1 use DMA for disk
2 use DMA for ATAPI
4 use DMA for CF

values may be or'd together

You need to rebuild the initrd after making the changes.
Comment 6 Alan Cox 2007-09-20 17:26:55 EDT
ide-nodma won't help on the old IDE. We've added a similar feature to the new
libata but it isn't in FC7 as it was added after FC7

Can you attach the dmesg after the boot and an lspci -vvxxx. I'm a bit puzzled
why UDMA100 fails and UDMA66 works (cable issues would take it down to UDMA33),
and its a unique bug so far- the other SiS bug we have is ATAPI specific.

Could be I have the max speed wrong for one obscure chip variant or the laptop
is doing interesting stuff. Do you know what speed it selects with FC6 (if you
just boot the FC6 install CD in text mode and switch to the shell prompt then
type dmesg you can check)
Comment 7 Jeff Layton 2007-09-20 18:08:54 EDT
Created attachment 201381 [details]
dmesg after boot to 2.6.22.5-76.fc7
Comment 8 Jeff Layton 2007-09-20 18:09:31 EDT
Created attachment 201391 [details]
lspci -vvxxx after boot
Comment 9 Jeff Layton 2007-09-20 18:39:01 EDT
Created attachment 201451 [details]
dmesg from boot to fc6 installer image

Thanks for having a look. Here's dmesg from a fc6 install image -- looks like
it negotiated to ata-100, if I'm reading this correctly.

Let me know if you need other info or ssh access to it...
Comment 10 Alan Cox 2007-09-20 18:46:06 EDT
Ok so this is a SiS630 which matches the entry

                { 0x0630, &sis_info66 },

which says

static const struct ata_port_info sis_info66 = {   
        .sht            = &sis_sht,
        .flags          = ATA_FLAG_SLAVE_POSS,
        .pio_mask       = 0x1f, /* pio0-4 */
        .udma_mask      = ATA_UDMA4,    /* UDMA 66 */
        .port_ops       = &sis_66_ops,
};


Revision of the host chip is 0x31 which should mean its actually the very first
UDMA100 revision. So its a 630/ET which is pretty obscure and a set of very
quirky code paths and off its own specific timings

Now I've dumped the brain context in the bug I'll take a look through that code
tomorrow and double check the special cases versus the docs and old driver.

Comment 11 Alan Cox 2007-09-21 06:35:43 EDT
Tejun beat me to fixing an identical bug in the kernel bugzilla. Missing entry
in a table, now fixed
Comment 12 Chuck Ebbert 2007-09-21 10:53:31 EDT
Created attachment 202291 [details]
patch to fix this problem
Comment 13 Jeff Layton 2007-09-21 11:08:55 EDT
Thanks! I'll build a kernel with this patch and test it out RSN...
Comment 14 Jeff Layton 2007-09-21 12:50:45 EDT
Compiled a 2.6.22.6-83 kernel with that patch and it boots much more quickly
now. For posterity, here's the interesting bits from dmesg:

SCSI subsystem initialized
libata version 2.21 loaded.
pata_sis 0000:00:00.1: version 0.5.1
ACPI: Unable to derive IRQ for device 0000:00:00.1
ACPI: PCI Interrupt 0000:00:00.1[A]: no GSI
scsi0 : pata_sis
scsi1 : pata_sis
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011100 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011108 irq 15
ata1.00: ATA-5: TOSHIBA MK2017GAP, A5.04 H, max UDMA/100
ata1.00: 39070080 sectors, multi 16: LBA 
ata1.00: configured for UDMA/100
ata2.00: ATAPI: QSI DVD-ROM SDR-081, EVA1, max UDMA/33
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access     ATA      TOSHIBA MK2017GA A5.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 39070080 512-byte hardware sectors (20004 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 0:0:0:0: [sda] 39070080 512-byte hardware sectors (20004 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk

Thanks again -- any idea when this patch might go upstream or into a fedora kernel?
Comment 15 Chuck Ebbert 2007-09-25 17:00:09 EDT
Still not upstream; going into next Fedora 7 update.
Comment 16 Alan Cox 2007-09-25 17:30:25 EDT
Poke Andrew if it didnt make the current -mm
Comment 17 Jeff Layton 2007-09-26 16:03:55 EDT
This patch is not in 2.6.23-rc8-mm1

Comment 18 Chuck Ebbert 2007-09-26 16:08:06 EDT
It is in 2.6.23-rc8-git1.
Comment 19 Chuck Ebbert 2007-09-28 13:37:40 EDT
Fix is in Fedora kernel 2.6.22.9-91.fc7, will be in the updates-testing
repository soon...

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