On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
> From: Vitaly Andrianov
>
> This patch fixes the initrd setup code to use phys_addr_t instead of assuming
> 32-bit addressing. Without this we cannot boot on systems where initrd is
> located above the 4G physical address limit.
>
> Signed-off-by:
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
> From: Vitaly Andrianov
>
> The free_memmap() was mistakenly using unsigned long type to represent
> physical addresses. This breaks on PAE systems where memory could be placed
> above the 32-bit addressible limit.
>
> This patch fixes this functi
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
> From: Vitaly Andrianov
>
> This patch fixes the alloc_init_pud() function to use phys_addr_t instead of
> unsigned long when passing in the phys argument.
>
> This is an extension to commit 97092e0c56830457af0639f6bd904537a150ea4a, which
> applied
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
> This patch adds support for 64-bit physical addresses in virt_to_phys
> patching. This does not do real 64-bit add/sub, but instead patches in the
> upper 32-bits of the phys_offset directly into the output of virt_to_phys.
You should explain _why_
* Alex Kelly wrote:
> From: Alex Kelly
>
> This was done in preparation for making core dump functionality optional.
Please use present tense and a sane title, something like:
fs: Move core dump functionality into its own file
fs: Make core dump functionality optional
While looking at t
On Wed, 2012-07-25 at 15:09 +0900, Chanwoo Choi wrote:
> Hi Mark,
>
> On 07/21/2012 01:07 AM, Mark Brown wrote:
>
> > As well as identifying accessories the accessory detection hardware on
> > Arizona class devices can also detect a number of buttons which we should
> > report via the input API.
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
> This patch fixes up the types used when converting back and forth between
> physical and virtual addresses.
>
> Signed-off-by: Vitaly Andrianov
> Signed-off-by: Cyril Chemparathy
Did you verify that this didn't introduce any compilation warning w
On Sat, Aug 04, 2012 at 08:38:35AM +0300, Artem Bityutskiy wrote:
> On Sat, 2012-08-04 at 05:46 +0100, Al Viro wrote:
> > OK... I've ported Artem's patchset on top of exofs merge; Artem, could
> > you check if you are OK with the result currently in vfs.git#for-linus?
>
> Thanks Al, yes, it looks
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
> This patch replaces the original physical offset patching implementation
> with one that uses the newly added patching framework. In the process, we now
> unconditionally initialize the __pv_phys_offset and __pv_offset globals in the
> head.S code.
The computation of page offset index is incorrect to be used in scanning
prio tree, as huge page offset is required, and is fixed with well
defined routine.
Changes from v1
o s/linear_page_index/linear_hugepage_index/ for clearer code
o hp_idx variable added for less change
Signe
The nva3 copy engine exhibits random memory corruption in at least one
case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch
omits creating the engine for the specific chipset, falling back to
M2MF, which kills the symptoms.
Signed-off-by: Henrik Rydberg
---
Hi Ben,
this patch is
Seth,
[CC'd people, sorry we exchanged a few emails with Seth outside of the
lists, I passed him the acpi tables and here are gmux dumps]
Allright. thanks for gmux-dump. There seems to be progress, as I can see
the gmux dumps for the nividia-selected and intel-selected are clearly
different
On Fri, 2012-08-03 at 13:23 -0700, Linus Torvalds wrote:
> On Thu, Aug 2, 2012 at 11:47 PM, Artem Bityutskiy wrote:
> >
> > We have had 11 of 13 pieces of the 'sync_supers()' removal patch-sets
> > merged. The 12th piece removes dead code in exofs was supposed to go
> > through the exofs tree and
On Sat, 2012-08-04 at 06:49 +0200, Mike Galbraith wrote:
> On Sat, 2012-08-04 at 00:12 -0400, valdis.kletni...@vt.edu wrote:
> > On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:
> >
> > > documentation, hopefully things will work out. And this might actually
> > > be the kick in the rear-en
On Sat, 2012-08-04 at 05:46 +0100, Al Viro wrote:
> OK... I've ported Artem's patchset on top of exofs merge; Artem, could
> you check if you are OK with the result currently in vfs.git#for-linus?
Thanks Al, yes, it looks all right.
--
Best Regards,
Artem Bityutskiy
signature.asc
Description:
On Tue, 31 Jul 2012, Cyril Chemparathy wrote:
> The original phys_to_virt/virt_to_phys patching implementation relied on early
> patching prior to MMU initialization. On PAE systems running out of >4G
> address space, this would have entailed an additional round of patching after
> switching over
On Fri, Aug 03, 2012 at 09:46:15AM -0700, Pandita, Vikram wrote:
> I mostly work with ARM Soc - specifically on OMAP. SMP multi core
> systems in ARM-v7 world started to show up only few years back -
> unlike x86 world.
This is exactly the thing: other SMP vendors have made it so far without
emitt
On Sat, 2012-08-04 at 00:12 -0400, valdis.kletni...@vt.edu wrote:
> On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:
>
> > documentation, hopefully things will work out. And this might actually
> > be the kick in the rear-end that AMD and NVIDIA need to get into gear
> > and start developer
On Fri, Aug 03, 2012 at 01:23:29PM -0700, Linus Torvalds wrote:
> On Thu, Aug 2, 2012 at 11:47 PM, Artem Bityutskiy wrote:
> >
> > We have had 11 of 13 pieces of the 'sync_supers()' removal patch-sets
> > merged. The 12th piece removes dead code in exofs was supposed to go
> > through the exofs tr
On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:
> documentation, hopefully things will work out. And this might actually
> be the kick in the rear-end that AMD and NVIDIA need to get into gear
> and start developer some useful and Windows equivalent hardware drivers
> for ALL their cards for
The wmb() inside fw_load_abort is not necessary, since
complete() and wait_on_completion() has implied one pair
of memory barrier.
Also wmb() isn't a correct usage, so just remove it.
Signed-off-by: Ming Lei
---
drivers/base/firmware_class.c |1 -
1 file changed, 1 deletion(-)
diff --git a
It is not necessary to hold the firmware memory during the whole
driver lifetime, and obviously it does waste memory. Suppose there
are 4 ath9k-htc usb dongles working, kernel has to consume about
4*50KBytes RAM to cache firmware for all dongles. After applying the
patch, kernel only caches one sin
This patch implements caching devices' firmware automatically
during system syspend/resume cycle, so any device drivers can
call request_firmware or request_firmware_nowait inside resume
path to get the cached firmware if they have loaded firmwares
successfully at least once before entering suspend
Because device_cache_fw_images only cache the firmware which has been
loaded sucessfully at leat once, using a small loading timeout should
be reasonable.
Signed-off-by: Ming Lei
---
drivers/base/firmware_class.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/base/
This patch introduces the three helpers below:
void device_cache_fw_images(void)
void device_uncache_fw_images(void)
void device_uncache_fw_images_delay(unsigned long)
so we can use device_cache_fw_images() to cache firmware for
all devices which need firmware to work, and
This patch introduces one devres API of devres_for_each_res
so that the device's driver can iterate each resource it has
interest in.
The firmware loader will use the API to get each firmware name
from the device instance.
Signed-off-by: Ming Lei
---
drivers/base/devres.c | 42 ++
This patch will store firmware name into devres list of the device
which is requesting firmware loading, so that we can implement
auto cache and uncache firmware for devices in need.
Signed-off-by: Ming Lei
---
drivers/base/firmware_class.c | 64 +
1 fil
request_firmware_nowait is allowed to be called in atomic
context now if @gfp is GFP_ATOMIC, so fix the obsolete
comments and states which situations are suitable for using
it.
Signed-off-by: Ming Lei
---
drivers/base/firmware_class.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletio
Callers of request_firmware* must hold the reference count of
@device, otherwise it is easy to trigger oops since the firmware
loader device is the child of @device.
This patch adds comments about the usage. In fact, most of drivers
call request_firmware* in its probe() or open(), so the constrain
This patches introduce two kernel APIs of cache_firmware and
uncache_firmware, both of which take the firmware file name
as the only parameter.
So any drivers can call cache_firmware to cache the specified
firmware file into kernel memory, and can use the cached firmware
in situations which can't
This patch always let firmware_buf own the pages buffer allocated
inside firmware_data_write, and add all instances of firmware_buf
into the firmware cache global list. Also introduce one private field
in 'struct firmware', so release_firmware will see the instance of
firmware_buf associated with t
This patch introduces struct firmware_buf to describe the buffer
which holds the firmware data, which will make the following
cache_firmware/uncache_firmware implemented easily.
Signed-off-by: Ming Lei
---
drivers/base/firmware_class.c | 180 +++--
1 file cha
If one device driver calls request_firmware_nowait() to request
several different firmwares' loading, device_add() will return
failure since all firmware loader device use same name of the
device who is requesting firmware.
This patch always use the name of firmware image as the firmware
loader de
This patch fixes two races in loading firmware:
1, FW_STATUS_DONE should be set before waking up the task waitting
on _request_firmware_load, otherwise FW_STATUS_ABORT may be
thought as DONE mistakenly.
2, Inside _request_firmware_load(), there is a small window between
wait_for_completion() and
This patch doesn't transfer ownership of pages' buffer to the
instance of firmware until the firmware loading is completed,
which will simplify firmware_loading_store a lot, so help
to introduce the following cache_firmware and uncache_firmware
mechanism during system suspend-resume cycle.
In fact
h 15/15 is one example to apply the firmware cache mechanism on
ath9k-htc driver.
Even there are some corener cases[3] which can't be solved by the
cache approach, but as discussed in[4], the problem can be easily
fixed by a simple patch written by Linus.
This patch set is against 3.6.0-rc
On Fri, Aug 03, 2012 at 05:37:30PM -0700, Joe Perches wrote:
> On Fri, 2012-08-03 at 11:47 -0700, Josh Triplett wrote:
> > On Fri, Aug 03, 2012 at 11:33:21AM -0700, Joe Perches wrote:
> > > On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> > > > scripts/get_maintainer.pl defaults to showing
On Fri, 2012-08-03 at 22:39 +0200, Peter Zijlstra wrote:
> Now the question is, how did that stop thing get any time to begin with?
> Are we hotplugging or somesuch sillyness?
Nope, high frequency exec.
> Anyway, I think I like B best, could you re-submit as a proper patch so
> I can press the m
From: Tim Gardner
Date: Thu, 02 Aug 2012 06:28:58 -0600
> git://kernel.ubuntu.com/rtg/net-next.git master
>
> for you to fetch changes up to 044b722f36a17bc5f7f472cc3246cb15a430bb0e:
>
> firmware: Remove obsolete Chelsio cxgb3 firmware (2012-08-02 06:23:25
> -0600)
Pulled, thanks.
--
To un
From: Randy Dunlap
Date: Fri, 03 Aug 2012 17:38:07 -0700
> From: Randy Dunlap
>
> Fix build error on cris (not tested, no toolchain here):
>
> drivers/net/cris/eth_v10.c: error: too many arguments to function
> 'e100rxtx_interrupt'
>
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Randy
From: anish kumar
External connector devices that decides connection information based on
ADC values may use adc-jack device driver. The user simply needs to
provide a table of adc range and connection states. Then, extcon
framework will automatically notify others.
Signed-off-by: anish kumar
-
On Fri, 2012-08-03 at 16:08 -0600, David Ahern wrote:
> On 8/3/12 3:52 PM, Alex Williamson wrote:
> > Is this the chunk that's causing the oops?
>
> Yes. And taking it out fixes passthrough as well.
Hey David,
One more test please. It looks like sriov creates buses with bus->self
is NULL. I th
On Fri, 03 Aug 2012, Manoj Iyer wrote:
> Oops! This is embarrassing! my logic is flawed. Please ignore this
> patch, I will resend it
Presumably with at least one sentence to let us know how well the driver
does operate on the V-series since you want it to load there ;-)
--
"One disk to rule
On Fri, Aug 3, 2012 at 6:32 PM, Randy Dunlap wrote:
> On 08/03/2012 06:15 PM, Anton Vorontsov wrote:
>
>> On Fri, Aug 03, 2012 at 05:02:48PM -0700, Randy Dunlap wrote:
>>> From: Randy Dunlap
>>>
>>> Fix printk format warning (on i386) in pstore:
>>>
>>> fs/pstore/ram.c:409:3: warning: format '%lu
On 08/03/2012 06:15 PM, Anton Vorontsov wrote:
> On Fri, Aug 03, 2012 at 05:02:48PM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap
>>
>> Fix printk format warning (on i386) in pstore:
>>
>> fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned
>> int', but argument 2 has typ
On Fri, Aug 03, 2012 at 05:02:48PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix printk format warning (on i386) in pstore:
>
> fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned
> int', but argument 2 has type 'size_t'
>
> Signed-off-by: Randy Dunlap
> Acked-b
On Thu, Aug 02, 2012 at 10:44:05AM -0600, Stephen Warren wrote:
> On 08/02/2012 05:16 AM, Laxman Dewangan wrote:
> > .desc = { \
> > + .supply_name = "sys", \
> > .name =
On 04/08/12 10:32, da...@lang.hm wrote:
On Sat, 4 Aug 2012, Chris Jones wrote:
On 04/08/12 08:44, Cruz Julian Bishop wrote:
On 04/08/12 08:12, Chris Jones wrote:
There's a lot of attention at the moment focused toward Linux and
the future of gaming support on the platform. And it got me
thin
On Fri, Aug 03, 2012 at 09:30:10AM +0100, Lee Jones wrote:
> I do agree that it should be correct, but the difference between getting
> it 90% correct and absolutely perfect increases the effort at least x2.
> With so much left to do, I think it would be better to get everything in
> and functioni
From: Randy Dunlap
Fix build error on cris (not tested, no toolchain here):
drivers/net/cris/eth_v10.c: error: too many arguments to function
'e100rxtx_interrupt'
Reported-by: Geert Uytterhoeven
Signed-off-by: Randy Dunlap
Cc: Mikael Starvik
Cc: Jesper Nilsson
Cc: linux-cris-ke
> There's nothing confusing, drivers supporting several devices are
> legion. If the devices are really almost compatible, reusing an
> existing driver is the way to go.
With that in mind, here is an alpha preview of what the patch will
look like if SIS964 support is added in i2c-sis630.
diff --
On Fri, 2012-08-03 at 11:47 -0700, Josh Triplett wrote:
> On Fri, Aug 03, 2012 at 11:33:21AM -0700, Joe Perches wrote:
> > On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> > > scripts/get_maintainer.pl defaults to showing --rolestats, which
> > > provides annotations explaining why each pe
On 08/04/2012 02:05 AM, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin wrote:
>>
>> The problem with that code was that it doesn't work with dynamically
>> allocated hashtables, or hashtables that grow/shrink.
>
> Sure. But once you have that kind of complexity, why would yo
On Sat, 4 Aug 2012, Chris Jones wrote:
On 04/08/12 08:44, Cruz Julian Bishop wrote:
On 04/08/12 08:12, Chris Jones wrote:
There's a lot of attention at the moment focused toward Linux and the
future of gaming support on the platform. And it got me thinking, is there
any particular improvement
On 04/08/12 08:44, Cruz Julian Bishop wrote:
On 04/08/12 08:12, Chris Jones wrote:
There's a lot of attention at the moment focused toward Linux and the
future of gaming support on the platform. And it got me thinking, is
there any particular improvements that are planned to improve the
kernel
On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin wrote:
>
> The problem with that code was that it doesn't work with dynamically
> allocated hashtables, or hashtables that grow/shrink.
Sure. But once you have that kind of complexity, why would you care
about the trivial cases?
Linus
--
Hello,
On Fri, Aug 03, 2012 at 04:47:47PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo wrote:
> >
> > I suppose you mean unsized. I remember this working. Maybe I'm
> > confusing it with zero-sized array. Hmm... gcc doesn't complain about
> > the following. --std=c
From: Randy Dunlap
Fix printk format warning (on i386) in pstore:
fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned int',
but argument 2 has type 'size_t'
Signed-off-by: Randy Dunlap
Acked-by: Kees Cook
Cc: Anton Vorontsov
---
I posted this patch on June 15 and July 2
Hi Linus,
On 08/04/2012 01:47 AM, Linus Torvalds wrote:
> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
>
> I really think all the extra complexity and overhead is
From: Fengguang Wu
Date: Fri, 3 Aug 2012 17:10:01 +0800
> Fix a buffer overflow bug by removing the revision and printk.
>
> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> [ 22.097508] isdnloop: (loop0) virtual card added
> [ 22.174400] Kernel panic - not syncing: stack-protector: Kerne
From: Haiyang Zhang
Date: Fri, 3 Aug 2012 12:32:18 -0700
> We need to wait for send_completion msg before put_rndis_request() at
> the end of rndis_filter_halt_device(). Otherwise, netvsc_send_completion()
> may reference freed memory which is overwritten, and cause panic.
>
> Reported-by: Long
On Fri, Aug 3, 2012 at 2:53 PM, Piotr Gluszenia Slawinski
wrote:
>>> bug is present in all kernels since late 2.6.36
>>
>>
>> can you send the boot log with working and not working kernel?
>> Please make sure you have PCI_DEBUG set in your config.
>
>
> system is ISA based :) but i've enabled it f
On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo wrote:
>
> I suppose you mean unsized. I remember this working. Maybe I'm
> confusing it with zero-sized array. Hmm... gcc doesn't complain about
> the following. --std=c99 seems happy too.
Ok, I'm surprised, but maybe it's supposed to work if you do
From: Masanari Iida
Date: Fri, 3 Aug 2012 21:36:51 +0900
> Missing a CR in printk causes 2 messages printed in one line.
>
> Signed-off-by: Masanari Iida
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
From: "John W. Linville"
Date: Fri, 3 Aug 2012 10:56:04 -0400
> This request covers a batch of fixes intended for the 3.6 stream.
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On Tue, 31 Jul 2012, Denis Efremov wrote:
> The replacement of spin_lock_irq/spin_unlock_irq pairs which
> can be called from interrupt handler by irqsave/irqrestore
> versions.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Denis Efremov
Acked-by: Guenna
Seems that Thomas' and my patches collided during the last merge
window.
Signed-off-by: Stephen Boyd
---
arch/arm/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..b528d04 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -38,7 +3
On Fri, Aug 3, 2012 at 3:36 PM, Greg KH wrote:
> On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote:
>> >> This was something that got used internally and helped at times.
>> >
>> > Could you have used the trace point instead?
>>
>> As i understood the trace_prink(), one would need to
Sorry, had to send this again so it could go to the mailing list. I
accidentally replied to you personally :\
On 04/08/12 08:12, Chris Jones wrote:
There's a lot of attention at the moment focused toward Linux and the
future of gaming support on the platform. And it got me thinking, is
there a
Now that ARM has implemented its spinlocks with tickets we don't
need to use the generic lockbreak algorithm. Remove the Kconfig
from ARM so that we use the arch_spin_is_contended() definition
from the asm header. This also saves a word in each lock because
we don't need the break_lock member anymo
On Fri, Aug 03, 2012 at 11:29:56AM +0530, Laxman Dewangan wrote:
> Device have SYS rail which is always ON. It is system
> power bus. LDO5 and LDO_RTC get powered through this rail
> internally. Add support for this rail and make the
> LDO5/LDO_RTC input supply to "sys".
> Update document according
On Fri, Aug 03, 2012 at 03:29:10PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:23 PM, Tejun Heo wrote:
> >
> > I actually meant an enclosing struct. When you're defining a struct
> > member, simply putting the storage after a struct with var array
> > should be good enough. If that d
On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote:
> >> This was something that got used internally and helped at times.
> >
> > Could you have used the trace point instead?
>
> As i understood the trace_prink(), one would need to modify existing
> printk -> trace_printk. Is my under
I applied this series on top of v3.6-rc1 and took it for
a test drive with a little storm of 20 corrected interrupts.
The series worked ... but the console log was entirely unhelpful
in letting me know what had just happened to my system. All I saw
was:
mce: [Hardware Error]: Machine check event
On Fri, Aug 3, 2012 at 3:23 PM, Tejun Heo wrote:
>
> I actually meant an enclosing struct. When you're defining a struct
> member, simply putting the storage after a struct with var array
> should be good enough. If that doesn't work, quite a few things in
> the kernel will break.
The unsigned
On 08/04/2012 12:23 AM, Tejun Heo wrote:
> Hello,
>
> On Sat, Aug 04, 2012 at 12:20:02AM +0200, Sasha Levin wrote:
>> On 08/03/2012 11:48 PM, Tejun Heo wrote:
>>> On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
I forgot to comment on that one, sorry.
If we put hash entr
On Fri, Aug 3, 2012 at 3:13 PM, Greg KH wrote:
> On Fri, Aug 03, 2012 at 03:07:39PM -0700, Pandita, Vikram wrote:
>> On Fri, Aug 3, 2012 at 2:59 PM, Greg KH wrote:
>> > On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote:
>> >> Aaro
>> >>
>> >> On Fri, Aug 3, 2012 at 1:08 PM, Aaro Kos
Hello,
On Sat, Aug 04, 2012 at 12:20:02AM +0200, Sasha Levin wrote:
> On 08/03/2012 11:48 PM, Tejun Heo wrote:
> > On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
> >> I forgot to comment on that one, sorry.
> >>
> >> If we put hash entries after struct hash_table we don't take the
>
On 08/03/2012 11:48 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
>> I forgot to comment on that one, sorry.
>>
>> If we put hash entries after struct hash_table we don't take the
>> bits field size into account, or did I miss something?
>
> So, if
There's a lot of attention at the moment focused toward Linux and the
future of gaming support on the platform. And it got me thinking, is
there any particular improvements that are planned to improve the kernel
from better support for gaming?
Regards
--
Chris Jones @ kernel.devproj.
On Fri, Aug 03, 2012 at 03:07:39PM -0700, Pandita, Vikram wrote:
> On Fri, Aug 3, 2012 at 2:59 PM, Greg KH wrote:
> > On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote:
> >> Aaro
> >>
> >> On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen wrote:
> >> > Hi,
> >> >
> >> > On Fri, Aug 03,
On Sat, Aug 04, 2012 at 03:30:44AM +0530, Akhilesh Kumar wrote:
> Hi Hartman
>
> This patch just exports debugfs_file_operations which improve debugfs
> interface .
> Please review below patch for main line and share your review comments.
>
> Thanks,
> Akhilesh
>
>
>
>
> From fd68900cd32f220b
On 8/3/12 3:52 PM, Alex Williamson wrote:
Is this the chunk that's causing the oops?
Yes. And taking it out fixes passthrough as well.
David
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 7469b53..27d8c97 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/
On Fri, Aug 3, 2012 at 2:59 PM, Greg KH wrote:
> On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote:
>> Aaro
>>
>> On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen wrote:
>> > Hi,
>> >
>> > On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
>> >> > And really: Wasting 1/3
On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote:
> Aaro
>
> On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen wrote:
> > Hi,
> >
> > On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
> >> > And really: Wasting 1/3 of the 80 character line is too much.
> >>
> >> You _WAS
bug is present in all kernels since late 2.6.36
can you send the boot log with working and not working kernel?
Please make sure you have PCI_DEBUG set in your config.
system is ISA based :) but i've enabled it for sake of clarity.
logs are attached
both systems are 3.5 kernel, working is one
On Fri, 2012-08-03 at 15:12 -0600, David Ahern wrote:
> On 8/3/12 2:21 PM, Alex Williamson wrote:
> > On Fri, 2012-08-03 at 11:39 -0600, David Ahern wrote:
> >> Hi Alex:
> >>
> >> Hitting an oops with 3.6-rc1. Backtrace from console attached. git blame
> >> for the top function points to ad805758.
Hello,
On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
> I forgot to comment on that one, sorry.
>
> If we put hash entries after struct hash_table we don't take the
> bits field size into account, or did I miss something?
So, if you do the following,
struct {
Hello, Sasha.
On Fri, Aug 03, 2012 at 11:36:49PM +0200, Sasha Levin wrote:
> On 08/03/2012 11:30 PM, Tejun Heo wrote:
> The function definition itself is just a macro, for example:
>
> #define MM_SLOTS_HASH_CMP(mm_slot, obj) ((mm_slot)->mm == (obj))
It seems like it would make things more
On 08/03/2012 11:30 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Aug 03, 2012 at 11:19:57PM +0200, Sasha Levin wrote:
>>> Is this supposed to be embedded in struct definition? If so, the name
>>> is rather misleading as DEFINE_* is supposed to define and initialize
>>> stand-alone constructs. Also,
On 08/03/2012 12:57 PM, Jean Delvare wrote:
> Hi Randy,
>
> On Fri, 03 Aug 2012 10:24:34 -0700, Randy Dunlap wrote:
>> on x86_64:
>>
>> when CONFIG_GPIOLIB is not enabled:
>>
>> drivers/i2c/busses/i2c-i801.c: In function 'match_gpio_chip_by_label':
>> drivers/i2c/busses/i2c-i801.c:1011:21: error:
On 08/03/2012 11:30 PM, Tejun Heo wrote:
>> I think hash_for_for_each_possible() is useful if the comparison
>> > condition is more complex than a simple comparison of one of the
>> > object members with the key - there's no need to force it on all the
>> > users.
> I don't know. What's the differ
Hello,
On Fri, Aug 03, 2012 at 11:19:57PM +0200, Sasha Levin wrote:
> > Is this supposed to be embedded in struct definition? If so, the name
> > is rather misleading as DEFINE_* is supposed to define and initialize
> > stand-alone constructs. Also, for struct members, simply putting hash
> > en
Aaro
On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
>> > And really: Wasting 1/3 of the 80 character line is too much.
>>
>> You _WASTE_ 4 chars only if you are interested in this info by
>> enabling: CONFIG_PRINTK_C
From: Mikael Pettersson
commit c663600584a596b5e66258cc10716fb781a5c2c9 upstream.
Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the
`nfeth' ethernet device triggers a WARN_ONCE() in generic irq
handling code on the first irq for that device:
WARNING: at kernel/irq/handle.c:146 handle_
On 08/03/2012 07:15 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Fri, Aug 03, 2012 at 04:23:02PM +0200, Sasha Levin wrote:
>> +#define DEFINE_STATIC_HASHTABLE(n, b)
>> \
>> +static struct hash_table n = { .bits = (b), \
>> +
On 08/03/2012 08:00 PM, Eric Dumazet wrote:
> On Fri, 2012-08-03 at 16:23 +0200, Sasha Levin wrote:
>> /* initialize hash table */
>> -for (bucket = 0; bucket < ERRHASHSZ; bucket++)
>> -INIT_HLIST_HEAD(&hash_errmap[bucket]);
>> +hash_init(&hash_errmap, ERRHASHSZ);
>
> Why
From: Alex
Adds an expert Kconfig option, CONFIG_COREDUMP, which allows disabling of core
dump.
This saves approximately 2.6k in the compiled kernel, and complements
CONFIG_ELF_CORE,
which now depends on it.
CONFIG_COREDUMP also disables coredump-related sysctls, except for
suid_dumpable and
From: Alex Kelly
This was done in preparation for making core dump functionality optional.
The variable "suid_dumpable" and associated functions are left in fs/exec.c
because they're used elsewhere, such as in ptrace.
Signed-off-by: Alex Kelly
Reviewed-by: Josh Triplett
---
fs/Makefile
On Fri, Aug 03, 2012 at 01:31:44PM -0700, Paul E. McKenney wrote:
> On Fri, Aug 03, 2012 at 04:09:39PM -0400, Steven Rostedt wrote:
> > On Fri, 2012-08-03 at 21:45 +0200, Ingo Molnar wrote:
> > > * Frederic Weisbecker wrote:
> > >
> > > > Create a new subsystem that handles the probing on kernel
1 - 100 of 487 matches
Mail list logo
