Re: MacBookPro 5,1

[Jung-uk Kim]

On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote:
 Hi,

 My MacBookPro 5,1 does not boot using -current because memory
 inside the ACPI kernel module is used after free.

 The following patch temporily mitigates the problem:

 /usr/src/sys/dev/acpica/Osd/OsdMemory.c

 void
 AcpiOsFree(void *Memory)
 {
 + if (cold == 0)
 free(Memory, M_ACPICA);
 }

 Is there any way to debug this from user-land?

FYI, this problem should be fixed in r214848.

While I am here, I'd like to give many thanks to hps for trying out 
patches, to avg for the great in-depth analysis and initial patch, to 
ACPICA developers for continuous support and invaluable comments!

Thank you, all folks!

Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Jung-uk Kim]

On Friday 05 November 2010 04:14 pm, Jung-uk Kim wrote:
 On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote:
  Hi,
 
  My MacBookPro 5,1 does not boot using -current because memory
  inside the ACPI kernel module is used after free.
 
  The following patch temporily mitigates the problem:
 
  /usr/src/sys/dev/acpica/Osd/OsdMemory.c
 
  void
  AcpiOsFree(void *Memory)
  {
  + if (cold == 0)
  free(Memory, M_ACPICA);
  }
 
  Is there any way to debug this from user-land?

 FYI, this problem should be fixed in r214848.

And r214849.  I forgot to change one line. :-(

Sorry,

Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

RE: MacBookPro 5,1

[Moore, Robert]

The problem is stale pointers within the structure, yes?

Cannot copy the structure. I will never do this kind of thing again.

When ACPICA was designed 12 years ago, memory was expensive.

Bob


-Original Message-
From: Moore, Robert
Sent: Thursday, November 04, 2010 7:24 PM
To: 'Hans Petter Selasky'; Jung-uk Kim; freebsd-acpi@freebsd.org
Subject: RE: MacBookPro 5,1


You cannot assume that a full memcpy has been performed on the structure
when you invoke the equals operator.

This is basic C





-Original Message-
From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
a...@freebsd.org] On Behalf Of Hans Petter Selasky
Sent: Thursday, November 04, 2010 12:44 AM
To: Jung-uk Kim; freebsd-acpi@freebsd.org
Subject: Re: MacBookPro 5,1

On Tuesday 02 November 2010 20:29:01 Jung-uk Kim wrote:
  Hans,
 
  could you please test the following patch?
 
  diff --git a/sys/dev/acpica/acpi_pci_link.c
  b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644
  --- a/sys/dev/acpica/acpi_pci_link.c
  +++ b/sys/dev/acpica/acpi_pci_link.c
  @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
 
link-l_irq;
else
resptr-Data.ExtendedIrq.Interrupts[0] =
0;
 
  + memset(resptr-Data.ExtendedIrq.ResourceSource,
0,
  + sizeof(ACPI_RESOURCE_SOURCE));
 
link++;
i++;
break;

The Bug statements disappeared with this patch! Which patch is next to
try?

--HPS
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[John Baldwin]

On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote:
 On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote:
  On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote:
   On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote:
On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote:
 On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote:
  On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote:
   On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote:
on 29/10/2010 08:51 Andriy Gapon said the following:
 I guess that a general problem here is that it is
 incorrect to merely use memcpy/bcopy to create a copy
 of a resource if the resource has
 ACPI_RESOURCE_SOURCE field in it.
   
Hans,
   
could you please test the following patch?
   
diff --git a/sys/dev/acpica/acpi_pci_link.c
b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635
100644 --- a/sys/dev/acpica/acpi_pci_link.c
+++ b/sys/dev/acpica/acpi_pci_link.c
@@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
link-l_irq;
else

resptr-Data.ExtendedIrq.Interrupts[0] = 0;
+   
memset(resptr-Data.ExtendedIrq.ResourceSource, 0,
+   sizeof(ACPI_RESOURCE_SOURCE));
link++;
i++;
break;
  
   Hmm...  Very interesting.  Can you please try this, too?
 
  Linux doesn't set the resource source bits up at all when
  doing _SRS, so I'd rather just do that.  I think what I'd
  prefer is that we not use the prs_template, perhaps just
  save the type of the resource and build a new resource
  object from scratch where the resource is zero'd, the
  appropriate bits are set and then that resource is appended
  to the buffer being built.

 Linux doesn't do it is wrong if I am reading the spec.
 correctly, i.e., _CRS, _PRS and _SRS must have the same
 format and size.
   
Umm, but we aren't setting up the raw bits for _SRS.  We are
creating a list of ACPI_RESOURCE objects that ACPICA then
encodes into a buffer to send to _SRS.
  
   Yes, I understand.  However, ACPICA is expecting the same size of
   buffer *including* the optional parts if I am reading the code
   right. Besides, I don't think there is any harm in doing the
   right thing. ;-)
 
  To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero
  it, then set the type and the IRQ and that's it.  Leave the
  ResourceSource bits as zero.  The size will still be set based on
  the actual type (or if needed we can use the cached size from the
  template copy we save from _PRS).  The point would be to start from
  a zero structure instead of from a copy of what we got from _PRS.
 
 It may work if we don't use l_prs_template.

Well, we still need much of the info from the _PRS resource (the type, etc.),
but I think we should not blindly use the template directly when building the
buffer for _SRS.

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Jung-uk Kim]

On Wednesday 03 November 2010 08:28 am, John Baldwin wrote:
 On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote:
  On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote:
   On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote:
On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote:
 On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote:
  On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote:
   On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim 
wrote:
On Tuesday 02 November 2010 11:29 am, Andriy Gapon 
wrote:
 on 29/10/2010 08:51 Andriy Gapon said the following:
  I guess that a general problem here is that it is
  incorrect to merely use memcpy/bcopy to create a
  copy of a resource if the resource has
  ACPI_RESOURCE_SOURCE field in it.

 Hans,

 could you please test the following patch?

 diff --git a/sys/dev/acpica/acpi_pci_link.c
 b/sys/dev/acpica/acpi_pci_link.c index
 dcf101d..e842635 100644 ---
 a/sys/dev/acpica/acpi_pci_link.c +++
 b/sys/dev/acpica/acpi_pci_link.c
 @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
   link-l_irq;
   else
   
 resptr-Data.ExtendedIrq.Interrupts[0] = 0;
 + 
 memset(resptr-Data.ExtendedIrq.ResourceSource
, 0, + sizeof(ACPI_RESOURCE_SOURCE));
   link++;
   i++;
   break;
   
Hmm...  Very interesting.  Can you please try this,
too?
  
   Linux doesn't set the resource source bits up at all
   when doing _SRS, so I'd rather just do that.  I think
   what I'd prefer is that we not use the prs_template,
   perhaps just save the type of the resource and build a
   new resource object from scratch where the resource is
   zero'd, the appropriate bits are set and then that
   resource is appended to the buffer being built.
 
  Linux doesn't do it is wrong if I am reading the spec.
  correctly, i.e., _CRS, _PRS and _SRS must have the same
  format and size.

 Umm, but we aren't setting up the raw bits for _SRS.  We
 are creating a list of ACPI_RESOURCE objects that ACPICA
 then encodes into a buffer to send to _SRS.
   
Yes, I understand.  However, ACPICA is expecting the same
size of buffer *including* the optional parts if I am reading
the code right. Besides, I don't think there is any harm in
doing the right thing. ;-)
  
   To be clear, I am suggesting to take an ACPI_RESOURCE object,
   bzero it, then set the type and the IRQ and that's it.  Leave
   the ResourceSource bits as zero.  The size will still be set
   based on the actual type (or if needed we can use the cached
   size from the template copy we save from _PRS).  The point
   would be to start from a zero structure instead of from a copy
   of what we got from _PRS.
 
  It may work if we don't use l_prs_template.

 Well, we still need much of the info from the _PRS resource (the
 type, etc.), but I think we should not blindly use the template
 directly when building the buffer for _SRS.

Actually, I think we should get the information directly from _CRS as 
ACPI spec. is suggesting.

Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[John Baldwin]

On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote:
 On Wednesday 03 November 2010 08:28 am, John Baldwin wrote:
  On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote:
   On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote:
On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote:
 On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote:
  On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote:
   On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote:
On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim 
 wrote:
 On Tuesday 02 November 2010 11:29 am, Andriy Gapon 
 wrote:
  on 29/10/2010 08:51 Andriy Gapon said the following:
   I guess that a general problem here is that it is
   incorrect to merely use memcpy/bcopy to create a
   copy of a resource if the resource has
   ACPI_RESOURCE_SOURCE field in it.
 
  Hans,
 
  could you please test the following patch?
 
  diff --git a/sys/dev/acpica/acpi_pci_link.c
  b/sys/dev/acpica/acpi_pci_link.c index
  dcf101d..e842635 100644 ---
  a/sys/dev/acpica/acpi_pci_link.c +++
  b/sys/dev/acpica/acpi_pci_link.c
  @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
  link-l_irq;
  else
  
  resptr-Data.ExtendedIrq.Interrupts[0] = 0;
  +   
  memset(resptr-Data.ExtendedIrq.ResourceSource
 , 0, +   
 sizeof(ACPI_RESOURCE_SOURCE));
  link++;
  i++;
  break;

 Hmm...  Very interesting.  Can you please try this,
 too?
   
Linux doesn't set the resource source bits up at all
when doing _SRS, so I'd rather just do that.  I think
what I'd prefer is that we not use the prs_template,
perhaps just save the type of the resource and build a
new resource object from scratch where the resource is
zero'd, the appropriate bits are set and then that
resource is appended to the buffer being built.
  
   Linux doesn't do it is wrong if I am reading the spec.
   correctly, i.e., _CRS, _PRS and _SRS must have the same
   format and size.
 
  Umm, but we aren't setting up the raw bits for _SRS.  We
  are creating a list of ACPI_RESOURCE objects that ACPICA
  then encodes into a buffer to send to _SRS.

 Yes, I understand.  However, ACPICA is expecting the same
 size of buffer *including* the optional parts if I am reading
 the code right. Besides, I don't think there is any harm in
 doing the right thing. ;-)
   
To be clear, I am suggesting to take an ACPI_RESOURCE object,
bzero it, then set the type and the IRQ and that's it.  Leave
the ResourceSource bits as zero.  The size will still be set
based on the actual type (or if needed we can use the cached
size from the template copy we save from _PRS).  The point
would be to start from a zero structure instead of from a copy
of what we got from _PRS.
  
   It may work if we don't use l_prs_template.
 
  Well, we still need much of the info from the _PRS resource (the
  type, etc.), but I think we should not blindly use the template
  directly when building the buffer for _SRS.
 
 Actually, I think we should get the information directly from _CRS as 
 ACPI spec. is suggesting.

I would be fine with that, but that does not work if _CRS doesn't work
(the acpi_pci_link_srs_from_links() case).  Are we allowed to modify
the buffer ACPICA gives us from _CRS and then pass that back to _SRS?

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Jung-uk Kim]

On Wednesday 03 November 2010 12:47 pm, John Baldwin wrote:
 On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote:
  On Wednesday 03 November 2010 08:28 am, John Baldwin wrote:
   On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote:
