similar to: [PATCH, v3] fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled

Displaying 20 results from an estimated 100 matches similar to: "[PATCH, v3] fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled"

2012 Sep 18
4
[PATCH] EHCI/Xen: propagate controller reset information to hypervisor
Just like for the in-tree early console debug port driver, the hypervisor - when using a debug port based console - also needs to be told about controller resets, so it can suppress using and then re-initialize the debug port accordingly. Other than the in-tree driver, the hypervisor driver actually cares about doing this only for the device where the debug is port actually in use, i.e. it needs
2012 Oct 24
3
linux-next: Tree for Oct 24 (xen)
On 10/23/2012 09:19 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 201201023: > on x86_64: drivers/built-in.o: In function `dbgp_reset_prep': (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' Full randconfig file is
2012 Oct 24
3
linux-next: Tree for Oct 24 (xen)
On 10/23/2012 09:19 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 201201023: > on x86_64: drivers/built-in.o: In function `dbgp_reset_prep': (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' Full randconfig file is
2012 Oct 24
3
linux-next: Tree for Oct 24 (xen)
On 10/23/2012 09:19 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 201201023: > on x86_64: drivers/built-in.o: In function `dbgp_reset_prep': (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' Full randconfig file is
2013 Sep 12
23
More Coverity-reported issues.
Another bundle of issues from Coverity triage. The first one is in x86/mm, and looks scarier than it is. The others are all in xen/drivers and AFAICT are pretty minor. Cheers, Tim.
2013 Jul 09
6
4.3 regression in booting on a particular platform
Jan, I was given a machine to diagnose a boot problem on xen 4.3, that used to work on 4.2, and have bisected to the following changeset: commit d0d4635d034f202bb401a6efa3ba61530f3854ab Author: Jan Beulich <jbeulich@suse.com> Date: Thu Nov 22 10:47:58 2012 +0100 implement vmap() ... and use it as basis for a proper ioremap() on x86. Signed-off-by: Jan Beulich
2007 Nov 13
0
[LLVMdev] BasicAliasAnalysis and out-of-bound GEP indices
It's an optimization opportunity! When behavior is undefined, we're free to interpret it to be "whatever makes optimization easiest." If the two do actually happen to alias, well, it's the programmer's fault anyways, because they were doing something undefined! --Owen On Nov 13, 2007, at 4:13 PM, Wojciech Matyjewicz wrote: > Hi! > > While investigating
2007 Nov 13
2
[LLVMdev] BasicAliasAnalysis and out-of-bound GEP indices
Hi! While investigating into the PR1782 I spent some time analyzing BasicAliasAnalysis.cpp. While the mentioned problem should be fixed now (I hope), I have discovered some other possibilities for a bug to occur. In the case of checking for aliasing of two pointer values, where at least one of them is a GEP instruction with out-of-bound indices, BasicAliasAnalysis can return NoAlias, even if the
2011 Oct 07
4
NVIDIA (including Optimus) laptop owners - please read!
Hi guys and gals, I'm working on improving nouveau's support for MXM (Mobile PCI Express Module) chips and need some more data to check my implementation. To see if you can help, the first thing to do is jump over to /sys/firmware/acpi/tables and run "grep MXMS *". [root at nisroch tables]# grep MXMS * Binary file DSDT matches [root at nisroch tables]# If this isn't
2007 Nov 15
3
[LLVMdev] BasicAliasAnalysis and out-of-bound GEP indices
On 11/15/07, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > > Sadly, this will break a very common idiom. In GCC, we discovered it > > to be common enough that it broke a *bunch* of C code. > > > > In particular, you will break > > > > struct foo { > > int a; > > char name[0]; > > } > > > > bar = malloc(sizeof
2007 Nov 15
0
[LLVMdev] BasicAliasAnalysis and out-of-bound GEP indices
Hi, Daniel Berlin wrote: > Then the original reported code is fine, and the bug is in llvm or > llvm-gc (IE Owen is wrong) There is, actually, no problem with this example. I attached it, because it contains some specific programming technique, for which, after instcombining, a weird GEP is generated. I've pasted fragments of generated assembly code below, if someone is interested.
2007 Nov 15
2
[LLVMdev] BasicAliasAnalysis and out-of-bound GEP indices
Sadly, this will break a very common idiom. In GCC, we discovered it to be common enough that it broke a *bunch* of C code. In particular, you will break struct foo { int a; char name[0]; } bar = malloc(sizeof (struct foo) + strlen("thisismyname") + 1); strcpy(bar->name, "thisismyname"); It only started turning up when we started doing higher level loop opts and used
2013 Jun 24
2
ehci dbgp reset during boot?
Jan (or others), I'm seeing an issue with the EHCI debug port functionality, that I'm wondering whether it is a known limitation of the hardware, or if this is a bug. On a particular system that I had limited debug capabilities in the past (Dell Inspiron 15 i3) I am seeing the debug messages abruptly stop during boot, followed by garbage that looks like an uninitialized serial port:
2017 Jul 19
7
[PATCH 000/102] Convert drivers to explicit reset API
The reset control API has two modes: exclusive access, where the driver expects to have full and immediate control over the state of the reset line, and shared (clock-like) access, where drivers only request reset deassertion while active, but don't care about the state of the reset line while inactive. Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset
2012 Nov 02
4
[PATCH] ACPI/cpuidle: remove unused "power" field from Cx state data
It has never been used for anything, and Linux 3.7 doesn''t propagate this information anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Konrad, on the pv-ops side it may be better to pass zero rather than leaving the field completely uninitialized. --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -935,7 +935,6 @@ static void set_cx( }
2013 Jul 22
69
[xen-unstable] Commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, makes dom0 boot process stall several times.
Hi Jan, After commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, booting dom0 stalls several times. Sometimes this results in RCU stall warnings from the dom0 kernel, hitting the "any" key, on normal or serial console, makes the boot continue for a while but it stalls several times. (It also stalls on shutdown BTW) I have
2012 Nov 02
1
add1() alternative
Hi, I'm trying to build a hierarchical logistic regression model with lme4 package, but I have a problem on selecting the variables to include in this model. In a simple logistic regression, using Forward selection, i use a likelihood ratio test to check which variables i should include in the model, using the function add1(). The problem is that this function doesn't work with the
2007 Nov 15
0
[LLVMdev] BasicAliasAnalysis and out-of-bound GEP indices
Hi, > Sadly, this will break a very common idiom. In GCC, we discovered it > to be common enough that it broke a *bunch* of C code. > > In particular, you will break > > struct foo { > int a; > char name[0]; > } > > bar = malloc(sizeof (struct foo) + strlen("thisismyname") + 1); > strcpy(bar->name, "thisismyname"); > > > It
2012 Sep 11
12
Start xen on UEFI system with grub
2017 Jul 20
0
[PATCH 000/102] Convert drivers to explicit reset API
On Wed, Jul 19, 2017 at 05:25:04PM +0200, Philipp Zabel wrote: > The reset control API has two modes: exclusive access, where the driver > expects to have full and immediate control over the state of the reset > line, and shared (clock-like) access, where drivers only request reset > deassertion while active, but don't care about the state of the reset line > while inactive.