[ltp] /proc/acpi/ibm/bay gone with ThinkPad ACPI Extras v0.19-20080107/2.6.24

[Henrique de Moraes Holschuh]

On Thu, 31 Jan 2008, Marc MERLIN wrote:
> gandalf:~# lsmod | grep thinkpad
> gandalf:~# lsmod | grep bay
> bay                     7040  0 
> dock                   11412  1 bay
> gandalf:~# uname -r
> 2.6.24-slab-tpacpi0.19-p4core2smp-preempt-1khz-noticks-marc8
> 
> After that, indeed, releasing the eject hatch (without ejecting) doesn't generate
> any acpi event, or anything I can see in either /var/log/syslog /var/log/acpid

I think you get an event through udev when using the ACPI generic bay and
dock.  udevmonitor will tell you more (works like acpi_listen).

> acpid still works fine, my events are seen, I just get no events when
> I release the lever, and my system now hardlocks if I remove the drive
> :(

The hardlock means it was not ejected and something took it extremely bad.
It is better for your hardware to not *ever* remove anything from the bay
while the green bay led is still lit.  If it is still lit, the eject failed
(or it was not even performed).  Push the lever back in, there is no point
risking damage to hardware.

> If you meant /proc/acpi/events, I don't have that.

Nah, it is /proc/acpi/event. Sorry about that.

> Shouldn't thinkpad_acpi output some message at load time that says
> whether it saw the bay or if it was busy?

It does, when in debug mode.  I am not sure I should make it more verbose
without the debug switch, because it would be really noisy to log whether
each subdriver loaded sucessfully or not by default...

> > No.  You are currently out of luck because of some bug, let's find it, and
> > fix it.
> 
> Ok :)
> (one bug on each side apparently :) )

I really don't doubt that at all... :(

 > ACPI bay is supposed to simply work for you (although the way you get the
> > event that signals that the bay lever was released is different).
> 
> I see, so the _SB_.PCI0.IDE0.PRIM.MSTR: patch for thinkpad_acpi was
> required for the bay to work with that deprecated system, and you can't
> really fix that without breaking older machines, so my only way forward
> is getting the new acpi bay to work.

Yes, it is the way forward.

> Let's see where we get with that then.

Sure.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh