From: Holger Macht <hmacht@suse.de>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tejun Heo <htejun@gmail.com>,
linux-ide@vger.kernel.org, Jeff Garzik <jeff@garzik.org>
Subject: Re: 2.6.25 semantic change in bay handling?
Date: Tue, 6 May 2008 13:21:45 +0200 [thread overview]
Message-ID: <20080506112145.GA8560@homac> (raw)
In-Reply-To: <20080506091718.GA11617@srcf.ucam.org>
Hi,
(Can you please keep me CC'ed, I'm not on linux-ide)
Quoting your mail from the archives:
>> Right, so you never can rely on receiving a BAY_EVENT. Why not just
>> disregard this case and looking for a common solution?
> Oh, I agree - we need to solve this in any case. But for hardware where
> there is a separate request event before the device is pulled, users
> already have scripts that prompt them to unmount hardware. These worked
> in <2.6.25, but they're broken now. It'd be nice to get them working
> again.
Yes, the scripts were broken for the advantage to not freeze some devices ;-)
But I agree, we need such a possibility.
>> No. The moment when the bay event is generated, the moment the user pushes
>> the lever on the bay, the user might immediately pull out the device,
>> letting no chance for cleaning up...There must be an event before the user
>> touches anything, to have the time to unmount etc. and then tell "now it's
>> save to remove the bay device". This would also solve the "there's no bay
>> event" case.
> Hm. The hardware I have here has a separate "eject request" button and
> "physical eject" button. Hitting the former sends the request to the OS,
> and the light then pulses until the OS confirms that the dock can be
> removed. If the user removes the dock before this happens, that's user
> error.
Not by default. The dock driver immediately undocks unless
immediate_undock parameter is set to 0. Any access to the bay inside the
dock afterwards might freeze the system.
Actually I was talking about the "bay not in the dock"-case here.
Unfortunately, the hardware in question doesn't contain a bay.
> The only dock I have with no request button doesn't present as an ACPI
> dock to begin with. Do Thinkpad docks differ from this?
There are those which do simple PCI hotplugging without the involvement of
ACPI (many/all HPs AFAIK) and those which present themselves as a
dockstation through ACPI (those with a _DCK method). The thinkpad X60 dock
I have here has the request button, too.
Regards,
Holger
next prev parent reply other threads:[~2008-05-06 11:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 22:33 2.6.25 semantic change in bay handling? Matthew Garrett
2008-05-06 8:13 ` Holger Macht
2008-05-06 8:21 ` Matthew Garrett
2008-05-06 8:40 ` Tejun Heo
2008-05-06 8:46 ` Matthew Garrett
2008-05-06 8:53 ` Tejun Heo
2008-05-06 9:17 ` Matthew Garrett
2008-05-06 11:21 ` Holger Macht [this message]
2008-05-06 11:31 ` Matthew Garrett
2008-05-06 17:27 ` Holger Macht
2008-05-06 17:48 ` Matthew Garrett
2008-05-06 18:36 ` Holger Macht
2008-05-06 18:48 ` Matthew Garrett
2008-05-06 22:06 ` Holger Macht
2008-05-06 9:29 ` Holger Macht
2008-05-06 9:39 ` Matthew Garrett
2008-05-06 9:26 ` Holger Macht
2008-05-06 9:36 ` Matthew Garrett
2008-05-19 16:29 ` [PATCH] Fixups to ATA ACPI hotplug Matthew Garrett
2008-05-20 7:44 ` Holger Macht
2008-05-20 10:20 ` Matthew Garrett
2008-05-20 13:18 ` Holger Macht
2008-05-20 13:22 ` Matthew Garrett
2008-05-20 13:58 ` Holger Macht
2008-05-20 14:00 ` Matthew Garrett
2008-05-21 22:26 ` Andrew Morton
2008-05-20 8:49 ` Holger Macht
2008-05-06 8:40 ` 2.6.25 semantic change in bay handling? Holger Macht
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=20080506112145.GA8560@homac \
--to=hmacht@suse.de \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=mjg59@srcf.ucam.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.