Bug 234650
| Summary: | [CF VIA] 2.6.20 pata_via problem with CF card | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | kernel | Assignee: | Alan Cox <alan> |
| Status: | CLOSED UPSTREAM | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | davej, david.r.bentley |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-01-14 11:40:22 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: | |||
Created attachment 151322 [details]
dmidecode output for EPIA board
Created attachment 151323 [details]
a record from a normal boot with 2.6.19-1.2911.6.4.fc6 kernel
Created attachment 151325 [details]
syslog from a failed boot of a rawhide installation images with 2.6.20-1.3025.fc7
Options used here: pci=nomsi libata.fua=0 libata.atapi_dmadir=0
This is greeted with:
<3>Unknown boot option `libata.fua=0': ignoring
<3>Unknown boot option `libata.atapi_dmadir=0': ignoring
I am seeing a very similar problem when booting either FC7test3 DVD or rescueCD both stall for a long while loading the Pata_via driver and when I lookat what is happening on TTY4 (CTL+ALT+F4) except in my case it shows as ata4 I will add dmidecode output for my system from the already installed FC6 Created attachment 151393 [details]
dmidecode output
dmidecode output
Created attachment 151394 [details]
lspci output
lspci output
I retried with images using 2.6.20-1.3054.fc7. No change. <6>ata2: soft resetting port <4>ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80) <3>ata2.00: revalidation failed (errno=-5) and after that a disk access is dead. The 2.6.20 libata cannot cope with CF adapters which do not forward the DMA lines and do not modify the identify data to indicate no DMA. I think that is what is happening here as normal stuff works just fine on all the EPIA boxes tested. The old IDE error handling would recover in this situation (although you shortcut it by specifying ide=nodma). The 2.6.21 libata error handler can hopefully now recover the same way (by killing DMA), but the real problem appears to be faulty CF adapters. Some reported details are a bit different with 2.6.21-1.3116.fc7 but the general outcome unfortunately does not change: .... <4>ATA: abnormal status 0x8 on port 0x000101f7 <6>scsi1 : pata_via <6>ata2.00: ATA-0: CF 2GB, 20070131, max MWDMA2 <6>ata2.00: 4001760 sectors, multi 0: LBA <6>ata2.00: configured for MWDMA2 <5>scsi 1:0:0:0: Direct-Access ATA CF 2GB 2007 PQ: 0 ANSI: 5 <5>SCSI device sda: 4001760 512-byte hdwr sectors (2049 MB) <5>sda: Write Protect is off <7>sda: Mode Sense: 00 3a 00 00 <5>SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA <5>SCSI device sda: 4001760 512-byte hdwr sectors (2049 MB) <5>sda: Write Protect is off <7>sda: Mode Sense: 00 3a 00 00 <5>SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA <6> sda:<3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen <3>ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in <4> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) <6>ata2: soft resetting port <4>ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80) <3>ata2.00: revalidation failed (errno=-5) <4>ata2: failed to recover some devices, retrying in 5 secs <6>ata2: soft resetting port <4>ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80) <3>ata2.00: revalidation failed (errno=-5) <4>ata2.00: limiting speed to MWDMA2:PIO3 <4>ata2: failed to recover some devices, retrying in 5 secs <6>ata2: soft resetting port <4>ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80) <3>ata2.00: revalidation failed (errno=-5) <4>ata2.00: disabled <6>ata2: EH complete <6>sd 1:0:0:0: SCSI error: return code = 0x00040000 <4>end_request: I/O error, dev sda, sector 0 .... 2.6.23 allows you to disable DMA on problem CF adapters without disabling it elsewhere. |
Description of problem: I am trying to boot a small SBC which is using as its disk a flash memory with an interface which presents that as an ATA IDE device. When I am using, say, 2.6.19-1.2911.6.4.fc6 then there is no problem. This looks something like that: .... Probing IDE interface ide1... hdc: CF 2GB, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 .... hdc: max request size: 128KiB hdc: 4001760 sectors (2048 MB) w/1KiB Cache, CHS=3970/16/63 hdc: hdc1 .... and off we go. With libata (this is from a syslog from an attempt to boot into "rescue" from reasonably current rawhide boot images) I see this: .... <6>ata2.00: ATA-0: CF 2GB, 20070131, max MWDMA2 <6>ata2.00: 4001760 sectors, multi 0: LBA <6>ata2.00: configured for MWDMA2 <7>PM: Adding info for No Bus:target1:0:0 <5>scsi 1:0:0:0: Direct-Access ATA CF 2GB 2007 PQ: 0 ANSI: 5 <7>PM: Adding info for scsi:1:0:0:0 <5>SCSI device sda: 4001760 512-byte hdwr sectors (2049 MB) <5>sda: Write Protect is off <7>sda: Mode Sense: 00 3a 00 00 <5>SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA <5>SCSI device sda: 4001760 512-byte hdwr sectors (2049 MB) <5>sda: Write Protect is off <7>sda: Mode Sense: 00 3a 00 00 <5>SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA <6> sda:<3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen <3>ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in <4> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) <6>ata2: soft resetting port ..... <3>ata2.00: revalidation failed (errno=-5) <4>ata2.00: disabled <6>ata2: EH complete .... and I cannot get even a partitioning information not mentioning such details as some data off that device. As opposed to my some other encounter with libata I failed here to find kernel flags which would allow me to get around the issue. Is any way to force libata off? It looks to me that springing libata on an unsuspecting public may be a bit, ahem, premature. Here is a bus layout of the box in question: -[0000:00]-+-00.0 VIA Technologies, Inc. VT8623 [Apollo CLE266] +-01.0-[0000:01]----00.0 VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics +-0d.0 VIA Technologies, Inc. IEEE 1394 Host Controller +-10.0 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller +-10.1 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller +-10.2 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller +-10.3 VIA Technologies, Inc. USB 2.0 +-11.0 VIA Technologies, Inc. VT8235 ISA Bridge +-11.1 VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE \-12.0 VIA Technologies, Inc. VT6102 [Rhine-II] I attached also an output from dmidecode for the board, a sample dmesg output from a boot with 2.6.19-1.2911.6.4.fc6 and full syslog from one of attempts to get there through a rescue mode of a boot image using 2.6.20-1.3025.fc7 kernel. Note: 'ide=nodma' is not strictly necessary to boot 2.6.19-1.2911.6.4.fc6 but it seems to actually help a bit there and using DMA with a CF card does not look like the thing to do. Version-Release number of selected component (if applicable): kernel-2.6.20-1.3025.fc7 and other with 2.6.20 series How reproducible: always (failed to find a way not to reproduce).