Bug 243033
Summary: | kernel 2.6.21-1.3207.fc8 takes very loooong time to loose disks due to ata problems | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | 8 | CC: | triage | ||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | bzcl34nup | ||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2008-11-26 16:52:59 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Michal Jaegermann
2007-06-06 23:15:56 UTC
Created attachment 156408 [details]
dmesg for 2.6.21-1.3207.fc8 with "lost" disks
Created attachment 156409 [details]
dmesg for 2.6.21-1.3206.fc8 (disks are still there)
Created attachment 156410 [details]
dmesg for 2.6.21-1.3194.fc7 (the last one still usable)
This is apparently caused by the update from 2.6.22-rc3-git7 to 2.6.22-rc4, which added the patch: "libata: always use polling SETXFER" Hardware is sata_promise and sata_via, please confirm that it's the drives attached to the Promise controller that stopped working. > please confirm that it's the drives
> attached to the Promise controller that stopped working.
The best I can interpret messages from the working situation,
i.e. this:
sata_promise 0000:00:08.0: version 2.00
ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 18 (level, low) -> IRQ 18
sata_promise PATA port found
ata3: SATA max UDMA/133 cmd 0xffffc20000020200 ctl 0xffffc20000020238 bmdma
0x0000000000000000 irq 18
ata4: SATA max UDMA/133 cmd 0xffffc20000020280 ctl 0xffffc200000202b8 bmdma
0x0000000000000000 irq 18
ata5: PATA max UDMA/133 cmd 0xffffc20000020300 ctl 0xffffc20000020338 bmdma
0x0000000000000000 irq 18
scsi2 : sata_promise
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168
ata3.00: ATA-6: WDC WD2500JD-00GBB0, 02.05D02, max UDMA/100
ata3.00: 488397168 sectors, multi 0: LBA48
ata3.00: applying bridge limits
ata3.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168
ata3.00: configured for UDMA/100
scsi3 : sata_promise
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168
ata4.00: ATA-6: WDC WD2500JD-00GBB0, 02.05D02, max UDMA/100
ata4.00: 488397168 sectors, multi 0: LBA48
ata4.00: applying bridge limits
ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168
ata4.00: configured for UDMA/100
scsi4 : sata_promise
this is indeed the case.
2.6.21-1.3218.fc8 sees again disks on a Promise controller. A dmesg fragment where there were troubles look now as the one quoted in comment #5. 2.6.21-1.3221 was booting OK. 2.6.21-1.3223 is broken again in the same way as before. ata3: failed to recover some devices, retrying in 5 secs ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 ata3.00: qc timeout (cmd 0xef) ata3.00: failed to set xfermode (err_mask=0x4) ata3.00: disabled and that disk is goner. kernel 2.6.21-1.3225.fc8 gets sata_promise drives again. Changelogs do not provide enough information to make it possible to tell if this is a "lucky accident" or really a fix. Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. 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 |