Re: libata and legacy ide pcmcia failure

Re: libata and legacy ide pcmcia failure

[Tejun Heo]

Hello,

Robert de Rooy wrote:
> Jun  7 21:10:28 localhost kernel: ata3: soft resetting port
> Jun  7 21:10:28 localhost kernel: ata3: reset complete
> Jun  7 21:10:28 localhost kernel: ATA: abnormal status 0x80 on port
> 0x00014107
> Jun  7 21:10:28 localhost kernel: ATA: abnormal status 0x80 on port
> 0x00014107
> Jun  7 21:10:28 localhost kernel: ata3.00: issuing IDENTIFY
> Jun  7 21:10:29 localhost kernel: ata3.00: IDENTIFY complete
> Jun  7 21:10:29 localhost kernel: ata3.00: CFA: Memory Card Adapter,
> 20011212, max PIO1
> Jun  7 21:10:29 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA
> Jun  7 21:10:29 localhost kernel: ata3.00: issuing IDENTIFY
> Jun  7 21:10:29 localhost kernel: ata3.00: IDENTIFY complete
> Jun  7 21:10:29 localhost kernel: ata3.00: configured for PIO0
> Jun  7 21:10:29 localhost kernel: ata3: EH complete
> Jun  7 21:10:29 localhost kernel: scsi 3:0:0:0: Direct-Access    
> ATA      Memory Card Adap 2001 PQ: 0 ANSI: 5
> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] 253696 512-byte
> hardware sectors (130 MB)
> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] Write Protect is off
> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] Write cache:
> disabled, read cache: enabled, doesn't support DPO or FUA
> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] 253696 512-byte
> hardware sectors (130 MB)
> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] Write Protect is off
> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] Write cache:
> disabled, read cache: enabled, doesn't support DPO or FUA

So, that made it go through detection okay.  That's a good news.

> Jun  7 21:10:59 localhost kernel:  sdd:<3>ata3.00: exception Emask 0x0
> SAct 0x0 SErr 0x0 action 0x2 frozen
> Jun  7 21:10:59 localhost kernel: ata3.00: cmd
> 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
> Jun  7 21:10:59 localhost kernel:          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

But, read for partition table failed miserably and took the device
offline completely.

Whee... Cc'ing linux-ide and Mark Lord.  The original thread is..

  http://thread.gmane.org/gmane.linux.kernel/530099

Any ideas?

-- 
tejun

Re: libata and legacy ide pcmcia failure

[Mark Lord]

Tejun Heo wrote:
>
>> Jun  7 21:10:29 localhost kernel: ata3.00: CFA: Memory Card Adapter,
>> 20011212, max PIO1
>> Jun  7 21:10:29 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA
>> Jun  7 21:10:29 localhost kernel: ata3.00: issuing IDENTIFY
>> Jun  7 21:10:29 localhost kernel: ata3.00: IDENTIFY complete
>> Jun  7 21:10:29 localhost kernel: ata3.00: configured for PIO0
>> Jun  7 21:10:29 localhost kernel: ata3: EH complete
>> Jun  7 21:10:29 localhost kernel: scsi 3:0:0:0: Direct-Access    
>> ATA      Memory Card Adap 2001 PQ: 0 ANSI: 5
>> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] 253696 512-byte
>> hardware sectors (130 MB)
>> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] Write Protect is off
>> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] Write cache:
>> disabled, read cache: enabled, doesn't support DPO or FUA
>> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] 253696 512-byte
>> hardware sectors (130 MB)
>> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] Write Protect is off
>> Jun  7 21:10:29 localhost kernel: sd 3:0:0:0: [sdd] Write cache:
>> disabled, read cache: enabled, doesn't support DPO or FUA
> 
> So, that made it go through detection okay.  That's a good news.
> 
>> Jun  7 21:10:59 localhost kernel:  sdd:<3>ata3.00: exception Emask 0x0
>> SAct 0x0 SErr 0x0 action 0x2 frozen
>> Jun  7 21:10:59 localhost kernel: ata3.00: cmd
>> 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
>> Jun  7 21:10:59 localhost kernel:          res
>> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> 
> But, read for partition table failed miserably and took the device
> offline completely.
> 
> Whee... Cc'ing linux-ide and Mark Lord.  The original thread is..
> 
>   http://thread.gmane.org/gmane.linux.kernel/530099
> 
> Any ideas?

I still don't see much evidence that interrupts are actually functioning here.
It would be good to see /proc/interrupts before/after libata tries to talk to it.

Let's assume for the moment that interrupts are b0rken.
The legacy IDE driver can talk to such devices completely without interrupts,
if the IDE polling patch (below) is applied.

So, Robert:  could you try again with the old IDE driver,
except apply this patch to it first?  This will give valuable info.


--- old/drivers/ide/ide-probe.c	2007-04-11 00:18:51.000000000 -0400
+++ linux/drivers/ide/ide-probe.c	2007-04-12 09:26:14.000000000 -0400
@@ -1014,6 +1014,27 @@
  * but anything else has led to problems on some machines.  We re-enable
  * interrupts as much as we can safely do in most places.
  */
+struct timer_list polling_timer;
+static void ide_polling (unsigned long data)
+{
+	ide_hwgroup_t *hwgroup = (void *)data;
+	ide_hwif_t *hwif;
+	int irq = 0;
+
+	if (hwgroup) {
+		hwif = hwgroup->hwif;
+		if (hwif)
+			irq = hwif->irq;
+	}
+
+	ide_intr(irq, hwgroup);
+	init_timer(&polling_timer);
+	polling_timer.expires = jiffies + 2;
+	polling_timer.function = &ide_polling;
+	polling_timer.data = (unsigned long) hwgroup;
+	add_timer(&polling_timer);
+}
+
 static int init_irq (ide_hwif_t *hwif)
 {
 	unsigned int index;
@@ -1110,9 +1131,12 @@
 		if (hwif->io_ports[IDE_CONTROL_OFFSET])
 			/* clear nIEN */
 			hwif->OUTB(0x08, hwif->io_ports[IDE_CONTROL_OFFSET]);
-
+#if 0
 		if (request_irq(hwif->irq,&ide_intr,sa,hwif->name,hwgroup))
 	       		goto out_unlink;
+#else
+		ide_polling((unsigned long)hwgroup);
+#endif
 	}
 
 	/*
@@ -1156,6 +1180,7 @@
 	printk("\n");
 	up(&ide_cfg_sem);
 	return 0;
+#if 0
 out_unlink:
 	spin_lock_irq(&ide_lock);
 	if (hwif->next == hwif) {
@@ -1176,6 +1201,7 @@
 		BUG_ON(hwgroup->hwif == hwif);
 	}
 	spin_unlock_irq(&ide_lock);
+#endif
 out_up:
 	up(&ide_cfg_sem);
 	return 1;
--- old/drivers/ide/ide.c	2007-04-11 00:18:51.000000000 -0400
+++ linux/drivers/ide/ide.c	2007-04-12 09:31:59.000000000 -0400
@@ -569,6 +569,8 @@
  *	This is raving bonkers.
  */
 
+extern struct timer_list polling_timer;
+
 void ide_unregister(unsigned int index)
 {
 	ide_drive_t *drive;
@@ -612,7 +614,11 @@
 		g = g->next;
 	} while (g != hwgroup->hwif);
 	if (irq_count == 1)
+#if 0
 		free_irq(hwif->irq, hwgroup);
