Hi Greg,
I hoped the acpi-fixes from [1] (especially [2]) would fix my shown
"85% battery available", but a Ubuntu/trusty kernel reports the same
(battery defect?).
The 2nd revert is applicable, the 1st not, both are labeled with 3.16+.
Wanna pick them or have it already on your to-do?
Thanks.
On Sat, Sep 13, 2014 at 5:24 PM, Greg Kroah-Hartman
wrote:
> On Sat, Sep 13, 2014 at 02:52:52PM +0200, Sedat Dilek wrote:
>> Hi Greg,
>>
>> I hoped the acpi-fixes from [1] (especially [2]) would fix my shown
>> "85% battery available", but a Ubuntu/trust
On Sun, Mar 23, 2014 at 6:01 PM, Linus Torvalds
wrote:
> On Sun, Mar 23, 2014 at 9:45 AM, Al Viro wrote:
>>
>> It's easier to skip checking the overflow on prepend() of "\0" in the
>> beginning of the whole thing and just let the next operation to fail.
>> That's where the corner case comes from.
On Mon, Mar 24, 2014 at 11:58 PM, Imre Deak wrote:
>> [...]
>> Shortlog:
>> Al Viro (6):
>> make prepend_name() work correctly when called with negative
> *buflen
>
> A proper attribution for the above fix would have been nice. Tracking
> down the bug was the main thing after all:
>
> https:
On Tue, Mar 25, 2014 at 4:56 PM, Andrew Morton
wrote:
> On Tue, 25 Mar 2014 08:45:34 +0100 Sedat Dilek wrote:
>
>> Hi,
>>
>> as reported in [1] in my post-scriptum I see several OOPs when running
>> LTP and OOM tests (here: oom3).
>> Linus requested to send yo
On Tue, Mar 25, 2014 at 1:46 AM, Linus Torvalds
wrote:
> Just to clarify: the current vfs tree from Al works for you, no new issues?
>
> I was delaying the release first a day, and now I think I'll just do
> an rc8 after all (and do the final 3.14 next weekend), but I'd like to
> be sure what the
On Wed, Mar 26, 2014 at 9:55 PM, Linus Torvalds
wrote:
> On Wed, Mar 26, 2014 at 9:36 AM, Sedat Dilek wrote:
>>
>> Looking at [1] you did not pull-in the new changes.
>> Are you waiting for a new pull-request?
>
> Yeah, with the top commit updated, I'd like t
On Thu, May 29, 2014 at 6:06 PM, Miklos Szeredi wrote:
> On Thu, May 29, 2014 at 2:07 PM, Miklos Szeredi wrote:
>> On Thu, May 29, 2014 at 12:28:45PM +0100, David Howells wrote:
>>>
>>> This sequence of commands produces both errors:
>
> Fixes pushed to overlayfs.v22 (and overlayfs.current). Wil
On Thu, May 29, 2014 at 7:15 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> # grep LOCKDEP /boot/config-3.15.0-rc7-58.1-iniza-small
>> CONFIG_LOCKDEP_SUPPORT=y
>
> That's not LOCKDEP, merely support for it. What I see:
>
>
On Thu, May 29, 2014 at 7:15 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> # grep LOCKDEP /boot/config-3.15.0-rc7-58.1-iniza-small
>> CONFIG_LOCKDEP_SUPPORT=y
>
> That's not LOCKDEP, merely support for it. What I see:
>
>
On Thu, May 29, 2014 at 7:24 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> /mnt/a/foo101: Test file not on upper filesystem (line 30)
>
> Now check dmesg.
>
[ 1384.995334] tmpfs: No value for mount option 'union'
- Sedat -
--
To unsubscribe from this l
On Thu, May 29, 2014 at 7:41 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> >> /mnt/a/foo101: Test file not on upper filesystem (line 30)
>> >
>> > Now check dmesg.
>> >
>>
>> [ 1384.995334] tmpfs: No value for mount option '
On Thu, May 29, 2014 at 7:50 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> config LOCKDEP
>> bool
>
> It has no name, so you can't turn it on manually. You have to enable
> something the depends on or selects it.
>
> Turn on:
&
On Thu, May 29, 2014 at 8:22 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> > TEST_OVERLAYFS=1 ./run.sh
>> >
>> > right?
>> >
>>
>> Yes (with my mount-patch applied).
>>
>> ( ...and... # umount /lower /upper /mnt )
On Thu, May 29, 2014 at 8:44 PM, Sedat Dilek wrote:
> On Thu, May 29, 2014 at 8:22 PM, David Howells wrote:
>> Sedat Dilek wrote:
>>
>>> > TEST_OVERLAYFS=1 ./run.sh
>>> >
>>> > right?
>>> >
>>>
>>> Y
On Thu, May 29, 2014 at 9:20 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> Hmm, why is the generated binary callled "open-file" and in the
>> scripts I see "open_file"?
>
> grep is your friend:-) Look in tool_box.inc
>
I resetted to origin/H
On Thu, May 29, 2014 at 9:25 PM, David Howells wrote:
>
> Sedat Dilek wrote:
>
>> # LC_ALL=C TEST_OVERLAYFS="1" ./run.sh
>> [ run.sh ] TEST_OVERLAYFS is 1
>> ***
>> *** ./run.sh open-plain.test
>> ***
>> [ mount_union.sh ] TEST_OVERLAYFS i
On Thu, May 29, 2014 at 9:35 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> # LC_ALL=C TEST_OVERLAYFS="1" ./run.sh
>> [ run.sh ] TEST_OVERLAYFS is 1
>> ***
>> *** ./run.sh open-plain.test
>> ***
>> [ mount_union.sh ] TEST_OVERLAYFS is 1
On Thu, May 29, 2014 at 10:59 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> "Fixable" in your testsuite?
>
> Done and pushed.
>
Thanks.
I still see lots of...
umount: /mnt: not mounted
...and impermissible.test fails here...
***
*** ./run.sh impermiss
On Fri, May 30, 2014 at 6:15 AM, Sedat Dilek wrote:
> On Thu, May 29, 2014 at 10:59 PM, David Howells wrote:
>> Sedat Dilek wrote:
>>
>>> "Fixable" in your testsuite?
>>
>> Done and pushed.
>>
>
> Thanks.
>
> I still see lots o
On Fri, May 30, 2014 at 6:48 PM, Al Viro wrote:
> On Fri, May 30, 2014 at 08:31:30AM -0700, Linus Torvalds wrote:
>> On Fri, May 30, 2014 at 8:21 AM, Al Viro wrote:
>> >
>> > Linus, how would you prefer it to be handled?
>>
>> I'll just have to do an rc8. I really hoped to avoid it, because we're
On Tue, Jun 3, 2014 at 11:18 AM, Sedat Dilek wrote:
> [...]
>>> [ NOTE-2: The call-trace I have seen once (TERMSLASH=0). ]
>>
>> Do you know for which operation?
>>
>
> # echo $TESTS
> open-plain.test open-trunc.test open-creat.test open-creat-trunc.test
[...]
> The lockdep appears one time in the logs... I tried several...
>
> # LC_ALL=C TEST_OVERLAYFS=1 ./run.sh truncate.test
>
> ...and see the only lockdep.
>
> Sorry, I cannot say which of the test-no (is that what you mean by
> operation?) is causing the lockdep.
>
> Truncate-test results
On Tue, Jun 3, 2014 at 11:42 AM, Miklos Szeredi wrote:
> On Tue, Jun 3, 2014 at 11:26 AM, Sedat Dilek wrote:
>> On Tue, Jun 3, 2014 at 11:18 AM, Sedat Dilek wrote:
>>> [...]
>>>>> [ NOTE-2: The call-trace I have seen once (TERMSLASH=0). ]
>>>>
&
On Tue, Jun 3, 2014 at 12:21 PM, Sedat Dilek wrote:
> On Tue, Jun 3, 2014 at 11:42 AM, Miklos Szeredi wrote:
>> On Tue, Jun 3, 2014 at 11:26 AM, Sedat Dilek wrote:
>>> On Tue, Jun 3, 2014 at 11:18 AM, Sedat Dilek wrote:
>>>> [...]
>>>>>> [ NOTE
On Wed, Oct 23, 2013 at 5:13 PM, Thierry Reding
wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
WebGit URL?
Browsing "https://gitorious.org/thierryreding"; gives me a...
"Th
On Fri, Dec 27, 2013 at 5:32 AM, Ian Kent wrote:
Hi,
saw some typos...
> From: Ian Kent
>
> The autofs4 module doesn't consider symlinks for expire as it did
> in the older autofs v3 module (so it's actually a long stnding
s/stnding/standing
> regression).
>
> The user space daemon has focus
Hi,
it's a cool idea to label Linux-kernels with an "EOL" on the mainpage
of .
But how can someone see how long a LongTerm Support (LTS) L-k is supported?
Is it possible to add a date line or a web-link on the mainpage?
Regards,
- Sedat -
--
To unsubscribe from this list: send the line "unsubscri
Oh cool.
Hmm, is it possible to link all "longterm:" labeled kernels to the
page you pointed me to?
- Sedat -
On Tue, Sep 9, 2014 at 2:27 PM, Konstantin Ryabitsev
wrote:
> On Tue, Sep 09, 2014 at 02:25:24PM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> it's a cool
On Wed, Sep 10, 2014 at 7:24 AM, Guenter Roeck wrote:
> On Tue, Sep 09, 2014 at 02:52:47PM +0200, Sedat Dilek wrote:
>> Oh cool.
>> Hmm, is it possible to link all "longterm:" labeled kernels to the
>> page you pointed me to?
>>
> You mean following the &qu
vfs: introduce clone_private_mount()
> vfs: export check_sticky()
> vfs: add whiteout support
> vfs: add RENAME_WHITEOUT
> ext4: support RENAME_WHITEOUT
> shmem: support RENAME_WHITEOUT
> overlay filesystem
> fs: limit filesystem stackin
On Wed, Aug 12, 2015 at 9:26 PM, Ville Syrjälä
wrote:
> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
>> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
>> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek
>> > wrote:
>> >> Hi,
>> &g
On Thu, Aug 13, 2015 at 4:33 PM, Hans de Goede wrote:
> Hi,
>
> On 12-08-15 21:26, Ville Syrjälä wrote:
>>
>> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
>>>
>>> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek
>>> wrote:
>>
On Fri, Aug 14, 2015 at 10:24 AM, Hans de Goede wrote:
> Hi,
>
>
> On 13-08-15 16:33, Hans de Goede wrote:
>>
>> Hi,
>>
>> On 12-08-15 21:26, Ville Syrjälä wrote:
>>>
>>> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
>>>
On 4/25/16, Sedat Dilek wrote:
> On Wed, Apr 20, 2016 at 3:35 AM, Howard Cochran
> wrote:
>> On Mon, Apr 18, 2016 at 5:06 PM, Jakob Unterwurzacher
>> wrote:
>>> On 12.04.2016 13:09, Tejun Heo wrote:
>>>>>
>>>>> Probably you wa
a8dd ("writeback: update wb_over_bg_thresh() to use wb_domain
> aware operations")
> Signed-off-by: Howard Cochran
> Acked-by: Tejun Heo
> Signed-off-by: Miklos Szeredi
> Cc: # v4.2+
Fell free to add my...
Tested-by Sedat Dilek
- sed@ -
> ---
> mm/page-
On 5/9/16, Stephen Rothwell wrote:
> Hi Josh,
>
> On Fri, 6 May 2016 09:22:25 -0500 Josh Poimboeuf
> wrote:
>>
>> I've also seen no problems on powerpc with 4.4 and 4.8. I suspect it's
>> specific to gcc 4.6. Stephen, can you confirm this patch fixes it?
>
> That will obviously fix the problem
On 4/4/16, Peter Zijlstra wrote:
> On Mon, Apr 04, 2016 at 05:31:40PM +0200, Sedat Dilek wrote:
>> > +/* https://en.wikipedia.org/wiki/Xorshift#xorshift.2A */
>> > +#define UINT64_C(x) x##ULL
>> > +static inline u64 xorshift64star(u64 x)
>> > +{
>> >
>From [1]...
[ QUOTE ]
This is the start of the stable review cycle for the 4.4.9 release.
There are 163 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 should be made by Thu May 5 00:04:47 UT
On 5/10/16, Greg Kroah-Hartman wrote:
> On Tue, May 10, 2016 at 10:45:57AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> I have tested with my usual setup/config on Ubuntu/precise AMD64.
>> Looks good and ships [1].
>>
>> Thanks.
>>
>> Hope this f
e it, too.
- Sedat -
> On Mon, May 2, 2016 at 11:39 AM, Sedat Dilek wrote:
>
>> On 4/25/16, Sedat Dilek wrote:
>> > On Wed, Apr 20, 2016 at 3:35 AM, Howard Cochran
>> > wrote:
>> >> On Mon, Apr 18, 2016 at 5:06 PM, Jakob Unterwurzacher
>&g
On 5/16/16, Sedat Dilek wrote:
> On 5/16/16, Peter Zijlstra wrote:
>> On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote:
>>
>>> Unfortunately, I could not reproduce this again with none of my
>>> 183-kernels.
>>> When I first hit a &
On 5/19/16, Reinoud Koornstra wrote:
> On Thu, May 19, 2016 at 2:20 AM, Reinoud Koornstra
> wrote:
>> On Wed, May 18, 2016 at 12:51 PM, Linus Torvalds
>> wrote:
>>> On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
>>> wrote:
From what I can tell, there's a merge bug in commit 909b27f7
On 5/25/16, Jani Nikula wrote:
> On Wed, 25 May 2016, Sedat Dilek wrote:
>> Hi Daniel,
>>
>> with latest Linus Git I see this with my Intel SandyBridge GPU...
>>
>> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>> *ERROR* CP
On 5/27/16, Chris Bainbridge wrote:
> On 25 May 2016 at 08:31, Sedat Dilek wrote:
>> Hi Daniel,
>>
>> with latest Linus Git I see this with my Intel SandyBridge GPU...
>>
>> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>> *ERROR* CP
On 5/16/16, Ingo Molnar wrote:
>
> * Sedat Dilek wrote:
>
>> Hi,
>>
>> as Linux v4.6 is very near, I decided to write this bug report (only
>> drunk one coffee).
>>
>> First, I am not absolutely sure if this is a real issue as...
>> #1: Th
On 5/16/16, Peter Zijlstra wrote:
> On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote:
>
>> Unfortunately, I could not reproduce this again with none of my
>> 183-kernels.
>> When I first hit a "chain_key collision" issue, it was hard to redproduce,
&g
On Thu, Sep 10, 2015 at 4:53 PM, Tejun Heo wrote:
> On Thu, Sep 10, 2015 at 10:52:27AM -0400, Tejun Heo wrote:
>> Hey,
>>
>> On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
>> > I think we need to add might_sleep() on the top of __cancel_work_timer().
>> > The might_sleep() on the s
On Wed, Sep 9, 2015 at 2:54 PM, Peter Zijlstra wrote:
> On Wed, Sep 09, 2015 at 12:05:50PM +0200, Sedat Dilek wrote:
>> I can boot into a CLANG v3.7 compiled Linux-kernel when lib/bitmap is
>> compiled with GCC (here: v4.9).
>>
>> CONFIG_OPTIMIZE_INLINING has no effect
On Wed, Sep 9, 2015 at 4:42 AM, Sedat Dilek wrote:
> [ TO INTEL DRM DRIVERS maintainers ]
>
> Hi,
>
> out of curiosity and to play with the new bindeb-pkg make-target I
> built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a)
> Debian-kernel packages.
>
>
On Thu, Sep 10, 2015 at 2:25 AM, Fengguang Wu wrote:
> On Mon, Sep 07, 2015 at 09:12:58PM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> is it possible to use a different compiler at build-time?
>
> btw, it'd be great if clang can just work on mainline kernel.
>
I am
On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra wrote:
> On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
>> > It looks like an inline-optimization bug in CLANG when the compiler's
>> > optimization-level is higher than -O2.
>
>> > [1]
>>
On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra wrote:
> On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
>> > It looks like an inline-optimization bug in CLANG when the compiler's
>> > optimization-level is higher than -O2.
>
>> > [1]
>>
On Mon, Sep 14, 2015 at 9:35 AM, Sedat Dilek wrote:
> On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra wrote:
>> On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
>>> > It looks like an inline-optimization bug in CLANG when the compiler's
>>> >
On Mon, Sep 14, 2015 at 11:35 AM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> > I invite you to join the discussion at LLVMLinux... As I know... "YES, you
>> > can." Linux x86/x86_64 (assembler) Kung-Fu. ( I admit I have not these
>> > skillz.
>> > )
>>
>> Its a matter of time for me; I
On Mon, Sep 14, 2015 at 11:59 AM, Ingo Molnar wrote:
>
> * Sedat Dilek wrote:
>
>> From my side... How can the correbolation be improved...?
>
> The best workflow would be for someone to send patches that are considered
> clean
> enough.
>
What do you mean by &quo
On Fri, Sep 11, 2015 at 6:12 PM, Sedat Dilek wrote:
> On Thu, Sep 10, 2015 at 4:53 PM, Tejun Heo wrote:
>> On Thu, Sep 10, 2015 at 10:52:27AM -0400, Tejun Heo wrote:
>>> Hey,
>>>
>>> On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
>>>
y?
Below tools/ directory we have also an OPTIMIZATION variable used.
Something like a "global" solution is desired from my side.
I have attached a patchset on top of my llvmlinux-amd64-fixes-4.4,
hope this helps a bit to see what I mean.
It is not doing what I desire - still WIP.
Thoughts?
On Mon, Jan 4, 2016 at 11:54 AM, Sedat Dilek wrote:
> [ Not sure if I have addressed all the correct people and mailing-lists ]
>
> Hi,
>
> while still digging into a llvmlinux issue with workqueue I saw that
> the wrong optimization compiler-flag was used on x86 architecture an
On Mon, Jan 4, 2016 at 12:33 PM, One Thousand Gnomes
wrote:
>> As said... I checked only for x86 and acpi only.
>>
>> For example '-Os' is hardcoded in...
>>
>> arch/x86/Makefile
>> arch/x86/purgatory/Makefile
>>
>> drivers/acpi/Makefile
>> drivers/acpi/acpica/Makefile
>>
>> For acpi part we have
On Wed, Feb 24, 2016 at 6:34 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160223:
>
...
> The aio tree still had a build failure so I used the version from
> next-20160111.
>
Might be good to poke the maintainer as I am seeing this for a long
time in Linux-next.
- Sedat -
On Thu, Nov 20, 2014 at 5:45 PM, Miklos Szeredi wrote:
> Hi Al,
>
> Please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
> overlayfs-current
>
This seems to be the place where overlayfs-fixes are collected for a
git-pull request.
Can you add a "T:" line with the
On Fri, Nov 21, 2014 at 11:50 AM, Miklos Szeredi wrote:
> On Fri, Nov 21, 2014 at 11:43 AM, Sedat Dilek wrote:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
>>> overlayfs-current
>>>
>>
>> This seems to be the place where overl
On Fri, May 22, 2015 at 11:48 PM, wrote:
[...]
> You will need quilt to apply these patches to the latest Linus release (3.x
> or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
>
[...]
Should be updated to "4.x" and "4.x-rcY".
- Se
On Sat, May 2, 2015 at 6:12 AM, Linus Torvalds
wrote:
> On Fri, May 1, 2015 at 2:41 PM, Abelardo Ricart III
> wrote:
>>
>> Here's my two-line patch strictly defining the build order, for your perusal.
>
> Ok, so this looks possible and sounds like it could explain the issues.
>
> But I'd like so
On Wed, Mar 25, 2015 at 3:34 PM, Takashi Iwai wrote:
> At Wed, 25 Mar 2015 14:26:50 +0100,
> Daniel Vetter wrote:
>>
>> On Tue, Mar 24, 2015 at 07:09:03PM +0100, Sedat Dilek wrote:
>> > On Mon, Mar 23, 2015 at 9:25 AM, Daniel Vetter wrote:
>> > > On Mon,
On Fri, Mar 27, 2015 at 12:06 PM, Takashi Iwai wrote:
> At Fri, 27 Mar 2015 12:01:33 +0100,
> Sedat Dilek wrote:
>>
>> On Wed, Mar 25, 2015 at 3:34 PM, Takashi Iwai wrote:
>> > At Wed, 25 Mar 2015 14:26:50 +0100,
>> > Daniel Vetter wrote:
>> >>
On Mon, Mar 23, 2015 at 9:25 AM, Daniel Vetter wrote:
> On Mon, Mar 23, 2015 at 07:25:27AM +0100, Sedat Dilek wrote:
>> Hi,
>>
>> I did my weekly update of the Linux RC (here: v4.0-rc5) and fell over
>> some warning in the drm area.
>>
>> Please have a l
_startup_entry+0x37e/0x580
> [] start_secondary+0x140/0x150
> intel_pstate CPU 2 exiting
>
> ...
>
> By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
> condition is cpu_online(smp_processor_id()), we can avoid calling RCU
> protected
> code
On Fri, Feb 6, 2015 at 9:21 PM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 21:11:57 +0100
> Sedat Dilek wrote:
>
>> On Fri, Feb 6, 2015 at 9:06 PM, Steven Rostedt wrote:
>> > From: "Steven Rostedt (Red Hat)"
>> >
>>
>> Subject: x86/tbl/t
On Fri, Feb 6, 2015 at 10:18 PM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 22:07:56 +0100
> Sedat Dilek wrote:
>
>> Your patchset fixes the issue for me (look at the attached files for
>> more detailed information).
>
> So I can add your Tested-by tag?
>
Yes.
&
On Fri, Feb 6, 2015 at 10:19 PM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 16:18:03 -0500
> Steven Rostedt wrote:
>
>
>> But the first patch is a much broader change and more generic which
>> could affect many other locations as well. It is specific to
>> tracepoints, where the tlb one is specif
On Fri, Feb 6, 2015 at 10:24 PM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 16:19:24 -0500
> Steven Rostedt wrote:
>
>> On Fri, 6 Feb 2015 16:18:03 -0500
>> Steven Rostedt wrote:
>>
>>
>> > But the first patch is a much broader change and more generic which
>> > could affect many other locations
On Fri, Feb 6, 2015 at 10:34 PM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 21:11:57 +0100
> Sedat Dilek wrote:
>
>> On Fri, Feb 6, 2015 at 9:06 PM, Steven Rostedt wrote:
>> > From: "Steven Rostedt (Red Hat)"
>> >
>>
>> Subject: x86/tbl
On Fri, Feb 6, 2015 at 10:38 PM, Paul E. McKenney
wrote:
> On Fri, Feb 06, 2015 at 10:07:56PM +0100, Sedat Dilek wrote:
>> On Fri, Feb 6, 2015 at 9:06 PM, Steven Rostedt wrote:
>> > Paul,
>> >
>> > I found a much better fix than adding the rcu_nocheck(). Simpl
On Fri, Feb 6, 2015 at 10:42 PM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 22:39:52 +0100
> Sedat Dilek wrote:
>
>> Man man man you write and test your stuff still on ancient x85 arch.
>> What's coming next... revive/reinclude i386 code?
>
> Real mode for Re
On Fri, Feb 6, 2015 at 11:48 PM, Paul E. McKenney
wrote:
> On Fri, Feb 06, 2015 at 05:35:48PM -0500, Steven Rostedt wrote:
>> On Fri, 6 Feb 2015 23:13:02 +0100
>> Sedat Dilek wrote:
>>
>>
>> > OK, so both patches go through Steve's tree.
>>
>&g
On Fri, Feb 6, 2015 at 11:51 PM, Sedat Dilek wrote:
> On Fri, Feb 6, 2015 at 11:48 PM, Paul E. McKenney
> wrote:
>> On Fri, Feb 06, 2015 at 05:35:48PM -0500, Steven Rostedt wrote:
>>> On Fri, 6 Feb 2015 23:13:02 +0100
>>> Sedat Dilek wrote:
>>>
>>&
On Sat, Feb 7, 2015 at 5:02 AM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 15:27:54 -0800
> "Paul E. McKenney" wrote:
>
>> > Reported-by: Sedat Dilek
>> > Suggested-by: Paul E. McKenney
>> > Signed-off-by: Steven Rostedt
>>
>> Acked-by
On Sat, Feb 7, 2015 at 5:02 AM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 15:27:54 -0800
> "Paul E. McKenney" wrote:
>
>> > Reported-by: Sedat Dilek
>> > Suggested-by: Paul E. McKenney
>> > Signed-off-by: Steven Rostedt
>>
>> Acked-by
On Sat, Feb 7, 2015 at 4:20 PM, Steven Rostedt wrote:
> On Sat, 7 Feb 2015 09:01:34 +0100
> Sedat Dilek wrote:
>
>
>> - Tested-by's
>> - Reference of 2/2 to 1/2
>
> The two are together in the series and fix two different bugs. They do
> not need to referen
On Sat, Feb 7, 2015 at 9:09 PM, Paul E. McKenney
wrote:
> On Sat, Feb 07, 2015 at 10:20:02AM -0500, Steven Rostedt wrote:
>> On Sat, 7 Feb 2015 09:01:34 +0100
>> Sedat Dilek wrote:
>>
>>
>> > - Tested-by's
>> > - Reference of 2/2 to 1/2
&g
On Sat, Feb 7, 2015 at 11:14 PM, Paul E. McKenney
wrote:
> On Sat, Feb 07, 2015 at 04:52:05PM -0500, Steven Rostedt wrote:
>> On Sat, 7 Feb 2015 12:09:48 -0800
>> "Paul E. McKenney" wrote:
>>
>> >The tag sequence has the meaning of:
>> > git cherry-pick a1f84a3
>> > git cherry-pick
On Sun, Jan 4, 2015 at 8:53 AM, Sedat Dilek wrote:
> On Sun, Jan 4, 2015 at 1:59 AM, Ming Lei wrote:
>> Hi Sedat,
>>
>> On Sun, Jan 4, 2015 at 7:42 AM, Sedat Dilek wrote:
>>> On Thu, Jan 1, 2015 at 11:28 AM, Sedat Dilek wrote:
>>>> Hi,
>>>&g
Hi,
some personal notes on this release.
Several warnings and call-traces which I saw in Linux-next (upcoming
v3.20) turned out to be also issues in v3.19.
[1] aio: annotate aio_read_event_ring for sleep patterns
[2] tracing: Add condition check to RCU lockdep checks
[3] x86/tlb/trace: Do not t
On Mon, Feb 9, 2015 at 4:58 PM, Sedat Dilek wrote:
> On Mon, Feb 9, 2015 at 4:44 PM, Greg Kroah-Hartman
> wrote:
>> On Mon, Feb 09, 2015 at 04:35:53PM +0100, Sedat Dilek wrote:
>>> Hi Greg,
>>>
>>> nice to see the kbuild and trace patches I was involved ar
On Mon, Feb 9, 2015 at 5:02 PM, Sedat Dilek wrote:
> On Mon, Feb 9, 2015 at 4:58 PM, Sedat Dilek wrote:
>> On Mon, Feb 9, 2015 at 4:44 PM, Greg Kroah-Hartman
>> wrote:
>>> On Mon, Feb 09, 2015 at 04:35:53PM +0100, Sedat Dilek wrote:
>>>> Hi Greg,
>&g
On Wed, Feb 4, 2015 at 4:16 PM, Jens Axboe wrote:
> On 02/04/2015 05:26 AM, Sedat Dilek wrote:
>>
>> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
>> wrote:
>>>
>>> Hi all,
>>>
>>> The next release I will be making will be next-2015
On Wed, Feb 4, 2015 at 4:31 PM, Jens Axboe wrote:
> On 02/04/2015 08:21 AM, Sedat Dilek wrote:
>>
>> On Wed, Feb 4, 2015 at 4:16 PM, Jens Axboe wrote:
>>>
>>> On 02/04/2015 05:26 AM, Sedat Dilek wrote:
>>>>
>>>>
>>
On Wed, Feb 4, 2015 at 4:58 PM, Martin K. Petersen
wrote:
>>>>>> "Sedat" == Sedat Dilek writes:
>
>>>>>> I am seeing the following in my logs several times...
>>>>>>
>>>>>> Feb 4 02:53:13 fambox kernel: [15507
On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
>> wrote:
>> > Hi all,
>> >
>> > The next release I will be making will be n
On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
>> wrote:
>> > Hi all,
>> >
>> > The next release I will be making will be n
On Thu, Feb 5, 2015 at 12:30 AM, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 11:46:32 PM Sedat Dilek wrote:
>> On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki
>> wrote:
>> > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> >
On Thu, Feb 5, 2015 at 12:25 AM, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 11:38:40 PM Sedat Dilek wrote:
>> On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki
>> wrote:
>> > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> >
gt;> > > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> > > > On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
>> > > > wrote:
>> > > > > Hi all,
>> > > > >
>> > > > > T
; > On Wed, Feb 04, 2015 at 10:54:07PM +0100, Rafael J. Wysocki wrote:
>> > > > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>
> [ . . . ]
>
>> > > > > [ 1144.482666] Disabling non-boot CPUs ...
>> > > > > [
On Thu, Feb 5, 2015 at 1:57 AM, Paul E. McKenney
wrote:
> On Thu, Feb 05, 2015 at 01:30:45AM +0100, Sedat Dilek wrote:
>> On Thu, Feb 5, 2015 at 1:10 AM, Paul E. McKenney
>> wrote:
>> > On Wed, Feb 04, 2015 at 03:51:15PM -0800, Paul E. McKenney wrote:
>> >>
On Thu, Feb 5, 2015 at 2:51 AM, Paul E. McKenney
wrote:
> On Thu, Feb 05, 2015 at 02:18:01AM +0100, Sedat Dilek wrote:
>> On Thu, Feb 5, 2015 at 1:57 AM, Paul E. McKenney
>> wrote:
>> > On Thu, Feb 05, 2015 at 01:30:45AM +0100, Sedat Dilek wrote:
>> >> On
On Thu, Feb 5, 2015 at 2:53 AM, Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 2:51 AM, Paul E. McKenney
> wrote:
>> On Thu, Feb 05, 2015 at 02:18:01AM +0100, Sedat Dilek wrote:
>>> On Thu, Feb 5, 2015 at 1:57 AM, Paul E. McKenney
>>> wrote:
>>> > On Th
On Thu, Feb 5, 2015 at 4:17 AM, Martin K. Petersen
wrote:
>>>>>> "Sedat" == Sedat Dilek writes:
>
> Sedat> No, but I am here on a so-called WUBI installation which
> Sedat> triggered some bugs being an exotic installation. My
> Sedat> Ubuntu/pre
901 - 1000 of 1434 matches
Mail list logo
