Bug 480142 - /proc/acpi/dsdt: No such device
/proc/acpi/dsdt: No such device
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
ia64 Linux
low Severity low
: rc
: ---
Assigned To: Prarit Bhargava
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-15 06:42 EST by CAI Qian
Modified: 2009-09-02 05:01 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:01:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
quick hack patch #1 (3.47 KB, patch)
2009-02-11 18:10 EST, Keiichiro Tokunaga
no flags Details | Diff
quick hack patch #2 (1.53 KB, patch)
2009-02-11 18:11 EST, Keiichiro Tokunaga
no flags Details | Diff
RHEL5 fix for this issue (1.32 KB, patch)
2009-02-11 18:36 EST, Prarit Bhargava
no flags Details | Diff
RHEL5 fix for this issue (1.31 KB, patch)
2009-02-11 18:53 EST, Prarit Bhargava
no flags Details | Diff

  None (edit)
Description CAI Qian 2009-01-15 06:42:02 EST
Description of problem:
I have seen one IA-64 machine,

pq0-0.lab.bos.redhat.com

failed to read /proc/acpi/dsdt: No such device..

Version-Release number of selected component (if applicable):
kernel-2.6.18-128.el5

How reproducible:
unknown

Steps to Reproduce:
cat /proc/acpi/dsdt
  
Actual results:
No such device

Expected results:
Display some content.

Additional info:
Similar bug seen on RHEL 4 kernel,
Bug 455253 - [4.7] /proc/acpi/dsdt: No such device
Comment 1 Prarit Bhargava 2009-01-27 09:56:47 EST
Cai, do you know if this was working previously on this system?

Thanks,

P.
Comment 2 CAI Qian 2009-01-27 11:13:14 EST
Prarit, I am afraid that I have never had a chance to test it on the previous release. The earliest kernel that I can found from the testing history was -120.el5, but the test was also failed there.

http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=4819624
Comment 3 Prarit Bhargava 2009-01-27 11:39:47 EST
Okay, no problem Cai -- I'll take a look and see if I can figure out what went wrong...

P.
Comment 4 Prarit Bhargava 2009-02-10 13:35:12 EST
Cai, this looks like a similar problem to 455253 (which is a RHEL4 BZ).

The issue is that the ACPI entry that reports the DSDT size has a bogus value in it.  It is reporting 0x471c7 or 291271 which is a *huge* size.

This is a PrimeQuest BIOS issue and I'm adding the Fujitsu on-site engineers to this BZ to see if they can request that the BIOS/ACPI Table be fixed to correctly report the size of the DSDT.

P.
Comment 5 Keiichiro Tokunaga 2009-02-10 17:02:37 EST
Thanks, Prarit.  It seems PRIMEQUEST has more than 256MB of DSDT, which exceeds the maximum size kmalloc can allocate on the system.  IIRC, this problem has been there since the previous kernels (at least 2.6.18-53) so I suppose it shouldn't be a (real) problem for Fujitsu, but I'll double-check that.

Kei
Fujitsu On-site Engineer
Comment 6 Prarit Bhargava 2009-02-10 18:30:50 EST
(In reply to comment #5)
> Thanks, Prarit.  It seems PRIMEQUEST has more than 256MB of DSDT, which exceeds
> the maximum size kmalloc can allocate on the system.  IIRC, this problem has
> been there since the previous kernels (at least 2.6.18-53) so I suppose it
> shouldn't be a (real) problem for Fujitsu, but I'll double-check that.
> 

Kei,

If that's the case (that these systems do have a large DSDT), then maybe we should 

a) modify the upstream code to use vmalloc, and
b) backport that patch to RHEL5 ?

What do you think?

P.

> Kei
> Fujitsu On-site Engineer
Comment 7 Keiichiro Tokunaga 2009-02-11 16:39:44 EST
(In reply to comment #6)
> (In reply to comment #5)
> > Thanks, Prarit.  It seems PRIMEQUEST has more than 256MB of DSDT, which exceeds
> > the maximum size kmalloc can allocate on the system.  IIRC, this problem has
> > been there since the previous kernels (at least 2.6.18-53) so I suppose it
> > shouldn't be a (real) problem for Fujitsu, but I'll double-check that.

Oh, just realized I put a wrong unit for the max size...  s/256MB/256KB/

> If that's the case (that these systems do have a large DSDT), then maybe we
> should 
> 
> a) modify the upstream code to use vmalloc, and
> b) backport that patch to RHEL5 ?
> 
> What do you think?

I think that's reasonable.  Probably, __vmalloc() would be more appropriate for tight controll over flags?

Kei
Comment 8 Keiichiro Tokunaga 2009-02-11 18:10:42 EST
Created attachment 331633 [details]
quick hack patch #1
Comment 9 Keiichiro Tokunaga 2009-02-11 18:11:19 EST
Created attachment 331634 [details]
quick hack patch #2
Comment 10 Keiichiro Tokunaga 2009-02-11 18:19:03 EST
The latest upstream kernel (2.6.29-rc4) has considered the /proc/acpi files as deprecated and replaced with /sys files.  And it can read /sys/firmware/acpi/tables/DSDT on the PRIMEQUEST with no problem.  So, I don't think we need a fix for upstream, but only for RHEL.  (The /proc/acpi files still can be created on recent kernels by specifying so in the Kconfig.)

I made two different quick hack patches for RHEL5, which I don't think change too much of RHEL code.  I confirmed it fixed the problem with either one of the patches.  (Also, Intel's ASL compiler disassembled the DSDT to an ASL with no problem.)

  - support_large_dsdt1.patch:
    Introduces ACPI_ALLOC_BUFFERV for someone who wants to use __vmalloc().
    The problem is there is only one who wants to use it today.

  - support_large_dsdt2.patch:
    Modifies acpi_system_read_dsdt() to read DSDT on its own, meaning it
    reads DSDT without calling acpi_get_table().

Kei
Comment 11 Prarit Bhargava 2009-02-11 18:36:35 EST
Created attachment 331635 [details]
RHEL5 fix for this issue

Kei, I actually was working on a patch :) -- it is very similar to the second one you posted.

IMO we don't need to do the irq check because the only caller of this function is the /proc read function.

P.
Comment 12 Keiichiro Tokunaga 2009-02-11 18:53:42 EST
(In reply to comment #11)
> Created an attachment (id=331635) [details]
> RHEL5 fix for this issue
> 
> Kei, I actually was working on a patch :) -- it is very similar to the second
> one you posted.

It looks good to me as it's cleaner than mine :-)

> IMO we don't need to do the irq check because the only caller of this function
> is the /proc read function.

That makes sense.

Kei
Comment 13 Prarit Bhargava 2009-02-11 18:53:42 EST
Created attachment 331636 [details]
RHEL5 fix for this issue

Oops -- after a final inspection, we don't need the length variable either.  tbl_ptr->length is good enough.

P.
Comment 14 Jeff Moyer 2009-02-13 16:41:31 EST
I installed a kernel with this patch, and now 'cat /proc/acpi/dsdt' outputs a bunch of binary garbage.
Comment 15 Prarit Bhargava 2009-02-13 18:47:54 EST
I ran the ASL on /proc/acpi/dsdt from the PrimeQuest system we have in RHTS (thanks jmoyer!) and it properly disassembles the binary output.

I will POST soon,

P.
Comment 16 RHEL Product and Program Management 2009-03-10 15:28:16 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 17 Don Zickus 2009-03-16 11:21:55 EDT
in kernel-2.6.18-135.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 20 errata-xmlrpc 2009-09-02 05:01:02 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html

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