From: Tejun Heo <htejun@gmail.com>
To: Tejun Heo <htejun@gmail.com>, Jeff Garzik <jeff@garzik.org>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Subject: Re: [PATCH] libata: Register for dock events when the drive is inside a dock station
Date: Tue, 04 Mar 2008 13:12:54 +0900 [thread overview]
Message-ID: <47CCCC46.6070908@gmail.com> (raw)
In-Reply-To: <20080228233610.GA3808@homac>
[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]
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
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 3761 bytes --]
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 9e8ec19..ea01875 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -118,45 +118,77 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
ap->pflags |= ATA_PFLAG_INIT_GTM_VALID;
}
-static void ata_acpi_handle_hotplug(struct ata_port *ap, struct kobject *kobj,
+static void ata_acpi_handle_hotplug(struct ata_port *ap, struct ata_device *dev,
u32 event)
{
char event_string[12];
char *envp[] = { event_string, NULL };
- struct ata_eh_info *ehi = &ap->link.eh_info;
-
- if (event == 0 || event == 1) {
- unsigned long flags;
- spin_lock_irqsave(ap->lock, flags);
- ata_ehi_clear_desc(ehi);
- ata_ehi_push_desc(ehi, "ACPI event");
- ata_ehi_hotplugged(ehi);
- ata_port_freeze(ap);
- spin_unlock_irqrestore(ap->lock, flags);
+ struct ata_eh_info *ehi;
+ struct kobject *kobj = NULL;
+ int wait = 0;
+ unsigned long flags;
+
+ if (!ap)
+ ap = dev->link->ap;
+ ehi = &ap->link.eh_info;
+
+ spin_lock_irqsave(ap->lock, flags);
+
+ switch (event) {
+ case ACPI_NOTIFY_BUS_CHECK:
+ case ACPI_NOTIFY_DEVICE_CHECK:
+ ata_ehi_push_desc(ehi, "ACPI event");
+ ata_ehi_hotplugged(ehi);
+ ata_port_freeze(ap);
+ break;
+
+ case ACPI_NOTIFY_EJECT_REQUEST:
+ ata_ehi_push_desc(ehi, "ACPI event");
+ if (dev)
+ dev->flags |= ATA_DFLAG_DETACH;
+ else {
+ struct ata_link *tlink;
+ struct ata_device *tdev;
+
+ ata_port_for_each_link(tlink, ap)
+ ata_link_for_each_dev(tdev, tlink)
+ tdev->flags |= ATA_DFLAG_DETACH;
+ }
+
+ ata_port_schedule_eh(ap);
+ wait = 1;
+ break;
}
+ if (dev) {
+ if (dev->sdev)
+ kobj = &dev->sdev->sdev_gendev.kobj;
+ } else
+ kobj = &ap->dev->kobj;
+
if (kobj) {
sprintf(event_string, "BAY_EVENT=%d", event);
kobject_uevent_env(kobj, KOBJ_CHANGE, envp);
}
+
+ spin_unlock_irqrestore(ap->lock, flags);
+
+ if (wait)
+ ata_port_wait_eh(ap);
}
static void ata_acpi_dev_notify(acpi_handle handle, u32 event, void *data)
{
struct ata_device *dev = data;
- struct kobject *kobj = NULL;
- if (dev->sdev)
- kobj = &dev->sdev->sdev_gendev.kobj;
-
- ata_acpi_handle_hotplug(dev->link->ap, kobj, event);
+ ata_acpi_handle_hotplug(NULL, dev, event);
}
static void ata_acpi_ap_notify(acpi_handle handle, u32 event, void *data)
{
struct ata_port *ap = data;
- ata_acpi_handle_hotplug(ap, &ap->dev->kobj, event);
+ ata_acpi_handle_hotplug(ap, NULL, event);
}
/**
@@ -191,20 +223,30 @@ void ata_acpi_associate(struct ata_host *host)
else
ata_acpi_associate_ide_port(ap);
- if (ap->acpi_handle)
- acpi_install_notify_handler (ap->acpi_handle,
- ACPI_SYSTEM_NOTIFY,
- ata_acpi_ap_notify,
- ap);
+ if (ap->acpi_handle) {
+ acpi_install_notify_handler(ap->acpi_handle,
+ ACPI_SYSTEM_NOTIFY,
+ ata_acpi_ap_notify, ap);
+#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_ap_notify, ap);
+#endif
+ }
for (j = 0; j < ata_link_max_devices(&ap->link); j++) {
struct ata_device *dev = &ap->link.device[j];
- if (dev->acpi_handle)
- acpi_install_notify_handler (dev->acpi_handle,
- ACPI_SYSTEM_NOTIFY,
- ata_acpi_dev_notify,
- dev);
+ if (dev->acpi_handle) {
+ acpi_install_notify_handler(dev->acpi_handle,
+ ACPI_SYSTEM_NOTIFY,
+ ata_acpi_dev_notify, dev);
+#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, dev);
+#endif
+ }
}
}
}
next prev parent reply other threads:[~2008-03-04 4:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-14 12:40 [PATCH] libata: Register for dock events when the drive is inside a dock station Holger Macht
2008-02-14 12:56 ` Holger Macht
2008-02-20 17:11 ` Jeff Garzik
2008-02-21 11:53 ` Holger Macht
2008-02-22 1:34 ` Tejun Heo
2008-02-26 10:15 ` Holger Macht
2008-02-28 9:35 ` Tejun Heo
2008-02-28 11:09 ` Holger Macht
2008-02-28 13:05 ` Tejun Heo
2008-02-28 15:58 ` Holger Macht
2008-02-28 18:32 ` Holger Macht
2008-02-28 23:36 ` Holger Macht
2008-03-04 4:12 ` Tejun Heo [this message]
2008-03-11 23:55 ` Holger Macht
2008-03-12 5:15 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47CCCC46.6070908@gmail.com \
--to=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=kristen.c.accardi@intel.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).