Menu
▾
▴
Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
|
From: Hal F. <hal...@gm...> - 2009-07-31 20:12:09
|
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 >>> >> > |