On Sun, 11 Aug 2013, Dan Carpenter wrote:
> ARRAY_AND_SIZE() macro is horrible, and I would like it if it were
> removed. What I meant before was just that probably people will
> probably complain if we try to remove it.
Well, I could either wait for someone to defend it, or send a patch
* Raghavendra K T [2013-08-09 19:52:02]:
>From 10e92f7911a8aed5b8574f53607ffc5d094d4de1 Mon Sep 17 00:00:00 2001
From: Srivatsa Vaddagiri
Date: Tue, 6 Aug 2013 14:55:41 +0530
Subject: [PATCH V13 RESEND 14/14] kvm : Paravirtual ticketlocks support for
linux
guests running on KVM hypervisor
On Sun, Aug 11, 2013 at 12:53:45AM -0400, Michael Marineau wrote:
> This driver adds an attribute to the existing virtio device so a CHANGE
> event is required in order udev rules to make use of it. The ADD event
> happens before this driver is probed and unlike a more typical driver
> like a
That sounds like an issue with specific preemption policies.
Mike Galbraith wrote:
>On Sat, 2013-08-10 at 21:27 -0700, H. Peter Anvin wrote:
>> On 08/10/2013 09:17 PM, Mike Galbraith wrote:
>> >>
>> >> Do you have any quantification of "munches throughput?" It seems
>odd
>> >> that it would be
This driver adds an attribute to the existing virtio device so a CHANGE
event is required in order udev rules to make use of it. The ADD event
happens before this driver is probed and unlike a more typical driver
like a block device there isn't a higher level device to watch for.
Signed-off-by:
On Sat, 2013-08-10 at 21:27 -0700, H. Peter Anvin wrote:
> On 08/10/2013 09:17 PM, Mike Galbraith wrote:
> >>
> >> Do you have any quantification of "munches throughput?" It seems odd
> >> that it would be worse than polling for preempt all over the kernel, but
> >> perhaps the additional
On 08/10/2013 09:17 PM, Mike Galbraith wrote:
>>
>> Do you have any quantification of "munches throughput?" It seems odd
>> that it would be worse than polling for preempt all over the kernel, but
>> perhaps the additional locking is what costs.
>
> I hadn't compared in ages, so made some fresh
On Sat, 2013-08-10 at 09:09 -0700, H. Peter Anvin wrote:
> On 08/09/2013 10:55 PM, Mike Galbraith wrote:
> >>
> >> Now, here is a bigger question: shouldn't we be deprecating/getting rid
> >> of PREEMPT_VOUNTARY in favor of PREEMPT?
> >
> > I sure hope not, PREEMPT munches throughput. If you
We give out all kinds of loans,If interested do contact us through email
lucasmooremultifinanc...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
My wife and I won the Euro Millions Lottery of £41 Million British
Pounds and we have decided to donate £1.5 million British Pounds each to
10
individuals worldwide as part of our own charity project.
To verify,please see our interview by visiting the web page below:
On Sat, Aug 10, 2013 at 10:07:08PM +, Shuah Khan wrote:
> On 08/09/2013 01:10 PM, Greg Kroah-Hartman wrote:
> > On Fri, Aug 09, 2013 at 02:42:24PM +, Shuah Khan wrote:
> >> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote:
> >>> This is the start of the stable review cycle for the 3.10.6
于 2013年08月10日 03:53, Brian Norris 写道:
The right way seems to be to avoid nand_scan() directly but instead to
> use nand_scan_ident() and nand_scan_tail() separately (that's what
> they're exported for) so that you can initialize any geometry-related
> options before nand_scan_tail() does the
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.
We can reserve irq range at first, and later allocate desc for those
pre-reserved irqs when they are needed.
The reasons for not allocating them during reserving:
1. only several pins
iommu irq's irq_desc should be on local node ram.
Fix the return value checking problem.
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
here only check !irq, so need to change it to use create_irq_nr instead.
-v2: According to
Now MSI-X is shown as MSI in /proc/interrupt.
We could use new added irq_print_chip() interface to append -X for MSI-X.
After this patch, we will have PCI-MSI-X-edge IR-PCI-MSI-X-edge for MSI-X
instead of PCI-MSI-edge IR-PCI-MSI-edge in the /proc/interrupt.
-v2: do not need to check if msi_desc
Now MSI-X is shown as MSI in /proc/interrupt.
We could use new added irq_print_chip() interface to append -X for MSI-X.
After this patch, we will have PCI-MSI-X-edge IR-PCI-MSI-X-edge for MSI-X
instead of PCI-MSI-edge IR-PCI-MSI-edge in the /proc/interrupt.
-v2: do not need to check if msi_desc
Change irq_remap_modify_chip_defaults() to static, as we have no
outside user.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/irq_remapping.h | 6 --
drivers/iommu/irq_remapping.c| 2 +-
2 files changed,
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.
We can reserve irq range at first, and later allocate desc for those
pre-reserved irqs when they are needed.
The reasons for not allocating them during reserving:
1. only several pins
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
Will use it to fix one return value checking for dmar_msi irq.
Signed-off-by: Yinghai Lu
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
Cc: sta...@vger.kernel.org
---
create_irq() will return -1 when failing to allocate.
create_irq_nr() will return 0 when failing to allocate.
It only causes confusion.
Now we have no user for create_irq(), so remove create_irq() for x86.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
Will use it to fix one return value checking for dmar_msi irq.
Signed-off-by: Yinghai Lu
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
Cc: sta...@vger.kernel.org
---
Change irq_remap_modify_chip_defaults() to static, as we have no
outside user.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/irq_remapping.h | 6 --
drivers/iommu/irq_remapping.c| 2 +-
2 files changed,
Change irq_remap_modify_chip_defaults() to static, as we have no
outside user.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/irq_remapping.h | 6 --
drivers/iommu/irq_remapping.c| 2 +-
2 files changed,
Print out exact MSI or MSI-X instead of MSI/MSI-X.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c
Change position only.
Prepare to update arch_early_irq_init() that needs to call some static
functions.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 89 +-
1
For hotadd and hotremove ioapic controller, we leave blank
slots in ioapics array.
So we can not use for (i=...) to loop them any more.
Introdue ioapics_mask bitmap to track used ioapics, and use
for_each_ioapic to loop them.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek
We need to have ioapic setup before normal pci drivers.
otherwise other pci driver can not setup irq.
So we should not treat them as normal pci devices.
Also we will need to support ioapic hotplug without pci device around.
We need to call ioapic add/remove during host-bridge add/remove.
All others are using "-" instead of "_".
Change dmar_msi and hpet_msi to use "-".
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
For hot add ioapic, irq_base is not equal to gsi_base.
We need a way to do mapping between gsi and irq.
Also remove irq_to_gsi() that is confusing, just use that array
directly as we only have one caller and it already check
input irq before use it.
Signed-off-by: Yinghai Lu
Cc: Pavel Machek
Split alloc_ioapic_save_registers() from early_irq_init(),
so it will be used per ioapic.
Will call that later for hot-added ioapic controller.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 22
Checking the id in register, if that is duplicated, will pick one and
update id register.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 38 +-
1 file changed, 33
ioapic hotplug should be built-in like pci root bus hotplug.
Also need to make it depends on X86_IO_APIC.
Signed-off-by: Yinghai Lu
---
drivers/pci/Kconfig | 3 ++-
drivers/pci/ioapic.c | 6 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/Kconfig
1. check overlaping gsi range
for hot-add ioapic case, BIOS may have some entries in MADT
and also have setting in pci root bus with _GSB of DSDT.
2. check if entries is in right range.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for new added ioapic controller.
We can reserve irq range at first, then allocate those
pre-reserved one when it is needed.
Add alloc_reserved_irq_and_cfg_at() to really allocate irq_desc and cfg,
because pre-reserved
Current code: after irq remapping is enabled, irq_chip fields are modified
during every irq setup.
mp_register_gsi
io_apic_set_pci_routing
io_apic_setup_irq_pin
setup_ioapic_irq
During ioapic hotplug, acpi_register_ioapic will be called.
Now for x86, that function is blank.
Fill that will update __mp_register_ioapic to use those ioapic.
Signed-off-by: Yinghai Lu
---
arch/x86/kernel/acpi/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
It needs to reserve irq range in allocated_irqs bitmaps
and irq_base will be used to get right irq for ioapic/pin or gsi.
also need to use lock to protect ioapics_mask to avoid racing.
Signed-off-by: Yinghai Lu
Cc: Paul Gortmaker
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian
To make x86 irq allocation to be same with booting path and ioapic
hot add path, We will pre-reserve irq for all gsi at first.
We have to use alloc_reserved here, otherwise irq_alloc_desc_at will fail
because bit is already get marked for pre-reserved in irq bitmaps.
Signed-off-by: Yinghai Lu
Hot-added interrupt controllers can reserve a range of interrupt
numbers, but only allocate some of them. To simplify the release on
hot-remove allow them to iterate over the reserved range, let the
free_desc() code return early when the descriptor does not exist
-v2: changelog from tglx
It will free ioapic related irq_desc and also clear allocated_irqs bits.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/mpspec.h | 1 +
arch/x86/kernel/apic/io_apic.c | 44
Hi,
Intel cpu (from IVB) include cpu cores, mem controller, and IIO.
When hotplug cpu physically, it will involve cpu hotplug, mem hotplug,
and pci root hotplug.
IIO includes pci host bridge, ioapic controller and iommu etc.
pci devices will need to use ioapic and iommu.
So to make pci root bus
We will use reserve and alloc_reserved_irq_and_cfg_at for hotplug ioapic path.
To make thing simple, we could make booting path use same code.
All irq range for all GSIs will be reserved at first, and alloc_reserved
will really allocate those irq_desc/cfg when it is used.
Signed-off-by: Yinghai
Hot-added interrupt controllers can reserve a range of interrupt
numbers, but only allocate some of them. To simplify the release on
hot-remove allow them to iterate over the reserved range, let the
free_desc() code return early when the descriptor does not exist
-v2: changelog from tglx
iommu irq's irq_desc should be on local node ram.
Fix the return value checking problem.
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
here only check !irq, so need to change it to use create_irq_nr instead.
-v2: According to
Address compiling problem that Fengguang report.
Reported-by: Fengguang Wu
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/mpspec.h | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index
Current code: after irq remapping is enabled, irq_chip fields are modified
during every irq setup.
mp_register_gsi
io_apic_set_pci_routing
io_apic_setup_irq_pin
setup_ioapic_irq
Some ioapic controllers do not show up on pci config space,
or pci device is there but no bar is used and is set by firmware in
other non standard registers.
We can get ioapic address from ACPI0009's _CRS.
Signed-off-by: Yinghai Lu
---
drivers/pci/ioapic.c | 86
All others are using "-" instead of "_".
Change dmar_msi and hpet_msi to use "-".
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
irq_alloc_descs and irq_reserve_irqs are almost the same.
Separate code out to __irq_reserved_irqs, and other two reuse
__irq_reserve_irqs.
We will use __irq_reserve_irqs for coming ioapic hotplug support.
-v2: fix func docbook related comments, pointed out by tglx.
Signed-off-by: Yinghai Lu
Now irq_2_pin list is own grown list for ioapic irq/pin tracking.
We can use generic list to replace it so we could use generic helper
functions to operate it.
Also make free_irq_cfg() free irq_2_pin list to support coming ioapic
hotplug.
Signed-off-by: Yinghai Lu
Cc: Konrad Rzeszutek Wilk
Cc:
Hi,
Intel cpu (from IVB) include cpu cores, mem controller, and IIO.
When hotplug cpu physically, it will involve cpu hotplug, mem hotplug,
and pci root hotplug.
IIO includes pci host bridge, ioapic controller and iommu etc.
pci devices will need to use ioapic and iommu.
So to make pci root bus
irq_alloc_descs and irq_reserve_irqs are almost the same.
Separate code out to __irq_reserved_irqs, and other two reuse
__irq_reserve_irqs.
We will use __irq_reserve_irqs for coming ioapic hotplug support.
-v2: fix func docbook related comments, pointed out by tglx.
Signed-off-by: Yinghai Lu
Print out exact MSI or MSI-X instead of MSI/MSI-X.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c
On Sat, 10 Aug 2013, Sukadev Bhattiprolu wrote:
>
> include/uapi/linux/perf_event.h | 55
> +++
> 1 files changed, 55 insertions(+), 0 deletions(-)
> +#define __PERF_LE1234
> +#define __PERF_BE4321
> +
> +#if defined(__KERNEL__)
I could be wrong,
On Sat, 10 Aug 2013, Thomas Richter wrote:
> Sorry, need to look further. I replaced ehci-pci from 2.6.31.14, and
> yenta_socket as well. No changes were necessary. Also replaced ehci-hcd,
Do you mean that you took the source code for ehci-hcd from the 2.6.31
kernel, copied it into the source
On Sat, 10 Aug 2013, Josep Lladonosa wrote:
> Hello,
>
> Have you tried to wait for 5 minutes? It could also be related to it
> what happens to my kernel 3.11.0-rc4 (and rc3) and USB
>
> I plug the drive. Only after 5 minutes of high-speed of USb bus, it mounts.
Your experience is not related
Hi!
> > [I wonder if this is clean-enough cause for "trivial in resubmit
> > mode?]
>
> On Sat, 10 Aug 2013, Belisko Marek wrote:
>
> > Same for gta04 (omap3 based device) [1].
> > It was send upstream 2 times and second time there is no reply from
> > 1.3.2013.
>
> Hi guys,
>
> once I am
From: Joe Mario
[AK: This seems like a ticking time bomb even without LTO,
so should be merged now. It causes very weird problems.
Thanks to Joe for tracking them down.]
With the added postfixes that LTO adds for local
symbols, the longest name in the kernel overflows
the namebuf[KSYM_NAME_LEN]
From: Andi Kleen
Also warn for too long symbols
Signed-off-by: Andi Kleen
---
scripts/kallsyms.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 6940f00..e5af4c5 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
From: Joe Mario
Use KSYM_NAME_LEN to size identifier buffers, so that it can
be easier increased.
Cc: ana...@in.ibm.com
Signed-off-by: Joe Mario
Signed-off-by: Andi Kleen
---
kernel/kprobes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/kprobes.c
Some systems declare fscanf with the warn_unused_result attribute. On
such systems, turbostat generates the following warnings:
turbostat.c: In function 'get_core_id':
turbostat.c:1203:8: warning: ignoring return value of 'fscanf', declared with
attribute warn_unused_result [-Wunused-result]
turbostat uses inline assembly to call cpuid. On 32-bit x86, on systems
that have certain security features enabled by default that make -fPIC
the default, this causes a build error:
turbostat.c: In function ‘check_cpuid’:
turbostat.c:1906:2: error: PIC register clobbered by ‘ebx’ in ‘asm’
turbostat uses the format %zx to print an off_t. However, %zx wants a
size_t, not an off_t. On 32-bit targets, those refer to different
types, potentially even with different sizes. Use %llx and a cast
instead, since printf does not have a length modifier for off_t.
Without this patch, when
turbostat's Makefile puts arch/x86/include/uapi/ in the include path, so
that it can include from it. It isn't in general safe to
include even uapi headers directly from the kernel tree without
processing them through scripts/headers_install.sh, but asm/msr.h
happens to work.
However, that
On 08/10/13 15:15, Randy Dunlap wrote:
> On 08/08/13 23:15, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20130808:
>>
>> *crickets*
>>
>
> on i386:
>
> ERROR: "__divdi3" [drivers/staging/ozwpan/ozwpan.ko] undefined!
>
2 occurrences of this in oz_hcd_heartbeat().
>
>
> Apologies if
On 08/10/2013 11:51 AM, Linus Torvalds wrote:
> Note that you still want the *test* to be done in C code, because together
> with "unlikely()" you'd likely do pretty close to optimal code
> generation, and hiding the decrement and test and conditional jump in
> asm you wouldn't get the proper
ARRAY_AND_SIZE() macro is horrible, and I would like it if it were
removed. What I meant before was just that probably people will
probably complain if we try to remove it.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Fri, Aug 09, 2013 at 05:33:43PM +0200, Michael Brunner wrote:
> This patch adds DMI system IDs for the new Kontron modules COMe-bHL6 and
> COMe-cTH6 to the Kontron PLD driver.
>
> Signed-off-by: Michael Brunner
Acked-by: Kevin Strasser
> ---
> drivers/mfd/kempld-core.c | 18
On Fri, Aug 09, 2013 at 05:33:06PM +0200, Michael Brunner wrote:
> This patch changes the driver name to be consistent with the name that
> is registered as cell name in the MFD driver. Otherwise the driver won't
> load.
>
> Signed-off-by: Michael Brunner
Acked-by: Kevin Strasser
> ---
>
On Fri, Aug 09, 2013 at 05:33:26PM +0200, Michael Brunner wrote:
> This patch fixes the bit masking within the GPIO driver. The masking is
> basically done twice which causes the wrong GPIOs to be addressed.
>
> Signed-off-by: Michael Brunner
Acked-by: Kevin Strasser
> ---
>
On 08/08/13 23:15, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130808:
>
> *crickets*
>
on i386:
ERROR: "__divdi3" [drivers/staging/ozwpan/ozwpan.ko] undefined!
Apologies if this has already been reported/fixed.
--
~Randy
--
To unsubscribe from this list: send the line
On 08/09/2013 07:56 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.57 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 08/09/2013 08:00 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.0.90 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 08/09/2013 01:10 PM, Greg Kroah-Hartman wrote:
> On Fri, Aug 09, 2013 at 02:42:24PM +, Shuah Khan wrote:
>> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.10.6 release.
>>> There are 102 patches in this series, all will be posted
Arnd Bergmann wrote:
GOAL
The goal of this patch was to make it possible to configure
daemons using simple file IO. The litmus test for this is
that commands like these should be possible
cat < /var/daemons/wpa_supplicant/use_channel
echo 5
On Saturday 10 August 2013, Bob Smith wrote:
> GOAL
> The goal of this patch was to make it possible to configure
> daemons using simple file IO. The litmus test for this is
> that commands like these should be possible
> cat < /var/daemons/wpa_supplicant/use_channel
> echo 5
On Sat, Aug 10, 2013 at 11:00 PM, Tom Gundersen wrote:
> It would be simple enough to add an udev rule to just print 'ignoring
> firmware event' to the logs.
This and I guess:
SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
would also just cancel the request at the same time without
richard -rw- weinberger wrote:
GOAL
The goal of this patch was to make it possible to configure
daemons using simple file IO. The litmus test for this is
that commands like these should be possible
cat < /var/daemons/wpa_supplicant/use_channel
echo 5
--
Lieber Freund!!!
Ich vermute das diese E-Mail eine Überraschung für Sie sein wird, aber es
ist
wahr.Ich bin bei einer routinen Überprüfung in meiner Bank (StandardBank
PLC von
Süd Afrika) wo ich arbeite, auf einem Konto gestoßen, was nicht in
anspruch
genommen worden ist, wo derzeit
My name is Mr.Wright Cain,a Christian from UK. I picked your email for
inheritance of $2.5 Million US Dollars.Contact me for more details here is my
Private E-mail Address: wrightc...@yahoo.com
Thanks,
Mr.Wright Cain
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sat, 10 August 2013 20:23:09 +0200, Borislav Petkov wrote:
>
> Sounds like the debug aspect and the preemption point addition need
> to be sorf-of split into two different functions/macros and each used
> separately.
>
> Something like keep the current might_sleep and have debug_sleep or
>
On Sat, 10 Aug 2013, Pavel Machek wrote:
> [I wonder if this is clean-enough cause for "trivial in resubmit
> mode?]
On Sat, 10 Aug 2013, Belisko Marek wrote:
> Same for gta04 (omap3 based device) [1].
> It was send upstream 2 times and second time there is no reply from 1.3.2013.
Hi guys,
On Sat, Aug 10, 2013 at 10:08 PM, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
>>
>> Otherwise, to accept this code, I need to see a way that normal users
>> can use it (i.e. no root or mknod), and that it can handle namespaces
>> and the security interface that the kernel has to support. To do
On 08/10/2013 11:51 AM, Linus Torvalds wrote:
> That "kernel_stack" thing is actually getting the thread_info pointer,
> and it doesn't get cached because gcc thinks the preempt_count value
> might alias.
This is just plain braindamaged. Somewhere on my list of things is to
merge thread_info and
Greg Kroah-Hartman wrote:
Otherwise, to accept this code, I need to see a way that normal users
can use it (i.e. no root or mknod), and that it can handle namespaces
and the security interface that the kernel has to support. To do so
otherwise would be unfair to users who expect such a thing.
Hi Josep,
Perhaps both cases are related, and if you waited after those 5
minutes of resets, your pen would work fine...
Have you checked your /var/log/messages after insertion of pen?
My automount is under XFCE, not Gnome... ;)
Unclear. Messages I get seem to make sense. First, it detects
On 10 August 2013 21:58, Josep Lladonosa wrote:
> On 10 August 2013 21:52, Thomas Richter wrote:
>> Hi Josep,
>>
>>
>>> Have you tried to wait for 5 minutes? It could also be related to it
>>> what happens to my kernel 3.11.0-rc4 (and rc3) and USB
>>>
>>> I plug the drive. Only after 5 minutes
On 10.08.2013 22:03, Josep Lladonosa wrote:
I add that some usb pendrives mount immediately and some others don't...
Nope, all the same here... None works. Pen drive, hard disk, does not
matter.
Greetings,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe
On 10 August 2013 21:52, Thomas Richter wrote:
> Hi Josep,
>
>
>> Have you tried to wait for 5 minutes? It could also be related to it
>> what happens to my kernel 3.11.0-rc4 (and rc3) and USB
>>
>> I plug the drive. Only after 5 minutes of high-speed of USb bus, it
>> mounts.
>
>
> No, currently
Hi Josep,
Have you tried to wait for 5 minutes? It could also be related to it
what happens to my kernel 3.11.0-rc4 (and rc3) and USB
I plug the drive. Only after 5 minutes of high-speed of USb bus, it mounts.
No, currently I don't even depend on gnome mounting it. I don't run a
desktop. I
On 10.08.2013 14:04, Alan Stern wrote:
On Sat, 10 Aug 2013, Thomas Richter wrote:
What about other usb modules? I would
probably need a short recap on through which modules the user data flows
before the write is triggered, and which modules are involved in the
configuration of the NEC
* Raghavendra K T [2013-08-09 19:52:02]:
resending because x86_cpu_to_apicid is defined only for SMP systems.
so fold back kvm_kick_vcpu function into CONFIG_PARAVIRT_SPINLOCK that
depends on SMP. (this was taken out to for pv-flushtlb usage)
---8<---
>From
add_memory() and remove_memory() can only handle a memory range aligned
with section. There are problems when an unaligned range is added and
then deleted as follows:
- add_memory() with an unaligned range succeeds, but __add_pages()
called from add_memory() adds a whole section of pages
Being a low-level component, various drivers (e.g. olpc-battery) assume that
it is ok to communicate with the OLPC Embedded Controller during probe.
Therefore the OLPC EC driver must be initialised before other drivers try to
use it. This was the case until it was recently moved out of arch/x86
Right... I mentioned the need to move thread count into percpu and the other
restructuring... all of that seems essential for this not to suck.
Linus Torvalds wrote:
>On Sat, Aug 10, 2013 at 10:18 AM, H. Peter Anvin wrote:
>>
>> We could then play a really ugly stunt by marking NEED_RESCHED by
+ Grant
On Thu, Aug 1, 2013 at 5:10 PM, Kumar Gala wrote:
>> On Jul 29, 2013, at 4:40 PM, Stephen Boyd wrote:
>>> On 07/29, Kumar Gala wrote:
> diff --git a/Documentation/devicetree/bindings/arm/msm/tcsr-mutex.txt
> b/Documentation/devicetree/bindings/arm/msm/tcsr-mutex.txt
> new
On 10 August 2013 14:04, Alan Stern wrote:
> On Sat, 10 Aug 2013, Thomas Richter wrote:
>
>> Which modules are relevant for handling the communication with the
>> device, and where would you suggest to start looking? I assume
>> yenta_socket is one thing for the cartbus adapter, then we have
On Sunday 11 August 2013 12:19 AM, walter harms wrote:
Hello Kumar,
i will try to resolve the riddle ...
doing something like fn(a,b,c,0) is a bad habit.
0 is called a "magic number" because noone reading the code has an idea
why it is there. Using the name IRQF_TRIGGER_NONE good.
Having a
Hello Kumar,
i will try to resolve the riddle ...
doing something like fn(a,b,c,0) is a bad habit.
0 is called a "magic number" because noone reading the code has an idea
why it is there. Using the name IRQF_TRIGGER_NONE good.
Having a named bit like IRQ_TRIGGER|IRQ_NMI is most times also a good
On Sat, Aug 10, 2013 at 10:18 AM, H. Peter Anvin wrote:
>
> We could then play a really ugly stunt by marking NEED_RESCHED by adding
> 0x7fff to the counter. Then the whole sequence becomes something like:
>
> subl $1,%fs:preempt_count
> jno 1f
> call
1 - 100 of 528 matches
Mail list logo
