Bug 82147 - (ACPI) Devices don't work w/ ACPI; Dec. 12 ACPI fixes problems
(ACPI) Devices don't work w/ ACPI; Dec. 12 ACPI fixes problems
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-18 00:47 EST by John
Modified: 2013-07-02 22:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-03 03:36:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John 2003-01-18 00:47:47 EST
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.

Thanks!
John


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


How reproducible:
Always

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
failed
 
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 00:35:00 EDT
Can you try RHL 10.0 BETA1 (Severn)? 
It includes ACPI code updated to 20030619 
 
 
Comment 2 John 2003-08-06 10:43:15 EDT
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 13:36:18 EDT
John,

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.

Tony
Comment 4 John 2004-03-03 10:23:28 EST
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!!!)

John

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