From: Hal F. <hal...@gm...> - 2009-07-28 23:32:47
Attachments:
tbootfail1.log
|
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 to work. My system has no USB ports plugged in, and no hardware changes. The one change is I recently updated my BIOS. I suspect this has to be the cause. One nice thing about the new BIOS is that the tboot hang actually reboots the machine with the ERRORCODE register intact. Its value is c00020a1. This is progress code 0ah, error code 1000, meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear what this means. My log is attached, including the hang and the relaunch of tboot. This is version 20090330 of tboot. Thanks very much - Hal Finney |
From: Ross P. <Ros...@ci...> - 2009-07-29 14:40:14
Attachments:
dmardump.tgz
|
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...@gm...] Sent: Tuesday, July 28, 2009 7:33 PM To: tbo...@li... Subject: [tboot-devel] GETSEC[SENTER] fail on HP dc7800 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 to work. My system has no USB ports plugged in, and no hardware changes. The one change is I recently updated my BIOS. I suspect this has to be the cause. One nice thing about the new BIOS is that the tboot hang actually reboots the machine with the ERRORCODE register intact. Its value is c00020a1. This is progress code 0ah, error code 1000, meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear what this means. My log is attached, including the hang and the relaunch of tboot. This is version 20090330 of tboot. Thanks very much - Hal Finney |
From: Hal F. <hal...@gm...> - 2009-07-29 16:36:29
Attachments:
dmardump_dc7800.txt
|
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<Ros...@ci...> 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 with DMAR. You will have to build and run it on linux. > > Thanks > Ross > > -----Original Message----- > From: Hal Finney [mailto:hal...@gm...] > Sent: Tuesday, July 28, 2009 7:33 PM > To: tbo...@li... > Subject: [tboot-devel] GETSEC[SENTER] fail on HP dc7800 > > 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 to work. My system has no USB ports plugged in, and no hardware changes. > > The one change is I recently updated my BIOS. I suspect this has to be the cause. One nice thing about the new BIOS is that the tboot hang actually reboots the machine with the ERRORCODE register intact. Its value is c00020a1. This is progress code 0ah, error code 1000, > meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear what this means. > > My log is attached, including the hang and the relaunch of tboot. This is version 20090330 of tboot. Thanks very much - > > Hal Finney > |
From: Ross P. <Ros...@ci...> - 2009-07-29 18:52:44
|
Hmm, nothing jumps out at me as to what is not correct. I guess that is a Intel Q35 (or similar) desktop system you have. The DHRD tables look like the ones I would expect from what I have seen with other Intel chipsets. The RMRR values also look reasonable for the iGfx and USB devices. The last time someone reported a similar problem on one of the lists it turned out their BIOS was missing the DHRD with the INCLUDE_ALL flag set but this looks OK in your case. Maybe someone else on the list might see something amiss with the DMAR. Thanks Ross -----Original Message----- From: Hal Finney [mailto:hal...@gm...] Sent: Wednesday, July 29, 2009 12:36 PM To: Ross Philipson Cc: tbo...@li... 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 7:40 AM, Ross Philipson<Ros...@ci...> 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 with DMAR. You will have to build and run it on linux. > > Thanks > Ross > > -----Original Message----- > From: Hal Finney [mailto:hal...@gm...] > Sent: Tuesday, July 28, 2009 7:33 PM > To: tbo...@li... > Subject: [tboot-devel] GETSEC[SENTER] fail on HP dc7800 > > 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 to work. My system has no USB ports plugged in, and no hardware changes. > > The one change is I recently updated my BIOS. I suspect this has to be the cause. One nice thing about the new BIOS is that the tboot hang actually reboots the machine with the ERRORCODE register intact. Its value is c00020a1. This is progress code 0ah, error code 1000, > meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear what this means. > > My log is attached, including the hang and the relaunch of tboot. This is version 20090330 of tboot. Thanks very much - > > Hal Finney > |
From: Shane W. <sha...@in...> - 2009-07-30 05:04:24
|
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 to work. My system has no USB ports > plugged in, and no hardware changes. > > The one change is I recently updated my BIOS. I suspect this has to be > the cause. One nice thing about the new BIOS is that the tboot hang > actually reboots the machine with the ERRORCODE register intact. Its > value is c00020a1. This is progress code 0ah, error code 1000, > meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear > what this means. > > My log is attached, including the hang and the relaunch of tboot. This > is version 20090330 of tboot. Thanks very much - > > Hal Finney |
From: Hal F. <hal...@gm...> - 2009-07-30 06:39:32
|
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, Shane Wang<sha...@in...> wrote: > 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 to work. My system has no USB ports >> plugged in, and no hardware changes. >> >> The one change is I recently updated my BIOS. I suspect this has to be >> the cause. One nice thing about the new BIOS is that the tboot hang >> actually reboots the machine with the ERRORCODE register intact. Its >> value is c00020a1. This is progress code 0ah, error code 1000, >> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >> what this means. >> >> My log is attached, including the hang and the relaunch of tboot. This >> is version 20090330 of tboot. Thanks very much - >> >> Hal Finney > > |
From: Shane W. <sha...@in...> - 2009-07-30 07:24:25
|
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? *Field or *Dale? Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? Thanks. Shane Hal Finney wrote: > 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, Shane Wang<sha...@in...> wrote: >> 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 to work. My system has no USB ports >>> plugged in, and no hardware changes. >>> >>> The one change is I recently updated my BIOS. I suspect this has to be >>> the cause. One nice thing about the new BIOS is that the tboot hang >>> actually reboots the machine with the ERRORCODE register intact. Its >>> value is c00020a1. This is progress code 0ah, error code 1000, >>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>> what this means. >>> >>> My log is attached, including the hang and the relaunch of tboot. This >>> is version 20090330 of tboot. Thanks very much - >>> >>> Hal Finney >> |
From: Hal F. <hal...@gm...> - 2009-07-30 17:29:00
|
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 can patch tboot to dump out, to indicate whether VT-d is turned on? My HP dc7800 was one of the very first commercially released systems to support TXT. I bought one as soon as they became available in order to experiment with this technology. It has an E6550 "Conroe" processor with a Q35 "Bearlake" chipset. Hal On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: > 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? *Field or *Dale? > Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? > > Thanks. > Shane > > Hal Finney wrote: >> >> 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, Shane Wang<sha...@in...> wrote: >>> >>> 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 to work. My system has no USB ports >>>> plugged in, and no hardware changes. >>>> >>>> The one change is I recently updated my BIOS. I suspect this has to be >>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>> actually reboots the machine with the ERRORCODE register intact. Its >>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>> what this means. >>>> >>>> My log is attached, including the hang and the relaunch of tboot. This >>>> is version 20090330 of tboot. Thanks very much - >>>> >>>> Hal Finney >>> > > |
From: Martin T. <ma...@th...> - 2009-07-30 20:30:09
|
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 for this. http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf I currently don't have access to my VT-d system so I can't give you a table of what it looks like on my machine but perhaps others could. Best regards, Martin Thiim On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote: > 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 can patch tboot to dump out, > to indicate whether VT-d is turned on? > > My HP dc7800 was one of the very first commercially released systems > to support TXT. I bought one as soon as they became available in order > to experiment with this technology. It has an E6550 "Conroe" processor > with a Q35 "Bearlake" chipset. > > Hal > > On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >> 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? *Field or *Dale? >> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >> >> Thanks. >> Shane >> >> Hal Finney wrote: >>> >>> 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, Shane Wang<sha...@in...> wrote: >>>> >>>> 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 to work. My system has no USB ports >>>>> plugged in, and no hardware changes. >>>>> >>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>> what this means. >>>>> >>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>> is version 20090330 of tboot. Thanks very much - >>>>> >>>>> 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 > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Martin T. <ma...@th...> - 2009-07-31 19:18:11
|
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. Best regards, Martin Thiim On Thu, Jul 30, 2009 at 10:07 PM, Martin Thiim<ma...@th...> wrote: > 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 for this. > > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf > > I currently don't have access to my VT-d system so I can't give you a > table of what it looks like on my machine but perhaps others could. > > Best regards, > > Martin Thiim > > On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote: >> 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 can patch tboot to dump out, >> to indicate whether VT-d is turned on? >> >> My HP dc7800 was one of the very first commercially released systems >> to support TXT. I bought one as soon as they became available in order >> to experiment with this technology. It has an E6550 "Conroe" processor >> with a Q35 "Bearlake" chipset. >> >> Hal >> >> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >>> 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? *Field or *Dale? >>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >>> >>> Thanks. >>> Shane >>> >>> Hal Finney wrote: >>>> >>>> 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, Shane Wang<sha...@in...> wrote: >>>>> >>>>> 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 to work. My system has no USB ports >>>>>> plugged in, and no hardware changes. >>>>>> >>>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>>> what this means. >>>>>> >>>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>>> is version 20090330 of tboot. Thanks very much - >>>>>> >>>>>> 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 >> tbo...@li... >> https://lists.sourceforge.net/lists/listinfo/tboot-devel >> > |
From: Hal F. <hal...@gm...> - 2009-07-31 20:12:09
Attachments:
lspci_nousb.txt
|
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) Subsystem: Hewlett-Packard Company Device 2819 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f0100000 (32-bit, non-prefetchable) [size=512K] I/O ports at 1230 [size=8] Memory at e0000000 (32-bit, prefetchable) [size=256M] Memory at f0000000 (32-bit, non-prefetchable) [size=1M] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02) Subsystem: Hewlett-Packard Company Device 2818 Flags: bus master, fast devsel, latency 0, IRQ 221 Memory at f0180000 (32-bit, non-prefetchable) [size=128K] Memory at f01a1000 (32-bit, non-prefetchable) [size=4K] I/O ports at 1100 [size=32] Capabilities: [c8] Power Management version 2 Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ Capabilities: [e0] PCIe advanced features <?> Kernel driver in use: e1000e Kernel modules: e1000e Deviice 02.00 is the video controller. It has BARs at f0100000, e0000000, and f0000000. This device is listed in the DMAR table as having the DMA remapping registers at fed91000. It is also the device listed in the RMRR reserved memory table as having addresses 0x3e600000 - 0x3effffff. My interpretation is that the PCI BAR addresses are mapped to the card itself; the DMA remapping registers are on a different device, part of the bus controller or chipset; and the reserved memory region, 10 MB of system RAM, is the video display RAM. I don't see any problem with all these addresses being different. The only other device with a BAR in the lspci output is the ethernet controller at 19.00. It has BARs at f0180000 and f01a1000. The first one immediately follows the video controller BAR, but it is on a separate page boundary so is consistent with the advice in the VT-d spec about BARS not overlapping pages. The one odd element is that the DMAR table shows DMA remapping hardware #2 in a DRHD table, which covers PCI devices 03.00, 03.02, and 03.03. However, lspci does not show any PCI devices at 03.XX. So I don't know what devices those would be, if they exist. I don't know if there is any requirement that the DHRD entries refer to actually existing PCI devices. I wonder where the BIOS came up with these. One other big question I have is, where does SINIT get the DMAR table? Is it just looking at known addresses in RAM and parsing ACPI data? Would it be possible for TBOOT to patch the DMAR table in memory before launching SINIT, in order to see if SINIT liked it any better? I should try an experiment of changing the DMAR checksum, see if SINIT complains about that (it's an earlier error code so presumably is checked sooner). If so, I could take out all of the DRHD's and RMRR's and see if SINIT likes it any better. Hal On Fri, Jul 31, 2009 at 12:17 PM, Martin Thiim<ma...@th...> wrote: > 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. > > Best regards, > > Martin Thiim > > On Thu, Jul 30, 2009 at 10:07 PM, Martin Thiim<ma...@th...> wrote: >> 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 for this. >> >> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf >> >> I currently don't have access to my VT-d system so I can't give you a >> table of what it looks like on my machine but perhaps others could. >> >> Best regards, >> >> Martin Thiim >> >> On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote: >>> 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 can patch tboot to dump out, >>> to indicate whether VT-d is turned on? >>> >>> My HP dc7800 was one of the very first commercially released systems >>> to support TXT. I bought one as soon as they became available in order >>> to experiment with this technology. It has an E6550 "Conroe" processor >>> with a Q35 "Bearlake" chipset. >>> >>> Hal >>> >>> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >>>> 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? *Field or *Dale? >>>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >>>> >>>> Thanks. >>>> Shane >>>> >>>> Hal Finney wrote: >>>>> >>>>> 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, Shane Wang<sha...@in...> wrote: >>>>>> >>>>>> 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 to work. My system has no USB ports >>>>>>> plugged in, and no hardware changes. >>>>>>> >>>>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>>>> what this means. >>>>>>> >>>>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>>>> is version 20090330 of tboot. Thanks very much - >>>>>>> >>>>>>> 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 >>> tbo...@li... >>> https://lists.sourceforge.net/lists/listinfo/tboot-devel >>> >> > |
From: Martin T. <ma...@th...> - 2009-07-31 20:50:21
|
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 PCI devices themselves. But I would have expected more correlation for the RMRR's. You could also try to inspect some of the registers reported for the DMA units in DRHD (0xfed90000, 0xfed91000) etc. to see if it looks like there really sits DMA units there? Say the version or capability registers (offset 0x0 and 0x4, according to section 10.4). It could be such checks that make SINIT conclude that the BAR "mismatches". Wild alternatives to what BAR could refer to (VT-d spec): - Page 98: Register indicating Base Address of Interrupt Remapping Table. - Page 113: Register providing the Base Address of Root-entry table. Best regards, Martin Thiim On Fri, Jul 31, 2009 at 10:11 PM, Hal Finney<hal...@gm...> wrote: > 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) > Subsystem: Hewlett-Packard Company Device 2819 > Flags: bus master, fast devsel, latency 0, IRQ 16 > Memory at f0100000 (32-bit, non-prefetchable) [size=512K] > I/O ports at 1230 [size=8] > Memory at e0000000 (32-bit, prefetchable) [size=256M] > Memory at f0000000 (32-bit, non-prefetchable) [size=1M] > Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- > Capabilities: [d0] Power Management version 2 > > 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit > Network Connection (rev 02) > Subsystem: Hewlett-Packard Company Device 2818 > Flags: bus master, fast devsel, latency 0, IRQ 221 > Memory at f0180000 (32-bit, non-prefetchable) [size=128K] > Memory at f01a1000 (32-bit, non-prefetchable) [size=4K] > I/O ports at 1100 [size=32] > Capabilities: [c8] Power Management version 2 > Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ > Capabilities: [e0] PCIe advanced features <?> > Kernel driver in use: e1000e > Kernel modules: e1000e > > Deviice 02.00 is the video controller. It has BARs at f0100000, > e0000000, and f0000000. This device is listed in the DMAR table as > having the DMA remapping registers at fed91000. It is also the device > listed in the RMRR reserved memory table as having addresses > 0x3e600000 - 0x3effffff. My interpretation is that the PCI BAR > addresses are mapped to the card itself; the DMA remapping registers > are on a different device, part of the bus controller or chipset; and > the reserved memory region, 10 MB of system RAM, is the video display > RAM. I don't see any problem with all these addresses being different. > > The only other device with a BAR in the lspci output is the ethernet > controller at 19.00. It has BARs at f0180000 and f01a1000. The first > one immediately follows the video controller BAR, but it is on a > separate page boundary so is consistent with the advice in the VT-d > spec about BARS not overlapping pages. > > The one odd element is that the DMAR table shows DMA remapping > hardware #2 in a DRHD table, which covers PCI devices 03.00, 03.02, > and 03.03. However, lspci does not show any PCI devices at 03.XX. So I > don't know what devices those would be, if they exist. I don't know if > there is any requirement that the DHRD entries refer to actually > existing PCI devices. I wonder where the BIOS came up with these. > > One other big question I have is, where does SINIT get the DMAR table? > Is it just looking at known addresses in RAM and parsing ACPI data? > Would it be possible for TBOOT to patch the DMAR table in memory > before launching SINIT, in order to see if SINIT liked it any better? > I should try an experiment of changing the DMAR checksum, see if SINIT > complains about that (it's an earlier error code so presumably is > checked sooner). If so, I could take out all of the DRHD's and RMRR's > and see if SINIT likes it any better. > > Hal > > > On Fri, Jul 31, 2009 at 12:17 PM, Martin Thiim<ma...@th...> wrote: >> 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. >> >> Best regards, >> >> Martin Thiim >> >> On Thu, Jul 30, 2009 at 10:07 PM, Martin Thiim<ma...@th...> wrote: >>> 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 for this. >>> >>> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf >>> >>> I currently don't have access to my VT-d system so I can't give you a >>> table of what it looks like on my machine but perhaps others could. >>> >>> Best regards, >>> >>> Martin Thiim >>> >>> On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote: >>>> 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 can patch tboot to dump out, >>>> to indicate whether VT-d is turned on? >>>> >>>> My HP dc7800 was one of the very first commercially released systems >>>> to support TXT. I bought one as soon as they became available in order >>>> to experiment with this technology. It has an E6550 "Conroe" processor >>>> with a Q35 "Bearlake" chipset. >>>> >>>> Hal >>>> >>>> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >>>>> 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? *Field or *Dale? >>>>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >>>>> >>>>> Thanks. >>>>> Shane >>>>> >>>>> Hal Finney wrote: >>>>>> >>>>>> 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, Shane Wang<sha...@in...> wrote: >>>>>>> >>>>>>> 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 to work. My system has no USB ports >>>>>>>> plugged in, and no hardware changes. >>>>>>>> >>>>>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>>>>> what this means. >>>>>>>> >>>>>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>>>>> is version 20090330 of tboot. Thanks very much - >>>>>>>> >>>>>>>> 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 >>>> tbo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel >>>> >>> >> > |
From: Hal F. <hal...@gm...> - 2009-08-01 06:40:24
|
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 |
From: Martin T. <ma...@th...> - 2009-08-01 10:54:53
|
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...@gm...> 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 > |
From: Shane W. <sha...@in...> - 2009-07-31 06:29:54
|
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 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 can patch tboot to dump out, > to indicate whether VT-d is turned on? > > My HP dc7800 was one of the very first commercially released systems > to support TXT. I bought one as soon as they became available in order > to experiment with this technology. It has an E6550 "Conroe" processor > with a Q35 "Bearlake" chipset. > > Hal > > On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >> 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? *Field or *Dale? >> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >> >> Thanks. >> Shane >> >> Hal Finney wrote: >>> 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, Shane Wang<sha...@in...> wrote: >>>> 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 to work. My system has no USB ports >>>>> plugged in, and no hardware changes. >>>>> >>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>> what this means. >>>>> >>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>> is version 20090330 of tboot. Thanks very much - >>>>> >>>>> Hal Finney >> |
From: Hal F. <hal...@gm...> - 2009-07-30 17:39:38
|
(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 be anything. But no, I don't see anything in BIOS about any of this. Hal |
From: Shane W. <sha...@in...> - 2009-07-31 06:10:59
|
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 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 be > anything. But no, I don't see anything in BIOS about any of this. > > Hal |
From: Ross P. <Ros...@ci...> - 2009-07-30 21:14:25
|
Martin, The dump utility I gave Hal earlier was reading the ACPI tables and formatting/tracing out the DMAR table from his system. The DMAR is there and on the surface it looked correct to me (at least nothing obviously wrong with it). Hal attached the trace in an earlier reply. Thanks Ross -----Original Message----- From: Martin Thiim [mailto:ma...@th...] Sent: Thursday, July 30, 2009 4:07 PM To: Hal Finney Cc: tbo...@li... Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800 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 for this. http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf I currently don't have access to my VT-d system so I can't give you a table of what it looks like on my machine but perhaps others could. Best regards, Martin Thiim On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote: > 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 can patch tboot to dump out, > to indicate whether VT-d is turned on? > > My HP dc7800 was one of the very first commercially released systems > to support TXT. I bought one as soon as they became available in order > to experiment with this technology. It has an E6550 "Conroe" processor > with a Q35 "Bearlake" chipset. > > Hal > > On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >> 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? *Field or *Dale? >> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >> >> Thanks. >> Shane >> >> Hal Finney wrote: >>> >>> 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, Shane Wang<sha...@in...> wrote: >>>> >>>> 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 to work. My system has no USB ports >>>>> plugged in, and no hardware changes. >>>>> >>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>> what this means. >>>>> >>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>> is version 20090330 of tboot. Thanks very much - >>>>> >>>>> 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 > tbo...@li... > 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 tbo...@li... https://lists.sourceforge.net/lists/listinfo/tboot-devel |
From: Hal F. <hal...@gm...> - 2009-07-30 23:16:36
|
Right, you can see my output from Ross's dmardump utility at http://docs.google.com/View?id=df2b4r7r_1hcbtgbnd Or here is the binary output of acpidump -t DMAR. BTW you can see the BEARLAKE chipset ID right there: DMAR @ 0x3e2c225f 0000: 44 4d 41 52 98 01 00 00 01 ce 43 4f 4d 50 41 51 DMAR......COMPAQ 0010: 42 45 41 52 4c 41 4b 45 01 00 00 00 00 00 00 00 BEARLAKE........ 0020: 00 00 00 00 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 18 00 00 00 00 00 00 00 d9 fe 00 00 00 00 ................ 0040: 01 08 00 00 00 00 1b 00 00 00 18 00 00 00 00 00 ................ 0050: 00 10 d9 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ 0060: 00 00 28 00 00 00 00 00 00 20 d9 fe 00 00 00 00 ..(...... ...... 0070: 01 08 00 00 00 00 03 00 01 08 00 00 00 00 03 02 ................ 0080: 01 08 00 00 00 00 03 03 00 00 10 00 01 00 00 00 ................ 0090: 00 30 d9 fe 00 00 00 00 01 00 20 00 00 00 00 00 .0........ ..... 00a0: 00 00 60 3e 00 00 00 00 ff ff ff 3e 00 00 00 00 ..`>.......>.... 00b0: 01 08 00 00 00 00 02 00 01 00 20 00 00 00 00 00 .......... ..... 00c0: 00 00 2d 3e 00 00 00 00 ff 0f 2d 3e 00 00 00 00 ..->......->.... 00d0: 01 08 00 00 00 00 1d 07 01 00 20 00 00 00 00 00 .......... ..... 00e0: 00 10 2d 3e 00 00 00 00 ff 1f 2d 3e 00 00 00 00 ..->......->.... 00f0: 01 08 00 00 00 00 1a 07 01 00 20 00 00 00 00 00 .......... ..... 0100: 00 20 2d 3e 00 00 00 00 ff 2f 2d 3e 00 00 00 00 . ->...../->.... 0110: 01 08 00 00 00 00 1d 00 01 00 20 00 00 00 00 00 .......... ..... 0120: 00 30 2d 3e 00 00 00 00 ff 3f 2d 3e 00 00 00 00 .0->.....?->.... 0130: 01 08 00 00 00 00 1d 01 01 00 20 00 00 00 00 00 .......... ..... 0140: 00 40 2d 3e 00 00 00 00 ff 4f 2d 3e 00 00 00 00 .@->.....O->.... 0150: 01 08 00 00 00 00 1d 02 01 00 20 00 00 00 00 00 .......... ..... 0160: 00 50 2d 3e 00 00 00 00 ff 5f 2d 3e 00 00 00 00 .P->....._->.... 0170: 01 08 00 00 00 00 1a 00 01 00 20 00 00 00 00 00 .......... ..... 0180: 00 60 2d 3e 00 00 00 00 ff 6f 2d 3e 00 00 00 00 .`->.....o->.... 0190: 01 08 00 00 00 00 1a 01 ........ Comparing with the VT-d spec, it looks pretty reasonable to me. But I may be missing some details. There must be something about it that SINIT doesn't like. Hal On Thu, Jul 30, 2009 at 2:14 PM, Ross Philipson<Ros...@ci...> wrote: > Martin, > > The dump utility I gave Hal earlier was reading the ACPI tables and formatting/tracing out the DMAR table from his system. The DMAR is there and on the surface it looked correct to me (at least nothing obviously wrong with it). Hal attached the trace in an earlier reply. > > Thanks > Ross > > -----Original Message----- > From: Martin Thiim [mailto:ma...@th...] > Sent: Thursday, July 30, 2009 4:07 PM > To: Hal Finney > Cc: tbo...@li... > Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800 > > 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 for this. > > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf > > I currently don't have access to my VT-d system so I can't give you a > table of what it looks like on my machine but perhaps others could. > > Best regards, > > Martin Thiim > > On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote: >> 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 can patch tboot to dump out, >> to indicate whether VT-d is turned on? >> >> My HP dc7800 was one of the very first commercially released systems >> to support TXT. I bought one as soon as they became available in order >> to experiment with this technology. It has an E6550 "Conroe" processor >> with a Q35 "Bearlake" chipset. >> >> Hal >> >> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >>> 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? *Field or *Dale? >>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >>> >>> Thanks. >>> Shane >>> >>> Hal Finney wrote: >>>> >>>> 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, Shane Wang<sha...@in...> wrote: >>>>> >>>>> 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 to work. My system has no USB ports >>>>>> plugged in, and no hardware changes. >>>>>> >>>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>>> what this means. >>>>>> >>>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>>> is version 20090330 of tboot. Thanks very much - >>>>>> >>>>>> 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 >> tbo...@li... >> 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 > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Martin T. <ma...@th...> - 2009-07-31 13:45:22
|
Hello Ross Right, I had not noticed the utility operated at the ACPI-level; I only jumped into the thread when I saw Hal's question on how to detect if the BIOS actually had enabled VT-d. Based on the ACPI tables the answer is a "yes" :-) I think I may have found the error in the tables though! In the description of the RMRR's under the DMAR the spec says on pg. 75 (in the description of the device scope under the RMRR): "The Device Scope structure contains...The devices identified in this structure must be devices under the scope of one of the remapping hardware units reported in _DRHD_." This was taken from: http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf However, consider the DeviceScope "-- Device: 0x1d Function: 0x07" reported under RMRR #2 and of some of the other RMRR's. This device is not present under any DRHD in the entire DMAR. This seems to be a violation of the spec. And it makes sense with the error code Hal got, "device scope of VT-d DMAR ACPI table is invalid" Best regards, Martin Thiim On Thu, Jul 30, 2009 at 11:14 PM, Ross Philipson<Ros...@ci...> wrote: > Martin, > > The dump utility I gave Hal earlier was reading the ACPI tables and formatting/tracing out the DMAR table from his system. The DMAR is there and on the surface it looked correct to me (at least nothing obviously wrong with it). Hal attached the trace in an earlier reply. > > Thanks > Ross > > -----Original Message----- > From: Martin Thiim [mailto:ma...@th...] > Sent: Thursday, July 30, 2009 4:07 PM > To: Hal Finney > Cc: tbo...@li... > Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800 > > 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 for this. > > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf > > I currently don't have access to my VT-d system so I can't give you a > table of what it looks like on my machine but perhaps others could. > > Best regards, > > Martin Thiim > > On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote: >> 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 can patch tboot to dump out, >> to indicate whether VT-d is turned on? >> >> My HP dc7800 was one of the very first commercially released systems >> to support TXT. I bought one as soon as they became available in order >> to experiment with this technology. It has an E6550 "Conroe" processor >> with a Q35 "Bearlake" chipset. >> >> Hal >> >> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >>> 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? *Field or *Dale? >>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >>> >>> Thanks. >>> Shane >>> >>> Hal Finney wrote: >>>> >>>> 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, Shane Wang<sha...@in...> wrote: >>>>> >>>>> 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 to work. My system has no USB ports >>>>>> plugged in, and no hardware changes. >>>>>> >>>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>>> what this means. >>>>>> >>>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>>> is version 20090330 of tboot. Thanks very much - >>>>>> >>>>>> 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 >> tbo...@li... >> 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 > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Ross P. <Ros...@ci...> - 2009-07-31 15:19:50
|
Well except DRHD #4 has the INCLUDE_ALL = yes which IIRC means it is the catch-all for devices not explicitly reporting under another DRHD. So "Device: 0x1d Function: 0x07" would be under the scope of this DRHD. Thanks Ross -----Original Message----- From: Martin Thiim [mailto:ma...@th...] Sent: Friday, July 31, 2009 9:21 AM To: Ross Philipson Cc: Hal Finney; tbo...@li... 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 saw Hal's question on how to detect if the BIOS actually had enabled VT-d. Based on the ACPI tables the answer is a "yes" :-) I think I may have found the error in the tables though! In the description of the RMRR's under the DMAR the spec says on pg. 75 (in the description of the device scope under the RMRR): "The Device Scope structure contains...The devices identified in this structure must be devices under the scope of one of the remapping hardware units reported in _DRHD_." This was taken from: http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf However, consider the DeviceScope "-- Device: 0x1d Function: 0x07" reported under RMRR #2 and of some of the other RMRR's. This device is not present under any DRHD in the entire DMAR. This seems to be a violation of the spec. And it makes sense with the error code Hal got, "device scope of VT-d DMAR ACPI table is invalid" Best regards, Martin Thiim On Thu, Jul 30, 2009 at 11:14 PM, Ross Philipson<Ros...@ci...> wrote: > Martin, > > The dump utility I gave Hal earlier was reading the ACPI tables and formatting/tracing out the DMAR table from his system. The DMAR is there and on the surface it looked correct to me (at least nothing obviously wrong with it). Hal attached the trace in an earlier reply. > > Thanks > Ross > > -----Original Message----- > From: Martin Thiim [mailto:ma...@th...] > Sent: Thursday, July 30, 2009 4:07 PM > To: Hal Finney > Cc: tbo...@li... > Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800 > > 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 for this. > > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf > > I currently don't have access to my VT-d system so I can't give you a > table of what it looks like on my machine but perhaps others could. > > Best regards, > > Martin Thiim > > On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote: >> 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 can patch tboot to dump out, >> to indicate whether VT-d is turned on? >> >> My HP dc7800 was one of the very first commercially released systems >> to support TXT. I bought one as soon as they became available in order >> to experiment with this technology. It has an E6550 "Conroe" processor >> with a Q35 "Bearlake" chipset. >> >> Hal >> >> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote: >>> 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? *Field or *Dale? >>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere? >>> >>> Thanks. >>> Shane >>> >>> Hal Finney wrote: >>>> >>>> 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, Shane Wang<sha...@in...> wrote: >>>>> >>>>> 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 to work. My system has no USB ports >>>>>> plugged in, and no hardware changes. >>>>>> >>>>>> The one change is I recently updated my BIOS. I suspect this has to be >>>>>> the cause. One nice thing about the new BIOS is that the tboot hang >>>>>> actually reboots the machine with the ERRORCODE register intact. Its >>>>>> value is c00020a1. This is progress code 0ah, error code 1000, >>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear >>>>>> what this means. >>>>>> >>>>>> My log is attached, including the hang and the relaunch of tboot. This >>>>>> is version 20090330 of tboot. Thanks very much - >>>>>> >>>>>> 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 >> tbo...@li... >> 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 > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Hal F. <hal...@gm...> - 2009-07-31 17:31:51
Attachments:
tbootfail_nousb.log
|
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 attaching the log of the two boot attempts (the first which hangs in SENTER, followed by the reboot which displays the error code). Here is the output of Ross's dmardump program in this state with USB disabled: DMAR dump utility - reading memory DMA Remapping Reporting Structure ================================================== Signature: DMAR Length: 0x000000a0 Revision: 0x01 Checksum: 0xb0 OEMID: COMPAQ OEM Table ID: BEARLAKE OEM Revision: 0x00000001 Creator ID: Creator Revision: 0x00000000 HAW: 0x23 Flags: 0x00 Reserved[10]: 00 00 00 00 00 00 00 00 00 00 Remapping Structures... DMA Remapping Hardware Unit Definition (DRHD) Structure #1 Type: 0x0000 (ACPI_DMAR_DRHD) Length: 0x0018 Flags: 0x00 -- INCLUDE_ALL = no Reserved: 0x00 Segment Number: 0x0000 Register Base: 0xfed91000 Device Scope Structure #1 ========================== Type: 0x01 (ACPI_DEV_ENDPOINT) Length: 0x08 Reserved: 00 00 Enumeration ID: 0x00 - Reserved Start Bus Num: 0x00 Path Depth = 1, Path Entries: -- Device: 0x02 Function: 0x00 DMA Remapping Hardware Unit Definition (DRHD) Structure #2 Type: 0x0000 (ACPI_DMAR_DRHD) Length: 0x0028 Flags: 0x00 -- INCLUDE_ALL = no Reserved: 0x00 Segment Number: 0x0000 Register Base: 0xfed92000 Device Scope Structure #1 ========================== Type: 0x01 (ACPI_DEV_ENDPOINT) Length: 0x08 Reserved: 00 00 Enumeration ID: 0x00 - Reserved Start Bus Num: 0x00 Path Depth = 1, Path Entries: -- Device: 0x03 Function: 0x00 Device Scope Structure #2 ========================== Type: 0x01 (ACPI_DEV_ENDPOINT) Length: 0x08 Reserved: 00 00 Enumeration ID: 0x00 - Reserved Start Bus Num: 0x00 Path Depth = 1, Path Entries: -- Device: 0x03 Function: 0x02 Device Scope Structure #3 ========================== Type: 0x01 (ACPI_DEV_ENDPOINT) Length: 0x08 Reserved: 00 00 Enumeration ID: 0x00 - Reserved Start Bus Num: 0x00 Path Depth = 1, Path Entries: -- Device: 0x03 Function: 0x03 DMA Remapping Hardware Unit Definition (DRHD) Structure #3 Type: 0x0000 (ACPI_DMAR_DRHD) Length: 0x0010 Flags: 0x01 -- INCLUDE_ALL = yes Reserved: 0x00 Segment Number: 0x0000 Register Base: 0xfed93000 Reserved Memory Region Reporting (RMRR) Structure #1 Type: 0x0001 (ACPI_DMAR_RMRR) Length: 0x0020 Reserved: 0x0000 Segment Number: 0x0000 Base Address: 0x3e600000 End Address: 0x3effffff Device Scope Structure #1 ========================== Type: 0x01 (ACPI_DEV_ENDPOINT) Length: 0x08 Reserved: 00 00 Enumeration ID: 0x00 - Reserved Start Bus Num: 0x00 Path Depth = 1, Path Entries: -- Device: 0x02 Function: 0x00 ================================================== End DMAR A couple of differences: there is one fewer DRHD structure, 3 instead of 4, and there is only one RMRR structure instead of several. This one also avoids the potential problem Martin pointed out, that the device scopes under the RMRR's don't explicitly match any of the ones under the DRHD's. In this one, the only RMRR is device 2, function 0, which is covered explicitly under the first DRHD. I do agree with Ross that the full DMAR struct I posted earlier is kosher because of the INCLUDE_ALL DRHD which should cover all devices in PCI segment 0000, but just because we read the spec this way, that doesn't mean the SINIT author read it that way. (The frustrating thing is, SINIT doesn't actually seem to do anything with this DMAR data. It just copies it to the SinitMleData struct, for use by the MLE. SINIT wants to put the data into the TXT heap so it is protected. It is apparently just doing some sanity checks on the data structures before doing the copy, and obviously the SINIT author and the HP BIOS author were not on the same page. This happens a lot in implementing specs. But for me it means that we have two opaque pieces of code which are incompatible, and both only get updated a couple of times a year at best.) Anyway, back to the SINIT error, "BARs in Vt-d DMAR DRHD struct mismatch". It's like a Zen koan, what is the sound of one hand clapping. You have to try to puzzle out what on earth this could mean. First, what's a BAR? The closest thing I can see in the table is Register Base Address, which maybe could be called Base Address Register or BAR. Then, we have a complaint about a mismatch. Mismatch? What is it supposed to match against? It's just an address. The base addresses in the 3 DRHD structs are 0xfed91000, 0xfed92000, and 0xfed93000. Is that a problem? They seem reasonable enough to me. I can't figure out what it means to complain about a mismatch. This error code, 6, is less than the earlier error code with USB enabled, 8. I'm guessing that SINIT applies all these sanity checks to the DMAR data in order, and errors out when it doesn't like one. This suggests that it is not getting as far as it got earlier, so I don't know whether it still would have hit error code 8 or not (which was device scope invalid). The one other unusual aspect of my machine is that it has only 1 gig of memory. I was cheap when I ordered it, and it's run fine for what I've used it for. Conceivably the SINIT authors may have accidentally assumed a larger memory configuration would have been in use, in sanity checking some addresses. I suppose I could add a second gig and see if that makes a difference, but it seems like a long shot. At this point I will wait and hope to hear something from the SINIT group, if they have any ideas. I would of course be happy to run an experimental SINIT with additional debugging outputs or error codes if that would help. I'll also try reverting the BIOS version and see if that makes a difference. Thanks for all your help - Hal Finney |
From: Martin T. <ma...@th...> - 2009-07-31 19:05:30
|
>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 base/range in the table is somehow in conflict with what SINIT can see by other means of PCI enumeration? Maybe the table is now incomplete (since the error occurred after an apparent simplification in the table, and with an error code that seems to relate to an earlier check than before?). Perhaps you could send a dump from lspci - it would be interesting to cross-reference it with the values in the DMAR. Best regards, Martin Thiim On Fri, Jul 31, 2009 at 7:31 PM, Hal Finney<hal...@gm...> wrote: > 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 attaching the log of the two boot attempts (the first which hangs > in SENTER, followed by the reboot which displays the error code). Here > is the output of Ross's dmardump program in this state with USB > disabled: > > DMAR dump utility - reading memory > DMA Remapping Reporting Structure > ================================================== > Signature: DMAR > Length: 0x000000a0 > Revision: 0x01 > Checksum: 0xb0 > OEMID: COMPAQ > OEM Table ID: BEARLAKE > OEM Revision: 0x00000001 > Creator ID: > Creator Revision: 0x00000000 > HAW: 0x23 > Flags: 0x00 > Reserved[10]: 00 00 00 00 00 00 00 00 00 00 > > Remapping Structures... > > DMA Remapping Hardware Unit Definition (DRHD) Structure #1 > Type: 0x0000 (ACPI_DMAR_DRHD) > Length: 0x0018 > Flags: 0x00 -- INCLUDE_ALL = no > Reserved: 0x00 > Segment Number: 0x0000 > Register Base: 0xfed91000 > Device Scope Structure #1 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x02 Function: 0x00 > > DMA Remapping Hardware Unit Definition (DRHD) Structure #2 > Type: 0x0000 (ACPI_DMAR_DRHD) > Length: 0x0028 > Flags: 0x00 -- INCLUDE_ALL = no > Reserved: 0x00 > Segment Number: 0x0000 > Register Base: 0xfed92000 > Device Scope Structure #1 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x03 Function: 0x00 > Device Scope Structure #2 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x03 Function: 0x02 > Device Scope Structure #3 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x03 Function: 0x03 > > DMA Remapping Hardware Unit Definition (DRHD) Structure #3 > Type: 0x0000 (ACPI_DMAR_DRHD) > Length: 0x0010 > Flags: 0x01 -- INCLUDE_ALL = yes > Reserved: 0x00 > Segment Number: 0x0000 > Register Base: 0xfed93000 > > Reserved Memory Region Reporting (RMRR) Structure #1 > Type: 0x0001 (ACPI_DMAR_RMRR) > Length: 0x0020 > Reserved: 0x0000 > Segment Number: 0x0000 > Base Address: 0x3e600000 > End Address: 0x3effffff > Device Scope Structure #1 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x02 Function: 0x00 > > ================================================== > End DMAR > > > A couple of differences: there is one fewer DRHD structure, 3 instead > of 4, and there is only one RMRR structure instead of several. This > one also avoids the potential problem Martin pointed out, that the > device scopes under the RMRR's don't explicitly match any of the ones > under the DRHD's. In this one, the only RMRR is device 2, function 0, > which is covered explicitly under the first DRHD. I do agree with Ross > that the full DMAR struct I posted earlier is kosher because of the > INCLUDE_ALL DRHD which should cover all devices in PCI segment 0000, > but just because we read the spec this way, that doesn't mean the > SINIT author read it that way. > > (The frustrating thing is, SINIT doesn't actually seem to do anything > with this DMAR data. It just copies it to the SinitMleData struct, for > use by the MLE. SINIT wants to put the data into the TXT heap so it is > protected. It is apparently just doing some sanity checks on the data > structures before doing the copy, and obviously the SINIT author and > the HP BIOS author were not on the same page. This happens a lot in > implementing specs. But for me it means that we have two opaque pieces > of code which are incompatible, and both only get updated a couple of > times a year at best.) > > Anyway, back to the SINIT error, "BARs in Vt-d DMAR DRHD struct > mismatch". It's like a Zen koan, what is the sound of one hand > clapping. You have to try to puzzle out what on earth this could mean. > First, what's a BAR? The closest thing I can see in the table is > Register Base Address, which maybe could be called Base Address > Register or BAR. Then, we have a complaint about a mismatch. Mismatch? > What is it supposed to match against? It's just an address. > > The base addresses in the 3 DRHD structs are 0xfed91000, 0xfed92000, > and 0xfed93000. Is that a problem? They seem reasonable enough to me. > I can't figure out what it means to complain about a mismatch. > > This error code, 6, is less than the earlier error code with USB > enabled, 8. I'm guessing that SINIT applies all these sanity checks to > the DMAR data in order, and errors out when it doesn't like one. This > suggests that it is not getting as far as it got earlier, so I don't > know whether it still would have hit error code 8 or not (which was > device scope invalid). > > The one other unusual aspect of my machine is that it has only 1 gig > of memory. I was cheap when I ordered it, and it's run fine for what > I've used it for. Conceivably the SINIT authors may have accidentally > assumed a larger memory configuration would have been in use, in > sanity checking some addresses. I suppose I could add a second gig and > see if that makes a difference, but it seems like a long shot. > > At this point I will wait and hope to hear something from the SINIT > group, if they have any ideas. I would of course be happy to run an > experimental SINIT with additional debugging outputs or error codes if > that would help. I'll also try reverting the BIOS version and see if > that makes a difference. > > Thanks for all your help - > > Hal Finney > |
From: Jonathan M. M. <jon...@cm...> - 2009-08-03 17:11:07
|
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...@gm...> 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 > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Tondapu, K. <kar...@hp...> - 2009-08-06 18:30:02
|
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:jon...@cm...] Sent: Monday, August 03, 2009 12:10 PM To: Martin Thiim Cc: Hal Finney; tbo...@li...; 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...@gm...> 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 > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |