Holger Macht wrote:
> On Thu 28. Feb - 19:32:43, Holger Macht wrote:
>> On Thu 28. Feb - 16:58:17, Holger Macht wrote:
>>> On Thu 28. Feb - 22:05:53, Tejun Heo wrote:
>>>> Holger Macht wrote:
>>>>> On Thu 28. Feb - 18:35:06, Tejun Heo wrote:
>>>>>> Holger Macht wrote:
>>>>>>> The hotplug handler is only called if the device is actually inside the
>>>>>>> dock station. If it is not, nothing will happen. I hope that I got your
>>>>>>> question right?
>>>>>> Yes, right.
>>>>>>
>>>>>>> However, if this would be helpful, it would be easy to add something like
>>>>>>> a am_I_on_dock_station?(...) function to the dock driver.
>>>>>> Hmm.. as long as the event is only delivered when the device is actually
>>>>>> connected behind dock, I think it's okay.
>>>>> The dock driver also export a is_dock_device(acpi_handle) function, which
>>>>> could be used to make more fine-grained decisions, but it shouldn't be
>>>>> needed here.
>>>>>
>>>>>> Does the attached patch fix the previous undock problem?  It now
>>>>>> explicitly tells libata EH to detach the notified devices on
>>>>>> EJECT_REQUEST and wait for EH to complete such that control is returned
>>>>>> to ACPI after all notified devices are actually detached.
>>>>> No it does not. Apparently, it freezes faster (from 1 second down to
>>>>> immediately). Before, it just froze when someone (in this case HAL) tried
>>>>> to access the device. The "echo 1 > undock" call does not even return, so
>>>>> it might have introduced another problem.
>>>> The code should be in generally right direction.  Can you be persuaded
>>>> into tracking down what's going on?
>>> I had a quick glance with adding some printk's. Now I got a different
>>> behaviour once. System did not freeze, but were certainly confused. The
>>> last thing which got printed to messages was exactly before
>>> spin_lock_irqsave(ap->lock, flags); at the beginning of ata_acpi_handle_hotplug(...)
>>>
>>> The printk immediately after this call didn't come through anymore (with
>>> being able to use the system for a short time afterwards).
>> Ok, it seems that there is something broken somewhere else in
>> 2.6.25.rc3. Not sure at all if it's your patch freezing the machine. I'll
>> give 2.6.24.3 a try...
> 
> So once again...
> 
> After applying your patch, I got the OOPS seen in attachment
> 'oops-undock-1'. After changing the following, which is hopefully
> correct...
> 
> --- ../orig/linux-2.6.24.3/drivers/ata/libata-acpi.c	2008-02-29 00:31:44.000000000 +0100
> +++ drivers/ata/libata-acpi.c	2008-02-29 00:32:26.000000000 +0100
> @@ -123,7 +123,7 @@
>  {
>  	char event_string[12];
>  	char *envp[] = { event_string, NULL };
> -	struct ata_eh_info *ehi = &ap->link.eh_info;
> +	struct ata_eh_info *ehi;
>  	struct kobject *kobj = NULL;
>  	int wait = 0;
>  	unsigned long flags;
> @@ -131,6 +131,8 @@
>  	if (!ap)
>  		ap = dev->link->ap;
>  
> +	ehi = &ap->link.eh_info;
> +
>  	spin_lock_irqsave(ap->lock, flags);
>  
>  	switch (event) {
> 
> 
> ...I got both an oops when docking (attachments oops-dock) and when undocking
> (attachment oops-undock2).

Yeah, that was one mistake.  There's another.

+#if defined(CONFIG_ACPI_DOCK) || defined(CONFIG_ACPI_DOCK_MODULE)
+				/* we might be on a docking station */
+				register_hotplug_dock_device(ap->acpi_handle,
+							     ata_acpi_dev_notify,
+							     ap);
+#endif

dev_notify is being registered with a pointer to ap.  No wonder it causes
strange dereferences later on.  Attached is the fixed patch.  Can you
please give it a shot?

Thanks.

-- 
tejun