Bug 167484

Created attachment 118415 [details]
ibm-acpi-0.11 proposed FC3 build patch

I can confirm this with 2.6.12-1.1447_FC4.

I just test the newest kernel from updates-testing: 2.6.12-1.1450_FC4
and I still get the same error:

FATAL: Error inserting ibm_acpi
(/lib/modules/2.6.12-1.1450_FC4/kernel/drivers/acpi/ibm_acpi.ko): No such device

and I can see following with dmesg:
ibm_acpi: Using generic hotkey driver

I did just test it and with an older kernel (kernel-2.6.12-1.1398_FC4) it still
works.

The following sounds like it could be the root of the problem:
* Sat Aug 06 2005 Dave Jones <davej> [2.6.12-1.1420_FC4]
- update to final 2.6.12.4 patchset.
- ACPI update to 20050729.
- Disable experimental ACPI HOTKEY driver. (#163355)

Still running 2.6.12-1.1376_FC3 I see this in my logs, in addition to the failed
ibm_acpi module loading:

Sep 10 12:10:36 cliodev kernel:     ACPI-0105: *** Error: Could not allocate new
owner_id (32 max), AE_OWNER_ID_LIMIT

I suspect this is all related.  I'll also note that 2.6.12-1.1372_FC3 worked fine.

I am seeing the same errors on IBM thinkpad R50 (1836-3SU) running
2.6.12-1376_FC3, worked well on previous kernel.

Same thing with current latest FC3 updates-testing kernel (2.6.12-1377_FC3).
Some other ACPI issues appear to be resolved in this kernel, but the ibm_acpi
problem remains.

should be fixed in cvs, will be in next update.

Not to be a pest, but I'm going on the road this weekend and it would be really
nice if I could have ACPI working by then.   Any idea when you're going to be
building a "next update" for FC3?  I'm willing to pull it down from your
personal redhat website and test it.    Thanks!

I seem to have this problem on a Thinkpad T43 with FC4, kernel 2.6.12-1.1456_FC4.

[root@thinkpad ~]# modprobe ibm_acpi
FATAL: Error inserting ibm_acpi
(/lib/modules/2.6.12-1.1456_FC4/kernel/drivers/acpi/ibm_acpi.ko): No such device

Any idea when the fix will come? 

Thanks,

1379 will be at http://people.redhat.com/davej/kernels/Fedora/FC3/ in a few hours.

I want to get a few more things fixed in this release before I push it to
updates-final, so consider that an 'early preview'.

FC4 has it fixed in the kernel currently in updates-testing

I've downloaded 2.6.12-1.1379_FC3..  While the ibm_acpi module does load, the
system doesn't properly sleep anymore.  There is no /proc/acpi/sleep like there
was in previous versions, so I cannot suspend-to-ram anymore.  (Granted, I
haven't been able to do that since this ACPI problem started in 1376).

# cat /proc/cmdline
ro root=LABEL=/ acpi_sleep=s3_bios rhgb quiet
# ls /proc/acpi/
ac_adapter  dsdt                 fadt  info            thermal_zone
alarm       embedded_controller  fan   power_resource  video
battery     event                ibm   processor       wakeup

So, this problem is only mostly fixed in my mind.

'echo -n "mem" > /sys/power/state' instead

I don't know if removing the "sleep" node from /proc/acpi was intentional, but i
think it might be.

On first test, the .1379 kernel seems to work okay for me in regard to this!
(the driver is still backlevel, but hey, thats the driver that's in the vanilla
kernel, so i'm not gonna bitch too much about it) :o)

Sweet.  Thanks.  That works!   :)   I'll go change my script to use that.

fwiw, the removal of /proc/acpi/sleep was unintended, and will return in the
next fc3 update.

Hmm..  I'm still seeing APCI issues on my thinkpad running the 1379 FC3 kernel.
 This morning my machine lost ACPI events for about 5 hours.  Here's the logs
from /var/log/messages:

Oct  7 08:25:01 cliodev ACPI: Entering standby......
Oct  7 08:27:19 cliodev ACPI: Entering standby......
Oct  7 08:27:41 cliodev logger: Switching to Battery-powered state
Oct  7 08:27:42 cliodev kernel: hdc: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Oct  7 08:27:42 cliodev kernel: hdc: drive_cmd: error=0x04 { AbortedCommand }
Oct  7 08:27:42 cliodev kernel: ide: failed opcode was: 0xef
Oct  7 08:45:57 cliodev kernel: hdc: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Oct  7 08:45:57 cliodev kernel: hdc: drive_cmd: error=0x04 { AbortedCommand }
Oct  7 08:45:57 cliodev kernel: ide: failed opcode was: 0xef
[ removed some DHCP and pam messages ]
Oct  7 13:11:35 cliodev ACPI: Entering standby......
Oct  7 13:11:35 cliodev ACPI: Entering standby......
Oct  7 13:11:35 cliodev logger: Switching to AC-powered state
Oct  7 13:11:36 cliodev logger: Switching to AC-powered state
Oct  7 13:11:37 cliodev ACPI: Entering standby......
Oct  7 13:11:37 cliodev ACPI: Entering standby......
Oct  7 13:11:38 cliodev logger: Switching to AC-powered state
Oct  7 13:11:38 cliodev ACPI: Entering standby......
Oct  7 13:11:38 cliodev last message repeated 2 times
Oct  7 13:11:39 cliodev logger: Switching to AC-powered state

In particular the power events..  Going into battery mode and then coming back
to AC power doesn't seem to be recognized properly.  I just tried it again now
(pulling the power and then putting it back in) and there was still a delay:

Oct  7 13:23:39 cliodev logger: Switching to Battery-powered state
Oct  7 13:23:39 cliodev kernel: hdc: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Oct  7 13:23:39 cliodev kernel: hdc: drive_cmd: error=0x04 { AbortedCommand }
Oct  7 13:23:39 cliodev kernel: ide: failed opcode was: 0xef
Oct  7 13:24:26 cliodev logger: Switching to AC-powered state
Oct  7 13:24:27 cliodev kernel: hdc: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Oct  7 13:24:27 cliodev kernel: hdc: drive_cmd: error=0x04 { AbortedCommand }
Oct  7 13:24:27 cliodev kernel: ide: failed opcode was: 0xef

Why is it taking 50 seconds to notice the power-on event?  I doubt it's my ACPI
scripts, as those have always worked....   Unless some of the ACPI updates broke
my scripts.