On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote:
 On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote:
  On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote:
   On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim 
wrote:
On Tuesday 02 November 2010 03:41 pm, John Baldwin 
wrote:
 On Tuesday, November 02, 2010 3:29:01 pm Jung-uk
 Kim
 
  wrote:
  On Tuesday 02 November 2010 11:29 am, Andriy
  Gapon
 
  wrote:
   on 29/10/2010 08:51 Andriy Gapon said the 
following:
I guess that a general problem here is that
it is incorrect to merely use memcpy/bcopy to
create a copy of a resource if the resource
has ACPI_RESOURCE_SOURCE field in it.
  
   Hans,
  
   could you please test the following patch?
  
   diff --git a/sys/dev/acpica/acpi_pci_link.c
   b/sys/dev/acpica/acpi_pci_link.c index
   dcf101d..e842635 100644 ---
   a/sys/dev/acpica/acpi_pci_link.c +++
   b/sys/dev/acpica/acpi_pci_link.c
   @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
 link-l_irq;
 else
 
   resptr-Data.ExtendedIrq.Interrupts[0] =
   0;
   + 
   memset(resptr-Data.ExtendedIrq.ResourceSo
  urce , 0, +
  sizeof(ACPI_RESOURCE_SOURCE));
   link++;
 i++;
 break;
 
  Hmm...  Very interesting.  Can you please try
  this, too?

 Linux doesn't set the resource source bits up at
 all when doing _SRS, so I'd rather just do that.  I
 think what I'd prefer is that we not use the
 prs_template, perhaps just save the type of the
 resource and build a new resource object from
 scratch where the resource is zero'd, the
 appropriate bits are set and then that resource is
 appended to the buffer being built.
   
Linux doesn't do it is wrong if I am reading the
spec. correctly, i.e., _CRS, _PRS and _SRS must have
the same format and size.
  
   Umm, but we aren't setting up the raw bits for _SRS. 
   We are creating a list of ACPI_RESOURCE objects that
   ACPICA then encodes into a buffer to send to _SRS.
 
  Yes, I understand.  However, ACPICA is expecting the same
  size of buffer *including* the optional parts if I am
  reading the code right. Besides, I don't think there is
  any harm in doing the right thing. ;-)

 To be clear, I am suggesting to take an ACPI_RESOURCE
 object, bzero it, then set the type and the IRQ and that's
 it.  Leave the ResourceSource bits as zero.  The size will
 still be set based on the actual type (or if needed we can
 use the cached size from the template copy we save from
 _PRS).  The point would be to start from a zero structure
 instead of from a copy of what we got from _PRS.
   
It may work if we don't use l_prs_template.
  
   Well, we still need much of the info from the _PRS resource
   (the type, etc.), but I think we should not blindly use the
   template directly when building the buffer for _SRS.
 
  Actually, I think we should get the information directly from
  _CRS as ACPI spec. is suggesting.

 I would be fine with that, but that does not work if _CRS doesn't
 work (the acpi_pci_link_srs_from_links() case).

For that case, we must use the template, of course.  In fact, my patch 
is more useful for this particular case. :-)

 Are we allowed to modify the buffer ACPICA gives us from _CRS and
 then pass that back to _SRS?

I believe so.  If we go with that route, we don't have to worry about 
ResourceSource.StringPtr or acpi_AppendBufferResource() copying stale 
pointers.

Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Jung-uk Kim]

On Wednesday 03 November 2010 01:51 pm, Jung-uk Kim wrote:
 On Wednesday 03 November 2010 12:47 pm, John Baldwin wrote:
  On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote:
   On Wednesday 03 November 2010 08:28 am, John Baldwin wrote:
On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote:
 On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote:
  On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim 
wrote:
   On Tuesday 02 November 2010 04:24 pm, John Baldwin 
wrote:
On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim

 wrote:
 On Tuesday 02 November 2010 03:41 pm, John Baldwin

 wrote:
  On Tuesday, November 02, 2010 3:29:01 pm Jung-uk
  Kim
  
   wrote:
   On Tuesday 02 November 2010 11:29 am, Andriy
   Gapon
  
   wrote:
on 29/10/2010 08:51 Andriy Gapon said the

 following:
 I guess that a general problem here is that
 it is incorrect to merely use memcpy/bcopy
 to create a copy of a resource if the
 resource has ACPI_RESOURCE_SOURCE field in
 it.
   
Hans,
   
could you please test the following patch?
   
diff --git a/sys/dev/acpica/acpi_pci_link.c
b/sys/dev/acpica/acpi_pci_link.c index
dcf101d..e842635 100644 ---
a/sys/dev/acpica/acpi_pci_link.c +++
b/sys/dev/acpica/acpi_pci_link.c
@@ -767,6 +767,8 @@
acpi_pci_link_srs_from_crs link-l_irq;
else

resptr-Data.ExtendedIrq.Interrupts[0] =
0;
+   
memset(resptr-Data.ExtendedIrq.Resource
   So urce , 0, +  
sizeof(ACPI_RESOURCE_SOURCE)); link++;
i++;
break;
  
   Hmm...  Very interesting.  Can you please try
   this, too?
 
  Linux doesn't set the resource source bits up at
  all when doing _SRS, so I'd rather just do that. 
  I think what I'd prefer is that we not use the
  prs_template, perhaps just save the type of the
  resource and build a new resource object from
  scratch where the resource is zero'd, the
  appropriate bits are set and then that resource
  is appended to the buffer being built.

 Linux doesn't do it is wrong if I am reading the
 spec. correctly, i.e., _CRS, _PRS and _SRS must
 have the same format and size.
   
Umm, but we aren't setting up the raw bits for _SRS.
We are creating a list of ACPI_RESOURCE objects that
ACPICA then encodes into a buffer to send to _SRS.
  
   Yes, I understand.  However, ACPICA is expecting the
   same size of buffer *including* the optional parts if I
   am reading the code right. Besides, I don't think there
   is any harm in doing the right thing. ;-)
 
  To be clear, I am suggesting to take an ACPI_RESOURCE
  object, bzero it, then set the type and the IRQ and
  that's it.  Leave the ResourceSource bits as zero.  The
  size will still be set based on the actual type (or if
  needed we can use the cached size from the template copy
  we save from _PRS).  The point would be to start from a
  zero structure instead of from a copy of what we got from
  _PRS.

 It may work if we don't use l_prs_template.
   
Well, we still need much of the info from the _PRS resource
(the type, etc.), but I think we should not blindly use the
template directly when building the buffer for _SRS.
  
   Actually, I think we should get the information directly from
   _CRS as ACPI spec. is suggesting.
 
  I would be fine with that, but that does not work if _CRS doesn't
  work (the acpi_pci_link_srs_from_links() case).

 For that case, we must use the template, of course.  In fact, my
 patch is more useful for this particular case. :-)

  Are we allowed to modify the buffer ACPICA gives us from _CRS and
  then pass that back to _SRS?

 I believe so.  If we go with that route, we don't have to worry
 about ResourceSource.StringPtr or acpi_AppendBufferResource()
 copying stale pointers.

Please see the attached patch.  It seems working fine. :-)

Note I had to adjust resource length to prevent reading/writing beyond 
buffer size.  It should work okay for acpi_pci_link_srs_from_links() 
case, I believe.  It's a hack anyway. ;-)

Jung-uk Kim
--- sys/dev/acpica/acpi_pci_link.c  2010-03-05 15:07:53.0 -0500
+++ sys/dev/acpica/acpi_pci_link.c  2010-11-03 16:09:40.0 -0400
@@ -268,6 +268,7 @@ link_add_crs(ACPI_RESOURCE *res, void *c
 static ACPI_STATUS
 link_add_prs(ACPI_RESOURCE *res, void *context)
 {
+   ACPI_RESOURCE *tmp;

Re: MacBookPro 5,1

[Andriy Gapon]

on 03/11/2010 22:49 Jung-uk Kim said the following:
 On Wednesday 03 November 2010 04:25 pm, Jung-uk Kim wrote:
 Note I had to adjust resource length to prevent reading/writing
 beyond buffer size.  It should work okay for
 acpi_pci_link_srs_from_links() case, I believe.  It's a hack
 anyway. ;-)
 
 I realized two MPASS() checks were removed accidentally.  They are 
 still valid, so they won't be removed in the actual commit if it 
 works and everyone agrees.

I guess we are mostly waiting for hps's testing at this point?
Whom mysteriously has already disappeared from the cc-list :-)

On the other hand, I think there is no reason to keep Robert and Lin Ming (sorry
couldn't tell what is the first name and what is the last name) on this quite
technical discussion of this now very FreeBSD-specific issue.

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

RE: MacBookPro 5,1

[Moore, Robert]

We are interested here.

Our goal is to simplify your ACPI implementation.

I've we've screwed up, tell us.

If we can help in ACPICA, please let us know. We have at least 2 software 
engineers that are full-time on this project.

Robert B Moore
Intel Corporation



-Original Message-
From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
a...@freebsd.org] On Behalf Of Jung-uk Kim
Sent: Wednesday, November 03, 2010 1:50 PM
To: freebsd-acpi@FreeBSD.org
Cc: Andriy Gapon; Lin, Ming M; Moore, Robert
Subject: Re: MacBookPro 5,1

On Wednesday 03 November 2010 04:25 pm, Jung-uk Kim wrote:
 Note I had to adjust resource length to prevent reading/writing
 beyond buffer size.  It should work okay for
 acpi_pci_link_srs_from_links() case, I believe.  It's a hack
 anyway. ;-)

I realized two MPASS() checks were removed accidentally.  They are
still valid, so they won't be removed in the actual commit if it
works and everyone agrees.

Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 29/10/2010 08:51 Andriy Gapon said the following:
 I guess that a general problem here is that it is incorrect to merely use
 memcpy/bcopy to create a copy of a resource if the resource has
 ACPI_RESOURCE_SOURCE field in it.

Hans,

could you please test the following patch?

diff --git a/sys/dev/acpica/acpi_pci_link.c b/sys/dev/acpica/acpi_pci_link.c
index dcf101d..e842635 100644
--- a/sys/dev/acpica/acpi_pci_link.c
+++ b/sys/dev/acpica/acpi_pci_link.c
@@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
link-l_irq;
else
resptr-Data.ExtendedIrq.Interrupts[0] = 0;
+   memset(resptr-Data.ExtendedIrq.ResourceSource, 0,
+   sizeof(ACPI_RESOURCE_SOURCE));
link++;
i++;
break;


-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[John Baldwin]

On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote:
 On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote:
  on 29/10/2010 08:51 Andriy Gapon said the following:
   I guess that a general problem here is that it is incorrect to
   merely use memcpy/bcopy to create a copy of a resource if the
   resource has ACPI_RESOURCE_SOURCE field in it.
 
  Hans,
 
  could you please test the following patch?
 
  diff --git a/sys/dev/acpica/acpi_pci_link.c
  b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644
  --- a/sys/dev/acpica/acpi_pci_link.c
  +++ b/sys/dev/acpica/acpi_pci_link.c
  @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
  link-l_irq;
  else
  resptr-Data.ExtendedIrq.Interrupts[0] = 0;
  +   memset(resptr-Data.ExtendedIrq.ResourceSource, 0,
  +   sizeof(ACPI_RESOURCE_SOURCE));
  link++;
  i++;
  break;
 
 Hmm...  Very interesting.  Can you please try this, too?

