On Thu, Jul 22, 2010 at 9:28 PM, Cihula, Joseph wrote:
> The possible culprits for a change in behavior could be: "significant"
> memory change (e.g. <4GB to >4GB, PCI/PCIe devices added/removed, internal
> devices enabled/disabled (e.g. Azalia, ME). You could also try resetting the
> BIOS to
> From: Jonathan McCune [mailto:jonmcc...@cmu.edu]
> Sent: Thursday, July 22, 2010 4:01 PM
>
> Well, I tried lots of BIOS versions. v1.24 gives me a Microcode Error
> 1801 (unrelated to TXT) and runs the fans at full speed, so I didn't
> get very far with it. v1.26 hangs with the BIOS screen dis
Well, I tried lots of BIOS versions. v1.24 gives me a Microcode Error
1801 (unrelated to TXT) and runs the fans at full speed, so I didn't
get very far with it. v1.26 hangs with the BIOS screen displayed
after rebooting immediately upon executing SENTER (again sounds
consistent with what Hal was
Hi Hal, Martin, list,
Any progress on this front? I've just run into this same issue (error
codes 0xC00020A1 or 0xC00018A1 depending on whether USB/floppy/1394
are enabled -- suspect USB is what's meaningful but haven't dissected
it) on a dc7800 with tboot-20100427 (w/ Q35 SINIT modules v18, 17,a
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
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 wor
Hi
Sounds like some interesting tests. I wonder if the BIOS could have
locked the memory somehow after it is initialized - should be easy to
test :)
I agree that the "Register Base Address" in the DRHD is the register
base for the DMA hardware itself. Hence it wouldn't equal the BAR
reported by P
Hi Martin, thanks for those links. I've attached the output of lspci
-v when my system is booted with USB disabled. Here is an excerpt, the
only ones that have addresses listed:
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express
Integrated Graphics Controller (rev 02)
Subsy
Hello Hal
For a bit more on the PCI BAR, see this:
http://docs.sun.com/app/docs/doc/819-3196/6n5ed4hmv?a=view
Every PCI device has these registers that give the base address/range
of its registers. It seems these ranges don't match those in DMAR. It
makes sense SINIT would/could check this.
Bes
>From Googling, it seems BAR is a general PCI concept. The VT-d spec
mentions it in "8.3.6 Implications with Provisioning PCI BAR
Resources" (just next to the DRHD section) but doesn't give an obvious
clue to this error message (seems to be more of a recommendation).
Could it be that the register
I did another experiment, disabling USB and also audio in BIOS, and
trying tboot. It hung again in GETSEC[SENTER] as before. Upon
restarting it, it dumped the error code register, which was different
this time: Progress 0ah, error 6. That is:
"BARs in VT-d DMAR DRHD struct mismatch"
I am attachin
@thiim.net]
Sent: Friday, July 31, 2009 9:21 AM
To: Ross Philipson
Cc: Hal Finney; tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
Hello Ross
Right, I had not noticed the utility operated at the ACPI-level; I
only jumped into the thread when I
; Thanks
> Ross
>
> -Original Message-
> From: Martin Thiim [mailto:mar...@thiim.net]
> Sent: Thursday, July 30, 2009 4:07 PM
> To: Hal Finney
> Cc: tboot-devel@lists.sourceforge.net
> Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
>
> Hello Hal
>
Hal
My fault, since you have no chance to run into Xen or kernel.
I suspect it is the BIOS issue.
I am not sure whether it is convenient for you to downgrade the BIOS and
have a try.
Shane
Hal Finney wrote:
> Hi Shane - I'm not sure what it would do to add these switches, since
> tboot doesn't
I just want to confirm you don't have Azalia, because Azalia in some old
bios will enable the Isochronous VT-d table, which causes SINIT fails.
Forget this.
Shane
Hal Finney wrote:
> (Forgot to respond to this last part):
>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>
> I'm afraid
ith
> it). Hal attached the trace in an earlier reply.
>
> Thanks
> Ross
>
> -Original Message-
> From: Martin Thiim [mailto:mar...@thiim.net]
> Sent: Thursday, July 30, 2009 4:07 PM
> To: Hal Finney
> Cc: tboot-devel@lists.sourceforge.net
> Subject: Re: [tboot-dev
-Original Message-
From: Martin Thiim [mailto:mar...@thiim.net]
Sent: Thursday, July 30, 2009 4:07 PM
To: Hal Finney
Cc: tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
Hello Hal
I could be wrong, but I think what the "Enable VT-d"
Hello Hal
I could be wrong, but I think what the "Enable VT-d" option in the
BIOS really refers to is whether the BIOS should set up the ACPI
tables related to VT-d.
You could use acpidump to see if those tables contain anything VT-d
related (DMAR and the like) - the VT-d spec would be helpful fo
(Forgot to respond to this last part):
> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
I'm afraid these terms mean nothing to me. Azalia is something about
HD Audio? I don't know what that has to do with VT-d. Googling for
lsoc with VT-d or with Intel finds nothing relevant. And WA could
Hi Shane - I'm not sure what it would do to add these switches, since
tboot doesn't get as far as launching the kernel, since it hangs in
SENTER. However I can try doing it and then just booting into the
kernel, in case I get any error reports about VT-d.
Are there any MSRs or other registers I ca
Hal,
If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command
line (i.e. the end of "module /boot/xen.gz ...")
If you work with Linux, please try to add "iommu=on" in the command
line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
PS: do you know which platform HP dc7800 is? *F
Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
BIOS automatically enables VT-d when TXT is enabled.
I don't know of anything I would do in any grub configuration file to
enable VT-d for tboot and SINIT. Do you have any suggestions?
Hal
On Wed, Jul 29, 2009 at 10:04 PM, Sh
Hi Hal
The error code means VTd is disabled.
Is your VT-d enabled in your new BIOS and grub.conf?
Thanks.
Shane
Hal Finney wrote:
> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
> finding it hangs in GETSEC[SENTER]. This is even true with old
> versions of tboot that used
Finney [mailto:hal.fin...@gmail.com]
Sent: Wednesday, July 29, 2009 12:36 PM
To: Ross Philipson
Cc: tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
Hi Ross, thanks very much for that. I have attached the output from my dc7800.
Hal
On Wed, Jul 29, 2009 at
Hi Ross, thanks very much for that. I have attached the output from my dc7800.
Hal
On Wed, Jul 29, 2009 at 7:40 AM, Ross
Philipson wrote:
> Hal,
>
> I attached a little utility I wrote to dump the DMAR tables from ACPI. If you
> run it and post the output it might show what TXT thinks is wrong w
Hal,
I attached a little utility I wrote to dump the DMAR tables from ACPI. If you
run it and post the output it might show what TXT thinks is wrong with DMAR.
You will have to build and run it on linux.
Thanks
Ross
-Original Message-
From: Hal Finney [mailto:hal.fin...@gmail.com]
Sen
26 matches
Mail list logo
