Created attachment 73209 [details] sudo lspci -vvnn I'm using Ubuntu 12.04 with a Acer 4810TG laptop. This laptop has a DVD eject hardware button which renders the DVD-ROM device unusable when it's pressed. The "eject cdrom" command works if the button hasn't been pressed. But after it's been pressed it does not work anymore: $ eject cdrom eject: tried to use `/dev/scd0' as device name but it is no block device eject: unable to find or open device for: `cdrom' The system has to be restarted to make the DVD-ROM work again. Please see the attached dmesg-before.txt and dmesg-after.txt to see what's happening when that button is pressed. Also please take a look at the original bug report on Launchpad: https://bugs.launchpad.net/ubuntu/+source/eject/+bug/412527 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/811464 WORKAROUNDS: WORKAROUND #1: (should always work) Instead of pressing the hardware button enter this command in the command line: eject cdrom WORKAROUND #2: (works for some people including me) In the BIOS set SATA mode from AHCI to IDE. WORKAROUND #3: (works for some people but not for me) Use the noacpi kernel parameter.
Created attachment 73210 [details] dmesg before the eject button is pressed
Created attachment 73211 [details] dmesg after the eject button is pressed
The eject button appears to be set via ACPI to physically disconnect and power off the device. That's not usual behaviour and would explain this.
Alan, what indication did you find that ACPI (AML?) is handling the event and powering off the HW? Can we get the acpidump for a system that fails? Adam, upstream Linux doesn't have a "noacpi" parameter. Is that something specific to Ubuntu? What does it do, the same as "acpi=off"
Len: According to https://help.ubuntu.com/community/BootOptions acpi=off OR noacpi This parameter disables the whole ACPI system. This may prove very useful, for example, if your computer does not support ACPI or if you think the ACPI implementation might cause some problems (for instance random reboots or system lockups). So acpi=off and noacpi are the same. But as I mentioned above this workaround does not work for me.
May not be the ACPI but the button is ejecting the hardware from the traces [ 134.809241] ata5: SError: { DevExch } So we get a device exchange (ie a hot plug or unplug). The device is actually turning itself off it seems.
Hi Adam, Please attach your acpidump on this bug: # acpidump > acpidump.dat This issue may relate to zero power odd support Lin Ming and Aaron Lu have patch on this feature but still not in mainline kernel. Please check your BIOS have any option to disable zero power odd function.
Created attachment 80231 [details] acpidump when sata mode is ahci
Created attachment 80241 [details] acpidump when sata mode is ide
I added the requested acpidump file with both sata modes. (There is no bug when sata mode is set to ide, the bug occurs when it's set to ahci.) I also checked and there is no zero power odd function in the BIOS.
(In reply to comment #10) > I added the requested acpidump file with both sata modes. (There is no bug > when > sata mode is set to ide, the bug occurs when it's set to ahci.) > > I also checked and there is no zero power odd function in the BIOS. hm... IMHO this machine a bit old, it's may not implemented zero power odd that's define in SATA 3.1 spec. If this machine was implemented it, when ODD is powered off, inserting disk should trigger a GPE, then OSPM will resume this ODD device. Could you please check does value of GPE increase when you inserting disk to DVD? Please run the following command by root and monitor the number should increase when you insert disk: # watch -n 1 cat /sys/firmware/acpi/interrupts/gpe_all Thanks
Hi Lee, It can't be ZPODD that caused this problem, as ZPODD is not in upstream yet, so can't appear in Ubuntu's kernel.
Hi Aaron, (In reply to comment #12) > Hi Lee, > > It can't be ZPODD that caused this problem, as ZPODD is not in upstream yet, > so > can't appear in Ubuntu's kernel. I understand. Just I didn't see any hint for why the eject button causes device turned-off. So, I think maybe relate to zero power odd, and there should have GPE notify to driver for turn-on device again. So, I ask Adam to look at does there have any GPE emitted when press eject button.
(In reply to comment #13) > Just I didn't see any hint for why the eject button causes device turned-off. > So, I think maybe relate to zero power odd, and there should have GPE notify > to > driver for turn-on device again. > > So, I ask Adam to look at does there have any GPE emitted when press eject > button. I agree that we can try to see if GPE has happened in this case.
The number in gpe_all keeps rising continously around 8/sec: $ cat /sys/firmware/acpi/interrupts/gpe_all 34223 $ uptime 20:30:13 up 1:14, 2 users, load average: 1.58, 1.74, 1.69 I've tried both IDE and AHCI modes.
(In reply to comment #15) > The number in gpe_all keeps rising continously around 8/sec: > > $ cat /sys/firmware/acpi/interrupts/gpe_all > 34223 > $ uptime > 20:30:13 up 1:14, 2 users, load average: 1.58, 1.74, 1.69 > > I've tried both IDE and AHCI modes. Please press eject button then monitor does the value of gpe_all was increased? And, please check does there have any gpe number increased when you press eject button: check 00 to 0F: watch -n 1 cat /sys/firmware/acpi/interrupts/gpe[0][0123456789ABCDEF] check 10 to 1F: watch -n 1 cat /sys/firmware/acpi/interrupts/gpe[1][0123456789ABCDEF] check 20 to 2F: watch -n 1 cat /sys/firmware/acpi/interrupts/gpe[2][0123456789ABCDEF] check 30 to 3F: watch -n 1 cat /sys/firmware/acpi/interrupts/gpe[3][0123456789ABCDEF] ... Another testing is monitor does there have any acpi action when eject button pressed: Make sure CONFIG_ACPI_DEBUG=y is enabled, then add the following kernel parameter: acpi.debug_level=0x0000000F acpi.debug_layer=0xffffffff log_buf_len=5M After reboot, please press reject button and monitor the dmesg log.
Created attachment 89601 [details] content of all gpe files
Created attachment 89611 [details] dmesg-eject_button-CONFIG_ACPI_DEBUG
When I press the eject button none of the gpe value is increased except for gpe17 but it keeps increasing rapidly regardless of pressing the eject button. See attached file: https://bugzilla.kernel.org/attachment.cgi?id=89601 I've configured CONFIG_ACPI_DEBUG=y and used the kernel parameters that you mentioned and got the following output in dmesg right after pressing the eject button: https://bugzilla.kernel.org/attachment.cgi?id=89611 Thanks.
Hi Adam, Thanks for your testing and debug log. (In reply to comment #19) > When I press the eject button none of the gpe value is increased except for > gpe17 but it keeps increasing rapidly regardless of pressing the eject > button. > See attached file: https://bugzilla.kernel.org/attachment.cgi?id=89601 > > I've configured CONFIG_ACPI_DEBUG=y and used the kernel parameters that you > mentioned and got the following output in dmesg right after pressing the > eject > button: https://bugzilla.kernel.org/attachment.cgi?id=89611 > > Thanks. Per your debugging result, looks your machine doesn't emit any GPE to ACPI. So the root causes is not from ACPI side and zero power odd. Sorry for I have no idea currently for why we lost your DVD after pressed eject button. Maybe need check more about ATA side.
Hi Adam, According to the ACPI table, the 0x17 GPE bit is for the EC. The situation is, when the eject button is pressed, a EC event happened, and the query method _Q2E executes CDEJ, which make the DVD unusable. It's not clear to me what is exactly the problem: Should an EC event be generated for pressing the eject button? Should CDEJ be invoked if above is true? And is there a problem in the CDEJ control method? Perhaps only Acer knows what is the problem. Anyway we can involve some Acer guy into this problem? I don't see much we can do in Linux.
Do you still need some information from me?
No, I'll mark this as closed/invalid since the problem is in the ASL code provided by Acer.