search for: bringup

There's no way to get acceleration with GM20x... I'd rather save this until there is. For now reject the load and let the modesetting driver get used. OTOH, the DDX isn't released/integrated into distros at an infinite rate, and eventually GM20x will probably get acceleration.... could go either way. My immediate reaction is to hold though. There may be further differences... On Sun,

--- src/nv_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/nv_driver.c b/src/nv_driver.c index e726292..4c40763 100644 --- a/src/nv_driver.c +++ b/src/nv_driver.c @@ -377,6 +377,7 @@ NVHasKMS(struct pci_device *pci_dev, struct xf86_platform_device *platform_dev) case 0xf0: case 0x100: case 0x110: + case 0x120: break; default: xf86DrvMsg(-1, X_ERROR, "Unknown

We''ve been noticing a lot of these errors when booting VMs since we moved to 3.0.3 - I''ve traced this to the hotplug scripts in Dom0 taking >10s to run to completion and specifically the vif-bridge script taking >=9s to plug the vif into the s/w bridge on occasion - was wondering if anyone has any insight into why it might take this long. I added some instrumentation to

The aim of this patch is to define a stable way in which PVH is going to do AP bringup. Since we are running inside of a HVM container, PVH should only need to set flags, cr3 and user_regs in order to bring up a vCPU, the rest can be set once the vCPU is started using the bare metal methods. Additionally, the guest can also set cr0 and cr4, and those values will be appended to the d...

On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > The important point here is that the COFF MCSection needs to > have the right level of semantic information. In fact, > MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > proven somewhat problematic, mostly due to my lack of understanding. > I guess MCSectionXXX was meant to provide communication between them. > Sho...

...t;struct_module" found: kernel tainted. SCSI subsystem initialized Loading sd_mod.ko module Loading mptbase.ko module Fusion MPT base driver 3.01.20 Copyright (c) 1999-2004 LSI Logic Corporation ACPI: PCI Interrupt 0000:04:05.0[A] -> GSI 18 (level, low) -> IRQ 18 mptbase: Initiating ioc0 bringup ioc0: 53C1030: Capabilities={Initiator,Target} ACPI: PCI Interrupt 0000:04:05.1[B] -> GSI 19 (level, low) -> IRQ 19 mptbase: Initiating ioc1 bringup ioc1: 53C1030: Capabilities={Initiator,Target} Loading mptscsih.ko module Fusion MPT SCSI Host driver 3.01.20 scsi0 : ioc0: LSI53C1030, FwRev=01...

...behavior of Windows 8 and newer[1] (as observed via an AMLi > > > debugger trace) and stop using the DSM functions for D3cold when power > > > resources are available on the parent PCIe port. > > > > > > [1]: https://msdn.microsoft.com/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold > > > > > > Signed-off-by: Peter Wu <peter at lekensteyn.nl> > > > --- > > > drivers/gpu/drm/nouveau/nouveau_acpi.c | 34 ++++++++++++++++++++++++++++++---- > > > 1 file changed, 30 insertions(+), 4 deletions(-) &...

...oogleMock, but on the whole, I think it's better than the alternative and will allow more careful testing of C++ APIs where the interesting part is the API itself. Personally, I rather not do this, without very clear and compelling reasons. I understand that this could be very useful for your bringup (and so could be very useful locally), but once the passmanager is the default, it will get lost of in-tree testing by just about everything in the compiler. I'm not really excited about dragging another out of tree project in unless there is a compelling reason to do so. -Chris

...CentOS 4.0 on my X4100, I am ready to switch to it. TIA Sungsoo Kim ------------------- SCSI subsystem initialized Fusion MPT base driver 3.02.18 Copyright (c) 1999-2005 LSI Logic Corporation ACPI: PCI interrupt 0000:02:03.0[A] -> GSI 28 (level, low) -> IRQ 209 mptbase: Initiating ioc0 bringup ioc0: SAS1064: Capabilities={Initiator} Fusion MPT SCSI Host driver 3.02.18 scsi0 : ioc0: LSISAS1064, FwRev=01040000h, Ports=1, MaxQ=203, IRQ=209 Vendor: FUJITSU Model: MAV2073RCSUN72G Rev: 0301 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sda: 143374738 512...

...kernel on resume. > > Mirror the behavior of Windows 8 and newer[1] (as observed via an AMLi > debugger trace) and stop using the DSM functions for D3cold when power > resources are available on the parent PCIe port. > > [1]: https://msdn.microsoft.com/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold > > Signed-off-by: Peter Wu <peter at lekensteyn.nl> > --- > drivers/gpu/drm/nouveau/nouveau_acpi.c | 34 ++++++++++++++++++++++++++++++---- > 1 file changed, 30 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nou...

...48 MHz instead of the actual 27MHz crystal found on the board. I thus have the following questions: - Is it a fixed value hardcoded in RM? (Current way it is done in Nouveau) - Should we use crystal_MHz * 1.024? I could spend some time hooking up my osciloscope to the VR to check if it is a bringup issue but it would not help Nouveau much as we need to reproduce the behaviour of RM anyway since this is the only validated configuration. Thanks in advance, Martin PS: The registers for this PWM controller are 0x20340 and 0x20344.

...gt; On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > > > > The important point here is that the COFF MCSection needs to > > have the right level of semantic information. In fact, > > MCSection is the place that I'd start for COFF bringup. > > > > OK, I see that now. The current isolation > > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > > proven somewhat problematic, mostly due to my lack of understanding. > > I guess MCSectionXXX was meant to provide communication betwee...

...erfaces are the ones responsible for mapping a global/function -> section. This interface (not mcstreamer) should handle this. The important point here is that the COFF MCSection needs to have the right level of semantic information. In fact, MCSection is the place that I'd start for COFF bringup. > instead of SwitchSection, there would be BeginSymbol, and SymbolSymbol, it would > be illegal to call any EmitXXX function outside of these two calls > > BeginSymbol(Symbol, SectionHint) > EmitAttribute(...) > EmitAttribute(...) > ... > StartFragmentEmission() &gt...

With the release of the Rasberry Pi 3.x, I think we have a platform I could jump on board with. Performance has just been lacking until now! But I really don't want to jump the "RH ship" - I'd rather stick with an environment I am comfortable in. Can anybody comment here on the best way to run RHEL/Fedora/CentOS on a RasPi, or if there's even a useful port? Thanks

...+0000, Karanbir Singh wrote: > join the arm-dev list ( https://lists.centos.org ) CentOS has a great > story across the entire ARMv7 and v8 platform, with every major vendor > in the ARM 64bit platform working with us. We say the rpi3 release this > morning and are going to work on a bringup to match our rpi2 images. > However, we will also be doing a 64bit image, based on CentOS Linux > 7/aarch64 release FWIW, this is what was posted to the Fedora's ARM list about supporting the Pi3 in Fedora by Peter Robinson: No, not currently, and certainly won't be in Fedora 24 u...

...> On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > > > > The important point here is that the COFF MCSection needs to > > have the right level of semantic information. In fact, > > MCSection is the place that I'd start for COFF bringup. > > > > OK, I see that now. The current isolation > > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > > proven somewhat problematic, mostly due to my lack of understanding. > > I guess MCSectionXXX was meant to provide communication betwee...

Hi, I want to try Xen on ARMv8 Simulator. Can you please provide guidance?. I am looking for information about sources, build and procedure to launch Xen on ARMv8 Thanks & Regards Vijay

We (Michael Fetterman, George Dunlap and I) have been working over the last while on a full replacement for Xen''s shadow pagetable support. This mail contains some design notes, below; a patch against xen-unstable, giving a snapshot of the current state of the new shadow code, is at http://www.cl.cam.ac.uk/~tjd21/shadow2.patch Comments on both are welcome, although the code is not

xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead() is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests) is useful in the cpu bringup path. Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking on to the generic SMP booting framework. Also remove the...

xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead() is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests) is useful in the cpu bringup path. Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking on to the generic SMP booting framework. Also remove the...