Hi Alexandre,
On Fri, Jun 28, 2013 at 03:02:52PM +0200, Alexandre Belloni wrote:
> From: Brian Lilly
>
> The CFA-10058 is a breakout board for the CFA-10036 that has Ethernet, USB
> and a
> 5" LCD screen on it.
>
> Signed-off-by: Brian Lilly
> Signed-off-by: Alexandre Belloni
Acked-by: Maxi
On Fri, Jun 28, 2013 at 03:02:53PM +0200, Alexandre Belloni wrote:
> Signed-off-by: Alexandre Belloni
Acked-by: Maxime Ripard
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
On Sat, 2013-06-29 at 07:36 +0800, Joe Jin wrote:
> Hi Eric,
>
> The patch not fix the issue and panic as same as early I posted:
At least it fixes my own panics ;)
My test bed was :
Launch 24 concurrent "netperf -t UDP_STREAM -H destination -- -m 128"
Then on "destination" disconnect the eth
Hi Alexandre
On Fri, Jun 28, 2013 at 03:02:54PM +0200, Alexandre Belloni wrote:
> Signed-off-by: Alexandre Belloni
Acked-by: Maxime Ripard
With one minor comment, that applies to your other patches as well.
> ---
> arch/arm/boot/dts/imx28-cfa10037.dts | 19 ++-
> 1 file change
On Fri, Jun 28, 2013 at 03:02:55PM +0200, Alexandre Belloni wrote:
> Signed-off-by: Alexandre Belloni
Acked-by: Maxime Ripard
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
On Fri, Jun 28, 2013 at 03:02:56PM +0200, Alexandre Belloni wrote:
> Signed-off-by: Alexandre Belloni
Acked-by: Maxime Ripard
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
On Fri, Jun 28, 2013 at 03:02:57PM +0200, Alexandre Belloni wrote:
> Necessary pins are now grabbed by respective drivers. Unecessary hogpins are
> simply removed.
>
> Signed-off-by: Alexandre Belloni
Acked-by: Maxime Ripard
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android
On Fri, Jun 28, 2013 at 03:02:51PM +0200, Alexandre Belloni wrote:
> From: Brian Lilly
>
> The CFA-10056 is a breakout board for the CFA-10036, and is
> basically a CFA-10037, with a 4.3" screen.
>
> Signed-off-by: Brian Lilly
> Signed-off-by: Alexandre Belloni
> ---
> arch/arm/boot/dts/Makef
* Tim Chen wrote:
> > If my analysis is correct so far then it might be useful to add two
> > more stats: did rwsem_spin_on_owner() fail because lock->owner == NULL
> > [owner released the rwsem], or because owner_running() failed [owner
> > went to sleep]?
>
> Ingo,
>
> I tabulated the cas
Op 28-06-13 22:13, Davidlohr Bueso schreef:
> From: Davidlohr Bueso
>
> Upon entering the slowpath, we immediately attempt to acquire the lock
> by checking if it is already unlocked. If we are lucky enough that this
> is the case, then we don't need to deal with any waiter related logic.
>
> Furt
* jba...@akamai.com wrote:
> Hi,
>
> As pointed out by Andi Kleen, some static key users can be racy because they
> check the value of the key->enabled, and then subsequently update the branch
> direction. A number of call sites have 'higher' level locking that avoids this
> race, but the usage
On Sat, 2013-06-29 at 07:36 +0800, Joe Jin wrote:
> Hi Eric,
>
> The patch not fix the issue and panic as same as early I posted:
> > BUG: unable to handle kernel paging request at 88006d9e8d48
> > IP: [] memcpy+0xb/0x120
> > PGD 1798067 PUD 1fd2067 PMD 213f067 PTE 0
> > Oops: [#1] SMP
>
* Nathan Zimmer wrote:
> On 06/26/2013 10:35 PM, Daniel J Blueman wrote:
> >On Wednesday, June 26, 2013 9:30:02 PM UTC+8, Andrew Morton wrote:
> >>
> >> On Wed, 26 Jun 2013 11:22:48 +0200 Ingo Molnar
> > wrote:
> >>
> >> > except that on 32 TB
> >> > systems we don't spend ~2 hours initializing
On (06/28/13 19:43), Srivatsa S. Bhat wrote:
> On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
> > Hello,
> > Yes, this helps, of course, but at the same time it returns the previous
> > problem -- preventing cpu_hotplug in some places.
> >
> >
> > I have a bit different (perhaps naive) RFC pat
[v3->v4]:
1. use "bool enabled = is_trace_uprobe_enabled(tu);", suggested by Oleg.
2. use list_add_tail_rcu instead of list_add_rcu, suggested by Masami.
3. fix the error handling in probe_event_enable, found by Srikar.
---
Support multi-buffer on uprobe-based dynamic events by
us
Hi,
The same .config file, also report the compiling error below:
drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of function
‘iowrite8’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:86:2: error: implicit declaration of function
‘iowrite16’ [-Werror
On Sat, Jun 29, 2013 at 07:54:20AM +0200, Andreas Hartmann wrote:
> Sorry, but it doesn't work for me at all :-(. Behaviour is unchanged. It
> is exactly as described in the other mail: at the moment of binding vfio
> to 14.0, the fire begins.
Hmm, VFIO attaches the device to a new domain. That cl
On Sat, Jun 29, 2013 at 10:01 AM, Michael Schmitz wrote:
>> The same .config file, also report the compiling error below:
>>
>> drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of
>> function ‘iowrite8’ [-Werror=implicit-function-declaration]
>> drivers/i2c/busses/i2c-ocores.c:86:
Joerg Roedel schrieb:
On Sat, Jun 29, 2013 at 07:54:20AM +0200, Andreas Hartmann wrote:
Sorry, but it doesn't work for me at all :-(. Behaviour is unchanged. It
is exactly as described in the other mail: at the moment of binding vfio
to 14.0, the fire begins.
Hmm, VFIO attaches the device to a
After pread(), file->f_pos and m->read_pos get different,
and lseek() to m->read_pos did not update file->f_pos, then
a subsequent read may read from a wrong position, the following
program shows the problem:
char str1[32] = { 0 };
char str2[32] = { 0 };
int poffset = 10;
int count
On 2013/6/29 13:08, Tom Zanussi wrote:
> Hi,
>
> This is v2 of the trace event triggers patchset, addressing comments
> from Masami Hiramatsu, zhangwei(Jovi), and Steve Rostedt (thanks for
> reviewing v1).
>
> v2:
> - removed all changes to __ftrace_event_enable_disable() (except
>for patch
Intuos4 WL is separately reporting power supply and battery
charging status - now hid-wacom is using that information.
Previously hid-wacom was wrongly treating "battery charging" bit
as "power supply connected". Now it should report battery charging,
battery discharging, battery full and power sup
On Friday, June 28, 2013 04:34:21 PM Yinghai Lu wrote:
> On Fri, Jun 28, 2013 at 3:53 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > The ACPI dock driver uses register_acpi_bus_notifier() which
> > installs a notifier triggered globally for all system notifications.
> > That fir
On 06/24/2013 01:30 PM, Otavio Salvador wrote:
> On Sat, Jun 22, 2013 at 8:03 AM, Jonathan Cameron wrote:
>>> From what I could grasp, it might be related to the IIO subsystem but
>>> I couldn't find the culprit.
>>>
>>> It seems "iio_device_unregister_trigger_consumer", as:
>>>
>>> void iio_devic
On Sat, Jun 29, 2013 at 12:04:19PM +0800, Axel Lin wrote:
> The code in max77693_pmic_dt_parse_rdata() does skip setting rdata if
> !rmatch[i].init_data. So we may have some empty entries in rdata[].
> We need to skip register regulator if no platform initialization data,
> otherwise we may resiter
Hi Stefan,
Il 28/06/2013 22:08, Stefan Lippers-Hollmann ha scritto:
Hi
On Friday 28 June 2013, Riccardo Magliocchetti wrote:
Hello,
at boot udev (175-7.2 from debian unstable) blocks for maybe 30 seconds
and then gives (handcopied)
timeout: killing '/sbin/modprobe -b
pci:v8086d293
The kernel does not expose precise start time anywhere. Precision of
sysinfo() is limited to a second. The /proc/uptime has precision of two
decimals. Neither are good enough when klog messages are displayed with
a log time stamp that is converted to human understandable format, such
as ISO-8601
Hi,
bouncing this mail because originally my mail address was mangled due to MUA
misconfig.
Sorry
Marcus
On Mo, Jun 24, 2013 at 09:12:03PM +0200, Marcus Gelderie wrote:
> Hi,
>
> there seems to be a race condition in kernel/time/alarmtimer.c
>
> More specifically, the following function (lin
On Thu, 27 Jun 2013 22:30:41 -0700, Randy Dunlap said:
> + __ret = __wait_no_timeout(tout) ?: (tout) ?: 1;
Was this trying to do a wait_ho_timeout(!!tout) or something?
pgpc10X8PW5FX.pgp
Description: PGP signature
From: Kees Cook
The parsing routines for Kconfig files use strtol(), but store and
render values as int. Switch types and formating to long to support a
wider range of values. For example, 0x8000 wasn't representable.
Signed-off-by: Kees Cook
Tested-by: "Yann E. MORIN"
Reviewed-by: "Yann E
From: "Yann E. MORIN"
Hello Michal, All,
Please pull this kconfig fix from Kees that enables 64-bit-wide
(ie. signed long) [int,hex] ranges.
Regards,
Yann E. MORIN.
The following changes since commit 490f16171119a16e05d670306c105f3b45c38837:
Revert "kconfig: fix randomising choice entries
On Sat, 2013-06-29 at 00:53 +0100, Lorenzo Pieralisi wrote:
> On Fri, Jun 28, 2013 at 07:51:57PM +0100, Kamal Mostafa wrote:
> > 3.8.13.4 -stable review patch. If anyone has any objections, please let me
> > know.
>
> Owing to dependencies on other patches getting upstreamed but not
> necessaril
Nacked-by: "Eric W. Biederman"
The pach does not solve the problem described.
Sami Kerola writes:
> The kernel does not expose precise start time anywhere. Precision of
> sysinfo() is limited to a second. The /proc/uptime has precision of two
> decimals. Neither are good enough when klog m
On 06/29/2013 02:51 AM, Kamal Mostafa wrote:
> 3.8.13.4 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Aaron Lu
>
> commit 44521527be36172864e6e7a6fba4b66e9aa48e40 upstream.
>
> Commit 30dcf76acc69 "libata: migrate ACPI code over to
Add preempt_disable_strict and preempt_enable_strict functions that
can be used to demarcate atomic sections for which we would like
to enforce -even on non-PREEMPT builds with CONFIG_DEBUG_ATOMIC_SLEEP
disabled- that sleeping is not allowed.
The rationale is that in some cases, the risk of data c
Hello,
I haven't looked at bootmem for a while so could be a bit out of touch
but a couple questions.
On Fri, Jun 28, 2013 at 09:01:03PM -0400, Santosh Shilimkar wrote:
> - Started replacing bootmem_* usage with dirty hacked memblock based API.
> This can be letter wrapped with only needed parame
On 06/29/2013 12:20 AM, Eric Dumazet wrote:
On Sat, 2013-06-29 at 07:36 +0800, Joe Jin wrote:
Hi Eric,
The patch not fix the issue and panic as same as early I posted:
BUG: unable to handle kernel paging request at 88006d9e8d48
IP: [] memcpy+0xb/0x120
PGD 1798067 PUD 1fd2067 PMD 213f067 PT
On Sat, Jun 29, 2013 at 4:16 AM, Rafael J. Wysocki wrote:
> On Friday, June 28, 2013 04:34:21 PM Yinghai Lu wrote:
>> On Fri, Jun 28, 2013 at 3:53 PM, Rafael J. Wysocki wrote:
>> > From: Rafael J. Wysocki
>> >
>> > The ACPI dock driver uses register_acpi_bus_notifier() which
>> > installs a noti
On Sat, 2013-06-29 at 09:11 -0700, Ben Greear wrote:
> Do you know if your patch should go in 3.9?
>
Yes it should.
> Your test case sounds a bit like what gives us the rare crash in tcp_collapse
> (we have lots of bouncing wifi interfaces running slow-speed TCP trafic).
> But,
> it takes day
On 06/29/2013 09:26 AM, Eric Dumazet wrote:
On Sat, 2013-06-29 at 09:11 -0700, Ben Greear wrote:
Do you know if your patch should go in 3.9?
Yes it should.
Ok, I'll add that to my tree.
Your test case sounds a bit like what gives us the rare crash in tcp_collapse
(we have lots of bouncin
The implementation in of_regulator_match() already ensures match->init_data is
not NULL for all matched cases if the return value of of_regulator_match() > 0.
Thus remove NULL test for rmatch[i].init_data.
This patch also fixes the condition for loop iteration.
The for loop should iterate "matche
Hello, Tim.
On Fri, Jun 28, 2013 at 11:44:23AM -0700, Tim Hockin wrote:
> I totally understand where you're coming from - trying to get back to
> a stable feature set. But it sucks to be on the losing end of that
Oh, it has been sucking and will continue to suck like hell for me too
for the fore
On Sat, Jun 29, 2013 at 08:29:59AM -0700, Tejun Heo wrote:
> I suppose LPAE on arm is analogous to PAE on x86, IOW, high memory?
> This does affect memory initilization as you need to register memory
> areas which aren't addressable directly; however, why does it affect
> generic code which is just
Hi,
This is the fifth iteration of Pavel Emelyanov's patch-set implementing
write-back policy for FUSE page cache. Initial patch-set description was
the following:
One of the problems with the existing FUSE implementation is that it uses the
write-through cache policy which results in performance
From: Pavel Emelyanov
The .writepages callback will issue writeback requests with more than one
page aboard. Make existing end/check code be aware of this.
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff
From: Pavel Emelyanov
There will be a .writepageS callback implementation which will need to
get a fuse_file out of a fuse_inode, thus make a helper for this.
Signed-off-by: Maxim Patlasov
Signed-off-by: Pavel Emelyanov
---
fs/fuse/file.c | 24
1 files changed, 16 i
From: Pavel Emelyanov
A helper which gets called when read reports less bytes than was requested.
See patch #6 (trust kernel i_size only) for details.
Signed-off-by: Maxim Patlasov
Signed-off-by: Pavel Emelyanov
---
fs/fuse/file.c | 21 +
1 files changed, 13 insertions(+
From: Pavel Emelyanov
Off (0) by default. Will be used in the next patches and will be turned
on at the very end.
Signed-off-by: Maxim Patlasov
Signed-off-by: Pavel Emelyanov
---
fs/fuse/fuse_i.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/fuse/fuse_i.h b/fs/
From: Pavel Emelyanov
When writeback is ON every writeable file should be in per-inode write list,
not only mmap-ed ones. Thus introduce a helper for this linkage.
Signed-off-by: Maxim Patlasov
Signed-off-by: Pavel Emelyanov
---
fs/fuse/file.c | 33 +++--
1 files
From: Pavel Emelyanov
Make fuse think that when writeback is on the inode's i_size is always
up-to-date and not update it with the value received from the userspace.
This is done because the page cache code may update i_size without letting
the FS know.
This assumption implies fixing the previou
From: Pavel Emelyanov
The .writepages one is required to make each writeback request carry more than
one page on it. The patch enables optimized behaviour unconditionally,
i.e. mmap-ed writes will benefit from the patch even if fc->writeback_cache=0.
Signed-off-by: Maxim Patlasov
---
fs/fuse/f
From: Pavel Emelyanov
The .write_begin and .write_end are requiered to use generic routines
(generic_file_aio_write --> ... --> generic_perform_write) for buffered
writes.
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 97
1 files
Move the code filling and sending read request to a separate function. Future
patches will use it for .write_begin -- partial modification of a page
requires reading the page from the storage very similarly to what fuse_readpage
does.
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 55 +
Sorry for not commenting earlier, I was traveling and keeping email to
a minimum..
On Wed, Jun 26, 2013 at 10:43 AM, Waiman Long wrote:
> This patch introduces a new spinlock_refcount.h header file to be
> included by kernel code that want to do a lockless update of reference
> count protected by
Let the kernel maintain i_mtime locally:
- clear S_NOCMTIME
- implement i_op->update_time()
- flush mtime on fsync and last close
- update i_mtime explicitly on truncate and fallocate
Fuse inode flag FUSE_I_MTIME_UPDATED serves as indication that local i_mtime
should be flushed to the server e
fuse_writepage_locked() should never submit new i/o for given page->index
if there is another one 'in progress' already. In most cases it's safe to
wait on page writeback. But if it was called due to memory shortage
(WB_SYNC_NONE), we should redirty page rather than blocking caller.
Signed-off-by:
From: Pavel Emelyanov
Any write request requires a file handle to report to the userspace. Thus
when we close a file (and free the fuse_file with this info) we have to
flush all the outstanding dirty pages.
filemap_write_and_wait() is enough because every page under fuse writeback
is accounted i
From: Pavel Emelyanov
The problem is:
1. write cached data to a file
2. read directly from the same file (via another fd)
The 2nd operation may read stale data, i.e. the one that was in a file
before the 1st op. Problem is in how fuse manages writeback.
When direct op occurs the core kernel co
From: Pavel Emelyanov
Introduce a bit kernel and userspace exchange between each-other on
the init stage and turn writeback on if the userspace want this and
mount option 'allow_wbcache' is present (controlled by fusermount).
Also add each writable file into per-inode write list and call the
gen
The aim of .flush fop is to hint file-system that flushing its state or caches
or any other important data to reliable storage would be desirable now.
fuse_flush() passes this hint by sending FUSE_FLUSH request to userspace.
However, dirty pages and pages under writeback may be not visible to users
From: Miklos Szeredi
The feature prevents mistrusted filesystems to grow a large number of dirty
pages before throttling. For such filesystems balance_dirty_pages always
check bdi counters against bdi limits. I.e. even if global "nr_dirty" is under
"freerun", it's not allowed to skip bdi checks.
( Expanding cc list, original thread is at
http://thread.gmane.org/gmane.linux.kernel/1518046 )
Hello,
On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, some
On Sat, Jun 29, 2013 at 09:24:41AM +0200, Ingo Molnar wrote:
>
> * Nathan Zimmer wrote:
>
> > On 06/26/2013 10:35 PM, Daniel J Blueman wrote:
> > >On Wednesday, June 26, 2013 9:30:02 PM UTC+8, Andrew Morton wrote:
> > >>
> > >> On Wed, 26 Jun 2013 11:22:48 +0200 Ingo Molnar
> > > wrote:
> > >>
>
On Fri, Jun 28, 2013 at 10:45:12PM +0100, Lorenzo Pieralisi wrote:
> On Fri, Jun 28, 2013 at 09:05:42PM +0100, Olof Johansson wrote:
> > On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard
> > wrote:
> > > On Fri, Jun 28, 2013 at 06:15:32PM +0100, Lorenzo Pieralisi wrote:
> > >> On Fri, Jun 28, 2013 at
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich wrote:
>
> 3.10-rc7 doesn't compile for me
>
> rathamahata@piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage
> modules
> make[1]: Nothing to be done for `all'.
> make[1]: Nothing to be done for `relocs'.
> CHK include/generated/uap
3 makes sense to me.
Tejun Heo wrote:
>( Expanding cc list, original thread is at
> http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
>Hello,
>
>On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux
>wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
On Fri, Jun 28, 2013 at 6:49 AM, Mathieu Desnoyers
wrote:
> This __put_user() could be used by unprivileged processes to write into
> kernel memory. The issue here is that even if copy_siginfo_to_user()
> fails, the error code is not checked before __put_user() is executed.
> Luckily, ptrace_peek_
You know, either the "long" or the "offline" SMART test routines do exactly
that on any spinning rust device with a firmware that is not utterly broken.
The HDD's firmware will rewrite, and even reallocate any "weak" sectors
found by the surface scan.
--
"One disk to rule them all, One disk to
On 28/06/2013 19:51, Ben Hutchings wrote:
On Fri, 2013-06-28 at 15:59 +0300, Eliezer Tamir wrote:
Our use of sched_clock is OK because we don't mind the side effects
of calling it and occasionally waking up on a different CPU.
Sure about that? Jitter matters too.
Pretty sure, this is a limi
On Sat, Jun 29, 2013 at 07:07:30PM +0100, Maxime Ripard wrote:
> On Fri, Jun 28, 2013 at 10:45:12PM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Jun 28, 2013 at 09:05:42PM +0100, Olof Johansson wrote:
> > > On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard
> > > wrote:
> > > > On Fri, Jun 28, 2013 at
On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo wrote:
> ( Expanding cc list, original thread is at
> http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
> Hello,
>
> On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
>> Unfortunately, that has not been true on ARM - it's v
On Fri, Jun 28, 2013 at 01:05:42PM -0700, Olof Johansson wrote:
> On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard
> wrote:
> > On Fri, Jun 28, 2013 at 06:15:32PM +0100, Lorenzo Pieralisi wrote:
> >> The patch above should already be queued in next/dt right ?
> >
> > Indeed.
> >
> > Then why the lat
On Fri, Jun 28, 2013 at 6:45 PM, Brian Gitonga Marete
wrote:
> On Fri, Jun 28, 2013 at 3:55 PM, Deucher, Alexander
> wrote:
>>
>> Can you bisect?
>>
>
Hello Alexander,
So, it turns out that it is not so easy to reproduce this issue. I
have been trying to reproduce it with the exact revision of
Hi all,
I hate to say it, but this regression from 3.9 is still present in
3.10-rc7 :-(
Am 19.06.2013 11:02, schrieb Stefan Seyfried:
> The suspend/resume failure is easily reproduced by
>
> * booting with "init=/bin/bash no_console_suspend"
> * mount /sys
> * echo mem > /sys/power/state
> * res
On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo wrote:
> > ( Expanding cc list, original thread is at
> > http://thread.gmane.org/gmane.linux.kernel/1518046 )
> >
> > Hello,
> >
> > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King -
On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
wrote:
> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>> >> On these SoCs which Santosh is working on, the main physical memory
>> >> mapping is above 4GB, with just a small alias below 4GB to allow the
>> >> system to boot
On Sat, Jun 29, 2013 at 08:38:19PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 28, 2013 at 01:05:42PM -0700, Olof Johansson wrote:
> > On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard
> > wrote:
> > > On Fri, Jun 28, 2013 at 06:15:32PM +0100, Lorenzo Pieralisi wrote:
> > >> The patch above
From: Rob Landley
Mounting MS_NOUSER prevents --bind mounts from rootfs. Prevent new rootfs
mounts with a different mechanism that doesn't affect bind mounts.
Signed-off-by: Rob Landley
---
fs/ramfs/inode.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/ramf
From: Rob Landley
Conditionally call the appropriate fs_init function and fill_super functions.
Add a use once guard to shmem_init() to simply succeed on a second call.
(Note that IS_ENABLED() is a compile time constant so dead code elimination
removes unused function calls when CONFIG_TMPFS is
From: Rob Landley
When the rootfs code was a wrapper around ramfs, having them in the same
file made sense. Now that it can wrap another filesystem type, move it
in with the init code instead.
This also allows a subsequent patch to access rootfstype= command line arg.
Signed-off-by: Rob Landley
From: Rob Landley
Command line option rootfstype=ramfs to obtain old initramfs behavior,
and use ramfs instead of tmpfs for stub when root= defined (for cosmetic
reasons).
Signed-off-by: Rob Landley
---
init/do_mounts.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
From: Rob Landley
Even though ramfs hasn't got a backing device, commit e0bf68ddec4f added one
anyway, and put the initialization in init_rootfs() since that's the first
user, leaving it out of init_ramfs() to avoid duplication.
But initmpfs uses init_tmpfs() instead, so move the init into the f
On Fri, Jun 28, 2013 at 01:58:25PM +1000, Dave Chinner wrote:
> > Oh, that's easy enough to fix. It's just changing the wait_sb_inodes
> > loop to use a spin_trylock(&inode->i_lock), moving the inode to
> > the end of the sync list, dropping all locks and starting again...
>
> New version be
Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
Specify rootfstype=ramfs to get the old initramfs behavior.
The previous initramfs code provided a fairly crappy root filesystem:
didn't let you --bind mount directories out of it, reported zero
size/usage so it didn't show up in "df"
Add support for HPB-DMAC found in Renesas R-Car SoCs, using 'shdma-base' DMA
driver framework.
Based on the original patch by Phil Edworthy .
Signed-off-by: Max Filippov
[Sergei: removed useless #include, sorted #include's, fixed HPB_DMA_TCR_MAX,
fixed formats and removed line breaks in the dev
On 06/29/2013 01:45 PM, Linus Torvalds wrote:
Sorry for not commenting earlier, I was traveling and keeping email to
a minimum..
On Wed, Jun 26, 2013 at 10:43 AM, Waiman Long wrote:
This patch introduces a new spinlock_refcount.h header file to be
included by kernel code that want to do a lock
--
Seven Hundred and Fifty Thousand usd deposit alert from Western Union. Send
Your Name, Telephone Number, Country, Occupation
--
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 http://vger.ke
On 06/28/2013 09:46 AM, Thomas Gleixner wrote:
On Thu, 27 Jun 2013, Waiman Long wrote:
On 06/26/2013 09:37 PM, Andi Kleen wrote:
It will be hard to know what changes will be needed without knowing
the exact semantics of the spinlock functions with lock elision. Can
you explain a little more wha
Hi,
On 14 February 2013 21:12, Greg KH wrote:
> I'm announcing the release of the 3.7.8 kernel.
I've got issues with my radeon GPU on 3.7.8
...
[ 20.944106] BUG: unable to handle kernel NULL pointer dereference
at 01f8
[ 20.945753] IP: [] radeon_vm_bo_add+0xb3/0x110
[ 20.946498
On 29 June 2013 15:23, Eric W. Biederman wrote:
>
> Nacked-by: "Eric W. Biederman"
>
> The pach does not solve the problem described.
Which might be true, and I am open to better proposals.
> Sami Kerola writes:
>
>> The kernel does not expose precise start time anywhere. Precision of
>> sysi
On 29 June 2013 23:50, Sergey Meirovich wrote:
> Hi,
>
> On 14 February 2013 21:12, Greg KH wrote:
>> I'm announcing the release of the 3.7.8 kernel.
Please ignore - this is about 3.9.8 kernel
>
> I've got issues with my radeon GPU on 3.7.8
> ...
> [ 20.944106] BUG: unable to handle kernel NU
Hi,
On 27 June 2013 20:59, Greg KH wrote:
> I'm announcing the release of the 3.9.8 kernel.
>
> All users of the 3.9 kernel series must upgrade.
I've got issues with my radeon ("01:00.0 VGA compatible controller:
Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7500M/7600M
Series]") APU
On 06/27/2013 10:44 AM, Thomas Gleixner wrote:
On Wed, 26 Jun 2013, Waiman Long wrote:
On 06/26/2013 07:06 PM, Thomas Gleixner wrote:
On Wed, 26 Jun 2013, Waiman Long wrote:
This is a complete design disaster. You are violating every single
rule of proper layering. The differentiation of spinlo
Hi Linus,
On 29 June 2013 21:11, Linus Torvalds wrote:
> On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich
> wrote:
>>
>> 3.10-rc7 doesn't compile for me
>>
>> rathamahata@piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage
>> modules
>> make[1]: Nothing to be done for `all'.
>> make[1
On 06/29/2013 04:23 PM, Waiman Long wrote:
On 06/29/2013 01:45 PM, Linus Torvalds wrote:
But more importantly, I think this needs to be architecture-specific,
and using to try to do some generic 64-bit
cmpxchg() version is a bad bad idea.
Yes, I can put the current implementation into
asm-g
Hello.
On 06/30/2013 12:15 AM, Sergei Shtylyov wrote:
Oops, forgot to add the From: line. The patch is not mine, I've only
modified it slightly. Will repost now...
Add support for HPB-DMAC found in Renesas R-Car SoCs, using 'shdma-base' DMA
driver framework.
Based on the original patch b
Folks:
I sent the indented text to gre...@linuxfoundation.org, inappropriately
as I suspected. I got a polite automated response suggesting alternate
destinations for my email. To my non-technical eyes, your addresses
seemed most appropriate.
"Mr. Kroah-Hartman,
"Excuse me for bothe
On Sat, Jun 29, 2013 at 1:23 PM, Waiman Long wrote:
>>
>> But more importantly, I think this needs to be architecture-specific,
>> and using to try to do some generic 64-bit
>> cmpxchg() version is a bad bad idea.
>
> Yes, I can put the current implementation into
> asm-generic/spinlock_refcount.
On Sat, Jun 29, 2013 at 2:34 PM, Waiman Long wrote:
>
> I think I got it now. For architecture with transactional memory support to
> use an alternative implementation, we will need to use some kind of dynamic
> patching at kernel boot up time as not all CPUs in that architecture will
> have that
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich wrote:
>> (and possibly the
>> mkregtable binary) and trying again might fix it.
>
> Removing mkregtable has indeed the compile issue for me. Thanks!
Ok, so something failed at an earlier build. That error is probably
long gone, though, since the
1 - 100 of 139 matches
Mail list logo
