Bug 82147 - (ACPI) Devices don't work w/ ACPI; Dec. 12 ACPI fixes problems
Summary: (ACPI) Devices don't work w/ ACPI; Dec. 12 ACPI fixes problems
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-18 05:47 UTC by John
Modified: 2013-07-03 02:09 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2004-03-03 08:36:24 UTC

Attachments (Terms of Use)

Description John 2003-01-18 05:47:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021216

Description of problem:
I've been experimenting with Phoebe on a new Sony VAIO R505G.  I've gotten Red
Hat Linux 8.0 working pretty well with it using the stock kernel.org 2.4.20 +
the Dec. 12 ACPI patch.

ACPI is necessary for most of the devices on this laptop to work.  The IEEE 1394
controller (and thus the DVD drive), USB controller, and HSF winmodem do not
work w/o ACPI.  Also, for some reason the i810 sound system gives output with
pauses in it if ACPI is not working.

With a stock Linus-tree 2.4.20 kernel, about the only things that work on the
machine are the 3.5" floppy drive, video controller, and the ethernet adapter. 
Once the Dec. 12 ACPI patch set is applied, though, everything works well.

I wanted to give Phoebe a shot, since it includes ACPI support.  It would be
great if RH 8.1 works out of the box, w/o a need to roll my own kernels.  It
turns out, though, that some aspect of ACPI differs in the Phoebe patches from
the Dec. 12 patch such that the devices don't work.  They complain about bad
irqs, just like they do with a stock 2.4.20 kernel.

I haven't looked into ACPI much at all yet.  I have no idea how the Phoebe ACPI
patches differ from the Dec. 12 set.  But, I performed the simplest test I could
think of:  I backed the ACPI patches out of the Phoebe kernel sources, and
applied the Dec. 12 patch set.  When I booted the new kernel, kudzu detected the
USB controller & firewire adapter.  I've been using the new kernel for a couple
of hours now, testing devices, playing DVDs over firewire, etc., and everything
is working smoothly.

Let me know what information would be useful in narrowing the problem down. 
This is my first experience with ACPI, and I haven't had time to dig under the
hood yet.


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Try to install a module such as ohci1394 on a VAIO R505G.


Actual Results:  Using the standard Phoebe kernel, the output on the console
will be:
[root@dart Kernel]# /sbin/modprobe ohci1394
/lib/modules/2.4.20-2.2/kernel/drivers/ieee1394/ohci1394.o.gz: init_module: No
such device
Hint: insmod errors can be caused by incorrect module parameters, including
invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg
/lib/modules/2.4.20-2.2/kernel/drivers/ieee1394/ohci1394.o.gz: insmod
/lib/modules/2.4.20-2.2/kernel/drivers/ieee1394/ohci1394.o.gz failed
/lib/modules/2.4.20-2.2/kernel/drivers/ieee1394/ohci1394.o.gz: insmod ohci1394
The resulting output in /var/log/messages will look like:
Jan 16 17:16:10 dart kernel: ohci1394: $Rev: 578 $ Ben Collins <bcollins@debian.org>
Jan 16 17:16:10 dart kernel: PCI: No IRQ known for interrupt pin A of device
02:02.0. Please try using pci=biosirq.
Jan 16 17:16:10 dart kernel: ohci1394: Failed to allocate shared interrupt 0

Expected Results:  Using my modified Phoebe kernel, which includes the Dec. 12
ACPI patch set, the ohci1394 module installs correctly with no output on the
console.  The output in the log is:
Jan 18 01:40:13 dart kernel: ohci1394: $Rev: 578 $ Ben Collins <bcollins@debian.org>
Jan 18 01:40:13 dart kernel: ohci1394_0: OHCI-1394 1.1 (PCI): IRQ=[9] 
MMIO=[e0205000-e02057ff]  Max Packet=[2048]
Jan 18 01:40:13 dart kernel: ieee1394: sbp2: Logged into SBP-2 device
Jan 18 01:40:13 dart kernel: ieee1394: sbp2: Node[01:1023]: Max speed [S400] -
Max payload [2048]
Jan 18 01:40:13 dart /etc/hotplug/ieee1394.agent: Setup sbp2 for IEEE1394
product 0x080046/0x00609e/0x010483
Jan 18 01:40:13 dart devlabel: devlabel service started/restarted

Additional info:

Comment 1 Len Brown 2003-08-06 04:35:00 UTC
Can you try RHL 10.0 BETA1 (Severn)? 
It includes ACPI code updated to 20030619 

Comment 2 John 2003-08-06 14:43:15 UTC
No, I'm sorry, I don't think I can.  The laptop is now in production use, with a
hand rolled kernel.

But, if the Severn kernel will work with little hassle on a Red Hat 9 system,
I'd be willing to test it out.  Let me know if I should try it, and what other
packages I should install to make it work.

Comment 3 ajs 2003-08-07 17:36:18 UTC

I've been using the severn kernel for about a week now on my Sony VAIO laptop. 
So far I have not had to reboot to an older kernel.  Of course, YMMV.

Before installing the severn kernel I had a fully updated shrike system plus the
rawhide modutils and initscripts.  I had these installed to use Arjan's 2.6
kernels and I don't think they are necessary.

When I installed the severn kernel I also had to upgrade the XFree86 packages.


Comment 4 John 2004-03-03 15:23:28 UTC
Yep, I agree.  The ACPI kernel in Fedora Core 1 has been working well
for me for quite a while.  (Sorry I forgot to close the bug!!!)


Note You need to log in before you can comment on or make changes to this bug.