Mikulas,
> nvidia binary driver, but it may happen in other parts of the kernel too.
> The fact that it works in your setup doesn't mean that it is correct.
You are right. I am convinced.
As far as I looked around the kernel code,
it seems to be choosing kthread when one needs looping in backgro
Dave,
> That's where arbitrary delays in the storage stack below XFS cause
> problems - if the first FUA log write is delayed, the next log
> buffer will get filled, issued and delayed, and when we run out of
> log buffers (there are 8 maximum) the entire log subsystem will
> stall, stopping *all*
On Sat, Oct 05, 2013 at 06:10:54AM +, Dilger, Andreas wrote:
> >With modern kernels, the /dev/random driver has the
> >add_device_randomness() interface which is used to mix in
> >personalization information, which includes the network MAC address.
> >So that particular concern should be covere
On Sat, Oct 05, 2013 at 10:21:21AM -0400, Theodore Ts'o wrote:
> add_device_randomness() is called from __dev_open() and
> dev_set_mac_address() in net/core/dev.c. This is above the ethernet
> and infiniband level. So as long as it looks like a Linux network
> device, and they are setting the har
The following changes since commit 15c03dd4859ab16f9212238f29dd315654aa94f6:
Linux 3.12-rc3 (2013-09-29 15:02:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
tags/staging-3.12-rc4
for you to fetch changes up to 677a3156569
Hi Laurent,
Thanks for the patch! Some comments below.
On Thu, Oct 03, 2013 at 01:55:28AM +0200, Laurent Pinchart wrote:
...
> +int omap4iss_get_external_info(struct iss_pipeline *pipe,
> +struct media_link *link)
> +{
> + struct iss_device *iss =
> + c
On Sat, 5 Oct 2013, Akira Hayakawa wrote:
> Mikulas,
>
> > nvidia binary driver, but it may happen in other parts of the kernel too.
> > The fact that it works in your setup doesn't mean that it is correct.
> You are right. I am convinced.
>
> As far as I looked around the kernel code,
> it s
Hi
I looked at dm-writeboost source code and here I'm sending the list of
problems I found:
Polling for state
-
Some of the kernel threads that you spawn poll for data in one-second
interval - see migrate_proc, modulator_proc, recorder_proc, sync_proc.
flush_proc correctly co
Mikulas,
> The change seems ok. Please, also move this piece of code in flush_proc
> out of the spinlock:
> if (kthread_should_stop())
> return 0;
>
> It caused the workqueue warning I reported before and still causes warning
> with kthread
On Fri, Oct 04, 2013 at 07:31:03AM +0530, Varun B Patil wrote:
> ioctl_codec_process was calling get_paddr() with a wrong pointer as
> argument which resulted in wrong req_id being used to get the transaction
> inside get_paddr().
>
> Signed-off-by: Varun B Patil
> ---
> drivers/staging/omapdce/
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/s
11 matches
Mail list logo