Linux doesn't set the resource source bits up at all when doing _SRS, so I'd 
rather just do that.  I think what I'd prefer is that we not use the 
prs_template, perhaps just save the type of the resource and build a new
resource object from scratch where the resource is zero'd, the appropriate 
bits are set and then that resource is appended to the buffer being built.

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Jung-uk Kim]

On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote:
 On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote:
  On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote:
   on 29/10/2010 08:51 Andriy Gapon said the following:
I guess that a general problem here is that it is incorrect
to merely use memcpy/bcopy to create a copy of a resource if
the resource has ACPI_RESOURCE_SOURCE field in it.
  
   Hans,
  
   could you please test the following patch?
  
   diff --git a/sys/dev/acpica/acpi_pci_link.c
   b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644
   --- a/sys/dev/acpica/acpi_pci_link.c
   +++ b/sys/dev/acpica/acpi_pci_link.c
   @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
 link-l_irq;
 else
 resptr-Data.ExtendedIrq.Interrupts[0] = 0;
   + memset(resptr-Data.ExtendedIrq.ResourceSource, 0,
   + sizeof(ACPI_RESOURCE_SOURCE));
 link++;
 i++;
 break;
 
  Hmm...  Very interesting.  Can you please try this, too?

 Linux doesn't set the resource source bits up at all when doing
 _SRS, so I'd rather just do that.  I think what I'd prefer is that
 we not use the prs_template, perhaps just save the type of the
 resource and build a new resource object from scratch where the
 resource is zero'd, the appropriate bits are set and then that
 resource is appended to the buffer being built.

Linux doesn't do it is wrong if I am reading the spec. correctly, 
i.e., _CRS, _PRS and _SRS must have the same format and size.

Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[John Baldwin]

On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote:
 On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote:
  On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote:
   On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote:
on 29/10/2010 08:51 Andriy Gapon said the following:
 I guess that a general problem here is that it is incorrect
 to merely use memcpy/bcopy to create a copy of a resource if
 the resource has ACPI_RESOURCE_SOURCE field in it.
   
Hans,
   
could you please test the following patch?
   
diff --git a/sys/dev/acpica/acpi_pci_link.c
b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644
--- a/sys/dev/acpica/acpi_pci_link.c
+++ b/sys/dev/acpica/acpi_pci_link.c
@@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
link-l_irq;
else
resptr-Data.ExtendedIrq.Interrupts[0] 
= 0;
+   
memset(resptr-Data.ExtendedIrq.ResourceSource, 0,
+   sizeof(ACPI_RESOURCE_SOURCE));
link++;
i++;
break;
  
   Hmm...  Very interesting.  Can you please try this, too?
 
  Linux doesn't set the resource source bits up at all when doing
  _SRS, so I'd rather just do that.  I think what I'd prefer is that
  we not use the prs_template, perhaps just save the type of the
  resource and build a new resource object from scratch where the
  resource is zero'd, the appropriate bits are set and then that
  resource is appended to the buffer being built.
 
 Linux doesn't do it is wrong if I am reading the spec. correctly, 
 i.e., _CRS, _PRS and _SRS must have the same format and size.

Umm, but we aren't setting up the raw bits for _SRS.  We are creating
a list of ACPI_RESOURCE objects that ACPICA then encodes into a buffer
to send to _SRS.

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Jung-uk Kim]

On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote:
 On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote:
  On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote:
   On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote:
On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote:
 on 29/10/2010 08:51 Andriy Gapon said the following:
  I guess that a general problem here is that it is
  incorrect to merely use memcpy/bcopy to create a copy of
  a resource if the resource has ACPI_RESOURCE_SOURCE field
  in it.

 Hans,

 could you please test the following patch?

 diff --git a/sys/dev/acpica/acpi_pci_link.c
 b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635
 100644 --- a/sys/dev/acpica/acpi_pci_link.c
 +++ b/sys/dev/acpica/acpi_pci_link.c
 @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
   link-l_irq;
   else
   resptr-Data.ExtendedIrq.Interrupts[0] 
 = 0;
 + 
 memset(resptr-Data.ExtendedIrq.ResourceSource, 0,
 + sizeof(ACPI_RESOURCE_SOURCE));
   link++;
   i++;
   break;
   
Hmm...  Very interesting.  Can you please try this, too?
  
   Linux doesn't set the resource source bits up at all when doing
   _SRS, so I'd rather just do that.  I think what I'd prefer is
   that we not use the prs_template, perhaps just save the type of
   the resource and build a new resource object from scratch where
   the resource is zero'd, the appropriate bits are set and then
   that resource is appended to the buffer being built.
 
  Linux doesn't do it is wrong if I am reading the spec.
  correctly, i.e., _CRS, _PRS and _SRS must have the same format
  and size.

 Umm, but we aren't setting up the raw bits for _SRS.  We are
 creating a list of ACPI_RESOURCE objects that ACPICA then encodes
 into a buffer to send to _SRS.

Yes, I understand.  However, ACPICA is expecting the same size of 
buffer *including* the optional parts if I am reading the code right.  
Besides, I don't think there is any harm in doing the right 
thing. ;-)

Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[John Baldwin]

On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote:
 On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote:
  On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote:
   On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote:
On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote:
 On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote:
  on 29/10/2010 08:51 Andriy Gapon said the following:
   I guess that a general problem here is that it is
   incorrect to merely use memcpy/bcopy to create a copy of
   a resource if the resource has ACPI_RESOURCE_SOURCE field
   in it.
 
  Hans,
 
  could you please test the following patch?
 
  diff --git a/sys/dev/acpica/acpi_pci_link.c
  b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635
  100644 --- a/sys/dev/acpica/acpi_pci_link.c
  +++ b/sys/dev/acpica/acpi_pci_link.c
  @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
  link-l_irq;
  else
  resptr-Data.ExtendedIrq.Interrupts[0] 
  = 0;
  +   
  memset(resptr-Data.ExtendedIrq.ResourceSource, 0,
  +   sizeof(ACPI_RESOURCE_SOURCE));
  link++;
  i++;
  break;

 Hmm...  Very interesting.  Can you please try this, too?
   
Linux doesn't set the resource source bits up at all when doing
_SRS, so I'd rather just do that.  I think what I'd prefer is
that we not use the prs_template, perhaps just save the type of
the resource and build a new resource object from scratch where
the resource is zero'd, the appropriate bits are set and then
that resource is appended to the buffer being built.
  
   Linux doesn't do it is wrong if I am reading the spec.
   correctly, i.e., _CRS, _PRS and _SRS must have the same format
   and size.
 
  Umm, but we aren't setting up the raw bits for _SRS.  We are
  creating a list of ACPI_RESOURCE objects that ACPICA then encodes
  into a buffer to send to _SRS.
 
 Yes, I understand.  However, ACPICA is expecting the same size of 
 buffer *including* the optional parts if I am reading the code right.  
 Besides, I don't think there is any harm in doing the right 
 thing. ;-)

To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero it,
then set the type and the IRQ and that's it.  Leave the ResourceSource
bits as zero.  The size will still be set based on the actual type (or
if needed we can use the cached size from the template copy we save from
_PRS).  The point would be to start from a zero structure instead of
from a copy of what we got from _PRS.

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 02/11/2010 22:50 Jung-uk Kim said the following:
 Yes, I understand.  However, ACPICA is expecting the same size of 
 buffer *including* the optional parts if I am reading the code right.  

Hmm, where is ACPICA doing that?
I didn't see any connection between what *ACPICA* can return to OS in _CRS/_PRS
and what OS can pass in _SRS.

 Besides, I don't think there is any harm in doing the right 
 thing. ;-)

I don't think that this is any righter than zero-ing out resource source
description string.  BIOS/firmware can't possibly use that for anything
meaningful, IMO.

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Jung-uk Kim]

On Tuesday 02 November 2010 05:50 pm, Andriy Gapon wrote:
 on 02/11/2010 22:50 Jung-uk Kim said the following:
  Yes, I understand.  However, ACPICA is expecting the same size of
  buffer *including* the optional parts if I am reading the code
  right.

 Hmm, where is ACPICA doing that?

If you scrub ResourceSource, then:

AcpiSetCurrentResources() -
AcpiRsSetSrsMethodData() -
AcpiRsCreateAmlResources() -
AcpiRsGetAmlLength() -
AcpiRsStructOptionLength()

will return 0 and size of new buffer may be smaller than what we got 
from _CRS.  I may have read it wrong, though. :-/

 I didn't see any connection between what *ACPICA* can return to OS
 in _CRS/_PRS and what OS can pass in _SRS.

  Besides, I don't think there is any harm in doing the right
  thing. ;-)

 I don't think that this is any righter than zero-ing out resource
 source description string.  BIOS/firmware can't possibly use that
 for anything meaningful, IMO.

I didn't say it is ever useful.  My point was it may not work for some 
BIOS but I am not sure, that's all.

Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Lin Ming]

On Fri, 2010-10-29 at 13:19 +0800, Andriy Gapon wrote:
 on 29/10/2010 03:34 Lin Ming said the following:
  Hi, guys
  
  Hans and I have found the root cause of this bug.
 
 I believe that there could be a root for a root :-)

I will continue to check this bug next Monday.
Hope we can find the final root :)

Thanks.

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Lin Ming]

On Fri, 2010-10-29 at 00:10 +0800, Hans Petter Selasky wrote:
 On Thursday 28 October 2010 17:24:32 Lin Ming wrote:
  On Thu, 2010-10-28 at 23:05 +0800, Lin Ming wrote:
   On Thu, 2010-10-28 at 22:55 +0800, Hans Petter Selasky wrote:
On Thursday 28 October 2010 16:44:55 Lin Ming wrote:
 On Thu, 2010-10-28 at 22:40 +0800, Hans Petter Selasky wrote:
  I make two kernel builds, one with the following patch, and one
  without.
 
 snip
 
  Did you get the information you needed? Or do I need to send the
  complete dmesg?
 
 Yes, please send both dmesgs (with and without the patch)
 
 Thanks.
 
  --HPS
   
   DEBUG: Aml=0xff00031f9000, EndAml=0xff00031f900d,
   AmlSizeNeeded=13 DEBUG: Aml=0xff00031f9000, MinimumLength=9,
   AmlResourceSource=0xff00031f9009 DEBUG: string length=16
   
   AmlSizeNeeded=13, but string length=16, there is something pretty wrong.
   
   Thanks for the info.
   I'm checking...
  
  I find the evil, the resource buffer passed in by driver is wrong.
  
  Would you please try below patch?
  Just apply below patch, no kernel boot acpi options and no other
  patches.
  
  diff --git a/source/components/resources/rscalc.c
  b/source/components/resources/rscalc.c index 3215c9e..e68b5af 100644
  --- a/source/components/resources/rscalc.c
  +++ b/source/components/resources/rscalc.c
  @@ -203,7 +203,13 @@ AcpiRsStructOptionLength (
*/
   if (ResourceSource-StringPtr)
   {
  -return ((ACPI_RS_LENGTH) (ResourceSource-StringLength + 1));
  +if (ACPI_STRLEN (ResourceSource-StringPtr) + 1 !=
  ResourceSource-StringLength) +{
  +AcpiOsPrintf(Bug: the passed in resource buffer is wrong,
  ResourceSource-StringLength=%d,  +   but the real string
  length is %d\n,
  +   ResourceSource-StringLength, ACPI_STRLEN
  (ResourceSource-StringPtr) + 1); +}
  +return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource-StringPtr)
  + 1) + 1)); }
  
   return (0);
  
   Lin Ming
 
 That seems to have done the trick! There are some additional debug prints 
 from 
 some other sub-systems which you can ignore.
 
 1) copied fresh ACPICA sources from kernel tree.
 2) compiled with your patch.
 3) Resulting dmesg is attached.

