Re: [BUG] PATA_PCMCIA does not work

Re: [BUG] PATA_PCMCIA does not work

[Jeff Garzik]

Komuro wrote:
> Hi,
> 
> The pata_pcmcia problem is fixed. Thanks!
> (I tested it on kernel 2.6.20-git14)
> 
> But kernel 2.6.20-mm2 introduced new oops
> when I insert the pata_pcmcia device.
> 
> 
> pcmcia: registering new device pcmcia1.0
> SCSI subsystem initialized
> libata version 2.10 loaded.
> ata1: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x00000000 irq 3
> scsi0 : pata_pcmcia
> BUG: unable to handle kernel NULL pointer dereference at virtual address 0000004d
>  printing eip:
> d8a1b10e
> *pde = 00000000
> Oops: 0000 [#1]
> last sysfs file: /block/hda/size
> Modules linked in: pata_pcmcia libata scsi_mod dm_mirror dm_multipath dm_mod pcmcia yenta_socket rsrc_nonstatic pcmcia_core
> CPU:    0
> EIP:    0060:[<d8a1b10e>]    Not tainted VLI
> EFLAGS: 00010296   (2.6.20-mm2 #1)
> EIP is at ata_acpi_exec_tfs+0x157/0x8ad [libata]
> eax: 00000001   ebx: 00000000   ecx: d6d43c84   edx: d6d43c84
> esi: d51f4514   edi: 00000000   ebp: d51f438c   esp: d6f2bcdc
> ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
> Process scsi_eh_0 (pid: 1647, ti=d6f2a000 task=c13c9a70 task.ti=d6f2a000)
> Stack: d51f6190 00000246 00000246 00000000 d8a130b7 00000000 00000000 00000000 
>        00000000 d6f2bd48 d6f2bdf0 d51f4514 ec000000 d51f6190 00000000 00000000 
>        00000000 00000246 d6d43c84 00000000 00000000 00000000 00000000 ffffffff 
> Call Trace:
>  [<d8a130b7>] ata_exec_internal_sg+0x3ae/0x3b8 [libata]
>  [<d8a125f8>] ata_dev_configure+0xc1/0x7d2 [libata]
>  [<d8a10e87>] ata_dev_select+0xce/0x11a [libata]

Any chance you could insert some printk() calls into ata_apci_exec_tfs? 
  ata_exec_internal_sg() never calls that function, so I'm curious if 
something corrupted memory a bit, or what happened.

In any case, I'm surprised that ACPI would be executing taskfiles on 
PCMCIA anyway.

	Jeff

Re: [BUG] PATA_PCMCIA does not work

[Komuro]

On Sat, 24 Feb 2007 20:45:18 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> Any chance you could insert some printk() calls into ata_apci_exec_tfs? 
>   ata_exec_internal_sg() never calls that function, so I'm curious if 
> something corrupted memory a bit, or what happened.

I insert some printk().
I think the problem is happening on do_drive_get_GTF.


>pcmcia: registering new device pcmcia0.0
>SCSI subsystem initialized
>libata version 2.10 loaded.
>ata1: PATA max PIO0 cmd 0x00010100 ctl 0x0001010e bmdma 0x00000000 irq 4
>scsi0 : pata_pcmcia
>ata_acpi_exec_tfs 0  
>ata_acpi_exec_tfs 1  
>BUG: unable to handle kernel NULL pointer dereference at virtual address 0000004d
> printing eip:
>
>
>int ata_acpi_exec_tfs(struct ata_port *ap)
>{
>	int		ix;
>	int		ret =0;
>	unsigned int	gtf_length;
>	unsigned long	gtf_address;
>	unsigned long	obj_loc;
>
>	if (noacpi)
>		return 0;
>
>	for (ix = 0; ix < ATA_MAX_DEVICES; ix++) {
>		printk("ata_acpi_exec_tfs 0  \n");
>		if (!ata_dev_enabled(&ap->device[ix]))
>			continue;
>
>		printk("ata_acpi_exec_tfs 1  \n");
>		ret = do_drive_get_GTF(ap, ix,
>				&gtf_length, &gtf_address, &obj_loc);
>		printk("ata_acpi_exec_tfs 2  \n");
>		if (ret < 0) {

Best Regards
Komuro

libata reports bogus addresses for everything (was PATA_PCMCIA cmd port)

[Alan Cox]

On Sat, 17 Mar 2007 22:00:50 +0900
Komuro <komurojun-mbn@nifty.com> wrote:

> 
> Hi,
>  
> The pata_pcmcia driver reports the cmd port is 0x00010100,
> but actually the cmd port is 0x0100.
> 
> Is this corect?

When the pci_iomap patches were applied the ports reported for every
device went strange.  It appears to display the wrong information
nowdays. I see the same but I've got many more important things to work
on before I even bother to look at it.

My guess is someone is now printing the iomap virtual addresses not the
bus ones.

Alan

Re: libata reports bogus addresses for everything (was PATA_PCMCIA cmd port)

[Tejun Heo]

Alan Cox wrote:
> On Sat, 17 Mar 2007 22:00:50 +0900
> Komuro <komurojun-mbn@nifty.com> wrote:
> 
>> Hi,
>>  
>> The pata_pcmcia driver reports the cmd port is 0x00010100,
>> but actually the cmd port is 0x0100.
>>
>> Is this corect?
> 
> When the pci_iomap patches were applied the ports reported for every
> device went strange.  It appears to display the wrong information
> nowdays. I see the same but I've got many more important things to work
> on before I even bother to look at it.
> 
> My guess is someone is now printing the iomap virtual addresses not the
> bus ones.

Yes, we're printing the ioaddr.* directly and those are all iomapped
addressed now.  I wonder whether we should fix this or push the port
printing to LLDs (with sff helpers in libata-sff).  ahci and
pata_generic sharing one format doesn't sound like a too good idea.
I'll fix it after new init model.

-- 
tejun