Re: Help with SATA driver/libata/SCSI subsystem

From: Jeff Garzik
Date: Wed May 13 2009 - 15:36:51 EST


C Z wrote:
I am attempting to write a SATA driver under libata for a custom core on a Microblaze Xilinx FPGA. I can not get ata_device_add() in drivers/ata/libata-core.c to return successfully.

I have tracked the immediate problem to the function scsi_eh_flush_done_q() in drivers/scsi/scsi_error.c. The problem is this function calls "list_for_each_entry_safe(scmd, next, done_q, eh_entry)". Unfortunately, this returns the result scmd = 0xFFFFFFF0. This very strange address is the result of containerof() being called on a NULL pointer. The NULL pointer is the done_q list head. This is clearly wrong.

I have 2 questions. First, why is libata invoking the error handler after a probe in ata_device_add? This seems very counter intuitive to me. It isn't at all clear why libata needs to do this. Can someone explain the rationale behind this function?

Second, and more importantly, can someone who is experienced with this subsystem explain in simple terms the call flow that happens in the function ata_device_add? I am having trouble understanding which procedure should have issued a command and set up the done_q list head. Therefore I don't know how to track this problem further. Indeed, it doesn't appear to me that anyone actually issues a command during the probe. I'm guessing it was supposed to have been done somewhere, but where/in what function should I start looking? What was the command supposed to have been?

I am using an old kernel version 2.6.20, however I don't believe these subsystems have changed substantially since then.

Any assistance or advice from someone who has dealth with this area of the kernel before is appreciated.

Please cc linux-ide@xxxxxxxxxxxxxxx, and turn on word wrapping in your email.

Please also use an updated kernel, libata has changed substantially since 2.6.20.

Hardware drivers do not invoke ata_device_add() [which does not exist anymore], so it sounds like you are doing something really wrong...

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/