Hi, guys

Hans and I have found the root cause of this bug.
The ResourceSource-StringLength set by up layer driver is wrong, see the patch 
below.

Below patch fixes the bug and on Hans' machine it prints,

Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 10
Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 10
Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 10
Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 8
Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 10
Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 10
Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 10
Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 10
Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but the 
real string length is 10

The full dmesg also attached.

Kim, 

Could you write a fix in up layer code(seems in acpi_pci_link_route_irqs)?

Thanks.

diff --git a/source/components/resources/rscalc.c 
b/source/components/resources/rscalc.c
index 3215c9e..e68b5af 100644
--- a/source/components/resources/rscalc.c
+++ b/source/components/resources/rscalc.c
@@ -203,7 +203,13 @@ AcpiRsStructOptionLength (
  */
 if (ResourceSource-StringPtr)
 {
-return ((ACPI_RS_LENGTH) (ResourceSource-StringLength + 1));
+if (ACPI_STRLEN (ResourceSource-StringPtr) + 1 != 
ResourceSource-StringLength)
+{
+AcpiOsPrintf(Bug: the passed in resource buffer is wrong, 
ResourceSource-StringLength=%d, 
+   but the real string length is %d\n,
+   ResourceSource-StringLength, ACPI_STRLEN 
(ResourceSource-StringPtr) + 1);
+}
+return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource-StringPtr) + 
1) + 1));
 }
 
 return (0);

Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #88: Thu Oct 28 18:05:11 CEST 2010
r...@hpsbook:/usr/obj/usr/src/sys/GENERIC amd64
WARNING: WITNESS option enabled, expect reduced performance.
MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
MEMGUARD map base: 0xff800020
MEMGUARD map limit: 0xff8003a99000

Re: MacBookPro 5,1

[Andriy Gapon]

on 29/10/2010 03:34 Lin Ming said the following:
 Hi, guys
 
 Hans and I have found the root cause of this bug.

I believe that there could be a root for a root :-)

 The ResourceSource-StringLength set by up layer driver is wrong, see the 
 patch below.
 
 Below patch fixes the bug and on Hans' machine it prints,
 
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 8
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 
 The full dmesg also attached.
 
 Kim, 
 
 Could you write a fix in up layer code(seems in acpi_pci_link_route_irqs)?
 
 Thanks.
 
 diff --git a/source/components/resources/rscalc.c 
 b/source/components/resources/rscalc.c
 index 3215c9e..e68b5af 100644
 --- a/source/components/resources/rscalc.c
 +++ b/source/components/resources/rscalc.c
 @@ -203,7 +203,13 @@ AcpiRsStructOptionLength (
   */
  if (ResourceSource-StringPtr)
  {
 -return ((ACPI_RS_LENGTH) (ResourceSource-StringLength + 1));
 +if (ACPI_STRLEN (ResourceSource-StringPtr) + 1 != 
 ResourceSource-StringLength)
 +{
 +AcpiOsPrintf(Bug: the passed in resource buffer is wrong, 
 ResourceSource-StringLength=%d, 
 +   but the real string length is %d\n,
 +   ResourceSource-StringLength, ACPI_STRLEN 
 (ResourceSource-StringPtr) + 1);
 +}
 +return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource-StringPtr) + 
 1) + 1));
  }
  
  return (0);
 

As Hans has reported previously, it seems that resources for _SRS are prepared
by acpi_pci_link_srs_from_crs() in his case.
acpi_pci_link_srs_from_crs is a sufficiently small function that doesn't seem to
manipulate strings in any resources:
http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L689

At this line
http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L746
you can see that a resource is assigned from l_prs_template.

l_prs_template is populated in link_add_prs() function, which called to walk
over resources returned by _PRS:
http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L499
http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L269
http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L324

So, it would seem that those incorrect lengths would come from evaluation of
_PRS by ACPICA code.  But that's probably a naive conclusion, it could be that
we incorrectly manipulate a received resource.

It seems that the source of the trouble is resource template in BUFF, judging
from e.g. _PRS for LNK1 (in DSDT dump that Hans has provided).

I guess that we probably need more help with tracking this down further.
Could it be that we get or somehow insert/copy garbage as a content of a string
that should be empty?

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 29/10/2010 08:19 Andriy Gapon said the following:
 on 29/10/2010 03:34 Lin Ming said the following:
 Hi, guys

 Hans and I have found the root cause of this bug.
 
 I believe that there could be a root for a root :-)
 
 The ResourceSource-StringLength set by up layer driver is wrong, see the 
 patch below.

 Below patch fixes the bug and on Hans' machine it prints,

 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 8
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10
 Bug: the passed in resource buffer is wrong, Resource-StringLength=1, but 
 the real string length is 10

 The full dmesg also attached.

 Kim, 

 Could you write a fix in up layer code(seems in acpi_pci_link_route_irqs)?

 Thanks.

 diff --git a/source/components/resources/rscalc.c 
 b/source/components/resources/rscalc.c
 index 3215c9e..e68b5af 100644
 --- a/source/components/resources/rscalc.c
 +++ b/source/components/resources/rscalc.c
 @@ -203,7 +203,13 @@ AcpiRsStructOptionLength (
   */
  if (ResourceSource-StringPtr)
  {
 -return ((ACPI_RS_LENGTH) (ResourceSource-StringLength + 1));
 +if (ACPI_STRLEN (ResourceSource-StringPtr) + 1 != 
 ResourceSource-StringLength)
 +{
 +AcpiOsPrintf(Bug: the passed in resource buffer is wrong, 
 ResourceSource-StringLength=%d, 
 +   but the real string length is %d\n,
 +   ResourceSource-StringLength, ACPI_STRLEN 
 (ResourceSource-StringPtr) + 1);
 +}
 +return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource-StringPtr) 
 + 1) + 1));
  }
  
  return (0);

 
 As Hans has reported previously, it seems that resources for _SRS are prepared
 by acpi_pci_link_srs_from_crs() in his case.
 acpi_pci_link_srs_from_crs is a sufficiently small function that doesn't seem 
 to
 manipulate strings in any resources:
 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L689
 
 At this line
 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L746
 you can see that a resource is assigned from l_prs_template.
 
 l_prs_template is populated in link_add_prs() function, which called to walk
 over resources returned by _PRS:
 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L499
 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L269
 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L324
 
 So, it would seem that those incorrect lengths would come from evaluation of
 _PRS by ACPICA code.  But that's probably a naive conclusion, it could be that
 we incorrectly manipulate a received resource.
 
 It seems that the source of the trouble is resource template in BUFF, judging
 from e.g. _PRS for LNK1 (in DSDT dump that Hans has provided).
 
 I guess that we probably need more help with tracking this down further.
 Could it be that we get or somehow insert/copy garbage as a content of a 
 string
 that should be empty?

Now that I wrote this, could the bug be in the following FreeBSD function:
http://fxr.watson.org/fxr/source/dev/acpica/acpi.c?im=10#L2150

I guess Hans could insert the same code for verifying string length in the
strategic places mentioned above to catch the exact place where string length
and string content get out of sync.

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 29/10/2010 08:23 Andriy Gapon said the following:
 on 29/10/2010 08:19 Andriy Gapon said the following:
[snip]
 l_prs_template is populated in link_add_prs() function, which called to walk
 over resources returned by _PRS:
 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L499
 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L269
 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L324

 So, it would seem that those incorrect lengths would come from evaluation of
 _PRS by ACPICA code.  But that's probably a naive conclusion, it could be 
 that
 we incorrectly manipulate a received resource.

I guess that a general problem here is that it is incorrect to merely use
memcpy/bcopy to create a copy of a resource if the resource has
ACPI_RESOURCE_SOURCE field in it.

Is there a helper function for making such a copy?

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Hans Petter Selasky]

On Friday 22 October 2010 07:19:47 Lin Ming wrote:
 On Fri, 2010-10-22 at 10:39 +0800, Lin Ming wrote:
  On Fri, 2010-10-22 at 04:57 +0800, Hans Petter Selasky wrote:
   Here is the relevant output. First note, the buffer length is 512 and
   (uint8_t)512 = 0, so I modified the code to print out the 512 bytes.
   
   
   Passed in resource buffer length=512
   Buffer start
   0f 00 00 00 40 00 00 00 01 00 01 01 01 17 01 00 38 b0 17 03 00 ff ff ff
   11 00 00 00 11 00 00 00 12 00 00 00 13 00 00 00 14 00 00 00 15 00 00
   00 16 00 00 00 17 00 00 0
   0 00 00 00 00 00 00 00 00 07 00 00 00 10 00 00 00 00 00 00 00 00 00 00
   00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 00
   
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
   
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 0
   0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 00
   
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
   
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 0
   0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 00
   
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
   
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   00 00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00
   Buffer end
  
  Unfortunately, I can't reproduce it in the simulator(acpiexec).
 
 Hans,
 
 This bug seems really strange.
 
 As above resource buffer you got, it's interpreted as below
 
 [00] Extended IRQ Resource
Type : ResourceConsumer
  Triggering : Level
Polarity : ActiveLow
 Sharing : Shared
   Resource Source Index : 17
 Resource Source : [NULL NAMESTRING]
 Interrupt Count : 01
 Dword00 : 0011
 
 [01] EndTag Resource
 
 [NULL NAMESTRING] actually means empty string with size 1 (1 byte for
 NULL terminator).
 
 You wrote:
  It appears that when a string is present in the extended interrupt
  descriptor (6.4.3.6, ACPIspec30.pdf), then this is not handled
  correctly, meaning that the precomputed buffer space when encoding to
  AML, is incorrect and that data is written beyond the destination
  buffer!
 
 But for above resources, AcpiRsCreateAmlResources-AcpiRsGetAmlLength
 returns 13, which is the precomputed size for the AML buffer and it's
 correct.
 
 I'm lost now.
 Would you please try this patch to double check if the fault is really
 caused by the string in the extended interrupt descriptor?

I'm pretty sure it's a bug in the parsing of ACPI_RESOURCE_TYPE_EXTENDED_IRQ. 
I will test your patch to verify that more later today.

