Bug 224005 - pata_pcmcia fails
pata_pcmcia fails
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-23 10:58 EST by David Woodhouse
Modified: 2008-06-20 15:05 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2.6.25.6-27.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-20 15:05:16 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)
Requested debug output (4.76 KB, text/plain)
2007-01-24 09:21 EST, David Woodhouse
no flags Details
slab corruption on hotplug (31.02 KB, text/plain)
2007-01-24 10:59 EST, David Woodhouse
no flags Details

  None (edit)
Description David Woodhouse 2007-01-23 10:58:09 EST
Using a CF card in a PCMCIA-CF adapter in my shinybook:

pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
libata version 2.00 loaded.
ata1: PATA max PIO0 cmd 0x0 ctl 0xE bmdma 0x0 irq 53
scsi8 : pata_pcmcia
ata1.00: CFA, max PIO4, 500400 sectors: LBA 
ata1.00: ata1: dev 0 multi count 0
ata1.00: failed to set xfermode (err_mask=0x1)
ata1.00: disabled


Linux shinybook.infradead.org 2.6.19-1.2884.fc7 #1 Mon Dec 18 12:41:21 GMT 2006
ppc ppc ppc GNU/Linux

This usually works with ide-cs.
Comment 1 Alan Cox 2007-01-23 11:18:59 EST
If you can explain why the resources the PCMCIA layer assigned are at address
zero on PPC, while properly assigned on x86 this can get fixed.

Alan
Comment 2 David Woodhouse 2007-01-23 18:47:59 EST
What's wrong with zero? Have we been infected with the silly "zero isn't a real
number" disease which afflicts IRQ handling in some drivers these days? If so,
we either need to fix it or infect the PCMCIA core with the same error.

shinybook /sys/class/pcmcia_socket/pcmcia_socket0 # echo -0x00000000 -
0x007fffff > available_resources_io 
shinybook /sys/class/pcmcia_socket/pcmcia_socket0 # echo +0x00000100 -
0x007fffff > available_resources_io 
shinybook /sys/class/pcmcia_socket/pcmcia_socket0 # dmesg | tail -13
pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
ata5: PATA max PIO0 cmd 0x100 ctl 0x10E bmdma 0x0 irq 53
scsi12 : pata_pcmcia
IN from bad port 0 at f2d8ca28
IN from bad port 0 at f2d8ca28
IN from bad port 0 at f2d8ca28
ata5.00: CFA, max PIO4, 500400 sectors: LBA 
ata5.00: ata5: dev 0 multi count 0
IN from bad port 0 at f2d8ca28
IN from bad port 0 at f2d8ca28
ata5.00: failed to set xfermode (err_mask=0x1)
ata5.00: disabled

Seems we're still doing I/O to port zero when the CF device is elsewhere?
Comment 3 Alan Cox 2007-01-23 19:54:30 EST
Ok so the 0 is a real address. I'd assumed it was some kind of uninitialised
case. The system does check pci_resource == 0 as an indicator of disabled but
doesn't do so for anything else where 0 might be valid - so that should be ok.

Can you tell me what the backtrace from 0xf2d8ca28 bad  in is, that does look
suspiciously like our tree has a naughty read from the bmdma space in it which
should have been fixed long ago and wants smacking.

The rest starts ok - we get the correct signature and identify data (viz we know
its CFA and the size and it can do PIO4). The set mode then fails which is bad
and we are reporting that the failure was caused by the device.

So the sequence appears to be
- Probe , finds CFA signature
- Identify, works properly
- Set features PIO 0
- Error

Can't see what is up from code inspection, no obvious endianisms and I don't
think the stray 0x0 access is related (its a bug though)

Can you turn on ATA_DEBUG and ATA_VERBOSE_DEBUG and see what occurs (you might
want to build a kernel with old ide for the main hd and libata for pcmcia so you
can get sane logs not buried in log spew)


Comment 4 David Woodhouse 2007-01-23 22:56:32 EST
I had a brief look at finding where 0xf2d8ca28 was last night but it isn't as
easy finding addresses in modules as it used to be. I used to be able to work it
out from other symbols in /proc/ksyms from the same module.

I'll rebuild with the debugging and investigate further when I get home this
weekend -- I'm still in Shanghai doing OLPC build debugging which has to take
priority.

The Fedora kernel still uses old IDE for the main HDD anyway, since we don't
have a pata_pmac yet. It'd be good to be able to disable CONFIG_IDE before FC7
though :)
Comment 5 David Woodhouse 2007-01-24 09:21:36 EST
Created attachment 146405 [details]
Requested debug output
Comment 6 David Woodhouse 2007-01-24 09:48:43 EST
Should we expect CFA devices to respond to the SET_FEATURES command? If I hack
ata_dev_set_features() to return zero (and as discussed frob the resources so
that both I/O address and IRQ are non-zero to work around those bugs too), it
seems to work correctly.
Comment 7 David Woodhouse 2007-01-24 09:53:38 EST
FWIW ide-cs doesn't seem to be able to set the PIO mode either, and doesn't seem
to care...

shinybook /root # dmesg -c
pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
Probing IDE interface ide2...
hde: Hitachi XX.V.3.4.0.0, CFA DISK drive
ide2 at 0x000-0x007,0x00e on irq 53
hde: max request size: 128KiB
hde: 500400 sectors (256 MB) w/1KiB Cache, CHS=695/15/48
 hde: hde1
ide-cs: hde: Vpp = 0.0
shinybook /root # 
shinybook /root # hdparm -Xpio0 /dev/hde

/dev/hde:
 setting xfermode to 8 (PIO flow control mode0)
 HDIO_DRIVE_CMD(setxfermode) failed: Input/output error
shinybook /root # dmesg -c
hde: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hde: drive_cmd: error=0x04 { DriveStatusError }
ide: failed opcode was: 0xef

Comment 8 David Woodhouse 2007-01-24 10:59:02 EST
Created attachment 146415 [details]
slab corruption on hotplug

With the hack in ata_dev_set_features() it does also work at I/O address zero,
although I haven't yet tried IRQ 0.

However there seem to be problems with hot-unplug. 

I believe the first instance of slab corruption reported in the attachment was
after something along the lines of insert, mount, remove (leaving /dev/sda1
mounted), insert, mount sdb1, remove, umount sdb1, umount sda1, insert... BUG.
Comment 9 Alan Cox 2007-01-24 11:56:12 EST
Adding Jeff as the debug output shows that ata_bmdma_stop is being called on PIO
only devices during PIO transfers and I think he needs to fix that 8)

IRQ 0 won't work btw - IRQ 0 isn't valid as a real IRQ in Linux.

As to the command failing, thats very odd indeed and seems to be a device bug as
the device explicitly reports supporting PIO4 and that in turn requires it must
support PIO0..3 with IORDY mandatory on PIO3 and higher.

If you get a moment attach the full identify output (off either the new or old
driver) and lets see what lunacy it claims. Also see if ata mode 0 works (mode
0, no iordy)

Alan
Comment 10 Alan Cox 2007-01-24 12:16:42 EST
Ok ancient CFA specs don't require set features so that explains that bit. It
happens to work on old IDE for other reasons (sheer ignorance on the part of the
driver ;))
Comment 11 Alan Cox 2007-01-24 12:47:19 EST
Fixed the bmdma_stop reference (caused by post_internal_cmd always calling
bmdma_stop). Not sure that this should occur even for BMDMA capable controllers
on a non DMA command - one for Jeff.
Comment 12 Alan Cox 2007-01-24 14:02:12 EST
Taught my kernel tree that CFA devices may bogusly fail set features for PIO
modes. Don't have anything brain dead enough to fully test it right now.
Comment 13 Alan Cox 2007-03-07 14:23:13 EST
Please retest with a current kernel.
Comment 14 Alan Cox 2007-03-07 14:26:50 EST

*** This bug has been marked as a duplicate of 230318 ***
Comment 15 David Woodhouse 2007-03-08 14:22:12 EST
Works fine. And although it's still at the perfectly normal PIO address zero, we
seem to get away without confusing broken drivers because we now seem to use the
virtual memory address at which that "port" address got mapped:

pccard: PCMCIA card inserted into slot 0
cs: memory probe 0xf3000000-0xf3ffffff: excluding 0xf3000000-0xf33fffff
pcmcia: registering new device pcmcia0.0
PM: Adding info for pcmcia:0.0
SCSI subsystem initialized
libata version 2.20 loaded.
ata1: PATA max PIO0 cmd 0xfcde7000 ctl 0xfcde700e bmdma 0x00000000 irq 53
scsi0 : pata_pcmcia
PM: Adding info for No Bus:host0
ata1.00: CFA: Hitachi XX.V.3.4.0.0, Rev 0.00, max PIO4
ata1.00: 500400 sectors, multi 0: LBA 
ata1.00: configured for PIO0
PM: Adding info for No Bus:target0:0:0
scsi 0:0:0:0: Direct-Access     ATA      Hitachi XX.V.3.4 Rev  PQ: 0 ANSI: 5
PM: Adding info for scsi:0:0:0:0
scsi 0:0:0:0: Attached scsi generic sg0 type 0
SCSI device sda: 500400 512-byte hdwr sectors (256 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO
or FUA
SCSI device sda: 500400 512-byte hdwr sectors (256 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO
or FUA
 sda: sda1
sd 0:0:0:0: Attached scsi removable disk sda
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will
be case sensitive!


Linux shinybook.infradead.org 2.6.20-1.2967.fc7 #1 Tue Mar 6 19:53:36 GMT 2007
ppc ppc ppc GNU/Linux

Comment 16 David Woodhouse 2007-03-08 14:29:10 EST
Well, works until I remove the device, that is...

FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will
be case sensitive!
pccard: card ejected from slot 0
ata1.00: disabled
PM: Removing info for scsi:0:0:0:0
PM: Removing info for No Bus:host0
PM: Removing info for pcmcia:0.0
BUG: spinlock bad magic on CPU#0, scsi_eh_0/28982 (Not tainted)
Unable to handle kernel paging request for data at address 0x6b6b6c17
Faulting instruction address: 0xc01325f0
Oops: Kernel access of bad area, sig: 11 [#1]

Modules linked in: vfat(U) fat(U) sd_mod(U) sg(U) pata_pcmcia(U) libata(U)
scsi_mod(U) radeon(U) drm(U) hidp(U) hci_usb(U) rfcomm(U) l2cap(U) bluetooth(U)
arc4(U) ecb(U) blkcipher(U) ieee80211_crypt_wep(U) ipv6(U) nls_utf8(U)
hfsplus(U) dm_mirror(U) dm_mod(U) therm_adt746x(U) parport_pc(U) lp(U)
parport(U) bcm43xx(U) ieee80211softmac(U) ieee80211(U) ieee80211_crypt(U)
snd_aoa_i2sbus(U) snd_powermac(U) snd_seq_dummy(U) snd_seq_oss(U)
snd_seq_midi_event(U) snd_seq(U) ide_cd(U) cdrom(U) snd_seq_device(U)
snd_pcm_oss(U) snd_mixer_oss(U) snd_pcm(U) snd_timer(U) snd_page_alloc(U) snd(U)
soundcore(U) snd_aoa_soundbus(U) sungem(U) sungem_phy(U) fw_ohci(U) fw_core(U)
ext3(U) jbd(U) mbcache(U) ehci_hcd(U) ohci_hcd(U) uhci_hcd(U)
NIP: C01325F0 LR: C01325D8 CTR: 00000000
REGS: ce021e00 TRAP: 0300   Not tainted  (2.6.20-1.2967.fc7)
MSR: 00001032 <ME,IR,DR>  CR: 22000024  XER: 00000000
DAR: 6B6B6C17, DSISR: 40000000
TASK = ec111340[28982] 'scsi_eh_0' THREAD: ce020000
GPR00: C01325D8 CE021EB0 EC111340 00000043 00000001 6B6B6B6B C035FAF8 FFFFFFFF 
GPR08: 00000000 C0360000 00020355 C0420000 42000042 00000000 00000000 00000000 
GPR16: 00000000 00000000 00000000 00000000 00000000 0175960C 41400000 0175B45C 
GPR24: 00000000 C0370000 C0374A14 DC0F1E48 EC111340 00007136 CDADA384 6B6B6B6B 
NIP [C01325F0] spin_bug+0x7c/0xec
LR [C01325D8] spin_bug+0x64/0xec
Call Trace:
[CE021EB0] [C01325D8] spin_bug+0x64/0xec (unreliable)
[CE021EE0] [C01327A0] _raw_spin_lock+0x34/0x11c
[CE021F00] [C02CA370] _spin_lock_irqsave+0x20/0x38
[CE021F20] [F2C0237C] ata_port_flush_task+0x24/0xf0 [libata]
[CE021F40] [F2C0F974] ata_scsi_error+0x20/0x54c [libata]
[CE021F70] [F29B9A68] scsi_error_handler+0xd0/0x4f4 [scsi_mod]
[CE021FC0] [C0049C3C] kthread+0xc4/0x100
[CE021FF0] [C0013F7C] kernel_thread+0x44/0x60
Instruction dump:
38a00000 7c681b78 7f44d378 7fa7eb78 38794a38 4bf0236d 2f9f0000 3d20c036 
80bb0004 38c9faf8 38e0ffff 419e000c <80ff00ac> 38df0198 811b0008 3c60c037 
BUG: soft lockup detected on CPU#0!
Call Trace:
[CE021B10] [C0008C18] show_stack+0x50/0x184 (unreliable)
[CE021B30] [C0064FEC] softlockup_tick+0xb4/0xd0
[CE021B50] [C003DDC8] run_local_timers+0x18/0x28
[CE021B60] [C003DE18] update_process_times+0x40/0x7c
[CE021B70] [C001023C] timer_interrupt+0xcc/0x580
[CE021BE0] [C00136B8] ret_from_except+0x0/0x14
--- Exception: 901 at handle_IRQ_event+0x30/0xa0
    LR = handle_fasteoi_irq+0xc4/0x128
[CE021CA0] [CE021E00] 0xce021e00 (unreliable)
[CE021CC0] [C0066A40] handle_fasteoi_irq+0xc4/0x128
[CE021CE0] [C0006828] do_IRQ+0x8c/0xcc
[CE021CF0] [C00136B8] ret_from_except+0x0/0x14
--- Exception: 501 at _spin_unlock_irq+0x1c/0x2c
    LR = _spin_unlock_irq+0x10/0x2c
[CE021DC0] [C0011A94] die+0x168/0x1c0
[CE021DE0] [C0017384] bad_page_fault+0xb8/0xcc
[CE021DF0] [C00134AC] handle_page_fault+0x7c/0x80
--- Exception: 300 at spin_bug+0x7c/0xec
    LR = spin_bug+0x64/0xec
[CE021EE0] [C01327A0] _raw_spin_lock+0x34/0x11c
[CE021F00] [C02CA370] _spin_lock_irqsave+0x20/0x38
[CE021F20] [F2C0237C] ata_port_flush_task+0x24/0xf0 [libata]
[CE021F40] [F2C0F974] ata_scsi_error+0x20/0x54c [libata]
[CE021F70] [F29B9A68] scsi_error_handler+0xd0/0x4f4 [scsi_mod]
[CE021FC0] [C0049C3C] kthread+0xc4/0x100
[CE021FF0] [C0013F7C] kernel_thread+0x44/0x60
Comment 17 Alan Cox 2007-03-08 18:05:27 EST
Tbe last bit looks like breakage from the iomap changes, which needs Jeff to
look at I guess - I'm seeing other similar reports of this problem
Comment 18 Eric Smith 2007-11-25 22:11:50 EST
Same problem with a PCMCIA HDD, an Integral Viper 105, on Fedora 8 with kernel
2.6.23.1-49.fc8 (64-bit).

Athlon 64 X2 4800+ dual core socket 939 CPU
Asus A8V Deluxe motherboard
Syba SD-PCI-PCM PCI to PCMCIA controller card using Ricoh chip

lspci shows Ricoh chip as:
00:0d.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 81)

Inserting the Viper 105 generates these messages to syslog:

Nov 25 18:39:49 jevex kernel: pccard: PCMCIA card inserted into slot 0
Nov 25 18:39:49 jevex kernel: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0
000-0xfffff
Nov 25 18:39:49 jevex kernel: cs: memory probe 0x60000000-0x60ffffff: excluding 
0x60000000-0x60ffffff
Nov 25 18:39:49 jevex kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean.
Nov 25 18:39:49 jevex kernel: pcmcia: registering new device pcmcia0.0
Nov 25 18:39:49 jevex kernel: scsi12 : pata_pcmcia
Nov 25 18:39:49 jevex kernel: ata7: PATA max PIO0 cmd 0x0000000000010100 ctl 0x0
00000000001010e bmdma 0x0000000000000000 irq 18
Nov 25 18:39:52 jevex kernel: ata7.00: ATA-0: Integral Peripherals 8105PA, XEC80
U00, max PIO0
Nov 25 18:39:52 jevex kernel: ata7.00: 205904 sectors, multi 0, CHS 757/16/17
Nov 25 18:39:52 jevex kernel: ata7.00: failed to set xfermode (err_mask=0x1)
Nov 25 18:39:52 jevex kernel: ata7: failed to recover some devices, retrying in 
5 secs
Nov 25 18:39:58 jevex kernel: ata7.00: failed to set xfermode (err_mask=0x1)
Nov 25 18:39:58 jevex kernel: ata7: failed to recover some devices, retrying in 
5 secs
Nov 25 18:40:03 jevex kernel: ata7.00: failed to set xfermode (err_mask=0x1)
Nov 25 18:40:03 jevex kernel: ata7.00: disabled
Comment 19 Eric Smith 2007-11-26 04:12:20 EST
I booted Knoppix 3.6 (kernel 2.4.27, ide-cs), and it was able to access the
PCMCIA drive without any problems.  I was able to dd the entire 105MB contents
of the drive onto a USB drive without any problem.  Here's what the kernel had
to say about the drive:

root@ttyp0[knoppix]# ls /proc/ide/hdi
cache     driver    identify  model     smart_thresholds
capacity  geometry  media     settings  smart_values
root@ttyp0[knoppix]# cat /proc/ide/hdi/model
Integral Peripherals 8105PA
root@ttyp0[knoppix]# cat /proc/ide/hdi/geometry
physical     757/16/17
logical      757/16/17
root@ttyp0[knoppix]# cat /proc/ide/hdi/cache
32
root@ttyp0[knoppix]# cat /proc/ide/hdi/capacity
205904
root@ttyp0[knoppix]# cat /proc/ide/hdi/media
disk
root@ttyp0[knoppix]# cat /proc/ide/hdi/settings
name                    value           min             max             mode
----                    -----           ---             ---             ----
acoustic                0               0               254             rw
address                 0               0               2               rw
bios_cyl                757             0               65535           rw
bios_head               16              0               255             rw
bios_sect               17              0               63              rw
breada_readahead        8               0               255             rw
bswap                   0               0               1               r
current_speed           0               0               70              rw
failures                0               0               65535           rw
file_readahead          124             0               16384           rw
init_speed              0               0               70              rw
io_32bit                0               0               3               rw
keepsettings            0               0               1               rw
lun                     0               0               7               rw
max_failures            1               0               65535           rw
max_kb_per_request      128             1               255             rw
multcount               16              0               16              rw
nice1                   1               0               1               rw
nowerr                  0               0               1               rw
number                  0               0               3               rw
pio_mode                write-only      0               255             w
slow                    0               0               1               rw
unmaskirq               0               0               1               rw
using_dma               0               0               1               rw
wcache                  0               0               1               rw
root@ttyp0[knoppix]# cat /proc/ide/hdi/smart_values
root@ttyp0[knoppix]# cat /proc/ide/hdi/smart_thresholds
root@ttyp0[knoppix]# cat /proc/ide/hdi/identify
0c5a 02f5 0000 0010 0000 0000 0011 0000
0000 0000 4653 3039 3238 3632 0000 0000
0000 0000 0000 0000 0003 0040 0004 5845
4338 3055 3030 496e 7465 6772 616c 2050
6572 6970 6865 7261 6c73 2038 3130 3550
4120 2020 2020 2020 2020 2020 2020 0010
0000 0000 0000 0000 0000 0001 02f5 0010
0011 2450 0003 0110 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 02f5 1011 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 000f 005f 000f 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
Comment 20 Bug Zapper 2008-04-03 14:56:07 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

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.
Comment 21 Eric Smith 2008-04-03 15:29:31 EDT
Still happens with released Fedora 8 kernels, as I reported above on November
25.  I recently tested again with a more recent F8 kernel, and it still happens.
Comment 22 John W. Linville 2008-04-03 15:48:13 EDT
FWIW I hit this a few days ago using a pcmcia hard drive in a Thinkpad T43 
running a wireless-testing build based off 2.6.25-rc7.  I wasn't 100% sure 
that the card was good (and I didn't really need it), so I hadn't bothered to 
report it.  But as I happened to notice this fly by on the kernel-main email 
list...

From memory, my dmesg output looked very similar to dwmw2's original comment.  
I can play guinea pig if there is further interest...
Comment 23 Alan Cox 2008-04-09 06:06:37 EDT
I'd be interested to know what the device is if it is showing the xfer mode
report. I've posted a couple of patches into -mm yesterday which relax the rules
a bit for ancient hardware and dodgy emulations
Comment 24 Eric Smith 2008-04-09 15:52:21 EDT
What is the "xfer mode report"?  I wasn't able to get Fedora 8 to do anything at
all with the drive, and copied the log messages in comment 18 above.  In comment
19 I gave all of the information about it that I knew how to get from a 2.4.27
kernel (using Knoppix).  If there's specific information that you would find
helpful, I'll need an explanation of how to find it.

Alternatively, I'm willing to ship the disk and the PCI/Cardbus interface card
to you, and pay return shipping for you to send it back when you're done with it.
Comment 25 Alan Cox 2008-04-09 17:25:06 EDT
"ata1.00: failed to set xfermode (err_mask=0x1)"

The ATA specification says a device that supports ATA command sets must accept
the SET_XFER_MODE command to set modes. The CFA specification for CFA 1.1
doesn't include this but can therefore only do PIO 0-2 without IORDY.
Unfortunately we have devices that either report CFA and PIO > 2 or report ATA
but are not remotely compliant. In those cases we nowdays report the fault and
refuse the device (which is the correct thing to do in the normal case)
Comment 26 Eric Smith 2008-04-09 20:04:58 EDT
I don't know what the CFA specification is.  What version of ATA introduced
SET_XFER_MODE?  I'm not familiar with revisions newer than ATA3, and as far as I
can see, ATA3 didn't have that command, therefore ATA3 and earlier devices
should not be refused for not supporting it.
Comment 27 Alan Cox 2008-04-10 05:38:34 EDT
It's set features 0x03. It is required for any mode with IORDY but not for non
IORDY modes (ie PIO2+) as well as for DMA setting (although some devices
predating ATA2 but doing DMA simply blindly support DMA cycles/timings)

The latest 2.6.25-mm code accepts ATA devices erroring requests for PIO mode
setup providing they are a low ATA version so should already have fixed these
devices in the devel tree.
Comment 28 Eric Smith 2008-04-10 13:52:52 EDT
ATA3 says that all subcommands of the SET FEATURES command are optional, though
as you say devices not implementing it will restrict what transfer modes can be
used.  As far as I'm aware PCMCIA and CF only support the earliest PIO modes, so
it's not surprising that such devices would not bother to implement the subcommand.

I'll give it a try once there's a Fedora kernel RPM with the patch.

Thanks!
Eric
Comment 29 Chuck Ebbert 2008-05-27 14:17:54 EDT
Patch in kernel-2.6.25.4-12
Comment 31 Alan Cox 2008-06-10 05:16:28 EDT
Note that the reporter field in this bug has been corrupted by the bugzilla
account closure tools. 
Putting the correct reporter back in the cc: field at least.

I've opened a request to fix the account closure tools.
Comment 32 Fedora Update System 2008-06-11 21:20:28 EDT
kernel-2.6.25.6-24.fc8 has been submitted as an update for Fedora 8
Comment 33 Fedora Update System 2008-06-12 22:20:34 EDT
kernel-2.6.25.6-24.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-5267
Comment 34 Fedora Update System 2008-06-17 13:24:03 EDT
kernel-2.6.25.6-27.fc8 has been submitted as an update for Fedora 8
Comment 35 Fedora Update System 2008-06-20 15:04:57 EDT
kernel-2.6.25.6-27.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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