+#else
+		del_timer(&polling_timer);
+#endif
 
 	spin_lock_irq(&ide_lock);
 	/*

Re: libata and legacy ide pcmcia failure

[Robert de Rooy]

Mark Lord wrote:
> I still don't see much evidence that interrupts are actually 
> functioning here.
> It would be good to see /proc/interrupts before/after libata tries to 
> talk to it.
>
> Let's assume for the moment that interrupts are b0rken.
> The legacy IDE driver can talk to such devices completely without 
> interrupts,
> if the IDE polling patch (below) is applied.
>
> So, Robert:  could you try again with the old IDE driver,
> except apply this patch to it first?  This will give valuable info.
I tried the patch, but a get a kernel panic on boot with it. I can try 
to get a screenshot of it tomorrow.

Re: libata and legacy ide pcmcia failure

[Mark Lord]

Robert de Rooy wrote:
> Mark Lord wrote:
>> I still don't see much evidence that interrupts are actually 
>> functioning here.
>> It would be good to see /proc/interrupts before/after libata tries to 
>> talk to it.
>>
>> Let's assume for the moment that interrupts are b0rken.
>> The legacy IDE driver can talk to such devices completely without 
>> interrupts,
>> if the IDE polling patch (below) is applied.
>>
>> So, Robert:  could you try again with the old IDE driver,
>> except apply this patch to it first?  This will give valuable info.
>
> I tried the patch, but a get a kernel panic on boot with it. I can try 
> to get a screenshot of it tomorrow.

Oh crap.  I did test it a couple of months ago, but my boot/root drive
is libata not IDE -- so no panic on boot with it.  After booting, it worked
just fine talking to PC-CARD CF devices using the polling.

=ml

Re: libata and legacy ide pcmcia failure

[Robert de Rooy]

Mark Lord wrote:
> Oh crap.  I did test it a couple of months ago, but my boot/root drive
> is libata not IDE -- so no panic on boot with it.  After booting, it 
> worked
> just fine talking to PC-CARD CF devices using the polling.
>
> =ml

Ok, no problem. I recompiled the kernel with libata (but without the 
libata pcmcia support), and made legacy ide (only ide-core and ide-cs) 
modular.
This allowed me to boot my PATA HDD with libata, and when I plugged in 
the PCMCIA card it picked it up automatically with the legacy ide drivers.

Jun 10 02:40:06 localhost kernel: pccard: PCMCIA card inserted into slot 0
Jun 10 02:40:07 localhost kernel: cs: memory probe 
0xe8000000-0xefffffff: excluding 0xe8000000-0xefffffff
Jun 10 02:40:07 localhost kernel: cs: memory probe 
0xc0200000-0xcfffffff: excluding 0xc0200000-0xc11fffff 
0xc1a00000-0xc21fffff 0xc2a00000-0xc31fffff 0xc3a00000-0xcc1fffff 
0xcca00000-0xcd1fffff 0xcda00000-0xce1fffff 0xcea00000-0xcf1fffff 
0xcfa00000-0xd01fffff
Jun 10 02:40:07 localhost kernel: pcmcia: registering new device pcmcia0.0
Jun 10 02:40:07 localhost kernel: Uniform Multi-Platform E-IDE driver 
Revision: 7.00alpha2
Jun 10 02:40:07 localhost kernel: ide: Assuming 33MHz system bus speed 
for PIO modes; override with idebus=xx
Jun 10 02:40:07 localhost kernel: hda: Memory Card Adapter, CFA DISK drive
Jun 10 02:40:08 localhost kernel: ide0 at 0x4100-0x4107,0x410e on irq 3
Jun 10 02:40:08 localhost kernel: ide-cs: hda: Vpp = 0.0
Jun 10 02:40:08 localhost udevd-event[2630]: udev_rules_apply_format: 
unknown format variable '$modalias'

At this point I noticed no /dev/hda* devices existed, so I created them 
manually with mknod. But regardless I was not able to actually mount a 
filesystem, getting an error from mount that the device did not exist.

When pulling the card I also got the following..

Jun 10 02:41:53 localhost kernel: pccard: card ejected from slot 0
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: 
======================================================
Jun 10 02:41:53 localhost kernel: [ INFO: soft-safe -> soft-unsafe lock 
order detected ]
Jun 10 02:41:53 localhost kernel: 2.6.22-rc4 #5
Jun 10 02:41:53 localhost kernel: 
------------------------------------------------------
Jun 10 02:41:53 localhost kernel: pccardd/355 [HC0[0]:SC0[0]:HE0:SE1] is 
trying to acquire:
Jun 10 02:41:53 localhost kernel:  (resource_lock){--..}, at: 
[<c042dcb2>] __release_region+0x2f/0xdd
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: and this task is already holding:
Jun 10 02:41:53 localhost kernel:  (ide_lock){.+..}, at: [<f8e0269d>] 
ide_unregister+0x11d/0x56e [ide_core]
Jun 10 02:41:53 localhost kernel: which would create a new lock dependency:
Jun 10 02:41:53 localhost kernel:  (ide_lock){.+..} -> (resource_lock){--..}
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: but this new dependency connects a 
soft-irq-safe lock:
Jun 10 02:41:53 localhost kernel:  (ide_lock){.+..}
Jun 10 02:41:53 localhost kernel: ... which became soft-irq-safe at:
Jun 10 02:41:53 localhost kernel:   [<c0444171>] __lock_acquire+0x3ad/0xb12
Jun 10 02:41:53 localhost kernel:   [<c0444c97>] lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:   [<c061711f>] 
_spin_lock_irqsave+0x34/0x44
Jun 10 02:41:53 localhost kernel:   [<f8e04679>] ide_intr+0x17/0x1ac 
[ide_core]
Jun 10 02:41:53 localhost kernel:   [<f8e07825>] ide_polling+0x22/0x64 
[ide_core]
Jun 10 02:41:53 localhost kernel:   [<c0430446>] 
run_timer_softirq+0x11a/0x182
Jun 10 02:41:53 localhost kernel:   [<c042d286>] __do_softirq+0x6f/0xe9
Jun 10 02:41:53 localhost kernel:   [<c0406f72>] do_softirq+0x61/0xc7
Jun 10 02:41:53 localhost kernel:   [<ffffffff>] 0xffffffff
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: to a soft-irq-unsafe lock:
Jun 10 02:41:53 localhost kernel:  (resource_lock){--..}
Jun 10 02:41:53 localhost kernel: ... which became soft-irq-unsafe at:
Jun 10 02:41:53 localhost kernel: ...  [<c04441e4>] 
__lock_acquire+0x420/0xb12
Jun 10 02:41:53 localhost kernel:   [<c0444c97>] lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:   [<c0616e5e>] _write_lock+0x2b/0x38
Jun 10 02:41:53 localhost kernel:   [<c042dc60>] request_resource+0x13/0x36
Jun 10 02:41:53 localhost kernel:   [<c05068bb>] vgacon_startup+0x196/0x349
Jun 10 02:41:53 localhost kernel:   [<c075d3d5>] con_init+0x1a/0x217
Jun 10 02:41:53 localhost kernel:   [<c075cee5>] console_init+0x19/0x27
Jun 10 02:41:53 localhost kernel:   [<c07428b5>] start_kernel+0x242/0x34c
Jun 10 02:41:53 localhost kernel:   [<00000000>] 0x0
Jun 10 02:41:53 localhost kernel:   [<ffffffff>] 0xffffffff
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: other info that might help us debug this:
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: 2 locks held by pccardd/355:
Jun 10 02:41:53 localhost kernel:  #0:  (&socket->skt_mutex){--..}, at: 
[<c0615d3b>] mutex_lock+0x21/0x24
Jun 10 02:41:53 localhost kernel:  #1:  (ide_lock){.+..}, at: 
[<f8e0269d>] ide_unregister+0x11d/0x56e [ide_core]
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: the soft-irq-safe lock's dependencies:
Jun 10 02:41:53 localhost kernel: -> (ide_lock){.+..} ops: 0 {
Jun 10 02:41:53 localhost kernel:    initial-use  at:
Jun 10 02:41:53 localhost kernel:                         [<c04441f9>] 
__lock_acquire+0x435/0xb12
Jun 10 02:41:53 localhost kernel:                         [<c0444c97>] 
lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:                         [<c061711f>] 
_spin_lock_irqsave+0x34/0x44
Jun 10 02:41:53 localhost kernel:                         [<f8e04679>] 
ide_intr+0x17/0x1ac [ide_core]
Jun 10 02:41:53 localhost kernel:                         [<f8e07825>] 
ide_polling+0x22/0x64 [ide_core]
Jun 10 02:41:53 localhost kernel:                         [<f8e07a62>] 
init_irq+0x1fb/0x3bd [ide_core]
Jun 10 02:41:53 localhost kernel:                         [<f8e07d4e>] 
hwif_init+0x12a/0x302 [ide_core]
Jun 10 02:41:53 localhost kernel:                         [<f8e0808c>] 
probe_hwif_init_with_fixup+0x20/0x8c [ide_core]
Jun 10 02:41:53 localhost kernel:                         [<f8e02c11>] 
ide_register_hw_with_fixup+0x123/0x156 [ide_core]
Jun 10 02:41:53 localhost kernel:                         [<f8cae0b8>] 
idecs_register+0x72/0x7a [ide_cs]
Jun 10 02:41:53 localhost kernel:                         [<f8cae464>] 
ide_probe+0x3a4/0x4c0 [ide_cs]
Jun 10 02:41:53 localhost kernel:                         [<c0566ac3>] 
pcmcia_device_probe+0xab/0xff
Jun 10 02:41:53 localhost kernel:                         [<c055ccdc>] 
driver_probe_device+0xe9/0x16a
Jun 10 02:41:53 localhost kernel:                         [<c055ce86>] 
__driver_attach+0x76/0xaf
Jun 10 02:41:53 localhost kernel:                         [<c055c1cc>] 
bus_for_each_dev+0x3a/0x5f
Jun 10 02:41:53 localhost kernel:                         [<c055cb27>] 
driver_attach+0x19/0x1b
Jun 10 02:41:53 localhost kernel:                         [<c055c4ea>] 
bus_add_driver+0x79/0x181
Jun 10 02:41:53 localhost kernel:                         [<c055d081>] 
driver_register+0x67/0x6c
Jun 10 02:41:53 localhost kernel:                         [<c0567565>] 
pcmcia_register_driver+0xf7/0x128
Jun 10 02:41:53 localhost kernel:                         [<f8a2f00d>] 
0xf8a2f00d
Jun 10 02:41:53 localhost kernel:                         [<c044c2eb>] 
sys_init_module+0x1579/0x16ca
Jun 10 02:41:53 localhost kernel:                         [<c0404e26>] 
sysenter_past_esp+0x5f/0x99
Jun 10 02:41:53 localhost kernel:                         [<ffffffff>] 
0xffffffff
Jun 10 02:41:53 localhost kernel:    in-softirq-W at:
Jun 10 02:41:53 localhost kernel:                         [<c0444171>] 
__lock_acquire+0x3ad/0xb12
Jun 10 02:41:53 localhost kernel:                         [<c0444c97>] 
lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:                         [<c061711f>] 
_spin_lock_irqsave+0x34/0x44
Jun 10 02:41:53 localhost kernel:                         [<f8e04679>] 
ide_intr+0x17/0x1ac [ide_core]
Jun 10 02:41:53 localhost kernel:                         [<f8e07825>] 
ide_polling+0x22/0x64 [ide_core]
Jun 10 02:41:53 localhost kernel:                         [<c0430446>] 
run_timer_softirq+0x11a/0x182
Jun 10 02:41:53 localhost kernel:                         [<c042d286>] 
__do_softirq+0x6f/0xe9
Jun 10 02:41:53 localhost kernel:                         [<c0406f72>] 
do_softirq+0x61/0xc7
Jun 10 02:41:53 localhost kernel:                         [<ffffffff>] 
0xffffffff
Jun 10 02:41:53 localhost kernel:  }
Jun 10 02:41:53 localhost kernel:  ... key      at: [<f8e13c10>] 
ide_lock+0x10/0xffff6afd [ide_core]
Jun 10 02:41:53 localhost kernel:  -> (&n->list_lock){.+..} ops: 0 {
Jun 10 02:41:53 localhost kernel:     initial-use  at:
Jun 10 02:41:53 localhost kernel:                           [<c04441f9>] 
__lock_acquire+0x435/0xb12
Jun 10 02:41:53 localhost kernel:                           [<c0444c97>] 
lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:                           [<c0616de9>] 
_spin_lock+0x2b/0x38
Jun 10 02:41:53 localhost kernel:                           [<c04788ee>] 
add_partial+0xe/0x27
Jun 10 02:41:53 localhost kernel:                           [<c04794ed>] 
__slab_free+0x5e/0x278
Jun 10 02:41:53 localhost kernel:                           [<c0479ec2>] 
kmem_cache_free+0x77/0x97
Jun 10 02:41:53 localhost kernel:                           [<c05119ac>] 
acpi_os_release_object+0x8/0xc
Jun 10 02:41:53 localhost kernel:                           [<c0527d9a>] 
acpi_ut_delete_object_desc+0x47/0x4d
Jun 10 02:41:53 localhost kernel:                           [<c05274c5>] 
acpi_ut_delete_internal_obj+0x141/0x148
Jun 10 02:41:53 localhost kernel:                           [<c0527519>] 
acpi_ut_update_ref_count+0x4d/0xa6
Jun 10 02:41:53 localhost kernel:                           [<c0527631>] 
acpi_ut_update_object_reference+0xbf/0x125
Jun 10 02:41:53 localhost kernel:                           [<c05276bc>] 
acpi_ut_remove_reference+0x25/0x28
Jun 10 02:41:53 localhost kernel:                           [<c051c4e9>] 
acpi_ex_create_method+0x99/0xa3
Jun 10 02:41:53 localhost kernel:                           [<c0515729>] 
acpi_ds_load1_end_op+0xfd/0x144
Jun 10 02:41:53 localhost kernel:                           [<c0522e32>] 
acpi_ps_parse_loop+0x587/0x719
Jun 10 02:41:53 localhost kernel:                           [<c0522292>] 
acpi_ps_parse_aml+0x68/0x246
Jun 10 02:41:53 localhost kernel:                           [<c0521c42>] 
acpi_ns_one_complete_parse+0xbe/0xd1
Jun 10 02:41:53 localhost kernel:                           [<c0521c67>] 
acpi_ns_parse_table+0x12/0x23
Jun 10 02:41:53 localhost kernel:                           [<c051fda2>] 
acpi_ns_load_table+0x3e/0x80
Jun 10 02:41:53 localhost kernel:                           [<c0524bbb>] 
acpi_load_tables+0xd3/0x17f
Jun 10 02:41:53 localhost kernel:                           [<c075aa59>] 
acpi_early_init+0x71/0x105
Jun 10 02:41:53 localhost kernel:                           [<c07429b2>] 
start_kernel+0x33f/0x34c
Jun 10 02:41:53 localhost kernel:                           [<00000000>] 0x0
Jun 10 02:41:53 localhost kernel:                           [<ffffffff>] 
0xffffffff
Jun 10 02:41:53 localhost kernel:     in-softirq-W at:
Jun 10 02:41:53 localhost kernel:                           [<c0444171>] 
__lock_acquire+0x3ad/0xb12
Jun 10 02:41:53 localhost kernel:                           [<c0444c97>] 
lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:                           [<c0616de9>] 
_spin_lock+0x2b/0x38
Jun 10 02:41:53 localhost kernel:                           [<c04788ee>] 
add_partial+0xe/0x27
Jun 10 02:41:53 localhost kernel:                           [<c04794ed>] 
__slab_free+0x5e/0x278
Jun 10 02:41:53 localhost kernel:                           [<c0479ec2>] 
kmem_cache_free+0x77/0x97
Jun 10 02:41:53 localhost kernel:                           [<c048c53a>] 
__d_free+0x23/0x26
Jun 10 02:41:53 localhost kernel:                           [<c048c5b5>] 
d_callback+0xb/0xd
Jun 10 02:41:53 localhost kernel:                           [<c043766f>] 
__rcu_process_callbacks+0xff/0x16f
Jun 10 02:41:53 localhost kernel:                           [<c04376fa>] 
rcu_process_callbacks+0x1b/0x35
Jun 10 02:41:53 localhost kernel:                           [<c042d386>] 
tasklet_action+0x53/0xa8
Jun 10 02:41:53 localhost kernel:                           [<c042d286>] 
__do_softirq+0x6f/0xe9
Jun 10 02:41:53 localhost kernel:                           [<c0406f72>] 
do_softirq+0x61/0xc7
Jun 10 02:41:53 localhost kernel:                           [<ffffffff>] 
0xffffffff
Jun 10 02:41:53 localhost kernel:   }
Jun 10 02:41:53 localhost kernel:   ... key      at: [<c0a1f0e4>] 
__key.17793+0x0/0x8
Jun 10 02:41:53 localhost kernel:  ... acquired at:
Jun 10 02:41:53 localhost kernel:    [<c044475d>] __lock_acquire+0x999/0xb12
Jun 10 02:41:53 localhost kernel:    [<c0444c97>] lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:    [<c0616de9>] _spin_lock+0x2b/0x38
Jun 10 02:41:53 localhost kernel:    [<c04788ee>] add_partial+0xe/0x27
Jun 10 02:41:53 localhost kernel:    [<c04794ed>] __slab_free+0x5e/0x278
Jun 10 02:41:53 localhost kernel:    [<c0479ca6>] kfree+0x82/0xa2
Jun 10 02:41:53 localhost kernel:    [<f8e08223>] 
drive_release_dev+0x67/0xae [ide_core]
Jun 10 02:41:53 localhost kernel:    [<c055a228>] device_release+0x3c/0x7e
Jun 10 02:41:53 localhost kernel:    [<c04ea5b3>] kobject_cleanup+0x45/0x5f
Jun 10 02:41:53 localhost kernel:    [<c04ea5d8>] kobject_release+0xb/0xd
Jun 10 02:41:53 localhost kernel:    [<c04eb1df>] kref_put+0x63/0x71
Jun 10 02:41:53 localhost kernel:    [<c04ea56c>] kobject_put+0x14/0x16
Jun 10 02:41:53 localhost kernel:    [<c055a37b>] put_device+0x11/0x13
Jun 10 02:41:53 localhost kernel:    [<c055ab1f>] 
device_unregister+0x12/0x15
Jun 10 02:41:53 localhost kernel:    [<f8e02623>] 
ide_unregister+0xa3/0x56e [ide_core]
Jun 10 02:41:53 localhost kernel:    [<f8cae01b>] ide_release+0x1b/0x2d 
[ide_cs]
Jun 10 02:41:53 localhost kernel:    [<f8cae038>] ide_detach+0xb/0x19 
[ide_cs]
Jun 10 02:41:53 localhost kernel:    [<c056697d>] 
pcmcia_device_remove+0x53/0xb9
Jun 10 02:41:53 localhost kernel:    [<c055caf2>] 
__device_release_driver+0x74/0x90
Jun 10 02:41:53 localhost kernel:    [<c055cef4>] 
device_release_driver+0x35/0x4c
Jun 10 02:41:53 localhost kernel:    [<c055c462>] 
bus_remove_device+0x73/0x82
Jun 10 02:41:53 localhost kernel:    [<c055aa97>] device_del+0x218/0x28e
Jun 10 02:41:53 localhost kernel:    [<c055ab18>] device_unregister+0xb/0x15
Jun 10 02:41:53 localhost kernel:    [<c05665a1>] 
pcmcia_card_remove+0x5a/0x7d
Jun 10 02:41:53 localhost kernel:    [<c0566f88>] ds_event+0x59/0x8b
Jun 10 02:41:53 localhost kernel:    [<c0562c20>] send_event+0x3e/0x57
Jun 10 02:41:53 localhost kernel:    [<c0562e0b>] 
socket_remove_drivers+0x12/0x14
Jun 10 02:41:53 localhost kernel:    [<c0562e1c>] socket_shutdown+0xf/0xb5
Jun 10 02:41:53 localhost kernel:    [<c0562ee8>] socket_remove+0x26/0x2b
Jun 10 02:41:53 localhost kernel:    [<c05634b4>] pccardd+0x12a/0x1e6
Jun 10 02:41:53 localhost kernel:    [<c0439600>] kthread+0x3b/0x63
Jun 10 02:41:53 localhost kernel:    [<c0405b13>] 
kernel_thread_helper+0x7/0x10
Jun 10 02:41:53 localhost kernel:    [<ffffffff>] 0xffffffff
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: the soft-irq-unsafe lock's dependencies:
Jun 10 02:41:53 localhost kernel: -> (resource_lock){--..} ops: 0 {
Jun 10 02:41:53 localhost kernel:    initial-use  at:
Jun 10 02:41:53 localhost kernel:                         [<c04441f9>] 
__lock_acquire+0x435/0xb12
Jun 10 02:41:53 localhost kernel:                         [<c0444c97>] 
lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:                         [<c0616e5e>] 
_write_lock+0x2b/0x38
Jun 10 02:41:53 localhost kernel:                         [<c042dc60>] 
request_resource+0x13/0x36
Jun 10 02:41:53 localhost kernel:                         [<c05068bb>] 
vgacon_startup+0x196/0x349
Jun 10 02:41:53 localhost kernel:                         [<c075d3d5>] 
con_init+0x1a/0x217
Jun 10 02:41:53 localhost kernel:                         [<c075cee5>] 
console_init+0x19/0x27
Jun 10 02:41:53 localhost kernel:                         [<c07428b5>] 
start_kernel+0x242/0x34c
Jun 10 02:41:53 localhost kernel:                         [<00000000>] 0x0
Jun 10 02:41:53 localhost kernel:                         [<ffffffff>] 
0xffffffff
Jun 10 02:41:53 localhost kernel:    softirq-on-W at:
Jun 10 02:41:53 localhost kernel:                         [<c04441e4>] 
__lock_acquire+0x420/0xb12
Jun 10 02:41:53 localhost kernel:                         [<c0444c97>] 
lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:                         [<c0616e5e>] 
_write_lock+0x2b/0x38
Jun 10 02:41:53 localhost kernel:                         [<c042dc60>] 
request_resource+0x13/0x36
Jun 10 02:41:53 localhost kernel:                         [<c05068bb>] 
vgacon_startup+0x196/0x349
Jun 10 02:41:53 localhost kernel:                         [<c075d3d5>] 
con_init+0x1a/0x217
Jun 10 02:41:53 localhost kernel:                         [<c075cee5>] 
console_init+0x19/0x27
Jun 10 02:41:53 localhost kernel:                         [<c07428b5>] 
start_kernel+0x242/0x34c
Jun 10 02:41:53 localhost kernel:                         [<00000000>] 0x0
Jun 10 02:41:53 localhost kernel:                         [<ffffffff>] 
0xffffffff
Jun 10 02:41:53 localhost kernel:    hardirq-on-W at:
Jun 10 02:41:53 localhost kernel:                         [<c04441c0>] 
__lock_acquire+0x3fc/0xb12
Jun 10 02:41:53 localhost kernel:                         [<c0444c97>] 
lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:                         [<c0616e5e>] 
_write_lock+0x2b/0x38
Jun 10 02:41:53 localhost kernel:                         [<c042dc60>] 
request_resource+0x13/0x36
Jun 10 02:41:53 localhost kernel:                         [<c05068bb>] 
vgacon_startup+0x196/0x349
Jun 10 02:41:53 localhost kernel:                         [<c075d3d5>] 
con_init+0x1a/0x217
Jun 10 02:41:53 localhost kernel:                         [<c075cee5>] 
console_init+0x19/0x27
Jun 10 02:41:53 localhost kernel:                         [<c07428b5>] 
start_kernel+0x242/0x34c
Jun 10 02:41:53 localhost kernel:                         [<00000000>] 0x0
Jun 10 02:41:53 localhost kernel:                         [<ffffffff>] 
0xffffffff
Jun 10 02:41:53 localhost kernel:  }
Jun 10 02:41:53 localhost kernel:  ... key      at: [<c06fce14>] 
resource_lock+0x10/0x1c
Jun 10 02:41:53 localhost kernel:
Jun 10 02:41:53 localhost kernel: stack backtrace:
Jun 10 02:41:53 localhost kernel:  [<c0405e6a>] show_trace_log_lvl+0x1a/0x2f
Jun 10 02:41:53 localhost kernel:  [<c04068cf>] show_trace+0x12/0x14
Jun 10 02:41:53 localhost kernel:  [<c0406928>] dump_stack+0x16/0x18
Jun 10 02:41:53 localhost kernel:  [<c0443d30>] check_usage+0x258/0x262
Jun 10 02:41:53 localhost kernel:  [<c04446c2>] __lock_acquire+0x8fe/0xb12
Jun 10 02:41:53 localhost kernel:  [<c0444c97>] lock_acquire+0x56/0x6f
Jun 10 02:41:53 localhost kernel:  [<c0616e5e>] _write_lock+0x2b/0x38
Jun 10 02:41:53 localhost kernel:  [<c042dcb2>] __release_region+0x2f/0xdd
Jun 10 02:41:53 localhost kernel:  [<f8e02521>] 
ide_hwif_release_regions+0x37/0x96 [ide_core]
Jun 10 02:41:53 localhost kernel:  [<f8e026a4>] 
ide_unregister+0x124/0x56e [ide_core]
Jun 10 02:41:53 localhost kernel:  [<f8cae01b>] ide_release+0x1b/0x2d 
[ide_cs]
Jun 10 02:41:53 localhost kernel:  [<f8cae038>] ide_detach+0xb/0x19 [ide_cs]
Jun 10 02:41:53 localhost kernel:  [<c056697d>] 
pcmcia_device_remove+0x53/0xb9
Jun 10 02:41:53 localhost kernel:  [<c055caf2>] 
__device_release_driver+0x74/0x90
Jun 10 02:41:53 localhost kernel:  [<c055cef4>] 
device_release_driver+0x35/0x4c
Jun 10 02:41:53 localhost kernel:  [<c055c462>] bus_remove_device+0x73/0x82
Jun 10 02:41:53 localhost kernel:  [<c055aa97>] device_del+0x218/0x28e
Jun 10 02:41:53 localhost kernel:  [<c055ab18>] device_unregister+0xb/0x15
Jun 10 02:41:53 localhost kernel:  [<c05665a1>] pcmcia_card_remove+0x5a/0x7d
Jun 10 02:41:53 localhost kernel:  [<c0566f88>] ds_event+0x59/0x8b
Jun 10 02:41:53 localhost kernel:  [<c0562c20>] send_event+0x3e/0x57
Jun 10 02:41:53 localhost kernel:  [<c0562e0b>] 
socket_remove_drivers+0x12/0x14
Jun 10 02:41:53 localhost kernel:  [<c0562e1c>] socket_shutdown+0xf/0xb5
Jun 10 02:41:53 localhost kernel:  [<c0562ee8>] socket_remove+0x26/0x2b
Jun 10 02:41:53 localhost kernel:  [<c05634b4>] pccardd+0x12a/0x1e6
Jun 10 02:41:53 localhost kernel:  [<c0439600>] kthread+0x3b/0x63
Jun 10 02:41:53 localhost kernel:  [<c0405b13>] 
kernel_thread_helper+0x7/0x10
Jun 10 02:41:53 localhost kernel:  =======================
Jun 10 02:41:53 localhost kernel: BUG: sleeping function called from 
invalid context at kernel/rwsem.c:20
Jun 10 02:41:53 localhost kernel: in_atomic():0, irqs_disabled():1
Jun 10 02:41:53 localhost kernel: INFO: lockdep is turned off.
Jun 10 02:41:53 localhost kernel: irq event stamp: 3798
Jun 10 02:41:53 localhost kernel: hardirqs last  enabled at (3797): 
[<c06171ed>] _spin_unlock_irqrestore+0x36/0x3c
Jun 10 02:41:53 localhost kernel: hardirqs last disabled at (3798): 
[<c0617032>] _spin_lock_irq+0xf/0x3e
Jun 10 02:41:53 localhost kernel: softirqs last  enabled at (3656): 
[<c042d2fa>] __do_softirq+0xe3/0xe9
Jun 10 02:41:53 localhost kernel: softirqs last disabled at (3647): 
[<c0406f72>] do_softirq+0x61/0xc7
Jun 10 02:41:53 localhost kernel:  [<c0405e6a>] show_trace_log_lvl+0x1a/0x2f
Jun 10 02:41:53 localhost kernel:  [<c04068cf>] show_trace+0x12/0x14
Jun 10 02:41:53 localhost kernel:  [<c0406928>] dump_stack+0x16/0x18
Jun 10 02:41:53 localhost kernel:  [<c0422152>] __might_sleep+0xce/0xd5
Jun 10 02:41:53 localhost kernel:  [<c043ca58>] down_read+0x18/0x51
Jun 10 02:41:53 localhost kernel:  [<c04f9066>] pci_get_subsys+0x69/0xe9
Jun 10 02:41:53 localhost kernel:  [<c04f90ff>] pci_get_device+0x19/0x1b
Jun 10 02:41:53 localhost kernel:  [<f8e0223a>] 
init_hwif_default+0x2d/0xf4 [ide_core]
Jun 10 02:41:53 localhost kernel:  [<f8e027c6>] 
ide_unregister+0x246/0x56e [ide_core]
Jun 10 02:41:53 localhost kernel:  [<f8cae01b>] ide_release+0x1b/0x2d 
[ide_cs]
Jun 10 02:41:53 localhost kernel:  [<f8cae038>] ide_detach+0xb/0x19 [ide_cs]
Jun 10 02:41:53 localhost kernel:  [<c056697d>] 
pcmcia_device_remove+0x53/0xb9
Jun 10 02:41:53 localhost kernel:  [<c055caf2>] 
__device_release_driver+0x74/0x90
Jun 10 02:41:53 localhost kernel:  [<c055cef4>] 
device_release_driver+0x35/0x4c
Jun 10 02:41:53 localhost kernel:  [<c055c462>] bus_remove_device+0x73/0x82
Jun 10 02:41:53 localhost kernel:  [<c055aa97>] device_del+0x218/0x28e
Jun 10 02:41:53 localhost kernel:  [<c055ab18>] device_unregister+0xb/0x15
Jun 10 02:41:53 localhost kernel:  [<c05665a1>] pcmcia_card_remove+0x5a/0x7d
Jun 10 02:41:53 localhost kernel:  [<c0566f88>] ds_event+0x59/0x8b
Jun 10 02:41:53 localhost kernel:  [<c0562c20>] send_event+0x3e/0x57
Jun 10 02:41:53 localhost kernel:  [<c0562e0b>] 
socket_remove_drivers+0x12/0x14
Jun 10 02:41:53 localhost kernel:  [<c0562e1c>] socket_shutdown+0xf/0xb5
Jun 10 02:41:53 localhost kernel:  [<c0562ee8>] socket_remove+0x26/0x2b
Jun 10 02:41:53 localhost kernel:  [<c05634b4>] pccardd+0x12a/0x1e6
Jun 10 02:41:53 localhost kernel:  [<c0439600>] kthread+0x3b/0x63
Jun 10 02:41:53 localhost kernel:  [<c0405b13>] 
kernel_thread_helper+0x7/0x10
Jun 10 02:41:53 localhost kernel:  =======================

Re: libata and legacy ide pcmcia failure

[Mark Lord]

Robert de Rooy wrote:
> Mark Lord wrote:
>> Oh crap.  I did test it a couple of months ago, but my boot/root drive
>> is libata not IDE -- so no panic on boot with it.  After booting, it 
>> worked
>> just fine talking to PC-CARD CF devices using the polling.
> 
> Ok, no problem. I recompiled the kernel with libata (but without the 
> libata pcmcia support), and made legacy ide (only ide-core and ide-cs) 
> modular.
> This allowed me to boot my PATA HDD with libata, and when I plugged in 
> the PCMCIA card it picked it up automatically with the legacy ide drivers.

Good stuff!

> Jun 10 02:40:06 localhost kernel: pccard: PCMCIA card inserted into slot 0
> Jun 10 02:40:07 localhost kernel: cs: memory probe 
> 0xe8000000-0xefffffff: excluding 0xe8000000-0xefffffff
> Jun 10 02:40:07 localhost kernel: cs: memory probe 
> 0xc0200000-0xcfffffff: excluding 0xc0200000-0xc11fffff 
> 0xc1a00000-0xc21fffff 0xc2a00000-0xc31fffff 0xc3a00000-0xcc1fffff 
> 0xcca00000-0xcd1fffff 0xcda00000-0xce1fffff 0xcea00000-0xcf1fffff 
> 0xcfa00000-0xd01fffff
> Jun 10 02:40:07 localhost kernel: pcmcia: registering new device pcmcia0.0
> Jun 10 02:40:07 localhost kernel: Uniform Multi-Platform E-IDE driver 
> Revision: 7.00alpha2
> Jun 10 02:40:07 localhost kernel: ide: Assuming 33MHz system bus speed 
> for PIO modes; override with idebus=xx
> Jun 10 02:40:07 localhost kernel: hda: Memory Card Adapter, CFA DISK drive
> Jun 10 02:40:08 localhost kernel: ide0 at 0x4100-0x4107,0x410e on irq 3
> Jun 10 02:40:08 localhost kernel: ide-cs: hda: Vpp = 0.0
> Jun 10 02:40:08 localhost udevd-event[2630]: udev_rules_apply_format: 
> unknown format variable '$modalias'
> 
> At this point I noticed no /dev/hda* devices existed, so I created them 
> manually with mknod. But regardless I was not able to actually mount a 
> filesystem, getting an error from mount that the device did not exist.

Yeah, I don't see any "parition table" messages there,
so it must've hung on the I/O somehow.
Bummer, but it was worth trying, I suppose.

> When pulling the card I also got the following..
> 
..
> Jun 10 02:41:53 localhost kernel: [ INFO: soft-safe -> soft-unsafe lock 
> order detected ]
..
That's probably some weird interaction with the simple polling patch,
so I think we can disregard it, unless it pops up again someday on
an unpatched kernel.

Well, at this point, I think the only way to make progress is for one of
the IDE/libata gurus to actually get hold of the same card you have,
meaning Alan Cox (best choice), or myself, or Bart.  Or maybe Tejun.

Without that, this isn't likely to improve much.  

Cheers

Re: libata and legacy ide pcmcia failure

[Robert de Rooy]

Mark Lord wrote:
>
> Well, at this point, I think the only way to make progress is for one of
> the IDE/libata gurus to actually get hold of the same card you have,
> meaning Alan Cox (best choice), or myself, or Bart.  Or maybe Tejun.
>
> Without that, this isn't likely to improve much. 
> Cheers
>

Yeah, I was figuring it was going to come to this.
I hardly ever use the adapter, as I have other means to read these 
memory cards.

So... Alan, want to receive a PCMCIA memory-card adapter? I will include 
a 16MB sony memorystick, so it actually works.
If so, send me your mailing address privately.

Re: libata and legacy ide pcmcia failure

[Russell King]

On Sun, Jun 10, 2007 at 11:50:52PM +0200, Robert de Rooy wrote:
> Mark Lord wrote:
> >
> > Well, at this point, I think the only way to make progress is for one of
> > the IDE/libata gurus to actually get hold of the same card you have,
> > meaning Alan Cox (best choice), or myself, or Bart.  Or maybe Tejun.
> >
> > Without that, this isn't likely to improve much. 
> > Cheers
> >
> 
> Yeah, I was figuring it was going to come to this.
> I hardly ever use the adapter, as I have other means to read these 
> memory cards.
> 
> So... Alan, want to receive a PCMCIA memory-card adapter? I will include 
> a 16MB sony memorystick, so it actually works.
> If so, send me your mailing address privately.

Before you do, it might help to build the ide-disk module and insert that
as well?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: libata and legacy ide pcmcia failure

[Mark Lord]

Russell King wrote:
> On Sun, Jun 10, 2007 at 11:50:52PM +0200, Robert de Rooy wrote:
>> Mark Lord wrote:
>>> Well, at this point, I think the only way to make progress is for one of
>>> the IDE/libata gurus to actually get hold of the same card you have,
>>> meaning Alan Cox (best choice), or myself, or Bart.  Or maybe Tejun.
>>>
>>> Without that, this isn't likely to improve much. 
>>> Cheers
>>>
>> Yeah, I was figuring it was going to come to this.
>> I hardly ever use the adapter, as I have other means to read these 
>> memory cards.
>>
>> So... Alan, want to receive a PCMCIA memory-card adapter? I will include 
>> a 16MB sony memorystick, so it actually works.
>> If so, send me your mailing address privately.
> 
> Before you do, it might help to build the ide-disk module and insert that
> as well?

ARrrggghh!!  Of course, that would explain the utter lack
of disk partition check messages, now wouldn't it!

Thanks Russell !

Re: libata and legacy ide pcmcia failure

[Robert de Rooy]

Mark Lord wrote:
> Russell King wrote:
>>
>> Before you do, it might help to build the ide-disk module and insert 
>> that
>> as well?
>
> ARrrggghh!!  Of course, that would explain the utter lack
> of disk partition check messages, now wouldn't it!
>
> Thanks Russell !
>

Doh! yes that would obviously help.
With this I can declare success!! I was able to read and write to the 
card without any problems, although I did not try to stress it.

Jun 12 00:19:42 localhost kernel: pccard: PCMCIA card inserted into slot 0
Jun 12 00:19:42 localhost kernel: cs: memory probe 
0xe8000000-0xefffffff: excluding 0xe8000000-0xefffffff
Jun 12 00:19:42 localhost kernel: cs: memory probe 
0xc0200000-0xcfffffff: excluding 0xc0200000-0xc11fffff 
0xc1a00000-0xc21fffff 0xc2a00000-0xc31fffff 0xc3a00000-0xcc1fffff 
0xcca00000-0xcd1fffff 0xcda00000-0xce1fffff 0xcea00000-0xcf1fffff 
0xcfa00000-0xd01fffff
Jun 12 00:19:42 localhost kernel: pcmcia: registering new device pcmcia0.0
Jun 12 00:19:42 localhost kernel: Uniform Multi-Platform E-IDE driver 
Revision: 7.00alpha2
Jun 12 00:19:42 localhost kernel: ide: Assuming 33MHz system bus speed 
for PIO modes; override with idebus=xx
Jun 12 00:19:45 localhost kernel: hda: Memory Card Adapter, CFA DISK drive
Jun 12 00:19:45 localhost kernel: ide0 at 0x4100-0x4107,0x410e on irq 3
Jun 12 00:19:45 localhost kernel: ide-cs: hda: Vpp = 0.0
Jun 12 00:19:45 localhost udevd-event[20730]: udev_rules_apply_format: 
unknown format variable '$modalias'
Jun 12 00:19:45 localhost kernel: hda: max request size: 128KiB
Jun 12 00:19:45 localhost kernel: hda: 253696 sectors (129 MB) w/1KiB 
Cache, CHS=991/16/16
Jun 12 00:19:45 localhost kernel:  hda: hda1
Jun 12 00:19:48 localhost hald: mounted /dev/hda1 on behalf of uid 0

Re: libata and legacy ide pcmcia failure

[Mark Lord]

Robert de Rooy wrote:
> (after applying the ide-polling experimental patch)
>
> With this I can declare success!! I was able to read and write to the 
> card without any problems, although I did not try to stress it.
> 
> Jun 12 00:19:42 localhost kernel: pccard: PCMCIA card inserted into slot 0
> Jun 12 00:19:42 localhost kernel: cs: memory probe 
> 0xe8000000-0xefffffff: excluding 0xe8000000-0xefffffff
> Jun 12 00:19:42 localhost kernel: cs: memory probe 
> 0xc0200000-0xcfffffff: excluding 0xc0200000-0xc11fffff 
> 0xc1a00000-0xc21fffff 0xc2a00000-0xc31fffff 0xc3a00000-0xcc1fffff 
> 0xcca00000-0xcd1fffff 0xcda00000-0xce1fffff 0xcea00000-0xcf1fffff 
> 0xcfa00000-0xd01fffff
> Jun 12 00:19:42 localhost kernel: pcmcia: registering new device pcmcia0.0
> Jun 12 00:19:42 localhost kernel: Uniform Multi-Platform E-IDE driver 
> Revision: 7.00alpha2
> Jun 12 00:19:42 localhost kernel: ide: Assuming 33MHz system bus speed 
> for PIO modes; override with idebus=xx
> Jun 12 00:19:45 localhost kernel: hda: Memory Card Adapter, CFA DISK drive
> Jun 12 00:19:45 localhost kernel: ide0 at 0x4100-0x4107,0x410e on irq 3
> Jun 12 00:19:45 localhost kernel: ide-cs: hda: Vpp = 0.0
> Jun 12 00:19:45 localhost udevd-event[20730]: udev_rules_apply_format: 
> unknown format variable '$modalias'
> Jun 12 00:19:45 localhost kernel: hda: max request size: 128KiB
> Jun 12 00:19:45 localhost kernel: hda: 253696 sectors (129 MB) w/1KiB 
> Cache, CHS=991/16/16
> Jun 12 00:19:45 localhost kernel:  hda: hda1
> Jun 12 00:19:48 localhost hald: mounted /dev/hda1 on behalf of uid 0

Okay, Tejun / Bart / Alan:

This proves that the device does work correctly in most respects
except for interrupt delivery.  The status bits are working and
it can be probed for, configured, and used.

So, next step might be to try and understand the interrupt mis-delivery
problem some more.   I've lost the history of the original issue,
but we now know that everything except the actual interrupt seems good.

Cheers
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

Re: libata and legacy ide pcmcia failure

[Tejun Heo]

Mark Lord wrote:
> Robert de Rooy wrote:
>> (after applying the ide-polling experimental patch)
>>
>> With this I can declare success!! I was able to read and write to the
>> card without any problems, although I did not try to stress it.
>>
>> Jun 12 00:19:42 localhost kernel: pccard: PCMCIA card inserted into
>> slot 0
>> Jun 12 00:19:42 localhost kernel: cs: memory probe
>> 0xe8000000-0xefffffff: excluding 0xe8000000-0xefffffff
>> Jun 12 00:19:42 localhost kernel: cs: memory probe
>> 0xc0200000-0xcfffffff: excluding 0xc0200000-0xc11fffff
>> 0xc1a00000-0xc21fffff 0xc2a00000-0xc31fffff 0xc3a00000-0xcc1fffff
>> 0xcca00000-0xcd1fffff 0xcda00000-0xce1fffff 0xcea00000-0xcf1fffff
>> 0xcfa00000-0xd01fffff
>> Jun 12 00:19:42 localhost kernel: pcmcia: registering new device
>> pcmcia0.0
>> Jun 12 00:19:42 localhost kernel: Uniform Multi-Platform E-IDE driver
>> Revision: 7.00alpha2
>> Jun 12 00:19:42 localhost kernel: ide: Assuming 33MHz system bus speed
>> for PIO modes; override with idebus=xx
>> Jun 12 00:19:45 localhost kernel: hda: Memory Card Adapter, CFA DISK
>> drive
>> Jun 12 00:19:45 localhost kernel: ide0 at 0x4100-0x4107,0x410e on irq 3
>> Jun 12 00:19:45 localhost kernel: ide-cs: hda: Vpp = 0.0
>> Jun 12 00:19:45 localhost udevd-event[20730]: udev_rules_apply_format:
>> unknown format variable '$modalias'
>> Jun 12 00:19:45 localhost kernel: hda: max request size: 128KiB
>> Jun 12 00:19:45 localhost kernel: hda: 253696 sectors (129 MB) w/1KiB
>> Cache, CHS=991/16/16
>> Jun 12 00:19:45 localhost kernel:  hda: hda1
>> Jun 12 00:19:48 localhost hald: mounted /dev/hda1 on behalf of uid 0
> 
> Okay, Tejun / Bart / Alan:
> 
> This proves that the device does work correctly in most respects
> except for interrupt delivery.  The status bits are working and
> it can be probed for, configured, and used.

libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't
cover nodata commands tho).

-- 
tejun

Re: libata and legacy ide pcmcia failure

[Albert Lee]

> 
> 
> libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't
> cover nodata commands tho).
> 

Hi Tejun,

Polling of nodata commands was fixed in:
http://marc.info/?l=linux-ide&m=116546272916399&w=2

--
albert

Re: libata and legacy ide pcmcia failure

[Tejun Heo]

Albert Lee wrote:
>>
>> libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't
>> cover nodata commands tho).
>>
> 
> Hi Tejun,
> 
> Polling of nodata commands was fixed in:
> http://marc.info/?l=linux-ide&m=116546272916399&w=2

Right.  Thanks for reminding me.  :-)

-- 
tejun

Re: libata and legacy ide pcmcia failure

[Robert de Rooy]

Tejun Heo wrote:
> Albert Lee wrote:
>   
>>> libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't
>>> cover nodata commands tho).
>>>
>>>       
>> Hi Tejun,
>>
>> Polling of nodata commands was fixed in:
>> http://marc.info/?l=linux-ide&m=116546272916399&w=2
>>     
>
> Right.  Thanks for reminding me.  :-)
>
>   

I did another try with libata pcmcia support using 2.6.22-rc5 which 
already includes the nodata polling fix, in combination with 
disable-dev_init_param-and-setxfermode-for-CFA.patch and the 
timing-debug.patch

Jun 22 13:19:44 localhost kernel: pccard: PCMCIA card inserted into slot 1
Jun 22 13:19:44 localhost kernel: cs: memory probe 
0xe8000000-0xefffffff: excluding 0xe8000000-0xefffffff
Jun 22 13:19:44 localhost kernel: cs: memory probe 
0xc0200000-0xcfffffff: excluding 0xc0200000-0xc11fffff 
0xc1a00000-0xc21fffff 0xc2a00000-0xc31fffff 0xc3a00000-0xcc1fffff 
0xcca00000-0xcd1fffff 0xcda00000-0xce1fffff 0xcea00000-0xcf1fffff 
0xcfa00000-0xd01fffff
Jun 22 13:19:44 localhost kernel: pcmcia: registering new device pcmcia1.0
Jun 22 13:19:44 localhost kernel: scsi2 : pata_pcmcia
Jun 22 13:19:44 localhost kernel: ata3: PATA max PIO0 cmd 0x00014100 ctl 
0x0001410e bmdma 0x00000000 irq 0
Jun 22 13:19:44 localhost kernel: ata3: soft resetting port
Jun 22 13:19:44 localhost kernel: ata3: reset complete
Jun 22 13:19:44 localhost kernel: ata3.00: issuing IDENTIFY
Jun 22 13:19:45 localhost kernel: ata3.00: IDENTIFY complete
Jun 22 13:19:45 localhost kernel: ata3.00: CFA: Memory Card Adapter, 
20011212, max PIO1
Jun 22 13:19:45 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA
Jun 22 13:19:45 localhost kernel: ata3.00: issuing IDENTIFY
Jun 22 13:19:45 localhost kernel: ata3.00: IDENTIFY complete
Jun 22 13:19:45 localhost kernel: ata3.00: configured for PIO0
Jun 22 13:19:45 localhost kernel: ata3: EH complete
Jun 22 13:19:45 localhost kernel: scsi 2:0:0:0: Direct-Access     
ATA      Memory Card Adap 2001 PQ: 0 ANSI: 5
Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] 253696 512-byte 
hardware sectors (130 MB)
Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write cache: 
disabled, read cache: enabled, doesn't support DPO or FUA
Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] 253696 512-byte 
hardware sectors (130 MB)
Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write cache: 
disabled, read cache: enabled, doesn't support DPO or FUA
Jun 22 13:20:15 localhost kernel:  sdb:<3>ata3.00: exception Emask 0x0 
SAct 0x0 SErr 0x0 action 0x2 frozen
Jun 22 13:20:15 localhost kernel: ata3.00: cmd 
20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
Jun 22 13:20:15 localhost kernel:          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jun 22 13:20:15 localhost kernel: ata3: soft resetting port
Jun 22 13:20:15 localhost kernel: ata3: reset complete
Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x80 on port 
0x00014107
Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x80 on port 
0x00014107
Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x58 on port 
0x00014107
Jun 22 13:20:15 localhost kernel: ata3.00: issuing IDENTIFY
Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x58 on port 
0x00014107
Jun 22 13:20:15 localhost last message repeated 4 times
Jun 22 13:20:15 localhost kernel: ata3.00: IDENTIFY complete
Jun 22 13:20:15 localhost kernel: ata3.00: failed to IDENTIFY (I/O 
error, err_mask=0x2)
Jun 22 13:20:15 localhost kernel: ata3.00: revalidation failed (errno=-5)
Jun 22 13:20:15 localhost kernel: ata3: failed to recover some devices, 
retrying in 5 secs
Jun 22 13:20:20 localhost kernel: ata3: soft resetting port
Jun 22 13:20:20 localhost kernel: ata3: reset complete
Jun 22 13:20:20 localhost kernel: ATA: abnormal status 0x80 on port 
0x00014107
Jun 22 13:20:20 localhost kernel: ATA: abnormal status 0x80 on port 
0x00014107
Jun 22 13:20:20 localhost kernel: ATA: abnormal status 0x58 on port 
0x00014107
Jun 22 13:20:20 localhost kernel: ata3.00: issuing IDENTIFY
Jun 22 13:20:20 localhost kernel: ATA: abnormal status 0x58 on port 
0x00014107
Jun 22 13:20:20 localhost last message repeated 4 times
Jun 22 13:20:20 localhost kernel: ata3.00: IDENTIFY complete
Jun 22 13:20:20 localhost kernel: ata3.00: failed to IDENTIFY (I/O 
error, err_mask=0x2)
Jun 22 13:20:20 localhost kernel: ata3.00: revalidation failed (errno=-5)
Jun 22 13:20:20 localhost kernel: ata3: failed to recover some devices, 
retrying in 5 secs
Jun 22 13:20:25 localhost kernel: ata3: soft resetting port
Jun 22 13:20:25 localhost kernel: ata3: reset complete
Jun 22 13:20:25 localhost kernel: ATA: abnormal status 0xB8 on port 
0x00014107
Jun 22 13:20:25 localhost kernel: ATA: abnormal status 0xB8 on port 
0x00014107
Jun 22 13:20:25 localhost kernel: ATA: abnormal status 0x58 on port 
0x00014107
Jun 22 13:20:25 localhost kernel: ata3.00: issuing IDENTIFY
Jun 22 13:20:25 localhost kernel: ATA: abnormal status 0x58 on port 
0x00014107
Jun 22 13:20:25 localhost last message repeated 4 times
Jun 22 13:20:25 localhost kernel: ata3.00: IDENTIFY complete
Jun 22 13:20:25 localhost kernel: ata3.00: failed to IDENTIFY (I/O 
error, err_mask=0x2)
Jun 22 13:20:25 localhost kernel: ata3.00: revalidation failed (errno=-5)
Jun 22 13:20:25 localhost kernel: ata3.00: disabled
Jun 22 13:20:26 localhost kernel: ata3: EH complete
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel: Dev sdb: unable to read RDB block 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: end_request: I/O error, dev sdb, sector 0
Jun 22 13:20:26 localhost kernel: Buffer I/O error on device sdb, 
logical block 0
Jun 22 13:20:26 localhost kernel:  unable to read partition table
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Attached SCSI 
removable disk
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: Attached scsi generic sg2 
type 0
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] READ CAPACITY failed
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Sense not available.
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Asking for cache 
data failed
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Assuming drive 
cache: write through
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] READ CAPACITY failed
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Sense not available.
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Asking for cache 
data failed
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Assuming drive 
cache: write through
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] READ CAPACITY failed
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Sense not available.
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Asking for cache 
data failed
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Assuming drive 
cache: write through
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] READ CAPACITY failed
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Sense not available.
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Asking for cache 
data failed
Jun 22 13:20:26 localhost kernel: sd 2:0:0:0: [sdb] Assuming drive 
cache: write through
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] READ CAPACITY failed
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Sense not available.
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Asking for cache 
data failed
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Assuming drive 
cache: write through
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] READ CAPACITY failed
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Sense not available.
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Asking for cache 
data failed
Jun 22 13:20:27 localhost kernel: sd 2:0:0:0: [sdb] Assuming drive 
cache: write through
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] READ CAPACITY failed
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Sense not available.
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Asking for cache 
data failed
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Assuming drive 
cache: write through
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] READ CAPACITY failed
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Sense not available.
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Asking for cache 
data failed
Jun 22 13:20:43 localhost kernel: sd 2:0:0:0: [sdb] Assuming drive 
cache: write through
Jun 22 13:20:48 localhost kernel: pccard: card ejected from slot 1
Jun 22 13:20:48 localhost kernel: sd 2:0:0:0: [sdb] Stopping disk
Jun 22 13:20:48 localhost kernel: sd 2:0:0:0: [sdb] START_STOP FAILED
Jun 22 13:20:48 localhost kernel: sd 2:0:0:0: [sdb] Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK

Re: libata and legacy ide pcmcia failure

[Mark Lord]

Robert de Rooy wrote:
>
> I did another try with libata pcmcia support using 2.6.22-rc5 which 
> already includes the nodata polling fix, in combination with 
> disable-dev_init_param-and-setxfermode-for-CFA.patch and the 
> timing-debug.patch
...
> Jun 22 13:19:44 localhost kernel: ata3.00: issuing IDENTIFY
> Jun 22 13:19:45 localhost kernel: ata3.00: IDENTIFY complete
> Jun 22 13:19:45 localhost kernel: ata3.00: CFA: Memory Card Adapter, 
> 20011212, max PIO1
> Jun 22 13:19:45 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA
> Jun 22 13:19:45 localhost kernel: ata3.00: issuing IDENTIFY
> Jun 22 13:19:45 localhost kernel: ata3.00: IDENTIFY complete
> Jun 22 13:19:45 localhost kernel: ata3.00: configured for PIO0
> Jun 22 13:19:45 localhost kernel: ata3: EH complete
> Jun 22 13:19:45 localhost kernel: scsi 2:0:0:0: Direct-Access     
> ATA      Memory Card Adap 2001 PQ: 0 ANSI: 5
> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] 253696 512-byte 
> hardware sectors (130 MB)
> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write cache: 
> disabled, read cache: enabled, doesn't support DPO or FUA
> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] 253696 512-byte 
> hardware sectors (130 MB)
> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write cache: 
> disabled, read cache: enabled, doesn't support DPO or FUA
> Jun 22 13:20:15 localhost kernel:  sdb:<3>ata3.00: exception Emask 0x0 
> SAct 0x0 SErr 0x0 action 0x2 frozen
> Jun 22 13:20:15 localhost kernel: ata3.00: cmd 
> 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
> Jun 22 13:20:15 localhost kernel:          res 
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Jun 22 13:20:15 localhost kernel: ata3: soft resetting port
> Jun 22 13:20:15 localhost kernel: ata3: reset complete
> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x80 on port 
> 0x00014107
> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x80 on port 
> 0x00014107
> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x58 on port 
> 0x00014107
> Jun 22 13:20:15 localhost kernel: ata3.00: issuing IDENTIFY
> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x58 on port 
> 0x00014107
...

Mmm.. I don't know about the first failure there,
but after that it gets into the "stuck DRQ" state
which libata makes no attempt to handle at present.

Here is an additional patch, which hopefully will apply to your kernel
to handle the stuck DRQ.  You may need to hand tweak it, though,
as I'm not entirely certain as to where to place the new call
to ata_drain_fifo().  It's currently on an error recovery path
which works for DMA, but your device is using PIO.  It may still get
hit as-is, but..  Give it a try.


--- linux/drivers/ata/libata-sff.c.orig	2007-04-26 12:02:46.000000000 -0400
+++ linux/drivers/ata/libata-sff.c	2007-04-29 08:29:27.000000000 -0400
@@ -413,6 +413,24 @@
 	ap->ops->irq_on(ap);
 }
 
+static void ata_drain_fifo (struct ata_port *ap, struct ata_queued_cmd *qc)
+{
+	u8 stat = ata_chk_status(ap);
+	/*
+	 * Try to clear stuck DRQ if necessary.
+	 */
+	if ((stat & ATA_DRQ) && (!qc || qc->dma_dir != DMA_TO_DEVICE)) {
+		unsigned int i, limit = 512;
+		printk("Draining up to %u words from data FIFO.\n", limit);
+		for (i = 0; i < limit ; ++i) {
+			ioread16(ap->ioaddr.data_addr);
+			if (!(ata_chk_status(ap) & ATA_DRQ))
+				break;
+		}
+		printk("Drained %u/%u words.\n", i, limit);
+	}
+}
+
 /**
  *	ata_bmdma_drive_eh - Perform EH with given methods for BMDMA controller
  *	@ap: port to handle error for
@@ -469,7 +487,7 @@
 	}
 
 	ata_altstatus(ap);
-	ata_chk_status(ap);
+	ata_drain_fifo(ap, qc);
 	ap->ops->irq_clear(ap);
 
 	spin_unlock_irqrestore(ap->lock, flags);

Re: libata and legacy ide pcmcia failure

[Albert Lee]

Mark Lord wrote:
> Robert de Rooy wrote:
> 
>>
>> I did another try with libata pcmcia support using 2.6.22-rc5 which
>> already includes the nodata polling fix, in combination with
>> disable-dev_init_param-and-setxfermode-for-CFA.patch and the
>> timing-debug.patch
> 
> ...
> 
>> Jun 22 13:19:44 localhost kernel: ata3.00: issuing IDENTIFY
>> Jun 22 13:19:45 localhost kernel: ata3.00: IDENTIFY complete
>> Jun 22 13:19:45 localhost kernel: ata3.00: CFA: Memory Card Adapter,
>> 20011212, max PIO1
>> Jun 22 13:19:45 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA
>> Jun 22 13:19:45 localhost kernel: ata3.00: issuing IDENTIFY
>> Jun 22 13:19:45 localhost kernel: ata3.00: IDENTIFY complete
>> Jun 22 13:19:45 localhost kernel: ata3.00: configured for PIO0
>> Jun 22 13:19:45 localhost kernel: ata3: EH complete
>> Jun 22 13:19:45 localhost kernel: scsi 2:0:0:0: Direct-Access    
>> ATA      Memory Card Adap 2001 PQ: 0 ANSI: 5
>> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] 253696 512-byte
>> hardware sectors (130 MB)
>> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
>> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write cache:
>> disabled, read cache: enabled, doesn't support DPO or FUA
>> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] 253696 512-byte
>> hardware sectors (130 MB)
>> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off
>> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write cache:
>> disabled, read cache: enabled, doesn't support DPO or FUA
>> Jun 22 13:20:15 localhost kernel:  sdb:<3>ata3.00: exception Emask 0x0
>> SAct 0x0 SErr 0x0 action 0x2 frozen
>> Jun 22 13:20:15 localhost kernel: ata3.00: cmd
>> 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
>> Jun 22 13:20:15 localhost kernel:          res
>> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
>> Jun 22 13:20:15 localhost kernel: ata3: soft resetting port
>> Jun 22 13:20:15 localhost kernel: ata3: reset complete
>> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x80 on port
>> 0x00014107
>> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x80 on port
>> 0x00014107
>> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x58 on port
>> 0x00014107
>> Jun 22 13:20:15 localhost kernel: ata3.00: issuing IDENTIFY
>> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x58 on port
>> 0x00014107
> 
> ...
> 
> Mmm.. I don't know about the first failure there,
> but after that it gets into the "stuck DRQ" state
> which libata makes no attempt to handle at present.
> 

It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe Robert
could try the following pio_polling patch first.

--
albert

---

--- libata-dev/drivers/ata/pata_pcmcia.c~	2007-06-12 16:44:43.000000000 +0800
+++ libata-dev/drivers/ata/pata_pcmcia.c	2007-06-25 11:53:37.000000000 +0800
@@ -299,7 +299,7 @@ next_entry:
 
 	ap->ops = &pcmcia_port_ops;
 	ap->pio_mask = 1;		/* ISA so PIO 0 cycles */
-	ap->flags |= ATA_FLAG_SLAVE_POSS;
+	ap->flags |= ATA_FLAG_SLAVE_POSS | ATA_FLAG_PIO_POLLING;
 	ap->ioaddr.cmd_addr = io_addr;
 	ap->ioaddr.altstatus_addr = ctl_addr;
 	ap->ioaddr.ctl_addr = ctl_addr;

Re: libata and legacy ide pcmcia failure

[Robert de Rooy]

Albert Lee wrote:
> Mark Lord wrote:
>   
>> ...
>>
>> Mmm.. I don't know about the first failure there,
>> but after that it gets into the "stuck DRQ" state
>> which libata makes no attempt to handle at present.
>>
>>     
>
> It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe Robert
> could try the following pio_polling patch first.
>   

I did not get the chance to try Marks patch, but the pio_polling patch 
from Albert works!!

Re: libata and legacy ide pcmcia failure

[Albert Lee]

Robert de Rooy wrote:
> Albert Lee wrote:
> 
>> Mark Lord wrote:
>>  
>>
>>> ...
>>>
>>> Mmm.. I don't know about the first failure there,
>>> but after that it gets into the "stuck DRQ" state
>>> which libata makes no attempt to handle at present.
>>>
>>>     
>>
>>
>> It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe Robert
>> could try the following pio_polling patch first.
>>   
> 
> 
> I did not get the chance to try Marks patch, but the pio_polling patch
> from Albert works!!
> 
> 

The patch just workarounds the "lost irq" problem by polling; not real
fix. We still need to find out why irq is lost per Mark's comment:

"This proves that the device does work correctly in most respects
except for interrupt delivery.  The status bits are working and
it can be probed for, configured, and used."

"So, next step might be to try and understand the interrupt mis-delivery
problem some more.   I've lost the history of the original issue,
but we now know that everything except the actual interrupt seems good."

I am not familiar with the PCMCIA interrupt delivery. It seems the
"Dazzle 4in1 Card Adapter" works under windows but somehow lost irq
under both IDE and libata. Maybe Alan/Bart or the PCMCIA developers
know better...
--
albert