--HPS

 
 Tell us if it boots OK or not with this patch.
 Thanks.
 
 diff --git a/source/components/resources/rsxface.c
 b/source/components/resources/rsxface.c index 2a019d1..17b88e2 100644
 --- a/source/components/resources/rsxface.c
 +++ b/source/components/resources/rsxface.c
 @@ -394,6 +394,7 @@ AcpiSetCurrentResources (
  {
  ACPI_STATUS Status;
  ACPI_NAMESPACE_NODE *Node;
 +ACPI_RESOURCE   *Res;
 
 
  ACPI_FUNCTION_TRACE (AcpiSetCurrentResources);
 @@ -416,6 +417,15 @@ AcpiSetCurrentResources (
  return_ACPI_STATUS (Status);
  }
 
 +Res = (ACPI_RESOURCE *) InBuffer-Pointer;
 +if (Res-Type == ACPI_RESOURCE_TYPE_EXTENDED_IRQ)
 +{
 +/* DEBUG: clear the string to see if it's the root cause */
 +
 +Res-Data.ExtendedIrq.ResourceSource.StringPtr = NULL;
 +Res-Data.ExtendedIrq.ResourceSource.StringLength = 0;
 +}
 +
  Status = AcpiRsSetSrsMethodData (Node, InBuffer);
  return_ACPI_STATUS (Status);
  }
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Hans Petter Selasky]

On Friday 22 October 2010 07:19:47 Lin Ming wrote:
 diff --git a/source/components/resources/rsxface.c
 b/source/components/resources/rsxface.c index 2a019d1..17b88e2 100644
 --- a/source/components/resources/rsxface.c
 +++ b/source/components/resources/rsxface.c
 @@ -394,6 +394,7 @@ AcpiSetCurrentResources (
  {
  ACPI_STATUS Status;
  ACPI_NAMESPACE_NODE *Node;
 +ACPI_RESOURCE   *Res;
  
  
  ACPI_FUNCTION_TRACE (AcpiSetCurrentResources);
 @@ -416,6 +417,15 @@ AcpiSetCurrentResources (
  return_ACPI_STATUS (Status);
  }
  
 +Res = (ACPI_RESOURCE *) InBuffer-Pointer;
 +if (Res-Type == ACPI_RESOURCE_TYPE_EXTENDED_IRQ)
 +{
 +/* DEBUG: clear the string to see if it's the root cause */
 +
 +Res-Data.ExtendedIrq.ResourceSource.StringPtr = NULL;
 +Res-Data.ExtendedIrq.ResourceSource.StringLength = 0;
 +}
 +
  Status = AcpiRsSetSrsMethodData (Node, InBuffer);
  return_ACPI_STATUS (Status);
  }

Hi,

After applying this patch I can confirm there are no more dirty free's.

--HPS
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Lin Ming]

On Thu, 2010-10-21 at 11:39 +0800, Lin Ming wrote:
 On Wed, 2010-10-20 at 16:06 +0800, Hans Petter Selasky wrote:
  On Wednesday 20 October 2010 08:36:31 Lin Ming wrote:
   On Wed, 2010-10-20 at 14:34 +0800, Hans Petter Selasky wrote:
On Tuesday 19 October 2010 07:47:02 Lin Ming wrote:
 On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
  On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
   Can you send us the acpidump for the machine?
   
   Also, tell us which control method is failing.
   
   Thanks
  
  Hi,
  
  Please find attached dump of ACPI tables.
  
  It is the function AcpiRsCreateAmlResources() which writes beyond 
  the
  buffer it allocates.
 
 Could you enable AML debug output to get more info?
 But I don't know how to enable it on FreeBSD.
 
 In Linux, the AML debug output is enabled with kernel boot parameters
 like below.
 acpi.debug_layer=0x acpi.debug_level=0x
 
 FreeBSD may have some similar boot parameters.

I've enabled the debug prints just around the failing function. Here is
the
   
result:
   What's the kernel parameters are you using?
   There should be a lot of AML debug output.
  
  
  Hi,
  
  During the function call that overwrites it's buffer, there are no more 
  debug 
  prints than shown in the code, even with all debug prints on. Where should 
  I 
  add more debug prints?
 
 I'm trying to reproduce this bug in the acpi simulator(acpiexec).
 Will get back to you.

Hi, 

Could you apply below debug patch and attach the output?
I'll try to reproduce this bug with the output.

It will print something like below,

Passed in resource buffer length=136
Buffer start
f 0 0 0 44 0 0 0 1 0 0 0 1 0 1 0 45 ee 44 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
Buffer end

Thanks.

diff --git a/source/components/resources/rsxface.c 
b/source/components/resources/rsxface.c
index 2a019d1..459ad44 100644
--- a/source/components/resources/rsxface.c
+++ b/source/components/resources/rsxface.c
@@ -394,6 +394,7 @@ AcpiSetCurrentResources (
 {
 ACPI_STATUS Status;
 ACPI_NAMESPACE_NODE *Node;
+UINT8   i, *Buffer;
 
 
 ACPI_FUNCTION_TRACE (AcpiSetCurrentResources);
@@ -416,6 +417,15 @@ AcpiSetCurrentResources (
 return_ACPI_STATUS (Status);
 }
 
+AcpiOsPrintf(Passed in resource buffer length=%d\n, InBuffer-Length);
+AcpiOsPrintf(Buffer start\n);
+Buffer = (UINT8*) InBuffer-Pointer;
+for (i = 0; i  (UINT8) InBuffer-Length; i++)
+{
+AcpiOsPrintf(%x , Buffer[i]); 
+}
+AcpiOsPrintf(\nBuffer end\n);
+
 Status = AcpiRsSetSrsMethodData (Node, InBuffer);
 return_ACPI_STATUS (Status);
 }

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Hans Petter Selasky]

Hi,

I will get you the debug output from this patch in about 8 hours.

--HPS

On Thursday 21 October 2010 09:12:27 Lin Ming wrote:
 
 Hi,
 
 Could you apply below debug patch and attach the output?
 I'll try to reproduce this bug with the output.
 
 It will print something like below,
 
 Passed in resource buffer length=136
 Buffer start
 f 0 0 0 44 0 0 0 1 0 0 0 1 0 1 0 45 ee 44 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 Buffer end
 
 Thanks.
 
 diff --git a/source/components/resources/rsxface.c
 b/source/components/resources/rsxface.c index 2a019d1..459ad44 100644
 --- a/source/components/resources/rsxface.c
 +++ b/source/components/resources/rsxface.c
 @@ -394,6 +394,7 @@ AcpiSetCurrentResources (
  {
  ACPI_STATUS Status;
  ACPI_NAMESPACE_NODE *Node;
 +UINT8   i, *Buffer;
 
 
  ACPI_FUNCTION_TRACE (AcpiSetCurrentResources);
 @@ -416,6 +417,15 @@ AcpiSetCurrentResources (
  return_ACPI_STATUS (Status);
  }
 
 +AcpiOsPrintf(Passed in resource buffer length=%d\n,
 InBuffer-Length); +AcpiOsPrintf(Buffer start\n);
 +Buffer = (UINT8*) InBuffer-Pointer;
 +for (i = 0; i  (UINT8) InBuffer-Length; i++)
 +{
 +AcpiOsPrintf(%x , Buffer[i]);
 +}
 +AcpiOsPrintf(\nBuffer end\n);
 +
  Status = AcpiRsSetSrsMethodData (Node, InBuffer);
  return_ACPI_STATUS (Status);
  }
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Hans Petter Selasky]

On Thursday 21 October 2010 09:12:27 Lin Ming wrote:
 On Thu, 2010-10-21 at 11:39 +0800, Lin Ming wrote:
  On Wed, 2010-10-20 at 16:06 +0800, Hans Petter Selasky wrote:
   On Wednesday 20 October 2010 08:36:31 Lin Ming wrote:
On Wed, 2010-10-20 at 14:34 +0800, Hans Petter Selasky wrote:
 On Tuesday 19 October 2010 07:47:02 Lin Ming wrote:
  On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
   On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
Can you send us the acpidump for the machine?

Also, tell us which control method is failing.

Thanks
   
   Hi,
   
   Please find attached dump of ACPI tables.
   
   It is the function AcpiRsCreateAmlResources() which writes
   beyond the buffer it allocates.
  
  Could you enable AML debug output to get more info?
  But I don't know how to enable it on FreeBSD.
  
  In Linux, the AML debug output is enabled with kernel boot
  parameters like below.
  acpi.debug_layer=0x acpi.debug_level=0x
  
  FreeBSD may have some similar boot parameters.
 
 I've enabled the debug prints just around the failing function.
 Here is the

 result:
What's the kernel parameters are you using?
There should be a lot of AML debug output.
   
   Hi,
   
   During the function call that overwrites it's buffer, there are no more
   debug prints than shown in the code, even with all debug prints on.
   Where should I add more debug prints?
  
  I'm trying to reproduce this bug in the acpi simulator(acpiexec).
  Will get back to you.
 
 Hi,
 
 Could you apply below debug patch and attach the output?
 I'll try to reproduce this bug with the output.
 
 It will print something like below,
 
 Passed in resource buffer length=136
 Buffer start
 f 0 0 0 44 0 0 0 1 0 0 0 1 0 1 0 45 ee 44 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 Buffer end
 
 Thanks.

Here is the relevant output. First note, the buffer length is 512 and 
(uint8_t)512 = 0, so I modified the code to print out the 512 bytes.


Passed in resource buffer length=512
Buffer start
0f 00 00 00 40 00 00 00 01 00 01 01 01 17 01 00 38 b0 17 03 00 ff ff ff 11 00 
00 00 11 00 00 00 12 00 00 00 13 00 00 00 14 00 00 00 15 00 00 00 16 00 00 00 
17 00 00 0
0 00 00 00 00 00 00 00 00 07 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 07 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Buffer end

 Context Switch from TID 0x to TID 0x186a0 

  rscalc-0293 [0x186a0] [188762] RsGetAmlLength: Entry
  rscalc-0369 [0x186a0] [188762] RsGetAmlLength: Exit- AE_OK
  rslist-0225 [0x186a0] [188762] RsConvertResourcesToAm: Entry
  rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
  rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
  rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
  rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
  rslist-0273 [0x186a0] [188762] RsConvertResourcesToAm: Exit- AE_OK
rscreate-0554 [0x186a0] [188761] RsCreateAmlResources  : OutputBuffer 
0xff00031f9000 Length D
Dirty free 0xff00031f9000 13 at 13

--HPS
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Lin Ming]

On Fri, 2010-10-22 at 04:57 +0800, Hans Petter Selasky wrote:
 On Thursday 21 October 2010 09:12:27 Lin Ming wrote:
  On Thu, 2010-10-21 at 11:39 +0800, Lin Ming wrote:
   On Wed, 2010-10-20 at 16:06 +0800, Hans Petter Selasky wrote:
On Wednesday 20 October 2010 08:36:31 Lin Ming wrote:
 On Wed, 2010-10-20 at 14:34 +0800, Hans Petter Selasky wrote:
  On Tuesday 19 October 2010 07:47:02 Lin Ming wrote:
   On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
 Can you send us the acpidump for the machine?
 
 Also, tell us which control method is failing.
 
 Thanks

Hi,

Please find attached dump of ACPI tables.

