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)
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
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.
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
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....
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.
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)
Created attachment 201381 [details] dmesg after boot to 2.6.22.5-76.fc7
Created attachment 201391 [details] lspci -vvxxx after boot
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...
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.
Tejun beat me to fixing an identical bug in the kernel bugzilla. Missing entry in a table, now fixed
Created attachment 202291 [details] patch to fix this problem
Thanks! I'll build a kernel with this patch and test it out RSN...
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?
Still not upstream; going into next Fedora 7 update.
Poke Andrew if it didnt make the current -mm
This patch is not in 2.6.23-rc8-mm1
It is in 2.6.23-rc8-git1.
Fix is in Fedora kernel 2.6.22.9-91.fc7, will be in the updates-testing repository soon...