Bug 480142

Cai, do you know if this was working previously on this system?

Thanks,

P.

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

Okay, no problem Cai -- I'll take a look and see if I can figure out what went wrong...

P.

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.

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

(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

(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

Created attachment 331633 [details]
quick hack patch #1

Created attachment 331634 [details]
quick hack patch #2

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

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.

(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

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.

I installed a kernel with this patch, and now 'cat /proc/acpi/dsdt' outputs a bunch of binary garbage.

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.

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.

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.

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