It is the function AcpiRsCreateAmlResources() which writes
beyond the buffer it allocates.
   
   Could you enable AML debug output to get more info?
   But I don't know how to enable it on FreeBSD.
   
   In Linux, the AML debug output is enabled with kernel boot
   parameters like below.
   acpi.debug_layer=0x acpi.debug_level=0x
   
   FreeBSD may have some similar boot parameters.
  
  I've enabled the debug prints just around the failing function.
  Here is the
 
  result:
 What's the kernel parameters are you using?
 There should be a lot of AML debug output.

Hi,

During the function call that overwrites it's buffer, there are no more
debug prints than shown in the code, even with all debug prints on.
Where should I add more debug prints?
   
   I'm trying to reproduce this bug in the acpi simulator(acpiexec).
   Will get back to you.
  
  Hi,
  
  Could you apply below debug patch and attach the output?
  I'll try to reproduce this bug with the output.
  
  It will print something like below,
  
  Passed in resource buffer length=136
  Buffer start
  f 0 0 0 44 0 0 0 1 0 0 0 1 0 1 0 45 ee 44 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0
  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 0
  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  Buffer end
  
  Thanks.
 
 Here is the relevant output. First note, the buffer length is 512 and 
 (uint8_t)512 = 0, so I modified the code to print out the 512 bytes.
 
 
 Passed in resource buffer length=512
 Buffer start
 0f 00 00 00 40 00 00 00 01 00 01 01 01 17 01 00 38 b0 17 03 00 ff ff ff 11 00 
 00 00 11 00 00 00 12 00 00 00 13 00 00 00 14 00 00 00 15 00 00 00 16 00 00 00 
 17 00 00 0
 0 00 00 00 00 00 00 00 00 07 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 07 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 0
 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 0
 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 Buffer end

Unfortunately, I can't reproduce it in the simulator(acpiexec).

Anyway, here is the debug patch I tried and the output as below.
$acpiexec dsdt.mbp51.bin

Set resource for \_SB_.PCI0.LNK1: success
Set resource for \_SB_.PCI0.LNK2: success
Set resource for \_SB_.PCI0.LNK3: success
Set resource for \_SB_.PCI0.LNK4: success
Set resource for \_SB_.PCI0.Z003: success
Set resource for \_SB_.PCI0.Z004: success
Set resource for \_SB_.PCI0.Z005: success
Set resource for \_SB_.PCI0.Z006: success
Set resource for \_SB_.PCI0.Z007: success
Set resource for \_SB_.PCI0.Z008: success
Set resource for \_SB_.PCI0.Z009: success
Set resource for \_SB_.PCI0.Z00A: success
Set resource for \_SB_.PCI0.Z00B: success
Set resource for \_SB_.PCI0.Z00C: success
Set resource for \_SB_.PCI0.Z00D: success
Set resource for \_SB_.PCI0.Z00E: success
Set resource for \_SB_.PCI0.Z00F: success
Set resource for 

Re: MacBookPro 5,1

[Lin Ming]

On Fri, 2010-10-22 at 10:39 +0800, Lin Ming wrote:
 On Fri, 2010-10-22 at 04:57 +0800, Hans Petter Selasky wrote:

  Here is the relevant output. First note, the buffer length is 512 and 
  (uint8_t)512 = 0, so I modified the code to print out the 512 bytes.
  
  
  Passed in resource buffer length=512
  Buffer start
  0f 00 00 00 40 00 00 00 01 00 01 01 01 17 01 00 38 b0 17 03 00 ff ff ff 11 
  00 
  00 00 11 00 00 00 12 00 00 00 13 00 00 00 14 00 00 00 15 00 00 00 16 00 00 
  00 
  17 00 00 0
  0 00 00 00 00 00 00 00 00 07 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 
  07 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 0
  0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 0
  0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 
  00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  Buffer end
 
 Unfortunately, I can't reproduce it in the simulator(acpiexec).

Hans,

This bug seems really strange.

As above resource buffer you got, it's interpreted as below

[00] Extended IRQ Resource
   Type : ResourceConsumer
 Triggering : Level
   Polarity : ActiveLow
Sharing : Shared
  Resource Source Index : 17
Resource Source : [NULL NAMESTRING]
Interrupt Count : 01
Dword00 : 0011

[01] EndTag Resource

[NULL NAMESTRING] actually means empty string with size 1 (1 byte for
NULL terminator).

You wrote:
 It appears that when a string is present in the extended interrupt
 descriptor (6.4.3.6, ACPIspec30.pdf), then this is not handled
 correctly, meaning that the precomputed buffer space when encoding to
 AML, is incorrect and that data is written beyond the destination
 buffer!

But for above resources, AcpiRsCreateAmlResources-AcpiRsGetAmlLength
returns 13, which is the precomputed size for the AML buffer and it's
correct.

I'm lost now.
Would you please try this patch to double check if the fault is really
caused by the string in the extended interrupt descriptor?

Tell us if it boots OK or not with this patch.
Thanks.

diff --git a/source/components/resources/rsxface.c 
b/source/components/resources/rsxface.c
index 2a019d1..17b88e2 100644
--- a/source/components/resources/rsxface.c
+++ b/source/components/resources/rsxface.c
@@ -394,6 +394,7 @@ AcpiSetCurrentResources (
 {
 ACPI_STATUS Status;
 ACPI_NAMESPACE_NODE *Node;
+ACPI_RESOURCE   *Res;
 
 
 ACPI_FUNCTION_TRACE (AcpiSetCurrentResources);
@@ -416,6 +417,15 @@ AcpiSetCurrentResources (
 return_ACPI_STATUS (Status);
 }
 
+Res = (ACPI_RESOURCE *) InBuffer-Pointer;
+if (Res-Type == ACPI_RESOURCE_TYPE_EXTENDED_IRQ)
+{
+/* DEBUG: clear the string to see if it's the root cause */
+
+Res-Data.ExtendedIrq.ResourceSource.StringPtr = NULL;
+Res-Data.ExtendedIrq.ResourceSource.StringLength = 0;
+}
+
 Status = AcpiRsSetSrsMethodData (Node, InBuffer);
 return_ACPI_STATUS (Status);
 }


___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Hans Petter Selasky]

On Tuesday 19 October 2010 07:47:02 Lin Ming wrote:
 On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
  On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
   Can you send us the acpidump for the machine?
   
   Also, tell us which control method is failing.
   
   Thanks
  
  Hi,
  
  Please find attached dump of ACPI tables.
  
  It is the function AcpiRsCreateAmlResources() which writes beyond the
  buffer it allocates.
 
 Could you enable AML debug output to get more info?
 But I don't know how to enable it on FreeBSD.
 
 In Linux, the AML debug output is enabled with kernel boot parameters
 like below.
 acpi.debug_layer=0x acpi.debug_level=0x
 
 FreeBSD may have some similar boot parameters.

I've enabled the debug prints just around the failing function. Here is the 
result:

pcib0: ACPI Host-PCI bridge on acpi0
pci0: ACPI PCI bus on pcib0
pci_link32: Enter debugger

 Context Switch from TID 0x to TID 0x186a0 

  rscalc-0293 [0x186a0] [188762] RsGetAmlLength: Entry
  rscalc-0369 [0x186a0] [188762] RsGetAmlLength: Exit- AE_OK
  rslist-0225 [0x186a0] [188762] RsConvertResourcesToAm: Entry
  rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
  rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
  rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
  rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
  rslist-0273 [0x186a0] [188762] RsConvertResourcesToAm: Exit- AE_OK
rscreate-0554 [0x186a0] [188761] RsCreateAmlResources  : OutputBuffer 
0xff00031f9000 Length D
Dirty free 0xff00031f9000 13 at 13
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
AcpiOsFree() at AcpiOsFree+0x72
AcpiUtDeleteInternalObj() at AcpiUtDeleteInternalObj+0x335
AcpiUtUpdateRefCount() at AcpiUtUpdateRefCount+0x188
AcpiUtUpdateObjectReference() at AcpiUtUpdateObjectReference+0x6e
AcpiUtRemoveReference() at AcpiUtRemoveReference+0xd5
AcpiRsSetSrsMethodData() at AcpiRsSetSrsMethodData+0x14b
AcpiSetCurrentResources() at AcpiSetCurrentResources+0xb8
acpi_pci_link_route_irqs() at acpi_pci_link_route_irqs+0x204
acpi_pci_link_route_interrupt() at acpi_pci_link_route_interrupt+0x1a9
acpi_pcib_route_interrupt() at acpi_pcib_route_interrupt+0x46b
pci_assign_interrupt() at pci_assign_interrupt+0x1c3
pci_add_resources() at pci_add_resources+0x14a
pci_add_children() at pci_add_children+0x10e
acpi_pci_attach() at acpi_pci_attach+0xcd
device_attach() at device_attach+0x69
bus_generic_attach() at bus_generic_attach+0x1a
acpi_pcib_attach() at acpi_pcib_attach+0x20e
acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x280
device_attach() at device_attach+0x69
bus_generic_attach() at bus_generic_attach+0x1a
acpi_attach() at acpi_attach+0xaa6
device_attach() at device_attach+0x69
bus_generic_attach() at bus_generic_attach+0x1a
nexus_acpi_attach() at nexus_acpi_attach+0x69
device_attach() at device_attach+0x69
bus_generic_new_pass() at bus_generic_new_pass+0xd6
bus_set_pass() at bus_set_pass+0x7a
configure() at configure+0xa
mi_startup() at mi_startup+0x59
btext() at btext+0x2c

--HPS
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Lin Ming]

On Wed, 2010-10-20 at 14:34 +0800, Hans Petter Selasky wrote:
 On Tuesday 19 October 2010 07:47:02 Lin Ming wrote:
  On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
   On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
Can you send us the acpidump for the machine?

Also, tell us which control method is failing.

Thanks
   
   Hi,
   
   Please find attached dump of ACPI tables.
   
   It is the function AcpiRsCreateAmlResources() which writes beyond the
   buffer it allocates.
  
  Could you enable AML debug output to get more info?
  But I don't know how to enable it on FreeBSD.
  
  In Linux, the AML debug output is enabled with kernel boot parameters
  like below.
  acpi.debug_layer=0x acpi.debug_level=0x
  
  FreeBSD may have some similar boot parameters.
 
 I've enabled the debug prints just around the failing function. Here is the 
 result:

What's the kernel parameters are you using?
There should be a lot of AML debug output.

