Hello list,

Here is the feedback from HP's Desktop team:
    We could not reproduce this issue on the dc7800 using the 1.28 BIOS. We 
downloaded the q35_sinit_17.bin SINIT from    
    http://sourceforge.net/projects/tboot/files website.
    We have seen the case where the TPM gets in a unknown state occasionally 
and will cause an issue. Ask them to go into the BIOS F10 Setup menu and 
    perform a Reset to the TPM and try it again to see if this resolves there 
issue. 
    Thank you.
    Best Regards,
    Dalvis Desselle 

Hi Jon, 
I have started to look into the issue you have mentioned on 8530p(F.0C), will 
let you know the status once I have an update. 

Thanks
Karthik

-----Original Message-----
From: Jonathan M. McCune [mailto:jonmcc...@cmu.edu] 
Sent: Monday, August 03, 2009 12:10 PM
To: Martin Thiim
Cc: Hal Finney; tboot-devel@lists.sourceforge.net; Tondapu, Karthik
Subject: GETSEC[SENTER] fail on HP 8530p

Hello list, cc Karthik,

I have recently upgraded the BIOS on an HP 8530p laptop (to version F.0C), and 
am experiencing what sound like extremely similar SENTER failures to those Hal 
is getting on his dc7800.  I cannot do a regression test, however, as the 
previous BIOS version did not support SENTER at all on this system.  This 
laptop does not have a serial port, so all I can capture is the in-memory log 
from the system following SENTER-inspired reboot (see attached).

The error code in the log decodes to "BARs in VT-d DMAR DRHD struct mismatch".

Note that I believe Hal's dc7800 has a Q35 Express chipset, and this laptop has 
"Mobile Intel PM45 Express Chipset ICH9M-Enhanced." 
Interesting that the possibly similar / related failures are across different 
chipsets.

In following along with attempting to debug Hal's system, I decided to go ahead 
and disable Audio and USB Legacy Support in BIOS, and to attach the output of 
`lspci -v` and Ross's dmardump.

I've copied Karthik from HP as he has previously been very helpful in 
determining that there were issues with SENTER and the previous BIOS version 
for this laptop.

I'm happy to execute additional tests to help track down the cause of these 
problems.

Thanks to all for their time and suggestions, -Jon



Martin Thiim wrote:
> Hi
> 
> Great. However, I'm still curious about what caused it to fail. I hope 
> in the future more info will be released on what SINIT actually does.
> 
> As my last posts indicated, it probably isn't/wasn't an inconsistency 
> in the tables themselves, but rather an inconsistency with the tables 
> and something outside the tables, such as either the PCI device BAR 
> registers, or perhaps the register base of the DMA units that are off 
> (i.e. maybe these registers don't actually point to a DMA unit).
> 
> Best regards,
> 
> Martin Thiim
> 
> On Sat, Aug 1, 2009 at 8:40 AM, Hal Finney<hal.fin...@gmail.com> wrote:
>> As an update, I successfully rolled back my BIOS to an earlier 
>> version. With this change, tboot works again! GETSEC[SENTER] executes 
>> with no errors and I get into the secure state. So it is definitely 
>> some problem relating to the new BIOS.
>>
>> Interestingly, I dumped the DMAR tables created by the working BIOS 
>> and they are byte for byte identical to what they were with the 
>> non-working BIOS. So clearly there is no point in going over those 
>> tables with a fine tooth comb to figure out what SINIT doesn't like 
>> about them. Something else must be different. I'd say the SINIT error 
>> codes are not particularly informative about what is going wrong in 
>> this case.
>>
>> I hope the SINIT team will still look into this. I can easily go back 
>> to the newer BIOS in order to reproduce the failing state. The new 
>> BIOS has the advantage that I can reboot after an SINIT failure and 
>> read the errorcode register. With the old BIOS, attempts to reboot 
>> hang in the BIOS and it's not possible to read the errorcodes, which 
>> made debugging TXT almost impossible.
>>
>> So I can either use the new BIOS which would allow some debugging but 
>> which unfortunately doesn't work with SINIT; or I can use the old 
>> BIOS which works with SINIT but reveals nothing when there is a failure.
>> Neither is a great alternative.
>>
>> Hal Finney
>>
> 
> ----------------------------------------------------------------------
> -------- Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008 30-Day trial. Simplify your report design, integration 
> and deployment - and focus on what you do best, core application 
> coding. Discover what's new with Crystal Reports now.  
> http://p.sf.net/sfu/bobj-july 
> _______________________________________________
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Reply via email to