Lin Ming

 
 pcib0: ACPI Host-PCI bridge on acpi0
 pci0: ACPI PCI bus on pcib0
 pci_link32: Enter debugger
 
  Context Switch from TID 0x to TID 0x186a0 
 
   rscalc-0293 [0x186a0] [188762] RsGetAmlLength: Entry
   rscalc-0369 [0x186a0] [188762] RsGetAmlLength: Exit- AE_OK
   rslist-0225 [0x186a0] [188762] RsConvertResourcesToAm: Entry
   rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
   rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
   rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
   rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
   rslist-0273 [0x186a0] [188762] RsConvertResourcesToAm: Exit- AE_OK
 rscreate-0554 [0x186a0] [188761] RsCreateAmlResources  : OutputBuffer 
 0xff00031f9000 Length D
 Dirty free 0xff00031f9000 13 at 13
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 AcpiOsFree() at AcpiOsFree+0x72
 AcpiUtDeleteInternalObj() at AcpiUtDeleteInternalObj+0x335
 AcpiUtUpdateRefCount() at AcpiUtUpdateRefCount+0x188
 AcpiUtUpdateObjectReference() at AcpiUtUpdateObjectReference+0x6e
 AcpiUtRemoveReference() at AcpiUtRemoveReference+0xd5
 AcpiRsSetSrsMethodData() at AcpiRsSetSrsMethodData+0x14b
 AcpiSetCurrentResources() at AcpiSetCurrentResources+0xb8
 acpi_pci_link_route_irqs() at acpi_pci_link_route_irqs+0x204
 acpi_pci_link_route_interrupt() at acpi_pci_link_route_interrupt+0x1a9
 acpi_pcib_route_interrupt() at acpi_pcib_route_interrupt+0x46b
 pci_assign_interrupt() at pci_assign_interrupt+0x1c3
 pci_add_resources() at pci_add_resources+0x14a
 pci_add_children() at pci_add_children+0x10e
 acpi_pci_attach() at acpi_pci_attach+0xcd
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 acpi_pcib_attach() at acpi_pcib_attach+0x20e
 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x280
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 acpi_attach() at acpi_attach+0xaa6
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 nexus_acpi_attach() at nexus_acpi_attach+0x69
 device_attach() at device_attach+0x69
 bus_generic_new_pass() at bus_generic_new_pass+0xd6
 bus_set_pass() at bus_set_pass+0x7a
 configure() at configure+0xa
 mi_startup() at mi_startup+0x59
 btext() at btext+0x2c
 
 --HPS


___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 20/10/2010 09:34 Hans Petter Selasky said the following:
 On Tuesday 19 October 2010 07:47:02 Lin Ming wrote:
 On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
 On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
 Can you send us the acpidump for the machine?

 Also, tell us which control method is failing.

 Thanks

 Hi,

 Please find attached dump of ACPI tables.

 It is the function AcpiRsCreateAmlResources() which writes beyond the
 buffer it allocates.

 Could you enable AML debug output to get more info?
 But I don't know how to enable it on FreeBSD.

 In Linux, the AML debug output is enabled with kernel boot parameters
 like below.
 acpi.debug_layer=0x acpi.debug_level=0x

 FreeBSD may have some similar boot parameters.
 
 I've enabled the debug prints just around the failing function. Here is the 
 result:
 
 pcib0: ACPI Host-PCI bridge on acpi0
 pci0: ACPI PCI bus on pcib0
 pci_link32: Enter debugger
 
  Context Switch from TID 0x to TID 0x186a0 
 
   rscalc-0293 [0x186a0] [188762] RsGetAmlLength: Entry
   rscalc-0369 [0x186a0] [188762] RsGetAmlLength: Exit- AE_OK
   rslist-0225 [0x186a0] [188762] RsConvertResourcesToAm: Entry
   rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
   rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
   rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
   rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
   rslist-0273 [0x186a0] [188762] RsConvertResourcesToAm: Exit- AE_OK
 rscreate-0554 [0x186a0] [188761] RsCreateAmlResources  : OutputBuffer 
 0xff00031f9000 Length D
 Dirty free 0xff00031f9000 13 at 13
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 AcpiOsFree() at AcpiOsFree+0x72
 AcpiUtDeleteInternalObj() at AcpiUtDeleteInternalObj+0x335
 AcpiUtUpdateRefCount() at AcpiUtUpdateRefCount+0x188
 AcpiUtUpdateObjectReference() at AcpiUtUpdateObjectReference+0x6e
 AcpiUtRemoveReference() at AcpiUtRemoveReference+0xd5
 AcpiRsSetSrsMethodData() at AcpiRsSetSrsMethodData+0x14b
 AcpiSetCurrentResources() at AcpiSetCurrentResources+0xb8
 acpi_pci_link_route_irqs() at acpi_pci_link_route_irqs+0x204

Can you please check which branch is executed here?
if (sc-pl_crs_bad)
status = acpi_pci_link_srs_from_links(sc, srsbuf);
else
status = acpi_pci_link_srs_from_crs(sc, srsbuf);


 acpi_pci_link_route_interrupt() at acpi_pci_link_route_interrupt+0x1a9
 acpi_pcib_route_interrupt() at acpi_pcib_route_interrupt+0x46b
 pci_assign_interrupt() at pci_assign_interrupt+0x1c3
 pci_add_resources() at pci_add_resources+0x14a
 pci_add_children() at pci_add_children+0x10e
 acpi_pci_attach() at acpi_pci_attach+0xcd
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 acpi_pcib_attach() at acpi_pcib_attach+0x20e
 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x280
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 acpi_attach() at acpi_attach+0xaa6
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 nexus_acpi_attach() at nexus_acpi_attach+0x69
 device_attach() at device_attach+0x69
 bus_generic_new_pass() at bus_generic_new_pass+0xd6
 bus_set_pass() at bus_set_pass+0x7a
 configure() at configure+0xa
 mi_startup() at mi_startup+0x59
 btext() at btext+0x2c
 
 --HPS


-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Hans Petter Selasky]

On Wednesday 20 October 2010 08:55:09 Andriy Gapon wrote:
 on 20/10/2010 09:34 Hans Petter Selasky said the following:
  On Tuesday 19 October 2010 07:47:02 Lin Ming wrote:
  On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
  On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
  Can you send us the acpidump for the machine?
  
  Also, tell us which control method is failing.
  
  Thanks
  
  Hi,
  
  Please find attached dump of ACPI tables.
  
  It is the function AcpiRsCreateAmlResources() which writes beyond the
  buffer it allocates.
  
  Could you enable AML debug output to get more info?
  But I don't know how to enable it on FreeBSD.
  
  In Linux, the AML debug output is enabled with kernel boot parameters
  like below.
  acpi.debug_layer=0x acpi.debug_level=0x
  
  FreeBSD may have some similar boot parameters.
  
  I've enabled the debug prints just around the failing function. Here is
  the result:
  
  pcib0: ACPI Host-PCI bridge on acpi0
  pci0: ACPI PCI bus on pcib0
  pci_link32: Enter debugger
  
   Context Switch from TID 0x to TID 0x186a0 
  
rscalc-0293 [0x186a0] [188762] RsGetAmlLength: Entry
rscalc-0369 [0x186a0] [188762] RsGetAmlLength: Exit- AE_OK
rslist-0225 [0x186a0] [188762] RsConvertResourcesToAm: Entry
rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
rsmisc-0437 [0x186a0] [188763] RsConvertResourceToAml: Entry
rsmisc-0636 [0x186a0] [188763] RsConvertResourceToAml: Exit- AE_OK
rslist-0273 [0x186a0] [188762] RsConvertResourcesToAm: Exit- AE_OK
  
  rscreate-0554 [0x186a0] [188761] RsCreateAmlResources  : OutputBuffer
  0xff00031f9000 Length D
  Dirty free 0xff00031f9000 13 at 13
  KDB: stack backtrace:
  db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
  AcpiOsFree() at AcpiOsFree+0x72
  AcpiUtDeleteInternalObj() at AcpiUtDeleteInternalObj+0x335
  AcpiUtUpdateRefCount() at AcpiUtUpdateRefCount+0x188
  AcpiUtUpdateObjectReference() at AcpiUtUpdateObjectReference+0x6e
  AcpiUtRemoveReference() at AcpiUtRemoveReference+0xd5
  AcpiRsSetSrsMethodData() at AcpiRsSetSrsMethodData+0x14b
  AcpiSetCurrentResources() at AcpiSetCurrentResources+0xb8
  acpi_pci_link_route_irqs() at acpi_pci_link_route_irqs+0x204
 
 Can you please check which branch is executed here?
 if (sc-pl_crs_bad)
 status = acpi_pci_link_srs_from_links(sc, srsbuf);
 else
 status = acpi_pci_link_srs_from_crs(sc, srsbuf);

The not bad case.

--HPS
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Hans Petter Selasky]

On Wednesday 20 October 2010 08:36:31 Lin Ming wrote:
 On Wed, 2010-10-20 at 14:34 +0800, Hans Petter Selasky wrote:
  On Tuesday 19 October 2010 07:47:02 Lin Ming wrote:
   On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
 Can you send us the acpidump for the machine?
 
 Also, tell us which control method is failing.
 
 Thanks

Hi,

Please find attached dump of ACPI tables.

It is the function AcpiRsCreateAmlResources() which writes beyond the
buffer it allocates.
   
   Could you enable AML debug output to get more info?
   But I don't know how to enable it on FreeBSD.
   
   In Linux, the AML debug output is enabled with kernel boot parameters
   like below.
   acpi.debug_layer=0x acpi.debug_level=0x
   
   FreeBSD may have some similar boot parameters.
  
  I've enabled the debug prints just around the failing function. Here is
  the
 
  result:
 What's the kernel parameters are you using?
 There should be a lot of AML debug output.


Hi,

During the function call that overwrites it's buffer, there are no more debug 
prints than shown in the code, even with all debug prints on. Where should I 
add more debug prints?

--HPS
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 20/10/2010 11:06 Hans Petter Selasky said the following:
 During the function call that overwrites it's buffer, there are no more debug 
 prints than shown in the code, even with all debug prints on. Where should I 
 add more debug prints?

Maybe there are some useful messages right before the call?

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Lin Ming]

On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote:
 On Monday 18 October 2010 02:01:09 Moore, Robert wrote:
  Can you send us the acpidump for the machine?
  
  Also, tell us which control method is failing.
  
  Thanks
 
 Hi,
 
 Please find attached dump of ACPI tables.
 
 It is the function AcpiRsCreateAmlResources() which writes beyond the buffer 
 it allocates.

Could you enable AML debug output to get more info?
But I don't know how to enable it on FreeBSD.

In Linux, the AML debug output is enabled with kernel boot parameters
like below.
acpi.debug_layer=0x acpi.debug_level=0x

FreeBSD may have some similar boot parameters.

Lin Ming

 
 --HPS


___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Hans Petter Selasky]

Hi,

Some more debugging reveals that:

The Resource type is 15, which is:

ACPI_RSCONVERT_INFO AcpiRsConvertExtIrq[9] =

And that it fails on:

ACPI_RSC_SOURCEX

That means it writes beyond the 11 bytes reserved for this element!

During sub-routines of AcpiRsCreateAmlResources().

--HPS


On Sunday 17 October 2010 10:56:12 Hans Petter Selasky wrote:
 Hi,
 
 After debugging for some time now I've found the issue.
 
 1) I extended all allocations from ACPI to PAGE_SIZE.
 2) Then I filled the extra area with zero.
 3) Then at free I checked if some buffers were overwritten, and indeed I
 got bingo this time. The printout has the format:
 
 printf(Dirty free allocation length first overwritten byte offset\n);
 kdb_backtrace();
 
 Is this enough information for you to make a patch?
 
 unknown: I/O range not supported 0xff00024c1000 0xcf8 0xcff
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 acpi_parse_resources() at acpi_parse_resources+0x287
 acpi_probe_child() at acpi_probe_child+0x1b4
 AcpiNsWalkNamespace() at AcpiNsWalkNamespace+0x163
 AcpiWalkNamespace() at AcpiWalkNamespace+0xbf
 acpi_attach() at acpi_attach+0x8fa
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 nexus_acpi_attach() at nexus_acpi_attach+0x69
 device_attach() at device_attach+0x69
 bus_generic_new_pass() at bus_generic_new_pass+0xd6
 bus_set_pass() at bus_set_pass+0x7a
 configure() at configure+0xa
 mi_startup() at mi_startup+0x59
 btext() at btext+0x2c
 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on
 acpi0
 Timecounter HPET frequency 2500 Hz quality 900
 hpet0: [FILTER]
 Event timer HPET frequency 2500 Hz quality 450
 Event timer HPET1 frequency 2500 Hz quality 440
 Event timer HPET2 frequency 2500 Hz quality 440
 Event timer HPET3 frequency 2500 Hz quality 440
 Timecounter ACPI-safe frequency 3579545 Hz quality 850
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 acpi_acad0: AC Adapter on acpi0
 acpi_lid0: Control Method Lid Switch on acpi0
 acpi_lid0: enable wake failed
 acpi_button0: Power Button on acpi0
 acpi_button1: Sleep Button on acpi0
 pcib0: ACPI Host-PCI bridge on acpi0
 pci0: ACPI PCI bus on pcib0
 Dirty free 13 at 13
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 AcpiOsFree() at AcpiOsFree+0x7a
 AcpiUtDeleteInternalObj() at AcpiUtDeleteInternalObj+0x77
 AcpiUtUpdateRefCount() at AcpiUtUpdateRefCount+0xb4
 AcpiUtUpdateObjectReference() at AcpiUtUpdateObjectReference+0x45
 AcpiRsSetSrsMethodData() at AcpiRsSetSrsMethodData+0xf2
 AcpiSetCurrentResources() at AcpiSetCurrentResources+0x49
 acpi_pci_link_route_irqs() at acpi_pci_link_route_irqs+0x204
 acpi_pci_link_route_interrupt() at acpi_pci_link_route_interrupt+0x1a9
 acpi_pcib_route_interrupt() at acpi_pcib_route_interrupt+0x40d
 pci_assign_interrupt() at pci_assign_interrupt+0x1c3
 pci_add_resources() at pci_add_resources+0x14a
 pci_add_children() at pci_add_children+0x10e
 acpi_pci_attach() at acpi_pci_attach+0xcd
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 acpi_pcib_attach() at acpi_pcib_attach+0x1a7
 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x1fd
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 acpi_attach() at acpi_attach+0xa28
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 nexus_acpi_attach() at nexus_acpi_attach+0x69
 device_attach() at device_attach+0x69
 bus_generic_new_pass() at bus_generic_new_pass+0xd6
 bus_set_pass() at bus_set_pass+0x7a
 configure() at configure+0xa
 mi_startup() at mi_startup+0x59
 btext() at btext+0x2c
 pci_link32: Enter debugger
 pci_link43: Enter debugger
 Dirty free 13 at 13
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 AcpiOsFree() at AcpiOsFree+0x7a
 AcpiUtDeleteInternalObj() at AcpiUtDeleteInternalObj+0x77
 AcpiUtUpdateRefCount() at AcpiUtUpdateRefCount+0xb4
 AcpiUtUpdateObjectReference() at AcpiUtUpdateObjectReference+0x45
 AcpiRsSetSrsMethodData() at AcpiRsSetSrsMethodData+0xf2
 AcpiSetCurrentResources() at AcpiSetCurrentResources+0x49
 acpi_pci_link_route_irqs() at acpi_pci_link_route_irqs+0x204
 acpi_pci_link_route_interrupt() at acpi_pci_link_route_interrupt+0x1a9
 acpi_pcib_route_interrupt() at acpi_pcib_route_interrupt+0x40d
 pci_assign_interrupt() at pci_assign_interrupt+0x1c3
 pci_add_resources() at pci_add_resources+0x14a
 pci_add_children() at pci_add_children+0x10e
 acpi_pci_attach() at acpi_pci_attach+0xcd
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 acpi_pcib_attach() at acpi_pcib_attach+0x1a7
 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x1fd
 device_attach() at device_attach+0x69
 bus_generic_attach() at bus_generic_attach+0x1a
 acpi_attach() at acpi_attach+0xa28
 device_attach() at 

RE: MacBookPro 5,1

[Moore, Robert]

Can you send us the acpidump for the machine?

Also, tell us which control method is failing.

Thanks


-Original Message-
From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
a...@freebsd.org] On Behalf Of Hans Petter Selasky
Sent: Sunday, October 17, 2010 6:48 AM
To: freebsd-acpi@freebsd.org
Cc: linux-a...@vger.kernel.org
Subject: Re: MacBookPro 5,1

Hi,

CC'ing the Linux guys, hence I belive you are using the same ACPI code like
in
FreeBSD.

It appears that when a string is present in the extended interrupt
descriptor
(6.4.3.6, ACPIspec30.pdf), then this is not handled correctly, meaning that
the precomputed buffer space when encoding to AML, is incorrect and that
data
is written beyond the destination buffer!

The error is catched on a MacBookPro 5,1 and is visible if you zero-pad all
ACPI allocations to 4096 bytes, and verify that the freed buffer is not
written beyond the allocation. Also the Extended interrupt descriptor must
be
the last element encoded in the AML.

The quick patch is to disable these elements. I tried to figure out why
this
happens, but this particular handling in the code looks very obfuscated to
me.

src/sys/contrib/dev/acpica
%svk diff
=== resources/rsmisc.c
==
--- resources/rsmisc.c  (revision 213698)
+++ resources/rsmisc.c  (local)
@@ -311,6 +311,8 @@


 case ACPI_RSC_SOURCEX:
+   break;  /* RSC_SOURCEX is broken */
+
 /*
  * Optional ResourceSource (Index and String). This is the
more
  * complicated case used by the Interrupt() macro
@@ -537,6 +539,8 @@


 case ACPI_RSC_SOURCEX:
+   break;  /* RSC_SOURCEX is broken */
+
 /*
  * Optional ResourceSource (Index and String)
  */


Any comments are welcome!

--HPS

Please keep me CC'ed.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 13/10/2010 16:14 Hans Petter Selasky said the following:
 On Tuesday 12 October 2010 22:43:46 Andriy Gapon wrote:
 on 12/10/2010 15:25 Hans Petter Selasky said the following:
 On Tuesday 12 October 2010 13:15:26 Andriy Gapon wrote:
 on 12/10/2010 13:09 Hans Petter Selasky said the following:
 Hi,

 My MacBookPro 5,1 does not boot using -current because memory inside
 the ACPI kernel module is used after free.

 The following patch temporily mitigates the problem:

 /usr/src/sys/dev/acpica/Osd/OsdMemory.c

 void
 AcpiOsFree(void *Memory)
 {
 + if (cold == 0)

 free(Memory, M_ACPICA);

 }

 Is there any way to debug this from user-land?

 I think that the best way is to get a backtrace at least or better a
 crashdump.

 The crashdump is not helpful. It crashes at init time, while the actual
 free happens very early during boot.

 Still a backtrace would be useful, I think.

So no backtrace yet? :-)

 Or track all calls to AcpiOsFree, e.g. using DTrace or stack(9) or etc.
 
 Do you have any hints how a shall configure DTrace to trace AcpiOsFree() ?

You set up DTrace using general procedure:
http://wiki.freebsd.org/DTrace

The you can write a little DTrace script to trace calls to AcpiOsFree (and
perhaps/probably AcpiOsAllocate) using fbt provider:
http://wikis.sun.com/display/DTrace/fbt+Provider

Sorry, EBUSY to write a complete script right now.
You might find DTrace function stack() and aggregations useful.

Things are bit trickier if the crash happens before you have a chance to do
anything in userland.
-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Jung-uk Kim]

On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote:
 Hi,

 My MacBookPro 5,1 does not boot using -current because memory
 inside the ACPI kernel module is used after free.

 The following patch temporily mitigates the problem:

 /usr/src/sys/dev/acpica/Osd/OsdMemory.c

 void
 AcpiOsFree(void *Memory)
 {
 + if (cold == 0)
 free(Memory, M_ACPICA);
 }

 Is there any way to debug this from user-land?

acpidb(8).  However, it is quite broken ATM. :-(

Alternatively, you may use acpiexec from ACPICA:

fetch http://www.acpica.org/download/acpica-unix-20101013.tar.gz
tar xpf acpica-unix-20101013.tar.gz
cd acpica-unix-20101013/tools/acpiexec
gmake
./acpiexec

Actually you need to extract ACPI tables from your BIOS (or UEFI in
your case) to use with acpiexec.  acpidump(8) gives you what you want
BUT you cannot use it with acpiexec directly.  You need to dump/extract
tables using Linux pmtools:

fetch 
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20100825.tar.bz2
fetch http://people.freebsd.org/~jkim/pmtools-20100825.diff
tar xpf pmtools-20100825.tar.bz2
cd pmtools
patch  ../pmtools-20100825.diff
gmake
sudo acpidump/acpidump -o ACPI.dat
acpixtract/acpixtract -a ACPI.dat

Note the pmtools patch is really a hack but it should work. ;-)

Good luck,

Jung-uk Kim

* PS: If anyone has enough free time, please fix acpidb.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

MacBookPro 5,1

[Hans Petter Selasky]

Hi,

My MacBookPro 5,1 does not boot using -current because memory inside the ACPI 
kernel module is used after free.

The following patch temporily mitigates the problem:

/usr/src/sys/dev/acpica/Osd/OsdMemory.c

void
AcpiOsFree(void *Memory)
{
+ if (cold == 0)
free(Memory, M_ACPICA);
}

Is there any way to debug this from user-land?

--HPS
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 12/10/2010 13:09 Hans Petter Selasky said the following:
 Hi,
 
 My MacBookPro 5,1 does not boot using -current because memory inside the ACPI 
 kernel module is used after free.
 
 The following patch temporily mitigates the problem:
 
 /usr/src/sys/dev/acpica/Osd/OsdMemory.c
 
 void
 AcpiOsFree(void *Memory)
 {
 + if (cold == 0)
 free(Memory, M_ACPICA);
 }
 
 Is there any way to debug this from user-land?

I think that the best way is to get a backtrace at least or better a crashdump.

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: MacBookPro 5,1

[Andriy Gapon]

on 12/10/2010 15:25 Hans Petter Selasky said the following:
 On Tuesday 12 October 2010 13:15:26 Andriy Gapon wrote:
 on 12/10/2010 13:09 Hans Petter Selasky said the following:
 Hi,

 My MacBookPro 5,1 does not boot using -current because memory inside the
 ACPI kernel module is used after free.

 The following patch temporily mitigates the problem:

 /usr/src/sys/dev/acpica/Osd/OsdMemory.c

 void
 AcpiOsFree(void *Memory)
 {
 + if (cold == 0)

 free(Memory, M_ACPICA);

 }

 Is there any way to debug this from user-land?

 I think that the best way is to get a backtrace at least or better a
 crashdump.
 
 The crashdump is not helpful. It crashes at init time, while the actual free 
 happens very early during boot.

Still a backtrace would be useful, I think.
Or track all calls to AcpiOsFree, e.g. using DTrace or stack(9) or etc.

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org