Re: linux-next: Tree for Mar 19
On Tue, Mar 19, 2013 at 6:54 AM, Stephen Rothwell wrote: > Hi, > > On Tue, 19 Mar 2013 16:47:48 +1100 Stephen Rothwell > wrote: >> >> On Tue, 19 Mar 2013 06:42:27 +0100 Sedat Dilek wrote: >> > >> > did forget to sent your email [1] to linux-next ML? >> >> No, and I even checked my mail server's logs and it was accepted by vger. > > Also, I received a copy via the list within about 12 seconds of posting > it. Now, I checked my Gmail SPAM folder and searched for "linux-next: Tree for Mar" pattern and I have not received it. But I received for example "linux-next: manual merge of the workqueues tree with Linus' tree" that's why I wonder I did not get it. - Sedat - > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Mar 19
On Tue, Mar 19, 2013 at 6:47 AM, Stephen Rothwell wrote: > Hi, > > On Tue, 19 Mar 2013 06:42:27 +0100 Sedat Dilek wrote: >> >> did forget to sent your email [1] to linux-next ML? > > No, and I even checked my mail server's logs and it was accepted by vger. > For sure - it's not in my inbox :-). But I can read it offline. - Sedat - [1] http://marc.info/?t=13321436071&r=1&w=2 > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 5
On Tue, Feb 5, 2013 at 6:34 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130204: > > The powerpc tree still had a build failure. > > The nfsd tree lost its build. > > The sound-asoc tree gained a build failure so I used the version from > next-20130204. > Several people ask for inclusion of [1] after having confirmed it fixes their issue. One guy pointed to the fact the fix [2] is pending in mmot*s* tree. When will it go to Linux-Next? Read the thread in [3] for more details. Thanks. - Sedat - [1] http://marc.info/?l=linux-mm&m=135929599505624&w=2 [2] http://ozlabs.org/~akpm/mmots/broken-out/swap-make-each-swap-partition-have-one-address_space-fix-fix.patch [3] http://marc.info/?t=13597814591&r=1&w=2 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert "console: implement lockdep support for console_lock"
On Fri, Feb 1, 2013 at 9:42 AM, Daniel Vetter wrote: > On Fri, Feb 1, 2013 at 9:21 AM, Sedat Dilek wrote: >> people having the fbcon-locking-fixes [1] in their local GIT tree can >> revert this change? > > Yeah, if you have all the fixes reverting this is fine and appreciated > to increase testing. Dave will probably push the revert himself to > drm-next soon. When will that happen: drm-next inclusion? Just FYI: Pulling fbcon-locking-fixes into Linux-Next (next-20130205) shows some ugly UTF-8 mismatch, means "fb: rework locking to fix lock ordering on takeover" is not the same patch as in -next. Just wanna let you know. It would be good to inform Andrew and Stephen when this happened, so Andrew can drop the two fb-fixes from his mmotm-tree. Thanks! - Sedat - > -Daniel > >> >> commit ff0d05bf73620eb7dc8aee7423e992ef87870bdf >> Refs: v3.8-rc5-194-gff0d05b >> Author: Dave Airlie >> AuthorDate: Thu Jan 31 14:27:03 2013 +1100 >> Commit: Dave Airlie >> CommitDate: Thu Jan 31 15:46:56 2013 +1100 >> >> Revert "console: implement lockdep support for console_lock" >> >> This reverts commit daee779718a319ff9f83e1ba3339334ac650bb22. >> >> I'll requeue this after the console locking fixes, so lockdep >> is useful again for people until fbcon is fixed. >> >> Signed-off-by: Dave Airlie >> >> Thanks! >> >> Regards, >> - Sedat >> >> [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert "console: implement lockdep support for console_lock"
On Tue, Feb 5, 2013 at 11:47 AM, Sedat Dilek wrote: > On Fri, Feb 1, 2013 at 9:42 AM, Daniel Vetter wrote: >> On Fri, Feb 1, 2013 at 9:21 AM, Sedat Dilek wrote: >>> people having the fbcon-locking-fixes [1] in their local GIT tree can >>> revert this change? >> >> Yeah, if you have all the fixes reverting this is fine and appreciated >> to increase testing. Dave will probably push the revert himself to >> drm-next soon. > > When will that happen: drm-next inclusion? > > Just FYI: > Pulling fbcon-locking-fixes into Linux-Next (next-20130205) shows some > ugly UTF-8 mismatch, means "fb: rework locking to fix lock ordering on > takeover" is not the same patch as in -next. > Just wanna let you know. > > It would be good to inform Andrew and Stephen when this happened, so > Andrew can drop the two fb-fixes from his mmotm-tree. > Attached the UTF-8 "mismatch" in vt.c. - Sedat - > Thanks! > > - Sedat - > >> -Daniel >> >>> >>> commit ff0d05bf73620eb7dc8aee7423e992ef87870bdf >>> Refs: v3.8-rc5-194-gff0d05b >>> Author: Dave Airlie >>> AuthorDate: Thu Jan 31 14:27:03 2013 +1100 >>> Commit: Dave Airlie >>> CommitDate: Thu Jan 31 15:46:56 2013 +1100 >>> >>> Revert "console: implement lockdep support for console_lock" >>> >>> This reverts commit daee779718a319ff9f83e1ba3339334ac650bb22. >>> >>> I'll requeue this after the console locking fixes, so lockdep >>> is useful again for people until fbcon is fixed. >>> >>> Signed-off-by: Dave Airlie >>> >>> Thanks! >>> >>> Regards, >>> - Sedat >>> >>> [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes >> >> >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch VT_C_UTF-8_CRAP.diff Description: Binary data
Re: linux-next: Tree for Feb 7 (fakeroot BROKEN due to SYSV IPC support?)
On Thu, Feb 7, 2013 at 7:37 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130206: > > Removed tree: kvmtool (still present via the tip tree) > > The block tree lost its build failure. > > The tip tree gained a conflict against the s390 tree. > > The kvm tree gained a conflict against Linus' tree. > > The tty tree lost its build failure. > > The arm-soc tree gained conflicts against the iommu tree. > > The signal tree gained a conflict against the s390 tree. > > The akpm tree gained a conflict against the kvm tree and lost its build > failure. > > > My build-script uses fakeroot and does no more start: $ ./scripts/build_linux-next.sh make options .. CC=gcc-4.6 -j4 KBUILD_BUILD_USER=sedat.di...@gmail.com LOCALVERSION=-next20130207-2-iniza-small dep-pkg options ... KDEB_PKGVERSION=3.8.0~rc6~next20130207-2~iniza+dileks1 fakeroot, while creating message channels: Invalid argument This may be due to a lack of SYSV IPC support. fakeroot: error while starting the `faked' daemon. kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] Any hints? ( I could run strace... ) - Sedat - build_linux-next.sh Description: Bourne shell script
Re: linux-next: Tree for Feb 7 (fakeroot BROKEN due to SYSV IPC support?)
On Thu, Feb 7, 2013 at 10:38 AM, Sedat Dilek wrote:
> On Thu, Feb 7, 2013 at 7:37 AM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> Changes since 20130206:
>>
>> Removed tree: kvmtool (still present via the tip tree)
>>
>> The block tree lost its build failure.
>>
>> The tip tree gained a conflict against the s390 tree.
>>
>> The kvm tree gained a conflict against Linus' tree.
>>
>> The tty tree lost its build failure.
>>
>> The arm-soc tree gained conflicts against the iommu tree.
>>
>> The signal tree gained a conflict against the s390 tree.
>>
>> The akpm tree gained a conflict against the kvm tree and lost its build
>> failure.
>>
>>
>>
>
> My build-script uses fakeroot and does no more start:
>
> $ ./scripts/build_linux-next.sh
> make options .. CC=gcc-4.6 -j4
> KBUILD_BUILD_USER=sedat.di...@gmail.com
> LOCALVERSION=-next20130207-2-iniza-small
> dep-pkg options ... KDEB_PKGVERSION=3.8.0~rc6~next20130207-2~iniza+dileks1
> fakeroot, while creating message channels: Invalid argument
> This may be due to a lack of SYSV IPC support.
> fakeroot: error while starting the `faked' daemon.
> kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec
> ... or kill -l [sigspec]
>
>
> Any hints?
> ( I could run strace... )
>
> - Sedat -
Attached strace outputs within yesterday's (GOOD) and today's (BAD) Linux-Next.
- Sedat -
execve("./scripts/build_linux-next.sh", ["./scripts/build_linux-next.sh"], [/*
48 vars */]) = 0
brk(0) = 0x139d000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4736ce8000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=93838, ...}) = 0
mmap(NULL, 93838, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4736cd1000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\30\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1811128, ...}) = 0
mmap(NULL, 3925208, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f4736709000
mprotect(0x7f47368be000, 2093056, PROT_NONE) = 0
mmap(0x7f4736abd000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0x7f4736abd000
mmap(0x7f4736ac3000, 17624, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4736ac3000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4736cd
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4736ccf000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4736cce000
arch_prctl(ARCH_SET_FS, 0x7f4736ccf700) = 0
mprotect(0x7f4736abd000, 16384, PROT_READ) = 0
mprotect(0x619000, 4096, PROT_READ) = 0
mprotect(0x7f4736cea000, 4096, PROT_READ) = 0
munmap(0x7f4736cd1000, 93838) = 0
getpid()= 2498
rt_sigaction(SIGCHLD, {0x40f100, ~[RTMIN RT_1], SA_RESTORER, 0x7f473673f4a0},
NULL, 8) = 0
geteuid() = 1000
brk(0) = 0x139d000
brk(0x13be000) = 0x13be000
getppid() = 2495
stat("/home/wearefam/src/linux-kernel", {st_mode=S_IFDIR|0775, st_size=12288,
...}) = 0
stat(".", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
open("./scripts/build_linux-next.sh", O_RDONLY) = 3
fcntl(3, F_DUPFD, 10) = 10
close(3)= 0
fcntl(10, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x40f100, ~[RTMIN RT_1], SA_RESTORER, 0x7f473673f4a0},
NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f473673f4a0},
NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f473673f4a0},
NULL, 8) = 0
read(10, "#!/bin/sh\n\n### HELP\n# 1. make de"..., 8192) = 3852
pipe([3, 4])= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f4736ccf9d0) = 2499
close(4)= 0
read(3, "/
Re: linux-next: Tree for Feb 7 (fakeroot BROKEN due to SYSV IPC support?)
On Thu, Feb 7, 2013 at 11:20 AM, Sedat Dilek wrote:
> On Thu, Feb 7, 2013 at 10:38 AM, Sedat Dilek wrote:
>> On Thu, Feb 7, 2013 at 7:37 AM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> Changes since 20130206:
>>>
>>> Removed tree: kvmtool (still present via the tip tree)
>>>
>>> The block tree lost its build failure.
>>>
>>> The tip tree gained a conflict against the s390 tree.
>>>
>>> The kvm tree gained a conflict against Linus' tree.
>>>
>>> The tty tree lost its build failure.
>>>
>>> The arm-soc tree gained conflicts against the iommu tree.
>>>
>>> The signal tree gained a conflict against the s390 tree.
>>>
>>> The akpm tree gained a conflict against the kvm tree and lost its build
>>> failure.
>>>
>>>
>>>
>>
>> My build-script uses fakeroot and does no more start:
>>
>> $ ./scripts/build_linux-next.sh
>> make options .. CC=gcc-4.6 -j4
>> KBUILD_BUILD_USER=sedat.di...@gmail.com
>> LOCALVERSION=-next20130207-2-iniza-small
>> dep-pkg options ... KDEB_PKGVERSION=3.8.0~rc6~next20130207-2~iniza+dileks1
>> fakeroot, while creating message channels: Invalid argument
>> This may be due to a lack of SYSV IPC support.
>> fakeroot: error while starting the `faked' daemon.
>> kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec
>> ... or kill -l [sigspec]
>>
>>
>> Any hints?
>> ( I could run strace... )
>>
>> - Sedat -
>
> Attached strace outputs within yesterday's (GOOD) and today's (BAD)
> Linux-Next.
>
> - Sedat -
[ CCing Al and Eric ]
I compared quickly the diff between the -next versions and saw changes
coming from signal and userns trees.
( Sorry for re-attaching the strace outputs. )
- Sedat -
execve("./scripts/build_linux-next.sh", ["./scripts/build_linux-next.sh"], [/*
48 vars */]) = 0
brk(0) = 0x139d000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4736ce8000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=93838, ...}) = 0
mmap(NULL, 93838, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4736cd1000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\30\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1811128, ...}) = 0
mmap(NULL, 3925208, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f4736709000
mprotect(0x7f47368be000, 2093056, PROT_NONE) = 0
mmap(0x7f4736abd000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0x7f4736abd000
mmap(0x7f4736ac3000, 17624, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4736ac3000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4736cd
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4736ccf000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4736cce000
arch_prctl(ARCH_SET_FS, 0x7f4736ccf700) = 0
mprotect(0x7f4736abd000, 16384, PROT_READ) = 0
mprotect(0x619000, 4096, PROT_READ) = 0
mprotect(0x7f4736cea000, 4096, PROT_READ) = 0
munmap(0x7f4736cd1000, 93838) = 0
getpid()= 2498
rt_sigaction(SIGCHLD, {0x40f100, ~[RTMIN RT_1], SA_RESTORER, 0x7f473673f4a0},
NULL, 8) = 0
geteuid() = 1000
brk(0) = 0x139d000
brk(0x13be000) = 0x13be000
getppid() = 2495
stat("/home/wearefam/src/linux-kernel", {st_mode=S_IFDIR|0775, st_size=12288,
...}) = 0
stat(".", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
open("./scripts/build_linux-next.sh", O_RDONLY) = 3
fcntl(3, F_DUPFD, 10) = 10
close(3)= 0
fcntl(10, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x40f100, ~[RTMIN RT_1], SA_RESTORER, 0x7f473673f4a0},
NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f473673f4a0},
NULL, 8)
Re: linux-next: Tree for Feb 7 (fakeroot BROKEN due to SYSV IPC support?)
On Thu, Feb 7, 2013 at 12:14 PM, Eric W. Biederman wrote: > Sedat Dilek writes: > >> On Thu, Feb 7, 2013 at 11:20 AM, Sedat Dilek wrote: >>> On Thu, Feb 7, 2013 at 10:38 AM, Sedat Dilek wrote: >>>> On Thu, Feb 7, 2013 at 7:37 AM, Stephen Rothwell >>>> wrote: >>>>> Hi all, >>>>> >>>>> Changes since 20130206: >>>>> >>>>> Removed tree: kvmtool (still present via the tip tree) >>>>> >>>>> The block tree lost its build failure. >>>>> >>>>> The tip tree gained a conflict against the s390 tree. >>>>> >>>>> The kvm tree gained a conflict against Linus' tree. >>>>> >>>>> The tty tree lost its build failure. >>>>> >>>>> The arm-soc tree gained conflicts against the iommu tree. >>>>> >>>>> The signal tree gained a conflict against the s390 tree. >>>>> >>>>> The akpm tree gained a conflict against the kvm tree and lost its build >>>>> failure. >>>>> >>>>> >>>>> >>>> >>>> My build-script uses fakeroot and does no more start: >>>> >>>> $ ./scripts/build_linux-next.sh >>>> make options .. CC=gcc-4.6 -j4 >>>> KBUILD_BUILD_USER=sedat.di...@gmail.com >>>> LOCALVERSION=-next20130207-2-iniza-small >>>> dep-pkg options ... KDEB_PKGVERSION=3.8.0~rc6~next20130207-2~iniza+dileks1 >>>> fakeroot, while creating message channels: Invalid argument >>>> This may be due to a lack of SYSV IPC support. >>>> fakeroot: error while starting the `faked' daemon. >>>> kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec >>>> ... or kill -l [sigspec] >>>> >>>> >>>> Any hints? >>>> ( I could run strace... ) >>>> >>>> - Sedat - >>> >>> Attached strace outputs within yesterday's (GOOD) and today's (BAD) >>> Linux-Next. >>> >>> - Sedat - >> >> [ CCing Al and Eric ] >> >> I compared quickly the diff between the -next versions and saw changes >> coming from signal and userns trees. >> ( Sorry for re-attaching the strace outputs. ) > > It has been about a week and a half since I have pushed anything into > the userns tree, and I don't have anything ipc related in my tree. > So the reason for the suspicion seems odd. > > The straces are useless because all they show is that fakeroot was > forked, but there is not a trace of fakeroot itself. > > Given the timing my initial suspect would be the idr_preload patches > from Tejun that were merged via Andrew's akpm tree. I didn't see > anything in there that would kill ipc but that is likely the most recent > touch to the ipc code. > [ CCing Tejun ] Hmm, still stepping in the dark... OK, fakeroot does PRELOADing so your assumption makes sense. How can I trigger fakeroot calls? Here I have... /usr/bin/faked-sysv /usr/bin/faked-tcp I think that is the main commit but I am not sure if I can revert the idr_preload part, otherwise it gets complicated: commit e2802c2defba1e5c88d7d168eb5c66813c86f249 "idr: implement idr_preload[_end]() and idr_alloc()" $ grep idr ../Linux-Next-v20130206-VS-v20130207.diff | grep ^'++Applying:' ++Applying: block: fix ext_devt_idr handling ++Applying: idr: fix a subtle bug in idr_get_next() ++Applying: nfsd: idr_destroy() no longer needs idr_remove_all() ++Applying: idr: cosmetic updates to struct / initializer definitions ++Applying: idr: relocate idr_for_each_entry() and reorganize id[r|a]_get_new() ++Applying: idr: remove _idr_rc_to_errno() hack ++Applying: idr: refactor idr_get_new_above() ++Applying: idr: implement idr_preload[_end]() and idr_alloc() ++Applying: block: convert to idr_alloc() ++Applying: block/loop: convert to idr_alloc() ++Applying: atm/nicstar: convert to idr_alloc() ++Applying: drbd: convert to idr_alloc() ++Applying: dca: convert to idr_alloc() ++Applying: dmaengine: convert to idr_alloc() ++Applying: firewire: convert to idr_alloc() ++Applying: gpio: convert to idr_alloc() ++Applying: drm: convert to idr_alloc() ++Applying: drm/exynos: convert to idr_alloc() ++Applying: drm/i915: convert to idr_alloc() ++Applying: drm/sis: convert to idr_alloc() ++Applying: drm/via: convert to idr_alloc() ++Applying: drm/vmwgfx: convert to idr_alloc() ++Applying: i2c: convert to idr_alloc() ++Applying: IB/core: convert to idr_alloc() ++Applying: IB/amso1100: convert to idr_alloc(
Re: linux-next: Tree for Feb 7 (fakeroot BROKEN due to SYSV IPC support?)
On Thu, Feb 7, 2013 at 2:39 PM, Sedat Dilek wrote: > On Thu, Feb 7, 2013 at 12:52 PM, Sedat Dilek wrote: >> On Thu, Feb 7, 2013 at 12:14 PM, Eric W. Biederman >> wrote: >>> Sedat Dilek writes: >>> >>>> On Thu, Feb 7, 2013 at 11:20 AM, Sedat Dilek wrote: >>>>> On Thu, Feb 7, 2013 at 10:38 AM, Sedat Dilek >>>>> wrote: >>>>>> On Thu, Feb 7, 2013 at 7:37 AM, Stephen Rothwell >>>>>> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Changes since 20130206: >>>>>>> >>>>>>> Removed tree: kvmtool (still present via the tip tree) >>>>>>> >>>>>>> The block tree lost its build failure. >>>>>>> >>>>>>> The tip tree gained a conflict against the s390 tree. >>>>>>> >>>>>>> The kvm tree gained a conflict against Linus' tree. >>>>>>> >>>>>>> The tty tree lost its build failure. >>>>>>> >>>>>>> The arm-soc tree gained conflicts against the iommu tree. >>>>>>> >>>>>>> The signal tree gained a conflict against the s390 tree. >>>>>>> >>>>>>> The akpm tree gained a conflict against the kvm tree and lost its build >>>>>>> failure. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> My build-script uses fakeroot and does no more start: >>>>>> >>>>>> $ ./scripts/build_linux-next.sh >>>>>> make options .. CC=gcc-4.6 -j4 >>>>>> KBUILD_BUILD_USER=sedat.di...@gmail.com >>>>>> LOCALVERSION=-next20130207-2-iniza-small >>>>>> dep-pkg options ... >>>>>> KDEB_PKGVERSION=3.8.0~rc6~next20130207-2~iniza+dileks1 >>>>>> fakeroot, while creating message channels: Invalid argument >>>>>> This may be due to a lack of SYSV IPC support. >>>>>> fakeroot: error while starting the `faked' daemon. >>>>>> kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec >>>>>> ... or kill -l [sigspec] >>>>>> >>>>>> >>>>>> Any hints? >>>>>> ( I could run strace... ) >>>>>> >>>>>> - Sedat - >>>>> >>>>> Attached strace outputs within yesterday's (GOOD) and today's (BAD) >>>>> Linux-Next. >>>>> >>>>> - Sedat - >>>> >>>> [ CCing Al and Eric ] >>>> >>>> I compared quickly the diff between the -next versions and saw changes >>>> coming from signal and userns trees. >>>> ( Sorry for re-attaching the strace outputs. ) >>> >>> It has been about a week and a half since I have pushed anything into >>> the userns tree, and I don't have anything ipc related in my tree. >>> So the reason for the suspicion seems odd. >>> >>> The straces are useless because all they show is that fakeroot was >>> forked, but there is not a trace of fakeroot itself. >>> >>> Given the timing my initial suspect would be the idr_preload patches >>> from Tejun that were merged via Andrew's akpm tree. I didn't see >>> anything in there that would kill ipc but that is likely the most recent >>> touch to the ipc code. >>> >> >> [ CCing Tejun ] >> >> Hmm, still stepping in the dark... >> >> OK, fakeroot does PRELOADing so your assumption makes sense. >> >> How can I trigger fakeroot calls? >> Here I have... >> /usr/bin/faked-sysv >> /usr/bin/faked-tcp >> >> I think that is the main commit but I am not sure if I can revert the >> idr_preload part, otherwise it gets complicated: >> >> commit e2802c2defba1e5c88d7d168eb5c66813c86f249 >> "idr: implement idr_preload[_end]() and idr_alloc()" >> >> $ grep idr ../Linux-Next-v20130206-VS-v20130207.diff | grep ^'++Applying:' >> ++Applying: block: fix ext_devt_idr handling >> ++Applying: idr: fix a subtle bug in idr_get_next() >> ++Applying: nfsd: idr_destroy() no longer needs idr_remove_all() >> ++Applying: idr: cosmetic updates to struct / initializer definitions >> ++Applying: idr: relocate idr_f
Re: [PATCH v2] ipc: convert to idr_alloc()
On Thu, Feb 7, 2013 at 5:14 PM, Tejun Heo wrote:
> Convert to the much saner new idr interface.
>
> The new interface doesn't directly translate to the way idr_pre_get()
> was used around ipc_addid() as preloading disables preemption. From
> my cursory reading, it seems like we should be able to do all
> allocation from ipc_addid(), so I moved it there. Can you please
> check whether this would be okay? If this is wrong and ipc_addid()
> should be allowed to be called from non-sleepable context, I'd suggest
> allocating id itself in the outer functions and later install the
> pointer using idr_replace().
>
> Only compile tested.
>
> v2: The v1 conversion of ipcget_public() was incorrect. As
> idr_pre_get() returns 0 for -ENOMEM failure, @err should have been
> initialized to 1 not 0. As the function doesn't do preloading
> itself anymore, there's no point in the error handling path.
> Simply remove the -ENOMEM path.
>
> Signed-off-by: Tejun Heo
> Reported-by: Sedat Dilek
> Cc: Stanislav Kinsbursky
> Cc: "Eric W. Biederman"
> Cc: James Morris
> ---
> Yeah, I messed up the ipcget_public() conversion. Can you please test
> this one?
>
Tested-by: Sedat Dilek [ The idr-i2c (v2) fix as well! ]
See also file attachments...
- Sedat -
> Thanks.
>
> ipc/util.c | 30 +-
> 1 file changed, 9 insertions(+), 21 deletions(-)
>
> --- a/ipc/util.c
> +++ b/ipc/util.c
> @@ -252,7 +252,7 @@ int ipc_addid(struct ipc_ids* ids, struc
> {
> kuid_t euid;
> kgid_t egid;
> - int id, err;
> + int id;
> int next_id = ids->next_id;
>
> if (size > IPCMNI)
> @@ -261,17 +261,21 @@ int ipc_addid(struct ipc_ids* ids, struc
> if (ids->in_use >= size)
> return -ENOSPC;
>
> + idr_preload(GFP_KERNEL);
> +
> spin_lock_init(&new->lock);
> new->deleted = 0;
> rcu_read_lock();
> spin_lock(&new->lock);
>
> - err = idr_get_new_above(&ids->ipcs_idr, new,
> - (next_id < 0) ? 0 : ipcid_to_idx(next_id),
> &id);
> - if (err) {
> + id = idr_alloc(&ids->ipcs_idr, new,
> + (next_id < 0) ? 0 : ipcid_to_idx(next_id), 0,
> + GFP_NOWAIT);
> + idr_preload_end();
> + if (id < 0) {
> spin_unlock(&new->lock);
> rcu_read_unlock();
> - return err;
> + return id;
> }
>
> ids->in_use++;
> @@ -307,19 +311,10 @@ static int ipcget_new(struct ipc_namespa
> struct ipc_ops *ops, struct ipc_params *params)
> {
> int err;
> -retry:
> - err = idr_pre_get(&ids->ipcs_idr, GFP_KERNEL);
> -
> - if (!err)
> - return -ENOMEM;
>
> down_write(&ids->rw_mutex);
> err = ops->getnew(ns, params);
> up_write(&ids->rw_mutex);
> -
> - if (err == -EAGAIN)
> - goto retry;
> -
> return err;
> }
>
> @@ -376,8 +371,6 @@ static int ipcget_public(struct ipc_name
> struct kern_ipc_perm *ipcp;
> int flg = params->flg;
> int err;
> -retry:
> - err = idr_pre_get(&ids->ipcs_idr, GFP_KERNEL);
>
> /*
> * Take the lock as a writer since we are potentially going to add
> @@ -389,8 +382,6 @@ retry:
> /* key not used */
> if (!(flg & IPC_CREAT))
> err = -ENOENT;
> - else if (!err)
> - err = -ENOMEM;
> else
> err = ops->getnew(ns, params);
> } else {
> @@ -413,9 +404,6 @@ retry:
> }
> up_write(&ids->rw_mutex);
>
> - if (err == -EAGAIN)
> - goto retry;
> -
> return err;
> }
>
execve("./scripts/build_linux-next.sh", ["./scripts/build_linux-next.sh"], [/*
48 vars */]) = 0
brk(0) = 0x17a
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fce1c17
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=93838, ...}) = 0
mmap(NULL, 93838, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fce1c159000
close(3)= 0
access("/etc/ld.s
Re: linux-next: Tree for Feb 6 [WARNING: at kernel/sched/clock.c:219 sched_clock_cpu+0xf9/0x110()]
On Wed, Feb 6, 2013 at 9:49 AM, Sedat Dilek wrote: > On Wed, Feb 6, 2013 at 9:23 AM, Sedat Dilek wrote: >> On Wed, Feb 6, 2013 at 8:43 AM, Stephen Rothwell >> wrote: >>> Hi all, >>> >>> Changes since 20130204: >>> >>> The metag tree gained a conflict against the arc tree. >>> >>> I added a couple of merge fix patches to the mips tree for breakage in >>> other architectures. >>> >>> The powerpc tree still had a build failure. >>> >>> The crypto tree gained a conflict against the net-next tree. >>> >>> The sound-asoc tree lost its build failure. >>> >>> The block tree gained a build failure for which I applied a merge fix >>> patch. >>> >>> The battery tree gained a conflict against the mfd tree. >>> >>> The spi tree gained a conflict against the sound-asoc tree. >>> >>> The kvm tree gained a conflict against the arm tree. >>> >>> The driver-core tree gained conflicts against the spi and iommu trees. >>> >>> The tty tree gained a build failure on sparc32 for which I applied a >>> patch. >>> >>> The akpm tree gained a conflict against the nfsd tree and a build failure >>> for which I reverted a commit. >>> >>> >>> >> >> [ CC x86 folks ] >> >> With today's Linux-Next I get this warning: >> >> [0.00] Console: colour dummy device 80x25 >> [0.00] [ cut here ] >> [0.00] WARNING: at kernel/sched/clock.c:219 >> sched_clock_cpu+0xf9/0x110() >> [0.00] Hardware name: 530U3BI/530U4BI/530U4BH >> [0.00] Modules linked in: >> [0.00] Pid: 0, comm: swapper/0 Not tainted >> 3.8.0-rc6-next20130206-1-iniza-small #1 >> [0.00] Call Trace: >> [0.00] [] warn_slowpath_common+0x7f/0xc0 >> [0.00] [] warn_slowpath_null+0x1a/0x20 >> [0.00] [] sched_clock_cpu+0xf9/0x110 >> [0.00] [] __console_unlock.part.9+0x31/0x440 >> [0.00] [] ? printk+0x61/0x63 >> [0.00] [] console_unlock+0x2d/0x40 >> [0.00] [] con_init+0x218/0x22b >> [0.00] [] console_init+0x16/0x27 >> [0.00] [] start_kernel+0x28b/0x3fc >> [0.00] [] ? repair_env_string+0x5a/0x5a >> [0.00] [] ? early_idt_handlers+0x120/0x120 >> [0.00] [] x86_64_start_reservations+0x2a/0x2c >> [0.00] [] x86_64_start_kernel+0xf3/0x102 >> [0.00] ---[ end trace 79eb6cf41ffc867b ]--- >> [0.00] console [tty0] enabled >> >> Not sure, if this related to the known console/fbcon locking issue. >> I will try later to merge [1] and check again. >> >> - Sedat - >> >> [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes > > Unrelated to known console/fbcon locking issue (see new dmesg). > > - Sedat - That issue disappeared with next-20130207, but with CONFIG_VIRT_CPU_ACCOUNTING=y. ( Did not test CONFIG_TICK_CPU_ACCOUNTING=y. ) /boot/config-3.8.0-rc6-next20130206-1-iniza-small:CONFIG_TICK_CPU_ACCOUNTING=y /boot/config-3.8.0-rc6-next20130207-1-iniza-small:CONFIG_VIRT_CPU_ACCOUNTING=y - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 8 [ idr fixes from akpm-tree ]
On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130207: > > The sound-asoc tree gained a build failure so I used the version from > next-20130207. > > The watchdog tree gained a conflict against the mfd tree. > > I applied a patch to restore some config defaults on PPC64. > > > Just FYI: I know of thwo idr patches in akpm-tree which are broken, means revert the one in Linux-Next and apply v2 from patchwork-service! The idr-ipc patch for example breaks fakeroot usage. - Sedat - [ Revert these ones ] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=2b24826129aab0352de55e44a99726aed47526a3 http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=5c72f8a116ad9e57b688e03ae9b44bf831100af9 [ Apply v2 ] https://patchwork.kernel.org/patch/2111991/ https://patchwork.kernel.org/patch/2112111/ -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130207: > > The sound-asoc tree gained a build failure so I used the version from > next-20130207. > > The watchdog tree gained a conflict against the mfd tree. > > I applied a patch to restore some config defaults on PPC64. > > > With today's Linux-Next I see this warning: [0.377442] [ cut here ] [0.377452] WARNING: at kernel/smp.c:245 smp_call_function_single+0x146/0x190() [0.377455] Hardware name: 530U3BI/530U4BI/530U4BH [0.377458] Modules linked in: [0.377463] Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc6-next20130208-1-iniza-small #1 [0.377467] Call Trace: [0.377473] [] warn_slowpath_common+0x7f/0xc0 [0.377479] [] ? acpi_cpufreq_target+0x2c0/0x2c0 [0.377483] [] warn_slowpath_null+0x1a/0x20 [0.377487] [] smp_call_function_single+0x146/0x190 [0.377492] [] ? acpi_cpufreq_target+0x2c0/0x2c0 [0.377496] [] smp_call_function_any+0x51/0x100 [0.377500] [] get_cur_val+0x99/0x130 [0.377504] [] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 [0.377508] [] get_cur_freq_on_cpu+0x60/0x80 [0.377512] [] acpi_cpufreq_cpu_init+0x412/0x6a0 [0.377517] [] cpufreq_add_dev+0x2d9/0x4f0 [0.377523] [] ? cpufreq_gov_dbs_init+0x2c/0x2c [0.377528] [] subsys_interface_register+0x89/0xd0 [0.377533] [] cpufreq_register_driver+0x8e/0x180 [0.377537] [] acpi_cpufreq_init+0xf6/0x1f8 [0.377542] [] ? platform_driver_register+0x46/0x50 [0.377547] [] do_one_initcall+0x3f/0x170 [0.377553] [] kernel_init_freeable+0x13e/0x1cd [0.377560] [] ? do_early_param+0x86/0x86 [0.377565] [] ? rest_init+0x80/0x80 [0.377569] [] kernel_init+0xe/0xf0 [0.377575] [] ret_from_fork+0x7c/0xb0 [0.377578] [] ? rest_init+0x80/0x80 [0.377581] ---[ end trace c6ec8280ce20313a ]--- kernel/smp.c: Line #245 see [1]. - Sedat - [1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=kernel/smp.c;hb=refs/tags/next-20130208#l245 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
On Fri, Feb 8, 2013 at 12:53 PM, Hillf Danton wrote:
> Hello Sedat
>
> On Fri, Feb 8, 2013 at 4:46 PM, Sedat Dilek wrote:
>> On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell
>> wrote:
>> With today's Linux-Next I see this warning:
>>
>> [0.377442] [ cut here ]
>> [0.377452] WARNING: at kernel/smp.c:245
>> smp_call_function_single+0x146/0x190()
>> [0.377455] Hardware name: 530U3BI/530U4BI/530U4BH
>> [0.377458] Modules linked in:
>> [0.377463] Pid: 1, comm: swapper/0 Not tainted
>> 3.8.0-rc6-next20130208-1-iniza-small #1
>> [0.377467] Call Trace:
>> [0.377473] [] warn_slowpath_common+0x7f/0xc0
>> [0.377479] [] ? acpi_cpufreq_target+0x2c0/0x2c0
>> [0.377483] [] warn_slowpath_null+0x1a/0x20
>> [0.377487] [] smp_call_function_single+0x146/0x190
>> [0.377492] [] ? acpi_cpufreq_target+0x2c0/0x2c0
>> [0.377496] [] smp_call_function_any+0x51/0x100
>> [0.377500] [] get_cur_val+0x99/0x130
>> [0.377504] [] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0
>> [0.377508] [] get_cur_freq_on_cpu+0x60/0x80
>> [0.377512] [] acpi_cpufreq_cpu_init+0x412/0x6a0
>> [0.377517] [] cpufreq_add_dev+0x2d9/0x4f0
>> [0.377523] [] ? cpufreq_gov_dbs_init+0x2c/0x2c
>> [0.377528] [] subsys_interface_register+0x89/0xd0
>> [0.377533] [] cpufreq_register_driver+0x8e/0x180
>> [0.377537] [] acpi_cpufreq_init+0xf6/0x1f8
>> [0.377542] [] ? platform_driver_register+0x46/0x50
>> [0.377547] [] do_one_initcall+0x3f/0x170
>> [0.377553] [] kernel_init_freeable+0x13e/0x1cd
>> [0.377560] [] ? do_early_param+0x86/0x86
>> [0.377565] [] ? rest_init+0x80/0x80
>> [0.377569] [] kernel_init+0xe/0xf0
>> [0.377575] [] ret_from_fork+0x7c/0xb0
>> [0.377578] [] ? rest_init+0x80/0x80
>> [0.377581] ---[ end trace c6ec8280ce20313a ]---
>>
>> kernel/smp.c: Line #245 see [1].
>>
> Can you please try the following?
>
> --- a/kernel/smp.c Fri Feb 8 19:25:32 2013
> +++ b/kernel/smp.c Fri Feb 8 19:53:14 2013
> @@ -241,7 +241,7 @@ int smp_call_function_single(int cpu, sm
> * send smp call function interrupt to this cpu and as such deadlocks
> * can't happen.
> */
> - WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() ||
> in_interrupt())
> + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> && !oops_in_progress);
>
> if (cpu == this_cpu) {
> --
NO, it doesn't.
So, you want to partly revert...
commit b29f39c7c3e75a741a7da88244ec707f293ec04c
"smp: Give WARN()ing if in_interrupt() when calling
smp_call_function_many()/single()"
...why not completely?
This patch was in last days Linux-Next and did not cause troubles (AFAICS).
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=b29f39c7c3e75a741a7da88244ec707f293ec04c
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
On Fri, Feb 8, 2013 at 2:21 PM, Rafael J. Wysocki wrote:
> On Friday, February 08, 2013 01:47:44 PM Sedat Dilek wrote:
>> On Fri, Feb 8, 2013 at 12:53 PM, Hillf Danton wrote:
>> > Hello Sedat
>> >
>> > On Fri, Feb 8, 2013 at 4:46 PM, Sedat Dilek wrote:
>> >> On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell
>> >> wrote:
>> >> With today's Linux-Next I see this warning:
>> >>
>> >> [0.377442] [ cut here ]
>> >> [0.377452] WARNING: at kernel/smp.c:245
>> >> smp_call_function_single+0x146/0x190()
>> >> [0.377455] Hardware name: 530U3BI/530U4BI/530U4BH
>> >> [0.377458] Modules linked in:
>> >> [0.377463] Pid: 1, comm: swapper/0 Not tainted
>> >> 3.8.0-rc6-next20130208-1-iniza-small #1
>> >> [0.377467] Call Trace:
>> >> [0.377473] [] warn_slowpath_common+0x7f/0xc0
>> >> [0.377479] [] ? acpi_cpufreq_target+0x2c0/0x2c0
>> >> [0.377483] [] warn_slowpath_null+0x1a/0x20
>> >> [0.377487] [] smp_call_function_single+0x146/0x190
>> >> [0.377492] [] ? acpi_cpufreq_target+0x2c0/0x2c0
>> >> [0.377496] [] smp_call_function_any+0x51/0x100
>> >> [0.377500] [] get_cur_val+0x99/0x130
>> >> [0.377504] [] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0
>> >> [0.377508] [] get_cur_freq_on_cpu+0x60/0x80
>> >> [0.377512] [] acpi_cpufreq_cpu_init+0x412/0x6a0
>> >> [0.377517] [] cpufreq_add_dev+0x2d9/0x4f0
>> >> [0.377523] [] ? cpufreq_gov_dbs_init+0x2c/0x2c
>> >> [0.377528] [] subsys_interface_register+0x89/0xd0
>> >> [0.377533] [] cpufreq_register_driver+0x8e/0x180
>> >> [0.377537] [] acpi_cpufreq_init+0xf6/0x1f8
>> >> [0.377542] [] ? platform_driver_register+0x46/0x50
>> >> [0.377547] [] do_one_initcall+0x3f/0x170
>> >> [0.377553] [] kernel_init_freeable+0x13e/0x1cd
>> >> [0.377560] [] ? do_early_param+0x86/0x86
>> >> [0.377565] [] ? rest_init+0x80/0x80
>> >> [0.377569] [] kernel_init+0xe/0xf0
>> >> [0.377575] [] ret_from_fork+0x7c/0xb0
>> >> [0.377578] [] ? rest_init+0x80/0x80
>> >> [0.377581] ---[ end trace c6ec8280ce20313a ]---
>> >>
>> >> kernel/smp.c: Line #245 see [1].
>> >>
>> > Can you please try the following?
>> >
>> > --- a/kernel/smp.c Fri Feb 8 19:25:32 2013
>> > +++ b/kernel/smp.c Fri Feb 8 19:53:14 2013
>> > @@ -241,7 +241,7 @@ int smp_call_function_single(int cpu, sm
>> > * send smp call function interrupt to this cpu and as such
>> > deadlocks
>> > * can't happen.
>> > */
>> > - WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() ||
>> > in_interrupt())
>> > + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
>> > && !oops_in_progress);
>> >
>> > if (cpu == this_cpu) {
>> > --
>>
>> NO, it doesn't.
>>
>> So, you want to partly revert...
>>
>> commit b29f39c7c3e75a741a7da88244ec707f293ec04c
>> "smp: Give WARN()ing if in_interrupt() when calling
>> smp_call_function_many()/single()"
>>
>> ...why not completely?
>>
>> This patch was in last days Linux-Next and did not cause troubles (AFAICS).
>
> This problem was introduced by some cpufreq changes that have been dropped
> from
> linux-next for now (they are still present in the one you're testing, though).
>
"...some...changes..." is not very concrete :-).
Which commit(s) caused this trouble?
Is current (meanwhile updated?) linux-pm.git#linux-next good (didn't
check last commit-ids of your tree from Next/ dir)?
- Sedat -
> Thanks,
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
On Fri, Feb 8, 2013 at 3:45 PM, Viresh Kumar wrote: > On 8 February 2013 18:51, Rafael J. Wysocki wrote: >> On Friday, February 08, 2013 01:47:44 PM Sedat Dilek wrote: >>> >> [0.377473] [] warn_slowpath_common+0x7f/0xc0 >>> >> [0.377479] [] ? acpi_cpufreq_target+0x2c0/0x2c0 >>> >> [0.377483] [] warn_slowpath_null+0x1a/0x20 >>> >> [0.377487] [] smp_call_function_single+0x146/0x190 >>> >> [0.377492] [] ? acpi_cpufreq_target+0x2c0/0x2c0 >>> >> [0.377496] [] smp_call_function_any+0x51/0x100 >>> >> [0.377500] [] get_cur_val+0x99/0x130 >>> >> [0.377504] [] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 >>> >> [0.377508] [] get_cur_freq_on_cpu+0x60/0x80 >>> >> [0.377512] [] acpi_cpufreq_cpu_init+0x412/0x6a0 >>> >> [0.377517] [] cpufreq_add_dev+0x2d9/0x4f0 > >> This problem was introduced by some cpufreq changes that have been dropped >> from >> linux-next for now (they are still present in the one you're testing, >> though). > > I know why you got this crash and a pull from following would > certainly fix it :) > > http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-rafael Nah, I pulled in latest pm-next where this commit is new... commit 8d5666f3456f2fd4a4e5dced228475b829851e53 "ACPI: Unbind ACPI drv when probe failed" ...building with it. Same to you, say concretely which commit is fixing what... Pull-N-B-Happy was never my strategy... I want to understand what went wrong and have stolen my time. - Sedat - [1] http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=commitdiff;h=8d5666f3456f2fd4a4e5dced228475b829851e53 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
On Fri, Feb 8, 2013 at 3:50 PM, Viresh Kumar wrote:
> On Fri, Feb 8, 2013 at 7:45 PM, Sedat Dilek wrote:
>> "...some...changes..." is not very concrete :-).
>> Which commit(s) caused this trouble?
>>
>> Is current (meanwhile updated?) linux-pm.git#linux-next good (didn't
>> check last commit-ids of your tree from Next/ dir)?
>
> Attached patch would fix it for you and it looks like and is going to be
> pulled in by Rafael:
>
> From: Viresh Kumar
> Date: Fri, 8 Feb 2013 10:35:31 +0530
> Subject: [PATCH] cpufreq: Remove unnecessary locking
>
> I have placed some locks intentionally around calls to driver->ops
> (init/exit),
> which look to be wrong as these calls can call routines that potentially
> sleep.
>
> Lets remove these locks.
>
> Signed-off-by: Viresh Kumar
Tested-by: Sedat Dilek
( 0001-cpufreq-Remove-unnecessary-locking.patch fixes the issue here! )
- Sedat -
> ---
> drivers/cpufreq/cpufreq.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 5d8a422..04aab05 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
>
> if (ret) {
> pr_debug("setting policy failed\n");
> - spin_lock_irqsave(&cpufreq_driver_lock, flags);
> if (driver->exit)
> driver->exit(policy);
> - spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> }
> return ret;
>
> @@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev,
> struct subsys_interface *sif)
> init_completion(&policy->kobj_unregister);
> INIT_WORK(&policy->update, handle_update);
>
> - spin_lock_irqsave(&cpufreq_driver_lock, flags);
> /* call driver. From then on the cpufreq must be able
> * to accept all calls to ->verify and ->setpolicy for this CPU
> */
> ret = driver->init(policy);
> if (ret) {
> pr_debug("initialization failed\n");
> - spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> goto err_set_policy_cpu;
> }
> - spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>
> /* related cpus should atleast have policy->cpus */
> cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
> @@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device
> *dev, struct subsys_interface *sif
> wait_for_completion(cmp);
> pr_debug("wait complete\n");
>
> - spin_lock_irqsave(&cpufreq_driver_lock, flags);
> if (driver->exit)
> driver->exit(data);
> - spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>
> free_cpumask_var(data->related_cpus);
> free_cpumask_var(data->cpus);
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
On Fri, Feb 8, 2013 at 3:56 PM, Viresh Kumar wrote: > On Fri, Feb 8, 2013 at 8:18 PM, Sedat Dilek wrote: >> Nah, I pulled in latest pm-next where this commit is new... >> >> commit 8d5666f3456f2fd4a4e5dced228475b829851e53 >> "ACPI: Unbind ACPI drv when probe failed" >> >> ...building with it. >> >> Same to you, say concretely which commit is fixing what... >> >> Pull-N-B-Happy was never my strategy... I want to understand what went >> wrong and have stolen my time. > > I don't have any pointers to broken tree and so can't point you to the > culprit, > but it was this patch: > > http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=commit;h=e034e731f4d9d18ad0401f033f485a3096796c58 > > minus > > the patch i sent you as attachment. > > There were some locking introduced around init/exit of cpufreq_driver, which > caused some drivers to break. Its fixed now in the above commit. Hmm, this "high-patch-maths" is not user-friendly! I will pull-in your tree into Linux-Next (next-20130208) and see if it applies cleanly. - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
On Fri, Feb 8, 2013 at 4:21 PM, Sedat Dilek wrote: > On Fri, Feb 8, 2013 at 3:56 PM, Viresh Kumar wrote: >> On Fri, Feb 8, 2013 at 8:18 PM, Sedat Dilek wrote: >>> Nah, I pulled in latest pm-next where this commit is new... >>> >>> commit 8d5666f3456f2fd4a4e5dced228475b829851e53 >>> "ACPI: Unbind ACPI drv when probe failed" >>> >>> ...building with it. >>> >>> Same to you, say concretely which commit is fixing what... >>> >>> Pull-N-B-Happy was never my strategy... I want to understand what went >>> wrong and have stolen my time. >> >> I don't have any pointers to broken tree and so can't point you to the >> culprit, >> but it was this patch: >> >> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=commit;h=e034e731f4d9d18ad0401f033f485a3096796c58 >> >> minus >> >> the patch i sent you as attachment. >> >> There were some locking introduced around init/exit of cpufreq_driver, which >> caused some drivers to break. Its fixed now in the above commit. > > Hmm, this "high-patch-maths" is not user-friendly! > > I will pull-in your tree into Linux-Next (next-20130208) and see if it > applies cleanly. > > - Sedat - No, it did NOT apply cleanly and I merged your tree like this. To me it does not look like your changes from the patch you sent me are included? - Sedat - cpufreq-next.patch Description: Binary data
Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
On Fri, Feb 8, 2013 at 5:28 PM, Sedat Dilek wrote: > On Fri, Feb 8, 2013 at 4:21 PM, Sedat Dilek wrote: >> On Fri, Feb 8, 2013 at 3:56 PM, Viresh Kumar wrote: >>> On Fri, Feb 8, 2013 at 8:18 PM, Sedat Dilek wrote: >>>> Nah, I pulled in latest pm-next where this commit is new... >>>> >>>> commit 8d5666f3456f2fd4a4e5dced228475b829851e53 >>>> "ACPI: Unbind ACPI drv when probe failed" >>>> >>>> ...building with it. >>>> >>>> Same to you, say concretely which commit is fixing what... >>>> >>>> Pull-N-B-Happy was never my strategy... I want to understand what went >>>> wrong and have stolen my time. >>> >>> I don't have any pointers to broken tree and so can't point you to the >>> culprit, >>> but it was this patch: >>> >>> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=commit;h=e034e731f4d9d18ad0401f033f485a3096796c58 >>> >>> minus >>> >>> the patch i sent you as attachment. >>> >>> There were some locking introduced around init/exit of cpufreq_driver, which >>> caused some drivers to break. Its fixed now in the above commit. >> >> Hmm, this "high-patch-maths" is not user-friendly! >> >> I will pull-in your tree into Linux-Next (next-20130208) and see if it >> applies cleanly. >> >> - Sedat - > > No, it did NOT apply cleanly and I merged your tree like this. > To me it does not look like your changes from the patch you sent me > are included? > > - Sedat - Looks like I did it correct - no WARNINGs. # diff -uprN /boot/config-3.8.0-rc6-next20130208-1-iniza-small /boot/config-3.8.0-rc6-next20130208-6-iniza-small --- /boot/config-3.8.0-rc6-next20130208-1-iniza-small 2013-02-08 09:34:59.0 +0100 +++ /boot/config-3.8.0-rc6-next20130208-6-iniza-small 2013-02-08 17:36:02.0 +0100 @@ -601,6 +601,7 @@ CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # x86 CPU frequency scaling drivers # +CONFIG_X86_INTEL_PSTATE=y CONFIG_X86_PCC_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ_CPB=y # dmesg | grep -i pstate [0.387256] Intel pstate controlling: cpu 0 [0.387273] Intel pstate controlling: cpu 1 [0.387286] Intel pstate controlling: cpu 2 [0.387303] Intel pstate controlling: cpu 3 [ 151.315937] Intel pstate controlling: cpu 1 [ 151.329400] Intel pstate controlling: cpu 2 [ 151.342778] Intel pstate controlling: cpu 3 So, suspend-resume is good here. - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 8:19 PM, Yinghai Lu wrote: > On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley > wrote: >> On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: >>> On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu wrote: >>> > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley >>> > wrote: >>> >> On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote: >>> >>> On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: >>> >>> > On Tue, 5 Feb 2013, Peter Hurley wrote: >>> >>> > >>> >>> > > With -next-20130204: >>> >>> > > >>> >>> > > [ 33.855570] irq 18: nobody cared (try booting with the "irqpoll" >>> >>> > > option) >>> >>> > > [ 33.855580] Pid: 0, comm: swapper/4 Not tainted >>> >>> > > 3.8.0-next-20130204-xeon #20130204 >>> >>> > > [ 33.855582] Call Trace: >>> >>> > > [ 33.855585][] >>> >>> > > __report_bad_irq+0x36/0xe0 >>> >>> > > [ 33.855600] [] note_interrupt+0x1aa/0x200 >>> >>> > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 >>> >>> > > [ 33.855610] [] >>> >>> > > handle_irq_event_percpu+0xc9/0x260 >>> >>> > > [ 33.855614] [] handle_irq_event+0x48/0x70 >>> >>> > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 >>> >>> > > [ 33.855624] [] handle_irq+0x22/0x40 >>> >>> > > [ 33.855630] [] do_IRQ+0x5a/0xd0 >>> >>> > > [ 33.855636] [] common_interrupt+0x6d/0x6d >>> >>> > > [ 33.855638][] ? >>> >>> > > rcu_eqs_enter_common+0x4a/0x320 >>> >>> > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 >>> >>> > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 >>> >>> > > [ 33.855653] [] cpu_idle+0x116/0x130 >>> >>> > > [ 33.855658] [] start_secondary+0x251/0x258 >>> >>> > > [ 33.855660] handlers: >>> >>> > > [ 33.855664] [] usb_hcd_irq >>> >>> > > [ 33.855667] Disabling IRQ #18 >>> >>> > > >>> >> https://bugzilla.kernel.org/show_bug.cgi?id=53561 >>> >> >>> >> Maybe this is some interaction with all the new ACPI code and fixes >>> >> written in those 8 days. >>> > >>> > interrupt routing seems get changed: >>> > next: >>> >5: 0 0 0 0 0 >>> > 0 0 0 IO-APIC-fasteoi snd_ctxfi >>> > 18: 99970 13 16 20 99940 >>> > 13 13 16 IO-APIC-fasteoi uhci_hcd:usb4 >>> > v3.8-rc7: >>> > 18:424 15 11112420 >>> > 16 18105 IO-APIC-fasteoi uhci_hcd:usb4, snd_ctxfi >>> > >>> > These messages in the bad dmesg log are interesting since PCI INT A is >>> > routed >>> > on >>> > irq 18 with the kernels that work. >>> > [8.983246] pci :00:1e.0: can't derive routing for PCI INT A >>> > [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 >>> > ... >>> > >>> > acpi_pci_irq_add_prt() add wrong bus for that bridge, because that >>> > that bridge is not scanned. >>> > >>> > Will check if I can produce one patch for it. >>> >>> Hi Peter, >>> >>> Can you try attached debug patch? >> >> Fixed, thanks. > > Bjorn, Rafael, > > acpi_pci_irq_add_prt need to be called after pci bridge get scanned, > so we can not call it from pci_acpi_setup, after we move dev_register > for pci_dev early. > > The attached debug patch move down that calling into > pci_bus_add_devices and that will make prt works again. > > Can acpi provide another hook after bridge get scanned? > 23: + /* need to after bridge is scanned */ 24: + pcibios_irq_setup(&dev->dev); ... need to *be called* after... Even this is a temporary workaround, can you send a separate patch for this? - Sedat - P.S.: Still wonder why people use "linux-2.6" as prefix in their patches. > Thanks > > Yinghai -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 12 [ WARNING: at drivers/tty/tty_buffer.c:427 flush_to_ldisc | tty is NULL ]
On Tue, Feb 12, 2013 at 6:09 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130211: > > The acpi tree lost its build failure. > > The net-next tree gained a conflict against the net tree. > > The arm-soc tree gained conflicts against the usb and metag trees. > > > [ CCing linux-serial and linux-pm folks ] When starting suspend (seen once, 2nd suspend was OK)... [ 706.950122] PM: Syncing filesystems ... done. [ 706.953773] PM: Preparing system for mem sleep [ 726.174449] [ cut here ] [ 726.174469] WARNING: at drivers/tty/tty_buffer.c:427 flush_to_ldisc+0x1ac/0x1c0() [ 726.174473] Hardware name: 530U3BI/530U4BI/530U4BH [ 726.174476] tty is NULL [ 707.034695] Freezing user space processes ... [ 726.174479] Modules linked in: btrfs zlib_deflate xfs libcrc32c bnep rfcomm parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_realtek coretemp kvm_intel arc4 kvm iwldvm mac80211 snd_hda_intel ghash_clmulni_intel aesni_intel snd_hda_codec xts uvcvideo aes_x86_64 snd_hwdep snd_pcm lrw gf128mul videobuf2_vmalloc ablk_helper snd_page_alloc joydev videobuf2_memops i915 cryptd snd_seq_midi videobuf2_core snd_seq_midi_event videodev iwlwifi snd_rawmidi snd_seq snd_timer snd_seq_device i2c_algo_bit drm_kms_helper cfg80211 btusb snd psmouse drm soundcore microcode bluetooth samsung_laptop serio_raw wmi lpc_ich mei mac_hid video lp parport hid_generic usbhid hid r8169 [ 726.174529] Pid: 2507, comm: kworker/0:0 Not tainted 3.8.0-rc7-next20130212-3-iniza-small #1 [ 726.174530] Call Trace: [ 726.174535] [] warn_slowpath_common+0x7f/0xc0 [ 726.174538] [] warn_slowpath_fmt+0x46/0x50 [ 726.174541] [] flush_to_ldisc+0x1ac/0x1c0 [ 726.174544] [] process_one_work+0x16b/0x400 [ 726.174547] [] worker_thread+0x118/0x360 [ 726.174549] [] ? manage_workers+0x350/0x350 [ 726.174552] [] kthread+0xc0/0xd0 [ 726.174554] [] ? flush_kthread_worker+0xb0/0xb0 [ 726.174557] [] ret_from_fork+0x7c/0xb0 [ 726.174559] [] ? flush_kthread_worker+0xb0/0xb0 [ 726.174560] ---[ end trace bf493695d326ce7b ]--- [ 726.379024] [ cut here ] - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 25 (BROKEN suspend)
On Mon, Jan 28, 2013 at 8:28 PM, Tejun Heo wrote: > Hello, guys. > > On Sun, Jan 27, 2013 at 02:01:50PM +0100, Sedat Dilek wrote: >> OK, that bisecting ruined a bit my weekend and showed me again you >> cannot really bisect Linux-Next. >> Sometimes, it is better not to trust the tools blindly and do a >> bisect-on-suspicion. >> Anyway... cultprit found... patch found... applied... all GOOD now. >> ( If I had waited for next Monday's next-20130127 I would not have >> seen what caused the trouble. ). > > Yeah, my usual test setup didn't have async tasks w/o domain so I > failed to notice the breakage. Sorry about the trouble guys and lots > of thanks to Sedat for the firefighting over the weekend. :) > [ CC James ] Hi Tejun, I don't see that git-bisect session as a time of waste, but two hints: 1. People should sent their patches concerning especially Linux-Next fixes not only to LKML but also to (if this is not known, pointing to James). 2. These patches for Linux-Next should contain a "-next" in their subject-line (use 'git format-patch --subject-prefix="PATCH -next" ...'). Of course, I should have checked the MLs... but for me it was not clear what was the root cause (which subsystem to blame)... I had only some suspicions. Anyway, noone gave me any pointer on how to log bastard logs before my system got frozen (2nd machine not available). I know that is tricky! For a better world... Regards, - Sedat - > -- > tejun -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 25 (BROKEN suspend)
On Mon, Jan 28, 2013 at 11:08 PM, Tejun Heo wrote: > Hello, Sedat. > > On Mon, Jan 28, 2013 at 11:06:11PM +0100, Sedat Dilek wrote: >> 1. People should sent their patches concerning especially Linux-Next >> fixes not only to LKML but also to (if >> this is not known, pointing to James). >> >> 2. These patches for Linux-Next should contain a "-next" in their >> subject-line (use 'git format-patch --subject-prefix="PATCH -next" >> ...'). >> >> Of course, I should have checked the MLs... but for me it was not >> clear what was the root cause (which subsystem to blame)... I had only >> some suspicions. > > Yeah, there was no way for you guys to easily discover that the > problem has already been identified and fix pending. I'll definitely > try to cc linux-next cc'd on patches which fix problems in -next. > > Thanks a lot! > Hi Tejun, BTW, I am reading MLs mostly offline! That means I cannot grep for search-patterns I like (here: LKML). Offline-reading also means, you get replies a lot of later. NO, I am not planning to flood my INBOX with postings from LKML :-). I highly suggest to send -next patches also to LKML. Patchwork-service [1] makes it easy to get them in mbox-format for easy application. FYI: I am subscribed to linux-next ML and some other "smaller" linux-* MLs. I dunno why Linux-Next hasn't join patchwork-service. Stephen? Also think of multiple postings of patches for the same issue :-). ...and lame and/or disappeared maintainers. For a more better world... - Sedat - [1] marc.info/?l=linux-kernel [2] http://marc.info/?l=linux-next [3] https://patchwork.kernel.org/project/LKML/list/ > -- > tejun -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] cputime: Safely read cputime of full dynticks CPUs
On Mon, Jan 28, 2013 at 10:51 PM, Sedat Dilek wrote: > On Mon, Jan 28, 2013 at 8:04 PM, Frederic Weisbecker > wrote: >> While remotely reading the cputime of a task running in a >> full dynticks CPU, the values stored in utime/stime fields >> of struct task_struct may be stale. Its values may be those >> of the last kernel <-> user transition time snapshot and >> we need to add the tickless time spent since this snapshot. >> >> To fix this, flush the cputime of the dynticks CPUs on >> kernel <-> user transition and record the time / context >> where we did this. Then on top of this snapshot and the current >> time, perform the fixup on the reader side from task_times() >> accessors. >> >> Signed-off-by: Frederic Weisbecker >> Cc: Andrew Morton >> Cc: Ingo Molnar >> Cc: Li Zhong >> Cc: Namhyung Kim >> Cc: Paul E. McKenney >> Cc: Paul Gortmaker >> Cc: Peter Zijlstra >> Cc: Steven Rostedt >> Cc: Thomas Gleixner >> [fixed kvm module related build errors] >> Signed-off-by: Sedat Dilek >> > > Can you explain a bit what is the difference between "3.8-rc4-nohz3" > and "full-dynticks-cputime-for-mingo" patchsets? > > Does the latter need no more EXPORT_SYMBOL_GPL for vtime_guest_enter() > and vtime_guest_exit() when CONFIG_KVM=m (see [1])? > > - Sedat - > > [1] https://lkml.org/lkml/2013/1/23/473 To answer my question by myself... $ grep 'CONFIG_KVM=' linux/.config CONFIG_KVM=m $ grep kvm deb-pkg.log CC arch/x86/kernel/kvm.o CC arch/x86/kernel/kvmclock.o LD arch/x86/kvm/built-in.o CC [M] arch/x86/kvm/vmx.o CC [M] arch/x86/kvm/../../../virt/kvm/kvm_main.o CC [M] arch/x86/kvm/../../../virt/kvm/ioapic.o CC [M] arch/x86/kvm/../../../virt/kvm/coalesced_mmio.o CC [M] arch/x86/kvm/../../../virt/kvm/irq_comm.o CC [M] arch/x86/kvm/../../../virt/kvm/eventfd.o CC [M] arch/x86/kvm/../../../virt/kvm/assigned-dev.o CC [M] arch/x86/kvm/../../../virt/kvm/iommu.o CC [M] arch/x86/kvm/../../../virt/kvm/async_pf.o CC [M] arch/x86/kvm/x86.o CC [M] arch/x86/kvm/mmu.o CC [M] arch/x86/kvm/emulate.o CC [M] arch/x86/kvm/i8259.o CC [M] arch/x86/kvm/irq.o CC [M] arch/x86/kvm/lapic.o CC [M] arch/x86/kvm/i8254.o CC [M] arch/x86/kvm/cpuid.o CC [M] arch/x86/kvm/pmu.o LD [M] arch/x86/kvm/kvm.o LD [M] arch/x86/kvm/kvm-intel.o CC arch/x86/kvm/kvm-intel.mod.o CC arch/x86/kvm/kvm.mod.o LD [M] arch/x86/kvm/kvm-intel.ko LD [M] arch/x86/kvm/kvm.ko INSTALL arch/x86/kvm/kvm-intel.ko INSTALL arch/x86/kvm/kvm.ko ...both EXPORT_SYMBOL_GPLs are no more needed! - Sedat . -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] cputime: Safely read cputime of full dynticks CPUs
On Thu, Jan 31, 2013 at 1:38 AM, Frederic Weisbecker wrote: > 2013/1/28 Sedat Dilek : >> On Mon, Jan 28, 2013 at 8:04 PM, Frederic Weisbecker >> wrote: >>> While remotely reading the cputime of a task running in a >>> full dynticks CPU, the values stored in utime/stime fields >>> of struct task_struct may be stale. Its values may be those >>> of the last kernel <-> user transition time snapshot and >>> we need to add the tickless time spent since this snapshot. >>> >>> To fix this, flush the cputime of the dynticks CPUs on >>> kernel <-> user transition and record the time / context >>> where we did this. Then on top of this snapshot and the current >>> time, perform the fixup on the reader side from task_times() >>> accessors. >>> >>> Signed-off-by: Frederic Weisbecker >>> Cc: Andrew Morton >>> Cc: Ingo Molnar >>> Cc: Li Zhong >>> Cc: Namhyung Kim >>> Cc: Paul E. McKenney >>> Cc: Paul Gortmaker >>> Cc: Peter Zijlstra >>> Cc: Steven Rostedt >>> Cc: Thomas Gleixner >>> [fixed kvm module related build errors] >>> Signed-off-by: Sedat Dilek >>> >> >> Can you explain a bit what is the difference between "3.8-rc4-nohz3" >> and "full-dynticks-cputime-for-mingo" patchsets? > > 3.8-rc4-nohz3 is the latest experimental tree that implements full > dynticks. It includes an earlier version of full dynticks cputime and > many other things to make the full dynticks possible: nohz printk, > many tweaks on the scheduler and timers...etc > So, dynticks-cputime will go into 3.9? What about the other parts? Coming later? >> >> Does the latter need no more EXPORT_SYMBOL_GPL for vtime_guest_enter() >> and vtime_guest_exit() when CONFIG_KVM=m (see [1])? > > It doesn't need export symbol on vtime_guest_() APIs, only on > guest_enter and guest_exit. > I verified this by building by myself. - Sedat - > Thanks. -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] cputime: Safely read cputime of full dynticks CPUs
On Thu, Jan 31, 2013 at 11:12 AM, Frederic Weisbecker wrote: > 2013/1/31 Sedat Dilek : >> On Thu, Jan 31, 2013 at 1:38 AM, Frederic Weisbecker >> wrote: >>> 2013/1/28 Sedat Dilek : >>>> On Mon, Jan 28, 2013 at 8:04 PM, Frederic Weisbecker >>>> wrote: >>>>> While remotely reading the cputime of a task running in a >>>>> full dynticks CPU, the values stored in utime/stime fields >>>>> of struct task_struct may be stale. Its values may be those >>>>> of the last kernel <-> user transition time snapshot and >>>>> we need to add the tickless time spent since this snapshot. >>>>> >>>>> To fix this, flush the cputime of the dynticks CPUs on >>>>> kernel <-> user transition and record the time / context >>>>> where we did this. Then on top of this snapshot and the current >>>>> time, perform the fixup on the reader side from task_times() >>>>> accessors. >>>>> >>>>> Signed-off-by: Frederic Weisbecker >>>>> Cc: Andrew Morton >>>>> Cc: Ingo Molnar >>>>> Cc: Li Zhong >>>>> Cc: Namhyung Kim >>>>> Cc: Paul E. McKenney >>>>> Cc: Paul Gortmaker >>>>> Cc: Peter Zijlstra >>>>> Cc: Steven Rostedt >>>>> Cc: Thomas Gleixner >>>>> [fixed kvm module related build errors] >>>>> Signed-off-by: Sedat Dilek >>>>> >>>> >>>> Can you explain a bit what is the difference between "3.8-rc4-nohz3" >>>> and "full-dynticks-cputime-for-mingo" patchsets? >>> >>> 3.8-rc4-nohz3 is the latest experimental tree that implements full >>> dynticks. It includes an earlier version of full dynticks cputime and >>> many other things to make the full dynticks possible: nohz printk, >>> many tweaks on the scheduler and timers...etc >>> >> >> So, dynticks-cputime will go into 3.9? > > I can't say "will" but I hope. > >> What about the other parts? Coming later? > > May be the printk part will go into 3.9. Linus ignored my pull request > so may be we'll get more chances if it goes through Ingo. > I still dunno all parts of dynticks and their correlation. AFAICS they seem to be independent, can't say if it is "complete" with dynticks-cputime-only. Was that dynticks stuff ever advertised for Linux-Next inclusion? Or wnt through any "mingo-next" tree? AFAICS, better chances these ways! - Sedat - > And the rest will come later. -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert "console: implement lockdep support for console_lock"
On Fri, Feb 1, 2013 at 9:42 AM, Daniel Vetter wrote:
> On Fri, Feb 1, 2013 at 9:21 AM, Sedat Dilek wrote:
>> people having the fbcon-locking-fixes [1] in their local GIT tree can
>> revert this change?
>
> Yeah, if you have all the fixes reverting this is fine and appreciated
> to increase testing. Dave will probably push the revert himself to
> drm-next soon.
[ CCing Ingo ]
The revert is now in -rc6.
Hmmm, I have here...
CONFIG_LOCKDEP_SUPPORT=y
Excerpts from the revert [1]:
[...]
-#ifdef CONFIG_LOCKDEP
-static struct lockdep_map console_lock_dep_map = {
- .name = "console_lock"
-};
-#endif
[...]
Checking for CONFIG_LOCKDEP ...
[ lib/Kconfig.debug ]
...
config LOCKDEP
bool
depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT &&
STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
select STACKTRACE
select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390
&& !MICROBLAZE
select KALLSYMS
select KALLSYMS_ALL
...
---> No help text.
---> Missing pointer to .
[ arch/x86/Kconfig ]
...
config LOCKDEP_SUPPORT
def_bool y
...
I would have expected a check for CONFIG_LOCKDEP_SUPPORT.
This is BTW with Linux v3.8-rc5!
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ff0d05bf73620eb7dc8aee7423e992ef87870bdf
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/lockdep-design.txt
> -Daniel
>
>>
>> commit ff0d05bf73620eb7dc8aee7423e992ef87870bdf
>> Refs: v3.8-rc5-194-gff0d05b
>> Author: Dave Airlie
>> AuthorDate: Thu Jan 31 14:27:03 2013 +1100
>> Commit: Dave Airlie
>> CommitDate: Thu Jan 31 15:46:56 2013 +1100
>>
>> Revert "console: implement lockdep support for console_lock"
>>
>> This reverts commit daee779718a319ff9f83e1ba3339334ac650bb22.
>>
>> I'll requeue this after the console locking fixes, so lockdep
>> is useful again for people until fbcon is fixed.
>>
>> Signed-off-by: Dave Airlie
>>
>> Thanks!
>>
>> Regards,
>> - Sedat
>>
>> [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 25 (BROKEN suspend)
On Sat, Jan 26, 2013 at 12:10 PM, Sedat Dilek wrote: > On Fri, Jan 25, 2013 at 6:26 AM, Stephen Rothwell > wrote: >> Hi all, >> >> Changes since 20130124: >> >> New trees: ipsec and ipsec-next >> >> The powerpc tree still had a build failure. >> >> The sound-asoc tree still had its build failure so I used the version from >> next-20130122. >> >> The akpm tree lost its build failure and several patches that turned up >> elsewhere. >> >> >> > > Unfortunately, on suspend or running the pm_test/freezer leads here to > a frozen machine - hard reset. > > I see 4-5 pages of call-traces but dunno how to log them in such a f-u-ed > state. > Any hints welcome! > > As I saw catched with my left eye on one call-trace sth. with... > > kernel/watchdog.c (line #245, watchdog_overflow_callback) > > ... I tried to revert the last two commits from Sascha (see -3 patch, > but no success. > > The same with reverting all cpu-freq changes since v3.8-rc4 (see -4 > patch) after seeing some suspicious lines on the screen. > > Can someone confirm that suspend is BROKEN for him/her before doing > eventually a bisect? > > Thanks! > > Regards, > - Sedat - > > [1] > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=kernel/watchdog.c;hb=refs/tags/next-20130125#l245 Just FYI: Linux-Next (next-20130124) is also BROKEN on suspend here. Latest GOOD is next-20130123... next-20130121 was also GOOD (I had tested some days ago). - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 25 (BROKEN suspend)
On Sat, Jan 26, 2013 at 2:25 PM, Rafael J. Wysocki wrote: > On Saturday, January 26, 2013 12:10:32 PM Sedat Dilek wrote: >> On Fri, Jan 25, 2013 at 6:26 AM, Stephen Rothwell >> wrote: >> > Hi all, >> > >> > Changes since 20130124: >> > >> > New trees: ipsec and ipsec-next >> > >> > The powerpc tree still had a build failure. >> > >> > The sound-asoc tree still had its build failure so I used the version from >> > next-20130122. >> > >> > The akpm tree lost its build failure and several patches that turned up >> > elsewhere. >> > >> > >> > >> >> Unfortunately, on suspend or running the pm_test/freezer leads here to >> a frozen machine - hard reset. >> >> I see 4-5 pages of call-traces but dunno how to log them in such a f-u-ed >> state. >> Any hints welcome! >> >> As I saw catched with my left eye on one call-trace sth. with... >> >> kernel/watchdog.c (line #245, watchdog_overflow_callback) >> >> ... I tried to revert the last two commits from Sascha (see -3 patch, >> but no success. >> >> The same with reverting all cpu-freq changes since v3.8-rc4 (see -4 >> patch) after seeing some suspicious lines on the screen. >> >> Can someone confirm that suspend is BROKEN for him/her before doing >> eventually a bisect? > > Can you please test the linux-next branch of the linux-pm.git tree alone? > That sounds like a good idea as I just reverted "cpu-hotplug, memory-hotplug: try offlining the node when hotremoving a cpu" [1] from akpm tree. Building... 1st with revert than trying pm-next only. - Sedat - [1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=154cb61f36690edef68beb5fd9dc0a5027f9dbd9 > Rafael > > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 25 (BROKEN suspend)
On Sat, Jan 26, 2013 at 2:24 PM, Sedat Dilek wrote: > On Sat, Jan 26, 2013 at 2:25 PM, Rafael J. Wysocki wrote: >> On Saturday, January 26, 2013 12:10:32 PM Sedat Dilek wrote: >>> On Fri, Jan 25, 2013 at 6:26 AM, Stephen Rothwell >>> wrote: >>> > Hi all, >>> > >>> > Changes since 20130124: >>> > >>> > New trees: ipsec and ipsec-next >>> > >>> > The powerpc tree still had a build failure. >>> > >>> > The sound-asoc tree still had its build failure so I used the version from >>> > next-20130122. >>> > >>> > The akpm tree lost its build failure and several patches that turned up >>> > elsewhere. >>> > >>> > >>> > >>> >>> Unfortunately, on suspend or running the pm_test/freezer leads here to >>> a frozen machine - hard reset. >>> >>> I see 4-5 pages of call-traces but dunno how to log them in such a f-u-ed >>> state. >>> Any hints welcome! >>> >>> As I saw catched with my left eye on one call-trace sth. with... >>> >>> kernel/watchdog.c (line #245, watchdog_overflow_callback) >>> >>> ... I tried to revert the last two commits from Sascha (see -3 patch, >>> but no success. >>> >>> The same with reverting all cpu-freq changes since v3.8-rc4 (see -4 >>> patch) after seeing some suspicious lines on the screen. >>> >>> Can someone confirm that suspend is BROKEN for him/her before doing >>> eventually a bisect? >> >> Can you please test the linux-next branch of the linux-pm.git tree alone? >> > > That sounds like a good idea as I just reverted "cpu-hotplug, > memory-hotplug: try offlining the node when hotremoving a cpu" [1] > from akpm tree. > Building... 1st with revert than trying pm-next only. > Your pm-next tree is fine here. commit 0b9d032a2bf0a0224ef446f3d6048fdd8a5b8280 "Merge branch 'pm-cpufreq-next' into linux-next linux-next" Furthermore, the culprit is not between akpm-master and akpm-current as I have seen cpu/mem hotplug and pm changes there. Hmm, maybe bisecting would have been faster than hunting on suspicious commits. - Sedat - > - Sedat - > > [1] > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=154cb61f36690edef68beb5fd9dc0a5027f9dbd9 > >> Rafael >> >> >> -- >> I speak only for myself. >> Rafael J. Wysocki, Intel Open Source Technology Center. -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 25 (BROKEN suspend)
On Sat, Jan 26, 2013 at 3:33 PM, Sedat Dilek wrote: > On Sat, Jan 26, 2013 at 2:24 PM, Sedat Dilek wrote: >> On Sat, Jan 26, 2013 at 2:25 PM, Rafael J. Wysocki wrote: >>> On Saturday, January 26, 2013 12:10:32 PM Sedat Dilek wrote: >>>> On Fri, Jan 25, 2013 at 6:26 AM, Stephen Rothwell >>>> wrote: >>>> > Hi all, >>>> > >>>> > Changes since 20130124: >>>> > >>>> > New trees: ipsec and ipsec-next >>>> > >>>> > The powerpc tree still had a build failure. >>>> > >>>> > The sound-asoc tree still had its build failure so I used the version >>>> > from >>>> > next-20130122. >>>> > >>>> > The akpm tree lost its build failure and several patches that turned up >>>> > elsewhere. >>>> > >>>> > >>>> > >>>> >>>> Unfortunately, on suspend or running the pm_test/freezer leads here to >>>> a frozen machine - hard reset. >>>> >>>> I see 4-5 pages of call-traces but dunno how to log them in such a f-u-ed >>>> state. >>>> Any hints welcome! >>>> >>>> As I saw catched with my left eye on one call-trace sth. with... >>>> >>>> kernel/watchdog.c (line #245, watchdog_overflow_callback) >>>> >>>> ... I tried to revert the last two commits from Sascha (see -3 patch, >>>> but no success. >>>> >>>> The same with reverting all cpu-freq changes since v3.8-rc4 (see -4 >>>> patch) after seeing some suspicious lines on the screen. >>>> >>>> Can someone confirm that suspend is BROKEN for him/her before doing >>>> eventually a bisect? >>> >>> Can you please test the linux-next branch of the linux-pm.git tree alone? >>> >> >> That sounds like a good idea as I just reverted "cpu-hotplug, >> memory-hotplug: try offlining the node when hotremoving a cpu" [1] >> from akpm tree. >> Building... 1st with revert than trying pm-next only. >> > > Your pm-next tree is fine here. > > commit 0b9d032a2bf0a0224ef446f3d6048fdd8a5b8280 > "Merge branch 'pm-cpufreq-next' into linux-next linux-next" > > Furthermore, the culprit is not between akpm-master and akpm-current > as I have seen cpu/mem hotplug and pm changes there. > > Hmm, maybe bisecting would have been faster than hunting on suspicious > commits. > > - Sedat - > >> - Sedat - >> >> [1] >> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=154cb61f36690edef68beb5fd9dc0a5027f9dbd9 >> >>> Rafael >>> >>> >>> -- >>> I speak only for myself. >>> Rafael J. Wysocki, Intel Open Source Technology Center. I merged on top of my Linux-v3.8-rc5 GIT branch... Sedat Dilek (8): mei: Fix some more kernel-doc typos in hw-me.c kbuild: deb-pkg: Try to determine distribution kbuild: deb-pkg: Bump year in debian/copyright file kbuild: deb-pkg: Update git repository URL in debian/copyright file Merge tag 'next-20130124' of git://git.kernel.org/.../next/linux-next into Linux-Next-v20130124 Merge branch 'deb-pkg-fixes' into 3.8.0-rc5-next20130124-1-pmnext-generic Merge branch 'Linux-Next-v20130124' into 3.8.0-rc5-next20130124-1-pmnext-generic Merge branch 'pm-next' into 3.8.0-rc5-next20130124-1-pmnext-generic ...and this f-u-s the machine as well. So, the culprit seems not to get from your PM stuff. Anyway, this does not help me... but hope it's good news for you, Rafael :-)! - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 25 (BROKEN suspend)
On Sat, Jan 26, 2013 at 4:05 PM, Sedat Dilek wrote: > On Sat, Jan 26, 2013 at 3:33 PM, Sedat Dilek wrote: >> On Sat, Jan 26, 2013 at 2:24 PM, Sedat Dilek wrote: >>> On Sat, Jan 26, 2013 at 2:25 PM, Rafael J. Wysocki wrote: >>>> On Saturday, January 26, 2013 12:10:32 PM Sedat Dilek wrote: >>>>> On Fri, Jan 25, 2013 at 6:26 AM, Stephen Rothwell >>>>> wrote: >>>>> > Hi all, >>>>> > >>>>> > Changes since 20130124: >>>>> > >>>>> > New trees: ipsec and ipsec-next >>>>> > >>>>> > The powerpc tree still had a build failure. >>>>> > >>>>> > The sound-asoc tree still had its build failure so I used the version >>>>> > from >>>>> > next-20130122. >>>>> > >>>>> > The akpm tree lost its build failure and several patches that turned up >>>>> > elsewhere. >>>>> > >>>>> > >>>>> > >>>>> >>>>> Unfortunately, on suspend or running the pm_test/freezer leads here to >>>>> a frozen machine - hard reset. >>>>> >>>>> I see 4-5 pages of call-traces but dunno how to log them in such a f-u-ed >>>>> state. >>>>> Any hints welcome! >>>>> >>>>> As I saw catched with my left eye on one call-trace sth. with... >>>>> >>>>> kernel/watchdog.c (line #245, watchdog_overflow_callback) >>>>> >>>>> ... I tried to revert the last two commits from Sascha (see -3 patch, >>>>> but no success. >>>>> >>>>> The same with reverting all cpu-freq changes since v3.8-rc4 (see -4 >>>>> patch) after seeing some suspicious lines on the screen. >>>>> >>>>> Can someone confirm that suspend is BROKEN for him/her before doing >>>>> eventually a bisect? >>>> >>>> Can you please test the linux-next branch of the linux-pm.git tree alone? >>>> >>> >>> That sounds like a good idea as I just reverted "cpu-hotplug, >>> memory-hotplug: try offlining the node when hotremoving a cpu" [1] >>> from akpm tree. >>> Building... 1st with revert than trying pm-next only. >>> >> >> Your pm-next tree is fine here. >> >> commit 0b9d032a2bf0a0224ef446f3d6048fdd8a5b8280 >> "Merge branch 'pm-cpufreq-next' into linux-next linux-next" >> >> Furthermore, the culprit is not between akpm-master and akpm-current >> as I have seen cpu/mem hotplug and pm changes there. >> >> Hmm, maybe bisecting would have been faster than hunting on suspicious >> commits. >> >> - Sedat - >> >>> - Sedat - >>> >>> [1] >>> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=154cb61f36690edef68beb5fd9dc0a5027f9dbd9 >>> >>>> Rafael >>>> >>>> >>>> -- >>>> I speak only for myself. >>>> Rafael J. Wysocki, Intel Open Source Technology Center. > > I merged on top of my Linux-v3.8-rc5 GIT branch... > > Sedat Dilek (8): > mei: Fix some more kernel-doc typos in hw-me.c > kbuild: deb-pkg: Try to determine distribution > kbuild: deb-pkg: Bump year in debian/copyright file > kbuild: deb-pkg: Update git repository URL in debian/copyright file > Merge tag 'next-20130124' of > git://git.kernel.org/.../next/linux-next into Linux-Next-v20130124 > Merge branch 'deb-pkg-fixes' into > 3.8.0-rc5-next20130124-1-pmnext-generic > Merge branch 'Linux-Next-v20130124' into > 3.8.0-rc5-next20130124-1-pmnext-generic > Merge branch 'pm-next' into 3.8.0-rc5-next20130124-1-pmnext-generic > > ...and this f-u-s the machine as well. > So, the culprit seems not to get from your PM stuff. > > Anyway, this does not help me... but hope it's good news for you, Rafael :-)! > > - Sedat - This tells me ZERO... $ cat git-bisect-log.txt git bisect start # bad: [a8ae185b9edd81927bd762b89a327617e3e7a1e8] Add linux-next specific files for 20130124 git bisect bad a8ae185b9edd81927bd762b89a327617e3e7a1e8 # good: [7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619] Linux 3.8-rc4 git bisect good 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619 # bad: [5a4e73d60a0f01a39c602e3c2cbb2f136268f717] Merge remote
Re: linux-next: Tree for Jan 25 (BROKEN suspend)
On Sat, Jan 26, 2013 at 10:49 PM, Rafael J. Wysocki wrote: > On Saturday, January 26, 2013 07:27:06 PM Sedat Dilek wrote: >> On Sat, Jan 26, 2013 at 4:05 PM, Sedat Dilek wrote: >> > On Sat, Jan 26, 2013 at 3:33 PM, Sedat Dilek wrote: >> >> On Sat, Jan 26, 2013 at 2:24 PM, Sedat Dilek >> >> wrote: >> >>> On Sat, Jan 26, 2013 at 2:25 PM, Rafael J. Wysocki wrote: >> >>>> On Saturday, January 26, 2013 12:10:32 PM Sedat Dilek wrote: >> >>>>> On Fri, Jan 25, 2013 at 6:26 AM, Stephen Rothwell >> >>>>> wrote: >> >>>>> > Hi all, >> >>>>> > >> >>>>> > Changes since 20130124: >> >>>>> > >> >>>>> > New trees: ipsec and ipsec-next >> >>>>> > >> >>>>> > The powerpc tree still had a build failure. >> >>>>> > >> >>>>> > The sound-asoc tree still had its build failure so I used the >> >>>>> > version from >> >>>>> > next-20130122. >> >>>>> > >> >>>>> > The akpm tree lost its build failure and several patches that turned >> >>>>> > up >> >>>>> > elsewhere. >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> >> >>>>> Unfortunately, on suspend or running the pm_test/freezer leads here to >> >>>>> a frozen machine - hard reset. >> >>>>> >> >>>>> I see 4-5 pages of call-traces but dunno how to log them in such a >> >>>>> f-u-ed state. >> >>>>> Any hints welcome! >> >>>>> >> >>>>> As I saw catched with my left eye on one call-trace sth. with... >> >>>>> >> >>>>> kernel/watchdog.c (line #245, watchdog_overflow_callback) >> >>>>> >> >>>>> ... I tried to revert the last two commits from Sascha (see -3 patch, >> >>>>> but no success. >> >>>>> >> >>>>> The same with reverting all cpu-freq changes since v3.8-rc4 (see -4 >> >>>>> patch) after seeing some suspicious lines on the screen. >> >>>>> >> >>>>> Can someone confirm that suspend is BROKEN for him/her before doing >> >>>>> eventually a bisect? >> >>>> >> >>>> Can you please test the linux-next branch of the linux-pm.git tree >> >>>> alone? >> >>>> >> >>> >> >>> That sounds like a good idea as I just reverted "cpu-hotplug, >> >>> memory-hotplug: try offlining the node when hotremoving a cpu" [1] >> >>> from akpm tree. >> >>> Building... 1st with revert than trying pm-next only. >> >>> >> >> >> >> Your pm-next tree is fine here. >> >> >> >> commit 0b9d032a2bf0a0224ef446f3d6048fdd8a5b8280 >> >> "Merge branch 'pm-cpufreq-next' into linux-next linux-next" >> >> >> >> Furthermore, the culprit is not between akpm-master and akpm-current >> >> as I have seen cpu/mem hotplug and pm changes there. >> >> >> >> Hmm, maybe bisecting would have been faster than hunting on suspicious >> >> commits. >> >> >> >> - Sedat - >> >> >> >>> - Sedat - >> >>> >> >>> [1] >> >>> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=154cb61f36690edef68beb5fd9dc0a5027f9dbd9 >> >>> >> >>>> Rafael >> >>>> >> >>>> >> >>>> -- >> >>>> I speak only for myself. >> >>>> Rafael J. Wysocki, Intel Open Source Technology Center. >> > >> > I merged on top of my Linux-v3.8-rc5 GIT branch... >> > >> > Sedat Dilek (8): >> > mei: Fix some more kernel-doc typos in hw-me.c >> > kbuild: deb-pkg: Try to determine distribution >> > kbuild: deb-pkg: Bump year in debian/copyright file >> > kbuild: deb-pkg: Update git repository URL in debian/copyright file >> > Merge tag 'next-20130124' of >> > git://git.kern
[next-20130124][next-20130125] Fix available for broken PM-suspend
Hi, this is just an information for people might trapping into the same issue. You can get the patch from patchwork-service [1] or directly from wq.git# for-3.9-async GIT tree [2]. Next Monday's Linux-Next (next-20130127) should be fine, again. Regards, - Sedat - [1] https://patchwork.kernel.org/patch/2042681/ [2] http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=a0327ff0eda915be623658babacef706099c11a8 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build regressions/improvements in v3.8-rc5
On Sun, Jan 27, 2013 at 7:48 PM, Guenter Roeck wrote: > On Sun, Jan 27, 2013 at 02:56:46PM +0100, Sedat Dilek wrote: >> Hi Geert, >> >> what is the intention of this list [1] which you regularly sent to LKML? >> >> Statistics? >> >> [ Compiler errors/warnings ] >> >> Are you directly contacting the maintainers of the subtree and inform >> them (per email, website etc.? >> Do you sent or plan to send this list as a whole (single list) or >> broken-down for each subsystem? >> The latter would be have more success. >> Can you add such a per-subsystem list (compiler errors/warnings etc.) >> to kisskb service (or plan to)? >> What is your feedback from Linux kernel maintainers? >> > FWIW, I track it to see if there are any errors or warnings in the hwmon > subsystem. > Cool, Guenter - you Ro(e)ck! - Sedat - > Guenter > >> [ In General ] >> >> What is your infrastructure (Linux OS etc.)? >> What is toolchain (compiler version etc.) do you use? >> Are those produced kernels tested on real or virtual hardware? >> Or do you test compiled-only or not? >> >> I really wish you success with your service! >> >> Thanks. >> >> Regards, >> - Sedat - >> >> [1] http://marc.info/?l=linux-kernel&m=135929071204017&w=2 >> -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] cputime: Safely read cputime of full dynticks CPUs
On Mon, Jan 28, 2013 at 8:04 PM, Frederic Weisbecker wrote: > While remotely reading the cputime of a task running in a > full dynticks CPU, the values stored in utime/stime fields > of struct task_struct may be stale. Its values may be those > of the last kernel <-> user transition time snapshot and > we need to add the tickless time spent since this snapshot. > > To fix this, flush the cputime of the dynticks CPUs on > kernel <-> user transition and record the time / context > where we did this. Then on top of this snapshot and the current > time, perform the fixup on the reader side from task_times() > accessors. > > Signed-off-by: Frederic Weisbecker > Cc: Andrew Morton > Cc: Ingo Molnar > Cc: Li Zhong > Cc: Namhyung Kim > Cc: Paul E. McKenney > Cc: Paul Gortmaker > Cc: Peter Zijlstra > Cc: Steven Rostedt > Cc: Thomas Gleixner > [fixed kvm module related build errors] > Signed-off-by: Sedat Dilek > Can you explain a bit what is the difference between "3.8-rc4-nohz3" and "full-dynticks-cputime-for-mingo" patchsets? Does the latter need no more EXPORT_SYMBOL_GPL for vtime_guest_enter() and vtime_guest_exit() when CONFIG_KVM=m (see [1])? - Sedat - [1] https://lkml.org/lkml/2013/1/23/473 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 23 [ fs/dcache.c: Root dentry has weird name ]
On Mon, Feb 25, 2013 at 3:27 PM, Al Viro wrote: > On Mon, Feb 25, 2013 at 03:22:03PM +0100, Sedat Dilek wrote: >> On Mon, Feb 25, 2013 at 2:54 PM, Al Viro wrote: >> > On Mon, Feb 25, 2013 at 02:22:42PM +0100, Sedat Dilek wrote: >> > >> >> [ 120.310366] Root dentry has weird name >> > >> > Umm... Almost certainly a result of switching to shmem_file_setup() to >> > d_alloc_pseudo(); I'll fix it (give the suckers ->d_op of their own). >> > For now, just ignore the warning - it's harmless. Or revert commit >> > 7dbc68fcb0cdce27737dba9ee252f26d39d75fb6 and see if the rest of your >> > problems persist; I would be very surprised if anything other than this >> > warning had been caused by that commit. >> >> Thanks for the quick fix! >> >> YES, with "Revert "shmem_setup_file(): use d_alloc_pseudo() instead of >> d_alloc()"" I do NOT see these warnings anymore. > > Umm... Are the perf ones you are seeing eliminated by that as well? I would > expect them to be an independent problem... Independent as I still see them. Please, see also my report in "Re: linux-next: Tree for Feb 23 [ perf: NULL pointer dereference perf_init_event() ]" [1]. - Sedat - [1] https://lkml.org/lkml/2013/2/25/119 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 24
February 26th... - Sedat - On Tue, Feb 26, 2013 at 4:16 AM, Stephen Rothwell wrote: > Hi all, > > Please do not add any work destined for v3.10 to your -next included > branches until after Linus has release v3.9-rc1. > > Changes since 20130223: > > The kbuild tree lost its build failure. > > The infiniband tree gained a conflict against Linus' tree. > > The drm tree still has its build failure for which I applied a patch. > > > > I have created today's linux-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you > are tracking the linux-next tree using git, you should not use "git pull" > to do so as that will try to merge the new linux-next release with the > old one. You should use "git fetch" as mentioned in the FAQ on the wiki > (see below). > > You can see which trees have been included by looking in the Next/Trees > file in the source. There are also quilt-import.log and merge.log files > in the Next directory. Between each merge, the tree was built with > a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the > final fixups (if any), it is also built with powerpc allnoconfig (32 and > 64 bit), ppc44x_defconfig and allyesconfig (minus > CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, > sparc64 and arm defconfig. These builds also have > CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and > CONFIG_DEBUG_INFO disabled when necessary. > > Below is a summary of the state of the merge. > > We are up to 216 trees (counting Linus' and 28 trees of patches pending > for Linus' tree), more are welcome (even if they are currently empty). > Thanks to those who have contributed, and to those who haven't, please do. > > Status of my local build tests will be at > http://kisskb.ellerman.id.au/linux-next . If maintainers want to give > advice about cross compilers/configs that work, we are always open to add > more builds. > > Thanks to Randy Dunlap for doing many randconfig builds. And to Paul > Gortmaker for triage and bug fixes. > > There is a wiki covering stuff to do with linux-next at > http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au > > $ git checkout master > $ git reset --hard stable > Merging origin/master (ab78265 Merge tag 'mfd-3.9-1' of > git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6) > Merging fixes/master (d287b87 Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) > Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' > of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) > Merging arm-current/fixes (b255188 ARM: fix scheduling while atomic warning > in alignment handling code) > Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. > CONFIG_HAS_DMA) > Merging powerpc-merge/merge (eda8eeb powerpc/mm: Fix hash computation > function) > Merging sparc/master (f9fd348 sparc32: refactor smp boot) > Merging net/master (eb970ff usbnet: smsc95xx: rename FEATURE_AUTOSUSPEND) > Merging ipsec/master (85dfb74 af_key: initialize satype in > key_notify_policy_flush()) > Merging sound-current/for-linus (d0ec95f ALSA: emu10k1: Allow to switch > hardware sampe rate on EMU) > Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when > removing a device) > Merging wireless/master (dc4a787 brcmfmac: fix missing unlock on error in > brcmf_notify_vif_event()) > Merging driver-core.current/driver-core-linus (949db15 Linux 3.8-rc5) > Merging tty.current/tty-linus (8b5628a Merge tag 'virt' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) > Merging usb.current/usb-linus (74e1a2a Merge tag 'usb-3.9-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) > Merging staging.current/staging-linus (8b5628a Merge tag 'virt' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) > Merging char-misc.current/char-misc-linus (7ed214a Merge tag > 'char-misc-3.9-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc) > Merging input-current/for-linus (171fb58 Input: ALPS - update documentation > for recent touchpad driver mods) > Merging md-current/for-linus (c43a660 md/raid1,raid10: fix deadlock with > freeze_array()) > Merging audit-current/for-linus (c158a35 audit: no leading space in > audit_log_d_path prefix) > Merging crypto-current/master (8fd61d3 crypto: user - ensure user supplied > strings are nul-terminated) > CONFLICT (content): Merge conflict in drivers/crypto/omap-sham.c > CONFLICT (content): Merge conflict in crypto/ctr.c > CONFLICT (content): Merge conflict in > Documentation/devicetree/bindings/crypto/fsl-sec4.txt > Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) > Merging dwm
Re: linux-next: Tree for Feb 26 [ vfs | mm/shmem ]
On Tue, Feb 26, 2013 at 4:16 AM, Stephen Rothwell wrote:
> Hi all,
>
> Please do not add any work destined for v3.10 to your -next included
> branches until after Linus has release v3.9-rc1.
>
> Changes since 20130223:
>
> The kbuild tree lost its build failure.
>
> The infiniband tree gained a conflict against Linus' tree.
>
> The drm tree still has its build failure for which I applied a patch.
>
>
>
[ Changed subject-line to correct date: Feb 26 ]
The warning I reported yesterday [0] still remains as Al's vfs-next
tree was updated some hours ago.
The correct fix [1] is pending there and will be in tommorrows next-20130227.
You still need to revert the old ("buggy") commit first in Linux-Next.
Just as a note:
The function is called "shmem_file_setup()" not "shmem_setup_file()"
as the subject-line of both patches indicates.
The pending patch fixes the warnings here!
- Sedat -
[0] http://marc.info/?l=linux-kernel&m=136179858021827&w=2
[1]
http://git.kernel.org/?p=linux/kernel/git/viro/vfs.git;a=patch;h=3451538a114d738a6528b1da58e19e7d8964c647
[2]
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=7dbc68fcb0cdce27737dba9ee252f26d39d75fb6
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: fs: WARNING: at fs/dcache.c:2587 prepend_path
On Tue, Feb 26, 2013 at 5:48 PM, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running latest -next, > I've started seeing a bunch of these, which wasn't there in the -next from > couple of days ago: > > [ 1169.020539] [ cut here ] > [ 1169.021297] WARNING: at fs/dcache.c:2587 prepend_path+0x188/0x1f0() > [ 1169.022903] Root dentry has weird name > [ 1169.023967] Modules linked in: > [ 1169.024479] Pid: 28818, comm: trinity Tainted: GW > 3.8.0-next-20130225-sasha-00042-g8547837 #997 > [ 1169.026771] Call Trace: > [ 1169.027527] [] warn_slowpath_common+0x8c/0xc0 > [ 1169.028442] [] warn_slowpath_fmt+0x41/0x50 > [ 1169.029829] [] ? lg_local_lock+0x70/0x80 > [ 1169.031038] [] ? prepend_path+0x3a/0x1f0 > [ 1169.032783] [] prepend_path+0x188/0x1f0 > [ 1169.034083] [] d_path+0x101/0x140 > [ 1169.034946] [] seq_path+0x5e/0xd0 > [ 1169.035804] [] show_map_vma+0x174/0x2b0 > [ 1169.037065] [] show_map+0x2a/0x60 > [ 1169.037790] [] show_pid_map+0xe/0x10 > [ 1169.038902] [] seq_read+0x311/0x430 > [ 1169.039944] [] vfs_read+0xb3/0x120 > [ 1169.040934] [] ? trace_hardirqs_on+0xd/0x10 > [ 1169.042842] [] sys_read+0x5d/0xa0 > [ 1169.043696] [] tracesys+0xdd/0xe2 > [ 1169.045019] ---[ end trace 6e68f4c39bb079ca ]--- > > Known issue, please see below link... http://marc.info/?l=linux-next&m=136187065814300&w=2 > Thanks, > Sasha > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.9] libertas: fix crash for SD8688
On Wed, Feb 27, 2013 at 11:46 AM, Dan Williams wrote:
> On Tue, 2013-02-26 at 12:58 -0800, Bing Zhao wrote:
>> For SD8688, FUNC_INIT command is queued before fw_ready flag is
>> set. This causes the following crash as lbs_thread blocks any
>> command if fw_ready is not set.
>
> While we're at this; does somebody want to take over Libertas
> maintainership? I don't have time for it anymore (and truth be told,
> haven't for a long time). So I'm happy if Daniel or Bing or anyone else
> who are already doing all this take it over. I've got a few Libertas
> devices (usb8388, sd8686, sd8687, cf8385) that I'm happy to send to
> anyone who wants them.
>
> I'll ack a patch to MAINTAINERS to switch to somebody else.
>
It would be great to send out a separate mail for this concern?
- Sedat -
> Dan
>
>> [ 209.338953] [] (__schedule+0x610/0x764) from []
>> (__lbs_cmd+0xb8/0x130 [libertas])
>> [ 209.348340] [] (__lbs_cmd+0xb8/0x130 [libertas]) from
>> [] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
>> [ 209.360136] [] (if_sdio_finish_power_on+0xec/0x1b0
>> [libertas_sdio]) from [] (if_sdio_power_on+0x18c/0x20c
>> [libertas_sdio])
>> [ 209.373052] [] (if_sdio_power_on+0x18c/0x20c [libertas_sdio])
>> from [] (if_sdio_probe+0x200/0x31c [libertas_sdio])
>> [ 209.385316] [] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from
>> [] (sdio_bus_probe+0x94/0xfc [mmc_core])
>> [ 209.396748] [] (sdio_bus_probe+0x94/0xfc [mmc_core]) from
>> [] (driver_probe_device+0x12c/0x348)
>> [ 209.407214] [] (driver_probe_device+0x12c/0x348) from
>> [] (__driver_attach+0x78/0x9c)
>> [ 209.416798] [] (__driver_attach+0x78/0x9c) from []
>> (bus_for_each_dev+0x50/0x88)
>> [ 209.425946] [] (bus_for_each_dev+0x50/0x88) from []
>> (bus_add_driver+0x108/0x268)
>> [ 209.435180] [] (bus_add_driver+0x108/0x268) from []
>> (driver_register+0xa4/0x134)
>> [ 209.26] [] (driver_register+0xa4/0x134) from []
>> (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
>> [ 209.455339] [] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
>> from [] (do_one_initcall+0x98/0x174)
>> [ 209.466236] [] (do_one_initcall+0x98/0x174) from []
>> (load_module+0x1c5c/0x1f80)
>> [ 209.475390] [] (load_module+0x1c5c/0x1f80) from []
>> (sys_init_module+0x104/0x128)
>> [ 209.484632] [] (sys_init_module+0x104/0x128) from []
>> (ret_fast_syscall+0x0/0x38)
>>
>> Fix it by setting fw_ready flag prior to queuing FUNC_INIT command.
>>
>> Cc: # 3.5+
>> Reported-by: Lubomir Rintel
>> Tested-by: Lubomir Rintel
>> Signed-off-by: Bing Zhao
>> ---
>> drivers/net/wireless/libertas/if_sdio.c |6 +-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/wireless/libertas/if_sdio.c
>> b/drivers/net/wireless/libertas/if_sdio.c
>> index 739309e..4557833 100644
>> --- a/drivers/net/wireless/libertas/if_sdio.c
>> +++ b/drivers/net/wireless/libertas/if_sdio.c
>> @@ -825,6 +825,11 @@ static void if_sdio_finish_power_on(struct if_sdio_card
>> *card)
>>
>> sdio_release_host(func);
>>
>> + /* Set fw_ready before queuing any commands so that
>> + * lbs_thread won't block from sending them to firmware.
>> + */
>> + priv->fw_ready = 1;
>> +
>> /*
>>* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
>>*/
>> @@ -839,7 +844,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card
>> *card)
>> netdev_alert(priv->dev, "CMD_FUNC_INIT cmd failed\n");
>> }
>>
>> - priv->fw_ready = 1;
>> wake_up(&card->pwron_waitq);
>>
>> if (!card->started) {
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ocfs2-users] Kernel panic due to ocfs2
On Wed, Feb 27, 2013 at 12:52 PM, richard -rw- weinberger wrote: > On Tue, Feb 26, 2013 at 8:54 AM, richard -rw- weinberger > wrote: >> On Tue, Feb 26, 2013 at 7:31 AM, Srinivas Eeda >> wrote: >>> This is due to a race in lock mastery/purge. I have recently fixed this >>> problem but haven't yet submitted the patch to mainline. Please file a >>> Service request with Oracle to get a one-off fix. >> >> Please submit the patch immediately. >> Why does one need a f§&"!#$ SR from Oracle to have this fixed? > > So, where can I find this patch? > Can you please share it with us insignificant and rubbishy community folks? > > https://oss.oracle.com/projects/ocfs2/source.html points to > http://git.kernel.org/?p=linux/kernel/git/jlbec/ocfs2.git;a=summary > This tree seems horrible outdated... > Looks like Al took some ocfs2 patches directly to his vfs GIT tree(s) and sent to mainline. - Sedat - http://git.kernel.org/?p=linux/kernel/git/viro/vfs.git;a=shortlog;h=refs/heads/for-linus http://git.kernel.org/?p=linux/kernel/git/viro/vfs.git;a=shortlog;h=refs/heads/for-next > -- > Thanks, > //richard > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [wathdog] GitWeb service not available?
On Wed, Feb 27, 2013 at 12:58 PM, Wim Van Sebroeck wrote: > Hi Sedat, > >> while digging into a Linux-Next issue [0] I wanted to browse the >> watchdog GitWeb, but it seems not to be available for me! > > Correct. I disabled it because the server has not enough memory... > Then please update your website, Thanks! - Sedat - > Kind regards, > Wim. > -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Feb 23 [ perf: NULL pointer dereference perf_init_event() ]
On Tue, Feb 26, 2013 at 10:39 AM, Sedat Dilek wrote: > On Mon, Feb 25, 2013 at 2:44 PM, Sedat Dilek wrote: >> On Mon, Feb 25, 2013 at 6:00 AM, Stephen Rothwell >> wrote: >>> Hi all, >>> >>> Please do not add any work destined for v3.10 to your -next included >>> branches until after Linus has release v3.9-rc1. >>> >>> Changes since 20130222: >>> >>> The metag tree gained a conflict against Linus' tree. >>> >>> The kbuild tree gained a build failure so I used the version from >>> next-20130222. >>> >>> The drm tree still has its build failure for which I applied a patch. >>> >>> The watchdog tree gained a conflict against Linus' tree. >>> >>> The akpm tree gained a conflict against the vfs tree and lost lots of >>> patches that turned up elsewhere. >>> >>> >>> >> >> With today's Linux-Next I see multiple call-traces pointing to perf >> issues (excerpt, for full dmesg see attachments): >> >> [0.093651] Call Trace: >> [0.093656] [] perf_event_alloc+0x358/0x490 >> [0.093661] [] ? touch_nmi_watchdog+0x80/0x80 >> [0.093666] [] >> perf_event_create_kernel_counter+0x2e/0xe0 >> [0.093670] [] watchdog_enable+0xfd/0x1e0 >> [0.093676] [] smpboot_thread_fn+0x9c/0x170 >> [0.093681] [] ? lg_global_lock+0x70/0x70 >> [0.093685] [] kthread+0xc0/0xd0 >> [0.093689] [] ? flush_kthread_worker+0xb0/0xb0 >> [0.093694] [] ret_from_fork+0x7c/0xb0 >> [0.093698] [] ? flush_kthread_worker+0xb0/0xb0 >> [0.093700] Code: 54 49 89 fc 48 c7 c7 c0 6d f5 81 53 48 83 ec 18 >> e8 e4 a5 f5 ff 41 8b b4 24 a0 00 00 00 41 89 c5 48 8b 05 a2 c9 e2 00 >> 89 f2 30 d2 <3b> 10 74 4a 48 c7 c7 80 6d f5 81 e8 ce ab 22 00 48 89 c3 >> 48 85 >> [0.093736] RIP [] perf_init_event+0x32/0x100 >> [0.093740] RSP >> [0.093742] CR2: >> [0.093746] ---[ end trace 941ac4690a5bae9e ]--- >> [0.104659] Disabled fast string operations >> [0.106781] Brought up 4 CPUs >> [0.106785] BUG: unable to handle kernel NULL pointer dereference >> at (null) >> [0.106790] IP: [] perf_init_event+0x32/0x100 >> [0.106791] PGD 0 >> [0.106794] Oops: [#4] SMP >> [0.106795] Modules linked in: >> [0.106798] CPU 3 >> [0.106798] Pid: 22, comm: watchdog/3 Tainted: G D >> 3.8.0-next20130225-1-iniza-small #1 SAMSUNG ELECTRONICS CO., LTD. >> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH >> [0.106801] RIP: 0010:[] [] >> perf_init_event+0x32/0x100 >> ... >> >> Regards, >> - Sedat - > > I see the same call-traces with today's Linux-Next (next-20130226)! > Any hints/help? > > - Sedat - [ CC Tejun and Borislav ] This turned out to be a idr issue [1]. Thanks Borislav for his help. Reverting "idr: implement lookup hint" commit [2] makes the call-traces go away. - Sedat - [1] http://marc.info/?l=linux-kernel&m=136197056415722&w=2 [2] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=29cf29e1fbb875019713eb55cf27ec35f1e5fa5e -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] kbuild changes for v3.9-rc1
Hi Marek, as I see the today's git-pull-request for linux-kbuild... I and some other people (see 2/3 and 3/3) sent minor fixes to deb-pkg. Where they overseen? Anything wrong with them? ( Sorry, didn't follow linux-kbuild ML for a while. ) Regards, - Sedat - [PATCH 1/3] kbuild, deb-pkg: Try to determine distribution [PATCH 2/3] kbuild, deb-pkg: Bump year in debian/copyright file [PATCH 3/3] kbuild, deb-pkg: Update git repository URL in debian/copyright file -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs: WARNING: at fs/dcache.c:2587 prepend_path
On Tue, Feb 26, 2013 at 6:01 PM, Sedat Dilek wrote: > On Tue, Feb 26, 2013 at 5:48 PM, Sasha Levin wrote: >> Hi all, >> >> While fuzzing with trinity inside a KVM tools guest running latest -next, >> I've started seeing a bunch of these, which wasn't there in the -next from >> couple of days ago: >> >> [ 1169.020539] [ cut here ] >> [ 1169.021297] WARNING: at fs/dcache.c:2587 prepend_path+0x188/0x1f0() >> [ 1169.022903] Root dentry has weird name >> [ 1169.023967] Modules linked in: >> [ 1169.024479] Pid: 28818, comm: trinity Tainted: GW >> 3.8.0-next-20130225-sasha-00042-g8547837 #997 >> [ 1169.026771] Call Trace: >> [ 1169.027527] [] warn_slowpath_common+0x8c/0xc0 >> [ 1169.028442] [] warn_slowpath_fmt+0x41/0x50 >> [ 1169.029829] [] ? lg_local_lock+0x70/0x80 >> [ 1169.031038] [] ? prepend_path+0x3a/0x1f0 >> [ 1169.032783] [] prepend_path+0x188/0x1f0 >> [ 1169.034083] [] d_path+0x101/0x140 >> [ 1169.034946] [] seq_path+0x5e/0xd0 >> [ 1169.035804] [] show_map_vma+0x174/0x2b0 >> [ 1169.037065] [] show_map+0x2a/0x60 >> [ 1169.037790] [] show_pid_map+0xe/0x10 >> [ 1169.038902] [] seq_read+0x311/0x430 >> [ 1169.039944] [] vfs_read+0xb3/0x120 >> [ 1169.040934] [] ? trace_hardirqs_on+0xd/0x10 >> [ 1169.042842] [] sys_read+0x5d/0xa0 >> [ 1169.043696] [] tracesys+0xdd/0xe2 >> [ 1169.045019] ---[ end trace 6e68f4c39bb079ca ]--- >> >> > > Known issue, please see below link... > > http://marc.info/?l=linux-next&m=136187065814300&w=2 > Just FYI: Linux-Next (next-20130227) has the corrected fix now. You should no more see these warnings. - Sedat - >> Thanks, >> Sasha >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] kbuild, deb-pkg: Try to determine distribution
On Wed, Feb 27, 2013 at 2:55 PM, Michal Marek wrote: > Sorry I missed this series. Max, can you have a look? I don't know the > policies for debian package changelogs. The full series is at > http://lkml.indiana.edu/hypermail/linux/kernel/1204.2/index.html#04252, > but the remaining two patches are obvious. > [ CC mirabilos and formorer ] [PATCH 1/3] kbuild, deb-pkg: Try to determine distribution ...was discussed in (hehe, so long ago) April 2012 on #grml IRC (a Linux live-system based on Debian) with Thorsten Glaser and Alexander Wirt. Both cool guys (longterm Debian maintainers and admins) gave me several good hints to make this a "proper" solution. Maybe, they won't remember :-). I switched from Debian/unstable to Ubuntu/precise these days and that was the reason I wanted the correct $distribution in my generated Debian kernel packages. Might be I come back when Debian/wheezy is released... you never know :-). Or I get an Amiga-3000 with Debian/m68k running... with DirOpus and DPaint-IV, hahaha. I was simply too lazy to place a rock-solid changelog. - Sedat - > Michal > > On 24.4.2012 00:16, Sedat Dilek wrote: >> Signed-off-by: Sedat Dilek >> --- >> scripts/package/builddeb | 15 ++- >> 1 file changed, 14 insertions(+), 1 deletion(-) >> >> diff --git a/scripts/package/builddeb b/scripts/package/builddeb >> index eee5f8e..f5b56ac 100644 >> --- a/scripts/package/builddeb >> +++ b/scripts/package/builddeb >> @@ -172,9 +172,22 @@ else >> fi >> maintainer="$name <$email>" >> >> +# Try to determine distribution >> +if [ -e $(which lsb_release) ]; then >> + codename=$(lsb_release --codename --short) >> + if [ "$codename" != "" ]; then >> + distribution=$codename >> + else >> + distribution="UNRELEASED" >> + echo "WARNING: The distribution could NOT be determined!" >> + fi >> +else >> + echo "HINT: Install lsb_release binary, this helps to identify your >> distribution!" >> +fi >> + >> # Generate a simple changelog template >> cat < debian/changelog >> -linux-upstream ($packageversion) unstable; urgency=low >> +linux-upstream ($packageversion) $distribution; urgency=low >> >>* Custom built Linux kernel. >> >> > > -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
On Wed, Feb 27, 2013 at 5:08 PM, Borislav Petkov wrote: > On Wed, Feb 27, 2013 at 04:56:27PM +0100, Sedat Dilek wrote: >> Hmm, I am not very amused to read all this, really. >> >> If such fixes are around why aren't they applied quickly? > > Sedat, you need to relax a little. You're testing a linux next tree > right during the merge window where patches are flying back and forth. > Things like that can happen and you, if you're really willing to test > such bleeding edge kernels, also would have to accept the fact that > fixes don't magically appear where they have to in no time. > > I debugged an issue which apparently got fixed already but I'm not > complaining. People are trying their best and screaming at them is not > constructive. At all. > I am not screaming or whining... people should reflect a bit on the patch workflow process? Also, I am sure a patchwork-service especially for -next is helpful. /me forgot to add a "call trace" to my 1st kernel checks. $ dmesg | egrep -i 'error|fail|warn|conflict|terminated|killed|call trace' That's why I have overseen it. > I'd suggest simply reporting the issue, maybe trying to debug it > yourself and patiently waiting. I'm sure you can find anything else to > do in the meantime :-) > Yupp, I had a coffee and two pieces of cake :-). > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in generic strncpy_from_user
[ QUOTE ] On Wed, Feb 27, 2013 at 3:15 AM, Heiko Carstens wrote: > > Tested with 64 bit kernel with 64 bit and 31 bit mode user space as well as > with 31 bit kernel and 31 bit user space. Each with legacy and flexible > mmap layout. > The bug is fixed and everything else still seems to work. Thanks! > > Tested-By: Heiko Carstens Ok, committed. I'm not marking it for stable, because it doesn't seem to matter all that much, but if there was some application that actually broke and made you notice it that way (as opposed to you just noticing the odd memory map), you might want to inform the stable team about commit 09884964335e. Linus [ /QUOTE ] Where is it? - Sedat - http://marc.info/?l=linux-kernel&m=136198317320605&w=2 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in generic strncpy_from_user
On Wed, Feb 27, 2013 at 6:20 PM, Linus Torvalds wrote: > On Wed, Feb 27, 2013 at 9:15 AM, Sedat Dilek wrote: >> >> Where is it? > > Oh sorry, I hadn't pushed it out, I was looking through other emails > in the meantime. > > Pushed out now (but mirror delays to public sites etc..) > > The patch itself is the same one I already attached earlier though > (the last version). > > Linus I have tested the latest one against next-20130227... - Sedat - 3.8.0-next20130227-4-iniza-small.patch Description: Binary data
Re: [git pull] drm merge for 3.9-rc1
Hi, I am seeing this also on Linux-Next. /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! This seems to be hard reproducible... Laptop-LCD... Sandybridge Mobile-GT2. Is there a way to force the error? Possible patch see [1]. - Sedat - [1] https://patchwork.kernel.org/patch/2192721/ -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm merge for 3.9-rc1
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek wrote: > Hi, > > I am seeing this also on Linux-Next. > > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > > This seems to be hard reproducible... > Laptop-LCD... Sandybridge Mobile-GT2. > > Is there a way to force the error? > > Possible patch see [1]. > > - Sedat - > > [1] https://patchwork.kernel.org/patch/2192721/ Hmm, I tried to apply the test-patch against next-20130227 and it fails building the i915 kernel-module. - Sedat - LD drivers/gpu/drm/i915/built-in.o CC [M] drivers/gpu/drm/i915/i915_drv.o CC [M] drivers/gpu/drm/i915/i915_dma.o CC [M] drivers/gpu/drm/i915/i915_irq.o CC [M] drivers/gpu/drm/i915/i915_debugfs.o CC [M] drivers/gpu/drm/i915/i915_suspend.o CC [M] drivers/gpu/drm/i915/i915_gem.o CC [M] drivers/gpu/drm/i915/i915_gem_context.o CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CC [M] drivers/gpu/drm/i915/i915_sysfs.o CC [M] drivers/gpu/drm/i915/i915_trace_points.o CC [M] drivers/gpu/drm/i915/i915_ums.o CC [M] drivers/gpu/drm/i915/intel_display.o CC [M] drivers/gpu/drm/i915/intel_crt.o CC [M] drivers/gpu/drm/i915/intel_lvds.o CC [M] drivers/gpu/drm/i915/intel_bios.o CC [M] drivers/gpu/drm/i915/intel_ddi.o CC [M] drivers/gpu/drm/i915/intel_dp.o drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_aux_wait_done': drivers/gpu/drm/i915/intel_dp.c:352:1: error: invalid storage class for function 'intel_dp_aux_ch' drivers/gpu/drm/i915/intel_dp.c:351:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/gpu/drm/i915/intel_dp.c:492:1: error: invalid storage class for function 'intel_dp_aux_native_write' drivers/gpu/drm/i915/intel_dp.c:525:1: error: invalid storage class for function 'intel_dp_aux_native_write_1' drivers/gpu/drm/i915/intel_dp.c:533:1: error: invalid storage class for function 'intel_dp_aux_native_read' drivers/gpu/drm/i915/intel_dp.c:572:1: error: invalid storage class for function 'intel_dp_i2c_aux_ch' drivers/gpu/drm/i915/intel_dp.c:669:1: error: invalid storage class for function 'intel_dp_i2c_init' drivers/gpu/drm/i915/intel_dp.c:845:13: error: invalid storage class for function 'ironlake_set_pll_edp' drivers/gpu/drm/i915/intel_dp.c:872:1: error: invalid storage class for function 'intel_dp_mode_set' drivers/gpu/drm/i915/intel_dp.c:985:13: error: invalid storage class for function 'ironlake_wait_panel_status' drivers/gpu/drm/i915/intel_dp.c:1004:13: error: invalid storage class for function 'ironlake_wait_panel_on' drivers/gpu/drm/i915/intel_dp.c:1010:13: error: invalid storage class for function 'ironlake_wait_panel_off' drivers/gpu/drm/i915/intel_dp.c:1016:13: error: invalid storage class for function 'ironlake_wait_panel_power_cycle' drivers/gpu/drm/i915/intel_dp.c:1027:13: error: invalid storage class for function 'ironlake_get_pp_control' drivers/gpu/drm/i915/intel_dp.c:1075:13: error: invalid storage class for function 'ironlake_panel_vdd_off_sync' drivers/gpu/drm/i915/intel_dp.c:1097:13: error: invalid storage class for function 'ironlake_panel_vdd_work' drivers/gpu/drm/i915/intel_dp.c:1244:13: error: invalid storage class for function 'ironlake_edp_pll_on' drivers/gpu/drm/i915/intel_dp.c:1270:13: error: invalid storage class for function 'ironlake_edp_pll_off' drivers/gpu/drm/i915/intel_dp.c:1325:13: error: invalid storage class for function 'intel_dp_get_hw_state' drivers/gpu/drm/i915/intel_dp.c:1374:13: error: invalid storage class for function 'intel_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1390:13: error: invalid storage class for function 'intel_post_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1400:13: error: invalid storage class for function 'intel_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1419:13: error: invalid storage class for function 'intel_pre_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1432:1: error: invalid storage class for function 'intel_dp_aux_native_read_retry' drivers/gpu/drm/i915/intel_dp.c:1457:1: error: invalid st
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
On Wed, Feb 27, 2013 at 4:07 PM, Tejun Heo wrote:
> Replying here too just in case.
>
> On Wed, Feb 27, 2013 at 02:08:40PM +0100, Sedat Dilek wrote:
>> >> static inline void *idr_find(struct idr *idr, int id)
>> >> {
>> >> struct idr_layer *hint = rcu_dereference_raw(idr->hint);
>> >> 86d7: 48 8b 05 00 00 00 00mov0x0(%rip),%rax#
>> >> 86de
>> >> 86da: R_X86_64_PC32 .bss+0xfc
>> >>
>> >> if ((id & ~IDR_MASK) == hint->prefix)
>> >> 86de: 89 f2 mov%esi,%edx
>> >> 86e0: 30 d2 xor%dl,%dl
>> >> 86e2: 3b 10 cmp(%rax),%edx
>> >> <--- trapping insn
>> >> 86e4: 74 4a je 8730
>> >> return rcu_dereference_raw(hint->ary[id & IDR_MASK]);
>> >>
>> >>
>> >> So 'hint' is NULL as RAX above confirms and we're not supposed to deref
>> >> NULL things.
>> >>
>> >> Looking at 29cf29e1fbb875019713eb55cf27ec35f1e5fa5e, Tejun should
>> >> probably know. CCed.
>
> Fix was posted some days ago.
>
> http://thread.gmane.org/gmane.linux.kernel.next/26213
>
> I got Andrew's patch added to -mm message a week ago. Not sure why it
> still hasn't showed up. Andrew, any ideas?
>
> Thanks.
>
> --
> tejun
AFAICS the updated (correct) patch "idr: implement lookup hint" is now
in mainline.
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0ffc2a9c8072969253a20821c2c733a2cbb4c7c7
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
On Thu, Feb 28, 2013 at 8:24 AM, Sedat Dilek wrote:
> On Wed, Feb 27, 2013 at 4:07 PM, Tejun Heo wrote:
>> Replying here too just in case.
>>
>> On Wed, Feb 27, 2013 at 02:08:40PM +0100, Sedat Dilek wrote:
>>> >> static inline void *idr_find(struct idr *idr, int id)
>>> >> {
>>> >> struct idr_layer *hint = rcu_dereference_raw(idr->hint);
>>> >> 86d7: 48 8b 05 00 00 00 00mov0x0(%rip),%rax#
>>> >> 86de
>>> >> 86da: R_X86_64_PC32 .bss+0xfc
>>> >>
>>> >> if ((id & ~IDR_MASK) == hint->prefix)
>>> >> 86de: 89 f2 mov%esi,%edx
>>> >> 86e0: 30 d2 xor%dl,%dl
>>> >> 86e2: 3b 10 cmp(%rax),%edx
>>> >> <--- trapping insn
>>> >> 86e4: 74 4a je 8730
>>> >>
>>> >> return rcu_dereference_raw(hint->ary[id & IDR_MASK]);
>>> >>
>>> >>
>>> >> So 'hint' is NULL as RAX above confirms and we're not supposed to deref
>>> >> NULL things.
>>> >>
>>> >> Looking at 29cf29e1fbb875019713eb55cf27ec35f1e5fa5e, Tejun should
>>> >> probably know. CCed.
>>
>> Fix was posted some days ago.
>>
>> http://thread.gmane.org/gmane.linux.kernel.next/26213
>>
>> I got Andrew's patch added to -mm message a week ago. Not sure why it
>> still hasn't showed up. Andrew, any ideas?
>>
>> Thanks.
>>
>> --
>> tejun
>
> AFAICS the updated (correct) patch "idr: implement lookup hint" is now
> in mainline.
>
...but not in next-20130228 yet (tomorrow's Linux-Next will have it).
- Sedat -
> - Sedat -
>
> [1]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0ffc2a9c8072969253a20821c2c733a2cbb4c7c7
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] kbuild, deb-pkg: Try to determine distribution
On Thu, Feb 28, 2013 at 8:32 AM, maximilian attems wrote: > On Wed, Feb 27, 2013 at 02:55:45PM +0100, Michal Marek wrote: >> Sorry I missed this series. Max, can you have a look? I don't know the >> policies for debian package changelogs. The full series is at >> http://lkml.indiana.edu/hypermail/linux/kernel/1204.2/index.html#04252, >> but the remaining two patches are obvious. > > the two remaining ones are trivial, should have pushed them a long time > ago and will do so this weekend in a combined version going up to 2013 > (sitting in my queue to send). > >> On 24.4.2012 00:16, Sedat Dilek wrote: >> > Signed-off-by: Sedat Dilek >> > --- >> > scripts/package/builddeb | 15 ++- >> > 1 file changed, 14 insertions(+), 1 deletion(-) >> > >> > diff --git a/scripts/package/builddeb b/scripts/package/builddeb >> > index eee5f8e..f5b56ac 100644 >> > --- a/scripts/package/builddeb >> > +++ b/scripts/package/builddeb >> > @@ -172,9 +172,22 @@ else >> > fi >> > maintainer="$name <$email>" >> > >> > +# Try to determine distribution >> > +if [ -e $(which lsb_release) ]; then >> > + codename=$(lsb_release --codename --short) >> > + if [ "$codename" != "" ]; then >> > + distribution=$codename >> > + else >> > + distribution="UNRELEASED" >> > + echo "WARNING: The distribution could NOT be determined!" >> > + fi >> > +else >> > + echo "HINT: Install lsb_release binary, this helps to identify >> > your distribution!" >> > +fi >> > + >> > # Generate a simple changelog template >> > cat < debian/changelog >> > -linux-upstream ($packageversion) unstable; urgency=low >> > +linux-upstream ($packageversion) $distribution; urgency=low >> > >> >* Custom built Linux kernel. > > this is pretty useless. > Nack, in adding a this additional lsb dep. > I know it should be installed by default, but in practise it is often not. > > If you'd really care about the changelog you'd generate it out of your > git repo with Debian's git dch in order to have something meaningful. > [ CCing Thorsten and Alexander ] Thank you for your response. This was a compromise for Debian and Ubuntu systems and as said discussed with two longterm Debian maintainers. Thorsten Glaser uses same mechanisms in his Debian build-environments (he prefers -cs as parameters than long-format). FYI: Ubuntu/precise ships lsb(-release) stuff by default! Can't say if it is a "essential" package on Debian these days or not (in my patch there is a warning if it's not available). Personally, I think lsb-release binary is a good compromise in a non-Debian-world, too. I don't know of a real distro not shipping it - not thinking of distros like LFS (Linux From Scratch) in first place (and did not verify even if LSB stuff is done or not, I might be wrong). What's your proposal to check for $codename/$distribution (just curious)? Last question: Should people CC you always on patches for deb-pkg? For me it looks like you are "maintaining" it, so why not place you as a maintainer in MAINTAINERS file? ( Didn't check what checkpatch.pl throws out. ) So, you do the work - get the credits :-)! - Sedat - P.S.: Ubuntu/precise beta1 ships lsb-release. # grep lsb packages_01_precise-beta1.txt ii lsb-base 4.0-0ubuntu20 Linux Standard Base 4.0 init script functionality ii lsb-release4.0-0ubuntu20 Linux Standard Base version reporting utility > > -- > maks -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 12:18 PM, Chris Wilson wrote:
> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek wrote:
>> > Hi,
>> >
>> > I am seeing this also on Linux-Next.
>> >
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > This seems to be hard reproducible...
>> > Laptop-LCD... Sandybridge Mobile-GT2.
>> >
>> > Is there a way to force the error?
>> >
>> > Possible patch see [1].
>> >
>> > - Sedat -
>> >
>> > [1] https://patchwork.kernel.org/patch/2192721/
>
> That was:
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + }
>
> You applied
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + {
>
> That second '{' is the source of the compile error.
Schei**e, OK I try with a v2.
A hint how to force the error?
- Sedat -
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Chris Wilson :
>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek wrote:
>>> > Hi,
>>> >
>>> > I am seeing this also on Linux-Next.
>>> >
>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> >
>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> >
>>> > This seems to be hard reproducible...
>>> > Laptop-LCD... Sandybridge Mobile-GT2.
>>> >
>>> > Is there a way to force the error?
>>> >
>>> > Possible patch see [1].
>>> >
>>> > - Sedat -
>>> >
>>> > [1] https://patchwork.kernel.org/patch/2192721/
>>
>> That was:
>>
>> + if (!done) {
>> + status = I915_READ_NOTRACE(ch_ctl);
>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>> %i), status=%08x!\n",
>> + has_aux_irq, status);
>> + }
>>
>> You applied
>>
>> + if (!done) {
>> + status = I915_READ_NOTRACE(ch_ctl);
>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>> %i), status=%08x!\n",
>> + has_aux_irq, status);
>> + {
>
> In addition to this, after the problem happens can you please dump the
> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
> by running intel-reg-read (from intel-gpu-tools) or by changing the
> DRM_ERROR above to also print the result of I915_READ(0x44008) and
> I915_READ(0xC4008).
>
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
> If you conclude that the value of 0x44008 is 0x0 while the value of
> 0xC4008 is not, then this patch should help:
> https://patchwork.kernel.org/patch/2177841/
>
>>
>> That second '{' is the source of the compile error.
>> -Chris
>>
>> --
>> Chris Wilson, Intel Open Source Technology Centre
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek wrote:
> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
>> Hi
>>
>> 2013/2/28 Chris Wilson :
>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > I am seeing this also on Linux-Next.
>>>> >
>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>> > (has irq: 1)!
>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>> > (has irq: 1)!
>>>> >
>>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>> > (has irq: 1)!
>>>> >
>>>> > This seems to be hard reproducible...
>>>> > Laptop-LCD... Sandybridge Mobile-GT2.
>>>> >
>>>> > Is there a way to force the error?
>>>> >
>>>> > Possible patch see [1].
>>>> >
>>>> > - Sedat -
>>>> >
>>>> > [1] https://patchwork.kernel.org/patch/2192721/
>>>
>>> That was:
>>>
>>> + if (!done) {
>>> + status = I915_READ_NOTRACE(ch_ctl);
>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>> %i), status=%08x!\n",
>>> + has_aux_irq, status);
>>> + }
>>>
>>> You applied
>>>
>>> + if (!done) {
>>> + status = I915_READ_NOTRACE(ch_ctl);
>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>> %i), status=%08x!\n",
>>> + has_aux_irq, status);
>>> + {
>>
>> In addition to this, after the problem happens can you please dump the
>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
>> by running intel-reg-read (from intel-gpu-tools) or by changing the
>> DRM_ERROR above to also print the result of I915_READ(0x44008) and
>> I915_READ(0xC4008).
>>
>
> Do I need a specific version of intel-gpu-tools?
> Ubuntu/precise has v1.2 in its archives - sufficient?
> Note: The error was twice after dozenz of Linux-Next kernel builds.
>
> - Sedat -
>
> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus<->write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus<->write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus<->write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
- Sedat -
>> If you conclude that the value of 0x44008 is 0x0 while the value of
>> 0xC4008 is not, then this patch should help:
>> https://patchwork.kernel.org/patch/2177841/
>>
>>>
>>> That second '{' is the source of the compile error.
>>> -Chris
>>>
>>> --
>>> Chris Wilson, Intel Open Source Technology Centre
>>> ___
>>> Intel-gfx mailing list
>>> intel-...@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>
>>
>> --
>> Paulo Zanoni
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Sedat Dilek :
>> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek wrote:
>>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
>>>> Hi
>>>>
>>>> 2013/2/28 Chris Wilson :
>>>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>>>>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I am seeing this also on Linux-Next.
>>>>>> >
>>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>> > (has irq: 1)!
>>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>> > (has irq: 1)!
>>>>>> >
>>>>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>> > (has irq: 1)!
>>>>>> >
>>>>>> > This seems to be hard reproducible...
>>>>>> > Laptop-LCD... Sandybridge Mobile-GT2.
>>>>>> >
>>>>>> > Is there a way to force the error?
>>>>>> >
>>>>>> > Possible patch see [1].
>>>>>> >
>>>>>> > - Sedat -
>>>>>> >
>>>>>> > [1] https://patchwork.kernel.org/patch/2192721/
>>>>>
>>>>> That was:
>>>>>
>>>>> + if (!done) {
>>>>> + status = I915_READ_NOTRACE(ch_ctl);
>>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>>>> %i), status=%08x!\n",
>>>>> + has_aux_irq, status);
>>>>> + }
>>>>>
>>>>> You applied
>>>>>
>>>>> + if (!done) {
>>>>> + status = I915_READ_NOTRACE(ch_ctl);
>>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>>>> %i), status=%08x!\n",
>>>>> + has_aux_irq, status);
>>>>> + {
>>>>
>>>> In addition to this, after the problem happens can you please dump the
>>>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
>>>> by running intel-reg-read (from intel-gpu-tools) or by changing the
>>>> DRM_ERROR above to also print the result of I915_READ(0x44008) and
>>>> I915_READ(0xC4008).
>>>>
>>>
>>> Do I need a specific version of intel-gpu-tools?
>>> Ubuntu/precise has v1.2 in its archives - sufficient?
>>> Note: The error was twice after dozenz of Linux-Next kernel builds.
>>>
>>> - Sedat -
>>>
>>> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>>>
>>
>> Installed intel-gpu-tools.
>>
>> # intel_reg_read
>> Usage: intel_reg_read [-f | addr]
>> -f : read back full range of registers.
>> WARNING! This could be danger to hang the machine!
>> addr : in 0x format
>>
>> # intel_reg_read 0x44008
>> Couldn't map MMIO region: Resource temporarily unavailable
>>
>> [ 368.281707] intel_reg_read:3657 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>> [ 381.521912] intel_reg_read:3658 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>> [ 401.136291] intel_reg_read:3659 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>>
>> Wrong i-g-t version? Missing enabled kernel-config option? Boot with
>> i915 debug enabled?
>
> Just build the version from git and it should work
> (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
>
NO.
$ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
intel-gpu-tools-git
$ cd intel-gpu-tools-git/
$ ./autogen.sh --disable-dumper <--- requires swig2.0 and python >=3.x
$ sudo ./tools/intel_reg_read 0x44008
0x44008 : 0x0
$ sudo ./tools/intel_reg_read 0xC4008
0xC4008 : 0x0
$ sudo ./tools/intel_reg_dumper > /tmp/intel_reg_dumper.txt <
Re: [PATCH V6 00/30] loop: Issue O_DIRECT aio using bio_vec
On Wed, Jan 30, 2013 at 8:26 PM, Dave Kleikamp wrote: > By the way, I have updated the patchset in git. I removed the version > from the name of the branch and will keep this one updated: > > git://github.com/kleikamp/linux-shaggy.git aio_loop What's the status of this patchset? Will it go into Linux-Next? Through Al's VFS tree? Any chance to have it for-3.9? - Sedat - > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)
On Tue, Mar 12, 2013 at 4:41 PM, Miklos Szeredi wrote: > Al and Linus, > > Please consider overlayfs for inclusion into 3.10. > > It's included in Ubuntu and openSUSE, used by OpenWrt and various other > projects. I regularly get emails asking when it will be included in mainline. > > Git tree is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs.v16 > > Thanks, > Miklos > > --- > Andy Whitcroft (3): > overlayfs-add-statfs-support > ovl-switch-to-inode_permission > overlayfs-copy-up-i_uid-i_gid-from-the-underlying-inode > > Erez Zadok (1): > overlayfs-implement-show_options > > Miklos Szeredi (6): > vfs-add-i_op-dentry_open > vfs-export-do_splice_direct-to-modules > vfs-introduce-clone_private_mount > overlay filesystem > fs-limit-filesystem-stacking-depth > vfs-export-inode_permission-to-modules > > Neil Brown (1): > overlay-overlay-filesystem-documentation > > Robin Dong (2): > overlayfs-fix-possible-leak-in-ovl_new_inode > overlayfs-create-new-inode-in-ovl_link > What happened to the subject lines (see v15)? - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/log/?h=overlayfs.v15 > --- > Documentation/filesystems/Locking |2 + > Documentation/filesystems/overlayfs.txt | 199 + > Documentation/filesystems/vfs.txt |7 + > MAINTAINERS |7 + > fs/Kconfig |1 + > fs/Makefile |1 + > fs/ecryptfs/main.c |7 + > fs/internal.h |5 - > fs/namei.c | 10 +- > fs/namespace.c | 18 + > fs/open.c | 23 +- > fs/overlayfs/Kconfig|4 + > fs/overlayfs/Makefile |7 + > fs/overlayfs/copy_up.c | 385 + > fs/overlayfs/dir.c | 604 +++ > fs/overlayfs/inode.c| 372 + > fs/overlayfs/overlayfs.h| 70 > fs/overlayfs/readdir.c | 566 + > fs/overlayfs/super.c| 685 > +++ > fs/splice.c |1 + > include/linux/fs.h | 14 + > include/linux/mount.h |3 + > 22 files changed, 2981 insertions(+), 10 deletions(-) > create mode 100644 Documentation/filesystems/overlayfs.txt > create mode 100644 fs/overlayfs/Kconfig > create mode 100644 fs/overlayfs/Makefile > create mode 100644 fs/overlayfs/copy_up.c > create mode 100644 fs/overlayfs/dir.c > create mode 100644 fs/overlayfs/inode.c > create mode 100644 fs/overlayfs/overlayfs.h > create mode 100644 fs/overlayfs/readdir.c > create mode 100644 fs/overlayfs/super.c > -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)
On Tue, Mar 12, 2013 at 11:23 PM, Al Viro wrote: > On Tue, Mar 12, 2013 at 02:50:02PM -0700, Linus Torvalds wrote: >> On Tue, Mar 12, 2013 at 8:41 AM, Miklos Szeredi wrote: >> > Al and Linus, >> > >> > Please consider overlayfs for inclusion into 3.10. >> >> Yes, I think we should just do it. It's in use, it's pretty small, and >> the other alternatives are worse. Let's just plan on getting this >> thing done with. >> >> Al, I realize you may not love this, but can you please give this a >> look? People clearly want to use it. In particular the new interfaces, >> like the inode ops open function with dentry passed in or whatever? >> The changes outside of overlayfs looked fine to me. > > I'll post a review tonight or tomorrow. FWIW, I was not too happy with > it the last time I looked, but I'll obviously need to reread the whole > thing. > > I *have* looked at unionmount lately, and the recent modifications dhowells > is doing there are closing most of my problems with that; on the other hand, > there's no fundamental reason why both can't get merged. Hell, might as > well resurrect aufs, while we are at it... > > union-like things are actually on top of my "things to deal with this cycle" > list, closely folowed by rework of ->readdir(). > > Miklos, two points: > * I would very much prefer to deal with that (as well as unionmount > and > aufs) as git branches _expected_ to be reordered/rebased/folded/mutilated/etc. > while we are sorting all that stuff out. For now, let's base them on -rc1. > I expect that vfs.git will grow common stem, with bits and pieces of those > guys getting gradually pulled into it, at which point(s) the rest will be > rebased. > * what Linus just said about bisectablity > Oh, and the third one - I still owe you a bottle of your choice for sorting > the atomic_open shite out. Is there any chance you'll be able to attend > LSFS this year? > Hi all, I only say: Al-lelujah! Congrats Miklos! - Sedat - > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Status of union-mount?
On Tue, Mar 12, 2013 at 6:18 PM, Mark Knecht wrote: > On Tue, Mar 12, 2013 at 9:55 AM, Sedat Dilek wrote: >> Hi, >> >> what's the status of union-mount? >> Where does the development happen - in [1]? >> >> Regards, >> - Sedat - >> >> [1] >> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=unionmount > > Sedat, >Did you look here for info? > > http://unionfs.filesystems.org/ > [ CC Erez ] Hi, UnionFS is a different solution than union-mount. Checking the official GIT repositories, the last commit is from February 2012. Can't say if the development stopped. Regards, - Sedat - [1] http://git.fsl.cs.sunysb.edu/?p=unionfs-latest.git;a=commitdiff;h=6a0a7bb2656c8790d355e2dfcdd13332da319b8f > Cheers, > Mark -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Status of union-mount?
On Tue, Mar 12, 2013 at 6:19 PM, David Howells wrote: > Sedat Dilek wrote: > >> what's the status of union-mount? > > It's being reengineered again to take account of VFS changes that went in in > the last merge window. > Hmmm, sorry for asking, but when do you plan to offer a "working" union-mount (u-m)? What's the status of the user-space tools or are they no more needed? AFAICS the original authors patched e2fsprogs etc. (see Valerie's old homepage [1]). >> Where does the development happen - in [1]? > > On a git tree on my PC - which is occasionally mirrored in [1] when I've got > it working. > Development on your local workstation does not look like you do an open development. So, it's currently only you doing the work on u-m? - Sedat - [1] http://valerieaurora.org/union/ > David -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)
On Tue, Mar 12, 2013 at 4:41 PM, Miklos Szeredi wrote: > Al and Linus, > > Please consider overlayfs for inclusion into 3.10. > > It's included in Ubuntu and openSUSE, used by OpenWrt and various other > projects. I regularly get emails asking when it will be included in mainline. > > Git tree is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs.v16 > > Thanks, > Miklos > Hi Miklos, Is it possible to get a backport of OverlayFS-v16 for Linux-stable v3.8.y? Thanks in advance. - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the final tree (drm-intel tree related)
On Tue, Mar 12, 2013 at 10:50 AM, Sedat Dilek wrote:
> On Tue, Mar 12, 2013 at 6:46 AM, Kees Cook wrote:
>> On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> After merging the final tree, today's linux-next build (i386 defconfig)
>>> failed like this:
>>>
>>> drivers/built-in.o: In function `i915_min_freq_set':
>>> i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3'
>>> drivers/built-in.o: In function `i915_max_freq_set':
>>> i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3'
>>>
>>> Caused by commit 2389cc500686 ("drm/i915: use simple attribute in debugfs
>>> routines") from the drm-intel tree.
>>>
>>> I have reverted that commit for today.
>>
>> Ah-ha, thanks. I've sent a follow-up patch to fix this.
>>
>
> Can you please point to the patch [1] next time?
> Thanks.
>
> - Sedat -
>
> [1] https://patchwork.kernel.org/patch/2253231/
>
Hi Kees, Hi Daniel,
was the above patch merged into drm (for me it does not look like it was [1])?
Regards,
- Sedat -
[1]
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=author&q=Kees+Cook
>> -Kees
>>
>> --
>> Kees Cook
>> Chrome OS Security
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-next" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 3:31 PM, Sedat Dilek wrote:
> On Wed, Mar 13, 2013 at 3:16 PM, Miklos Szeredi wrote:
>> Here's another version with the comments addressed plus a small bugfix and
>> some
>> checkpatch cleanups.
>>
>> Changes in v17:
>>
>> - fix wrong return value in a failure path in ovl_link()
>> - fix subjects
>> - use file_inode() and MODULE_ALIAS_FS()
>> - fold bugfix patches
>> - checkpatch cleanups
>>
>> Git tree is here:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
>> overlayfs.current
>>
>
> Hi,
>
> I pulled in v17 (current) into Linux-Next (next-20130313) and built
> OverlayFS as a module.
>
> Unfortunately, I do not see any success message on loading it.
>
> --- dmesg_3.9.0-rc2-next20130313-3-iniza-small.txt 2013-03-13
> 15:21:19.578712536 +0100
> +++ dmesg_3.9.0-rc2-next20130313-3-iniza-small_after-overlayfs-test.txt
> 2013-03-13 15:22:14.658238998 +0100
> @@ -806,3 +806,8 @@
> [ 25.517154] wlan0: associated
> [ 25.517214] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 54.149536] usb 2-1.5: USB disconnect, device number 3
> +[ 86.502215] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> +[ 87.007082] EXT4-fs (loop4): mounted filesystem with ordered data
> mode. Opts: (null)
> +[ 87.311998] EXT4-fs (loop4): re-mounted. Opts: data=ordered
> +[ 87.657291] EXT4-fs (loop4): re-mounted. Opts: data=ordered
> +[ 88.057251] EXT4-fs (loop4): re-mounted. Opts: data=ordered
>
> Highly appreciated to see such a message!
>
> Test-case script attached (needs an additional patch on top of
> overlayfs.current, see attachments).
>
Looks like this is missing (or intended?):
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 482c26f..f23ebfc 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
module_init(ovl_init);
module_exit(ovl_exit);
+MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem functionality");
+MODULE_AUTHOR("Miklos Szeredi ");
+MODULE_LICENSE("GPL");
Feel free to correct if I fill in bullshit...
- Sedat -
> - Sedat -
>
>> Thanks,
>> Miklos
>>
>> ---
>> Andy Whitcroft (1):
>> overlayfs: add statfs support
>>
>> Erez Zadok (1):
>> overlayfs: implement show_options
>>
>> Miklos Szeredi (6):
>> vfs: add i_op->dentry_open()
>> vfs: export do_splice_direct() to modules
>> vfs: export __inode_permission() to modules
>> vfs: introduce clone_private_mount()
>> overlay filesystem
>> fs: limit filesystem stacking depth
>>
>> Neil Brown (1):
>> overlay: overlay filesystem documentation
>>
>> ---
>> Documentation/filesystems/Locking |2 +
>> Documentation/filesystems/overlayfs.txt | 199 +
>> Documentation/filesystems/vfs.txt |7 +
>> MAINTAINERS |7 +
>> fs/Kconfig |1 +
>> fs/Makefile |1 +
>> fs/ecryptfs/main.c |7 +
>> fs/internal.h |5 -
>> fs/namei.c | 10 +-
>> fs/namespace.c | 18 +
>> fs/open.c | 23 +-
>> fs/overlayfs/Kconfig| 10 +
>> fs/overlayfs/Makefile |7 +
>> fs/overlayfs/copy_up.c | 385 +
>> fs/overlayfs/dir.c | 605 +++
>> fs/overlayfs/inode.c| 372 +
>> fs/overlayfs/overlayfs.h| 70
>> fs/overlayfs/readdir.c | 566 +
>> fs/overlayfs/super.c| 686
>> +++
>> fs/splice.c |1 +
>> include/linux/fs.h | 14 +
>> include/linux/mount.h |3 +
>> 22 files changed, 2989 insertions(+), 10 deletions(-)
>> create mode 100644 Documentation/filesystems/overlayfs.txt
>> create mode 100644 fs/overlayfs/Kconfig
>> create mode 100644 fs/overlayfs/Makefile
>> create mode 100644 fs/overlayfs/copy_up.c
>> create mode 100644 fs/overlayfs/dir.c
>> create mode 100644 fs/overlayfs/inode.c
>> create mode 100644 fs/overlayfs/overlayfs.h
>> create mode 100644 fs/overlayfs/readdir.c
>> create mode 100644 fs/overlayfs/super.c
>>
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi wrote:
>> Looks like this is missing (or intended?):
>>
>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> index 482c26f..f23ebfc 100644
>> --- a/fs/overlayfs/super.c
>> +++ b/fs/overlayfs/super.c
>> @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>>
>> module_init(ovl_init);
>> module_exit(ovl_exit);
>> +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem
>> functionality");
>> +MODULE_AUTHOR("Miklos Szeredi ");
>> +MODULE_LICENSE("GPL");
>
> No, it *is* already in there.
>
Where is it?
Last lines in [1] are:
685 module_init(ovl_init);
686 module_exit(ovl_exit);
- Sedat -
[1]
http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current
> Thanks,
> Miklos
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 4:26 PM, Sedat Dilek wrote:
> On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi wrote:
>>> Looks like this is missing (or intended?):
>>>
>>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>>> index 482c26f..f23ebfc 100644
>>> --- a/fs/overlayfs/super.c
>>> +++ b/fs/overlayfs/super.c
>>> @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>>>
>>> module_init(ovl_init);
>>> module_exit(ovl_exit);
>>> +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem
>>> functionality");
>>> +MODULE_AUTHOR("Miklos Szeredi ");
>>> +MODULE_LICENSE("GPL");
>>
>> No, it *is* already in there.
>>
>
> Where is it?
>
> Last lines in [1] are:
>
> 685 module_init(ovl_init);
> 686 module_exit(ovl_exit);
>
OK, I looked at SquashFS which is not converted to use MODULE_ALIAS_FS.
Hehe, with my patch that looks now funny :-).
$ sudo modinfo overlayfs
filename:
/lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/overlayfs/overlayfs.ko
license:GPL
author: Miklos Szeredi
description:overlayfs v17, provides overlay-filesystem functionality
alias: fs-overlayfs
license:GPL
description:Overlay filesystem
author: Miklos Szeredi
srcversion: 4332BB91603829A85CCEA59
depends:
intree: Y
vermagic: 3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload modversions
$ sudo modinfo squashfs
filename:
/lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/squashfs/squashfs.ko
license:GPL
author: Phillip Lougher
description:squashfs 4.0, a compressed read-only filesystem
alias: fs-squashfs
srcversion: 752DB671D8E8DFB606BFC88
depends:
intree: Y
vermagic: 3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload modversions
- Sedat -
> - Sedat -
>
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current
>
>> Thanks,
>> Miklos
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 4:53 PM, Sedat Dilek wrote:
> On Wed, Mar 13, 2013 at 4:26 PM, Sedat Dilek wrote:
>> On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi wrote:
>>>> Looks like this is missing (or intended?):
>>>>
>>>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>>>> index 482c26f..f23ebfc 100644
>>>> --- a/fs/overlayfs/super.c
>>>> +++ b/fs/overlayfs/super.c
>>>> @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>>>>
>>>> module_init(ovl_init);
>>>> module_exit(ovl_exit);
>>>> +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem
>>>> functionality");
>>>> +MODULE_AUTHOR("Miklos Szeredi ");
>>>> +MODULE_LICENSE("GPL");
>>>
>>> No, it *is* already in there.
>>>
>>
>> Where is it?
>>
>> Last lines in [1] are:
>>
>> 685 module_init(ovl_init);
>> 686 module_exit(ovl_exit);
>>
>
> OK, I looked at SquashFS which is not converted to use MODULE_ALIAS_FS.
>
> Hehe, with my patch that looks now funny :-).
>
> $ sudo modinfo overlayfs
> filename:
> /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/overlayfs/overlayfs.ko
> license:GPL
> author: Miklos Szeredi
> description:overlayfs v17, provides overlay-filesystem functionality
> alias: fs-overlayfs
> license:GPL
> description:Overlay filesystem
> author: Miklos Szeredi
> srcversion: 4332BB91603829A85CCEA59
> depends:
> intree: Y
> vermagic: 3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload
> modversions
>
>
> $ sudo modinfo squashfs
> filename:
> /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/squashfs/squashfs.ko
> license:GPL
> author: Phillip Lougher
> description:squashfs 4.0, a compressed read-only filesystem
> alias: fs-squashfs
> srcversion: 752DB671D8E8DFB606BFC88
> depends:
> intree: Y
> vermagic: 3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload
> modversions
>
Nah, SquashFS has MODULE_ALIAS_FS in Linux-Next, but /me looked into Linus-tree.
You are right, you have those MODULE_XXX at the beginning of
fs/overlayfs/super.c
Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
when the kernel-module is loaded.
So, is this intended?
SquashFS prints into the logs, so what is it doing differently?
- Sedat -
> - Sedat -
>
>> - Sedat -
>>
>> [1]
>> http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current
>>
>>> Thanks,
>>> Miklos
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi wrote: > On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek wrote: > >> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages >> when the kernel-module is loaded. >> So, is this intended? >> SquashFS prints into the logs, so what is it doing differently? > > Some modules do, some don't. It's not compulsory and not very useful. > That's some hardcoded printk-stuff which is IMHO wrong implemented and outdated. I hoped that this is handled in al FS-modules the same way. Do not assume... - Sedat - [1] http://marc.info/?l=linux-kernel&m=136319193916686&w=2 > Thanks, > Miklos -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi wrote:
> On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek wrote:
>
>> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
>> when the kernel-module is loaded.
>> So, is this intended?
>> SquashFS prints into the logs, so what is it doing differently?
>
> Some modules do, some don't. It's not compulsory and not very useful.
>
What about...
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 482c26f..92b9ad5 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -675,11 +675,13 @@ MODULE_ALIAS_FS("overlayfs");
static int __init ovl_init(void)
{
return register_filesystem(&ovl_fs_type);
+ printk(KERN_INFO "overlayfs: loaded\n");
}
static void __exit ovl_exit(void)
{
unregister_filesystem(&ovl_fs_type);
+ printk(KERN_INFO "overlayfs: unloaded\n");
}
module_init(ovl_init);
Maybe "loaded" is enough.
- Sedat -
> Thanks,
> Miklos
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] overlayfs: Print info when (un)loaded into the logs
Signed-off-by: Sedat Dilek
---
fs/overlayfs/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 482c26f..92b9ad5 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -675,11 +675,13 @@ MODULE_ALIAS_FS("overlayfs");
static int __init ovl_init(void)
{
return register_filesystem(&ovl_fs_type);
+ printk(KERN_INFO "overlayfs: loaded\n");
}
static void __exit ovl_exit(void)
{
unregister_filesystem(&ovl_fs_type);
+ printk(KERN_INFO "overlayfs: unloaded\n");
}
module_init(ovl_init);
--
1.8.2.rc3
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] squashfs: Simplify info in the logs when loaded
Signed-off-by: Sedat Dilek --- fs/squashfs/super.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/squashfs/super.c b/fs/squashfs/super.c index 260e392..9747764 100644 --- a/fs/squashfs/super.c +++ b/fs/squashfs/super.c @@ -447,8 +447,7 @@ static int __init init_squashfs_fs(void) return err; } - printk(KERN_INFO "squashfs: version 4.0 (2009/01/31) " - "Phillip Lougher\n"); + printk(KERN_INFO "squashfs: loaded\n"); return 0; } -- 1.8.2.rc3 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 7:37 PM, Felix Fietkau wrote:
> On 2013-03-13 7:12 PM, Robin Holt wrote:
>> On Wed, Mar 13, 2013 at 05:51:33PM +0100, Sedat Dilek wrote:
>>> On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi wrote:
>>> > On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek
>>> > wrote:
>>> >
>>> >> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
>>> >> when the kernel-module is loaded.
>>> >> So, is this intended?
>>> >> SquashFS prints into the logs, so what is it doing differently?
>>> >
>>> > Some modules do, some don't. It's not compulsory and not very useful.
>>> >
>>>
>>> What about...
>>>
>>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>>> index 482c26f..92b9ad5 100644
>>> --- a/fs/overlayfs/super.c
>>> +++ b/fs/overlayfs/super.c
>>> @@ -675,11 +675,13 @@ MODULE_ALIAS_FS("overlayfs");
>>> static int __init ovl_init(void)
>>> {
>>> return register_filesystem(&ovl_fs_type);
>>> + printk(KERN_INFO "overlayfs: loaded\n");
>>
>> How about pr_debug(). That makes things quite for most of us but gives
>> you info when looking for things like boot problems.
> How is having a printk/pr_debug useful here at all? The fact that other
> filesystems do this as well is not a good reason...
> Also, putting it *after* the return statement doesn't make much sense ;)
>
Hehe, I just checked my new kernel... that does not work (nothing in the logs).
But I think it's good to see if the filesystem is registered/loaded.
- Sedat -
> - Felix
>
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] overlayfs: Print info into the logs when loaded
Signed-off-by: Sedat Dilek
---
fs/overlayfs/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 482c26f..e30141f 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -674,6 +674,8 @@ MODULE_ALIAS_FS("overlayfs");
static int __init ovl_init(void)
{
+ printk(KERN_INFO "overlayfs: loaded\n");
+
return register_filesystem(&ovl_fs_type);
}
--
1.8.2.rc3
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 8:58 PM, Linus Torvalds wrote: > On Wed, Mar 13, 2013 at 12:54 PM, Eric W. Biederman > wrote: >>> >>> Hehe, I just checked my new kernel... that does not work (nothing in the >>> logs). >>> But I think it's good to see if the filesystem is registered/loaded. >> >> lsmod | grep overlayfs > > How about the compiled-in case? What's wrong with just using the > obvious /proc/filesystems? > As I don't need OverlayFS in my daily life, I have it here built as a module. Nevertheless, as module or built-in /me as an end-user wants to know what's going on. So, dmesg is normally my first weapon. I grep-ed trrough a bit through all the filesystems in fs/ and it is not handled unique. "Loaded" BTW is not the right term in FS-folks-jargon: The functions are called (un)register_filesystem(). $ dmesg | grep -i loaded [0.241037] vgaarb: loaded [0.241243] libata version 3.00 loaded. [0.358574] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [0.368711] brd: module loaded [0.369832] loop: module loaded [0.650086] PM: Hibernation image not present or could not be loaded. [0.651150] Loaded X.509 cert 'Magrathea: Glacier signing key: e75e3a59e59cb48db975ac12e21a905289ada56f' [1.788947] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [8.617549] lp: driver loaded but no devices found [ 10.490721] wmi: Mapper loaded [ 11.994985] iwlwifi :01:00.0: loaded firmware version 18.168.6.1 [ 73.885056] squashfs: loaded [ 81.345070] overlayfs: loaded I am not sure whether those lines "blabla: module loaded" is true for loop (block) it is a hardcoded printk-line. I doubt... CONFIG_BLK_DEV_LOOP=y Last but not least, user-space apps like GRUB trigger fs loaded. For me this is helpful. You might be bored or whatever reason I can't or don't want to understand. And just to have some fun about status informations: Check your drm (kms) driver with date and version :-). Stuff that is not maintained should be thrown out (yes, I had sent patches...). - Sedat - > Linus -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
On Wed, Mar 13, 2013 at 9:13 PM, Phillip Lougher
wrote:
>
>
> On Wed, Mar 13, 2013 at 4:10 PM, Sedat Dilek wrote:
>>
>> On Wed, Mar 13, 2013 at 4:53 PM, Sedat Dilek
>> wrote:
>> > On Wed, Mar 13, 2013 at 4:26 PM, Sedat Dilek
>> > wrote:
>> >> On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi
>> >> wrote:
>> >>>> Looks like this is missing (or intended?):
>> >>>>
>> >>>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> >>>> index 482c26f..f23ebfc 100644
>> >>>> --- a/fs/overlayfs/super.c
>> >>>> +++ b/fs/overlayfs/super.c
>> >>>> @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>> >>>>
>> >>>> module_init(ovl_init);
>> >>>> module_exit(ovl_exit);
>> >>>> +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem
>> >>>> functionality");
>> >>>> +MODULE_AUTHOR("Miklos Szeredi ");
>> >>>> +MODULE_LICENSE("GPL");
>> >>>
>> >>> No, it *is* already in there.
>> >>>
>> >>
>> >> Where is it?
>> >>
>> >> Last lines in [1] are:
>> >>
>> >> 685 module_init(ovl_init);
>> >> 686 module_exit(ovl_exit);
>> >>
>> >
>> > OK, I looked at SquashFS which is not converted to use MODULE_ALIAS_FS.
>> >
>> > Hehe, with my patch that looks now funny :-).
>> >
>> > $ sudo modinfo overlayfs
>> > filename:
>> >
>> > /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/overlayfs/overlayfs.ko
>> > license:GPL
>> > author: Miklos Szeredi
>> > description:overlayfs v17, provides overlay-filesystem functionality
>> > alias: fs-overlayfs
>> > license:GPL
>> > description:Overlay filesystem
>> > author: Miklos Szeredi
>> > srcversion: 4332BB91603829A85CCEA59
>> > depends:
>> > intree: Y
>> > vermagic: 3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload
>> > modversions
>> >
>> >
>> > $ sudo modinfo squashfs
>> > filename:
>> >
>> > /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/squashfs/squashfs.ko
>> > license:GPL
>> > author: Phillip Lougher
>> > description:squashfs 4.0, a compressed read-only filesystem
>> > alias: fs-squashfs
>> > srcversion: 752DB671D8E8DFB606BFC88
>> > depends:
>> > intree: Y
>> > vermagic: 3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload
>> > modversions
>> >
>>
>> Nah, SquashFS has MODULE_ALIAS_FS in Linux-Next, but /me looked into
>> Linus-tree.
>>
>> You are right, you have those MODULE_XXX at the beginning of
>> fs/overlayfs/super.c
>>
>> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
>> when the kernel-module is loaded.
>> So, is this intended?
>> SquashFS prints into the logs, so what is it doing differently?
>
>
> SquashFS did it because it was out of tree for a long time, and you couldn't
> use the kernel version to tell what version of Squashfs you had patched in.
>
> When people dug about in their embedded system (router, STB etc.) they often
> got kernels without modules, without source and no idea of the Squashfs
> version... When they emailed me to ask why xyz Squashfs filesystem
> wouldn't mount, which version of squashfs-tools they should use, I often had
> no way of knowing.
>
Hi Phillip,
thanks for your explanations.
I can imagine that sometimes to have version and date is helpful for
the developer.
But /me thinks the way it was implemented is not very cool.
See "version.h" in fs/btrfs and appropriate printk-line in fs/btrfs/super.c.
That solution pleased me well.
There you can put all the relevant informations (even you insist to
display your $author :-)).
But as said in another email that status information stuff is not
handled unique/consequently in fs/.
I just fell over it... not more not less. Asking should be allowed.
- Sedat -
> Phillip
>
>>
>> - Sedat -
>>
>>
>> > - Sedat -
>> >
>> >> - Sedat -
>> >>
>> >> [1]
>> >> http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current
>> >>
>> >>> Thanks,
>> >>> Miklos
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
>> in
>>
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] overlayfs: Print info into the logs when loaded
On Wed, Mar 13, 2013 at 9:05 PM, Al Viro wrote:
> On Wed, Mar 13, 2013 at 08:47:14PM +0100, Sedat Dilek wrote:
>>
>> Signed-off-by: Sedat Dilek
>> ---
>> fs/overlayfs/super.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> index 482c26f..e30141f 100644
>> --- a/fs/overlayfs/super.c
>> +++ b/fs/overlayfs/super.c
>> @@ -674,6 +674,8 @@ MODULE_ALIAS_FS("overlayfs");
>>
>> static int __init ovl_init(void)
>> {
>> + printk(KERN_INFO "overlayfs: loaded\n");
>> +
>
> Could we please create a new maillist for that kind of stuff? It's seriously
> overdue, IMO. linux-bikeshedd...@vger.kernel.org, if davem doesn't mind
> touching that...
Dear Mr. Viro,
I looked over fs/ especially in concerńs of status-informations - I
had better not done it.
This remembered me the crap with drm/kms with all its useless driver info.
Here for you:
[ 10.998890] [drm] Initialized drm 1.1.0 20060810
[ 13.147821] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
( On a quick Google search I found [1] (I rememebr there were 4
patches but break user-space as there exists kernel-drm and libdrm). )
As an enduser I want some useful help.
As a non-native English I had to look up that "bikeshedding" word.
People asked for review why not test it and give feedback - even
report on useless stuff seen from your POV.
This might be a little detail in your eyes - but you are free to have
a deeper look on overlayfs as an filesystem-expert.
For me it is important that this drama comes to an end.
O.O. drama - isn't someone dying in the end :-).
Take it with British humour :-).
- Sedat -
[1] https://lkml.org/lkml/2010/12/22/50
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the signal tree with the modules tree
On Fri, Mar 15, 2013 at 5:41 AM, Rusty Russell wrote:
> Stephen Rothwell writes:
>> Hi Al,
>>
>> Today's linux-next merge of the signal tree got a conflict in
>> include/asm-generic/unistd.h between commit 837718bfd28b
>> ("CONFIG_SYMBOL_PREFIX: cleanup") from the modules tree and commit
>> e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
>> from the signal tree.
>>
>> The latter moved the cond_syscall stuff to linkage.h, so I applied the
>> following patch as a merge fixup and can carry the fix as necessary (no
>> action is required). I am not sure if this is completely correct or all
>> that is needed.
>
> Your fix looks correct, thanks.
>
> I've been forced to update that patch after another round of
> improvements, so you may need to re-do the merge.
>
Hi,
I just looked into modules-next...
The improved version is in [1]...
...and contains a file called "kernel/modsign_certificate.S" which is
NOT in the latest Linux-Next tree [2].
So, I thought about reverting the one in -next and apply the new one
from modules-next.
This is not possible!
$ git log --oneline -2
d98f244 Merge tag 'next-20130315' of
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next into
Linux-Next-v20130315
1765898 Add linux-next specific files for 20130315
$ LC_ALL=C ls -l kernel/mod*
-rw-r--r-- 1 wearefam wearefam 458 Mar 15 11:13 kernel/module-internal.h
-rw-r--r-- 1 wearefam wearefam 99000 Mar 15 11:13 kernel/module.c
-rw-r--r-- 1 wearefam wearefam 6063 Mar 15 11:13 kernel/module_signing.c
Is this a generated file?
I have attached both patches extracted from Linux-Next [3] and modules-next [4].
Both patches list changes to "kernel/modsign_certificate.S".
/me ---> confused!
Can you please enlighten me?
Regards,
- Sedat -
[1]
http://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/commit/?h=modules-next&id=b92021b09df70c1609e3547f3d6128dd560be97f
[2]
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/kernel?id=next-20130315
[3]
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/?id=837718bfd28ba5f474c1182ef2639b6949d854fc
[4]
http://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/patch/?id=b92021b09df70c1609e3547f3d6128dd560be97f
> Cheers,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
CONFIG_SYMBOL_PREFIX-cleanup-from-modules-next.patch
Description: Binary data
CONFIG_SYMBOL_PREFIX-cleanup-from-next-20130315.patch
Description: Binary data
Re: linux-next: manual merge of the signal tree with the modules tree
On Fri, Mar 15, 2013 at 11:21 AM, Sedat Dilek wrote:
> On Fri, Mar 15, 2013 at 5:41 AM, Rusty Russell wrote:
>> Stephen Rothwell writes:
>>> Hi Al,
>>>
>>> Today's linux-next merge of the signal tree got a conflict in
>>> include/asm-generic/unistd.h between commit 837718bfd28b
>>> ("CONFIG_SYMBOL_PREFIX: cleanup") from the modules tree and commit
>>> e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
>>> from the signal tree.
>>>
>>> The latter moved the cond_syscall stuff to linkage.h, so I applied the
>>> following patch as a merge fixup and can carry the fix as necessary (no
>>> action is required). I am not sure if this is completely correct or all
>>> that is needed.
>>
>> Your fix looks correct, thanks.
>>
>> I've been forced to update that patch after another round of
>> improvements, so you may need to re-do the merge.
>>
>
> Hi,
>
> I just looked into modules-next...
> The improved version is in [1]...
> ...and contains a file called "kernel/modsign_certificate.S" which is
> NOT in the latest Linux-Next tree [2].
> So, I thought about reverting the one in -next and apply the new one
> from modules-next.
> This is not possible!
>
> $ git log --oneline -2
> d98f244 Merge tag 'next-20130315' of
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next into
> Linux-Next-v20130315
> 1765898 Add linux-next specific files for 20130315
>
> $ LC_ALL=C ls -l kernel/mod*
> -rw-r--r-- 1 wearefam wearefam 458 Mar 15 11:13 kernel/module-internal.h
> -rw-r--r-- 1 wearefam wearefam 99000 Mar 15 11:13 kernel/module.c
> -rw-r--r-- 1 wearefam wearefam 6063 Mar 15 11:13 kernel/module_signing.c
>
OK, renamed: kernel/modsign_certificate.S -> kernel/system_certificates.S... see
commit ebe2e946f60e0012c02a27845bdab70e34cc4202
KEYS: Separate the kernel signature checking keyring from module signing
> Is this a generated file?
> I have attached both patches extracted from Linux-Next [3] and modules-next
> [4].
> Both patches list changes to "kernel/modsign_certificate.S".
> /me ---> confused!
>
> Can you please enlighten me?
>
Is this attached follow-up correct?
- Sedat -
>
> Regards,
> - Sedat -
>
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/commit/?h=modules-next&id=b92021b09df70c1609e3547f3d6128dd560be97f
> [2]
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/kernel?id=next-20130315
> [3]
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/?id=837718bfd28ba5f474c1182ef2639b6949d854fc
> [4]
> http://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/patch/?id=b92021b09df70c1609e3547f3d6128dd560be97f
>
>> Cheers,
>> Rusty.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-next" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
0001-CONFIG_SYMBOL_PREFIX-cleanup-improved-version.patch
Description: Binary data
Re: linux-next: build warnings after merge of the drm tree
On Tue, Sep 4, 2012 at 5:58 AM, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
>
> drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
> drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
> drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
> drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
> drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
> warning: (PPC_PS3) selects USB_OHCI_LITTLE_ENDIAN which has unmet direct
> dependencies (USB_SUPPORT && USB_OHCI_HCD)
> warning: (PPC_PS3 && PPC_CELLEB) selects USB_OHCI_BIG_ENDIAN_MMIO which has
> unmet direct dependencies (USB_SUPPORT && USB_OHCI_HCD)
> warning: (PPC_PS3 && PPC_CELLEB && USB_EHCI_HCD_PMC_MSP && XPS_USB_HCD_XILINX
> && USB_OCTEON_EHCI) selects USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct
> dependencies (USB_SUPPORT && USB_EHCI_HCD && (PPC_CELLEB || PPC_PS3 || 440EPX
> || ARCH_IXP4XX || XPS_USB_HCD_XILINX || PPC_MPC512x || CPU_CAVIUM_OCTEON ||
> PMC_MSP || SPARC_LEON || MIPS_SEAD3))
>
> The x86_64 allmodconfig produces these:
>
> drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
> drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
> drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
> drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
> drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
> warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB &&
> JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG
> && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE &&
> INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK
> && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 &&
> IR_STREAMZAP && IR_IGUANA && IR_TTUSBIR && DRM_USB) selects USB which has
> unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD)
>
> Maybe introduced by commit df0b34430072 ("drm/usb: select USB_SUPPORT in
> Kconfig"), maybe interacting with a commit 8f057d7bca54 ("gpu/mfd/usb:
> Fix USB randconfig problems") from Linus' tree (that added "depends on
> USB_ARCH_HAS_HCD" to "config DRM_USB" and "config DRM_UDL").
>
> I have left this mess for now, but it needs addressing.
I have sent a fix ("drm/udl: usb: Fix recursive Kconfig dependency")
for this mess and pinged airlied on IRC.
NOTE: I saw this when I merged drm(-intel){-fixes,next} into next-20120824.
- Sedat -
[1] https://patchwork.kernel.org/patch/1373391/
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warnings after merge of the drm tree
On Tue, Sep 4, 2012 at 10:22 AM, Dave Airlie wrote:
>> > After merging the drm tree, today's linux-next build (powerpc
>> > ppc64_defconfig) produced these warnings:
>> >
>> > drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
>> > drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
>> > drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
>> > drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
>> > drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
>> > warning: (PPC_PS3) selects USB_OHCI_LITTLE_ENDIAN which has unmet direct
>> > dependencies (USB_SUPPORT && USB_OHCI_HCD)
>> > warning: (PPC_PS3 && PPC_CELLEB) selects USB_OHCI_BIG_ENDIAN_MMIO which
>> > has unmet direct dependencies (USB_SUPPORT && USB_OHCI_HCD)
>> > warning: (PPC_PS3 && PPC_CELLEB && USB_EHCI_HCD_PMC_MSP &&
>> > XPS_USB_HCD_XILINX && USB_OCTEON_EHCI) selects USB_EHCI_BIG_ENDIAN_MMIO
>> > which has unmet direct dependencies (USB_SUPPORT && USB_EHCI_HCD &&
>> > (PPC_CELLEB || PPC_PS3 || 440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX ||
>> > PPC_MPC512x || CPU_CAVIUM_OCTEON || PMC_MSP || SPARC_LEON || MIPS_SEAD3))
>> >
>> > The x86_64 allmodconfig produces these:
>> >
>> > drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
>> > drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
>> > drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
>> > drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
>> > drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
>> > warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB &&
>> > JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK &&
>> > TABLET_USB_HANWANG && TABLET_USB_KBTAB && TABLET_USB_WACOM &&
>> > TOUCHSCREEN_USB_COMPOSITE && INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE &&
>> > INPUT_POWERMATE && INPUT_YEALINK && INPUT_CM109 && RC_ATI_REMOTE &&
>> > IR_IMON && IR_MCEUSB && IR_REDRAT3 && IR_STREAMZAP && IR_IGUANA &&
>> > IR_TTUSBIR && DRM_USB) selects USB which has unmet direct dependencies
>> > (USB_SUPPORT && USB_ARCH_HAS_HCD)
>> >
>> > Maybe introduced by commit df0b34430072 ("drm/usb: select USB_SUPPORT in
>> > Kconfig"), maybe interacting with a commit 8f057d7bca54 ("gpu/mfd/usb:
>> > Fix USB randconfig problems") from Linus' tree (that added "depends on
>> > USB_ARCH_HAS_HCD" to "config DRM_USB" and "config DRM_UDL").
>> >
>> > I have left this mess for now, but it needs addressing.
>>
>> I have sent a fix ("drm/udl: usb: Fix recursive Kconfig dependency")
>> for this mess and pinged airlied on IRC.
>> NOTE: I saw this when I merged drm(-intel){-fixes,next} into next-20120824.
>
> I[ve pushed it to drm-next now hopefully it will resolve the mess.
>
Great and thanks!
Can't say if the label of my patch should be changed to "drm/usb: ..."
as the culprit commit df0b34430072 (drm/usb: select USB_SUPPORT in
Kconfig) has it and the fix is done in drm/usb Kconfig definition.
( Thinking loud of people searching within (git-)logs. )
For me the current status of drm-next is OK (next time I do better).
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=df0b344300724e00db9fff7eb6406eb91f450b91
> thanks,
> Dave.
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sept 11 (drm related: boot problems on amd64)
On Tue, Sep 11, 2012 at 8:31 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 201209010: > > New tree: ixp4xx > > The pci tree gained a build failure so I used the version from > next-20120910. > > The regulator tree lost its build failure. > > The staging tree lost its build failure. > > The akpm tree lost a few patches that turned up elsewhere. > > > Hi, today's and yesterday's Linux-Next is broken for me again. I tried with systemd and upstart on Ubuntu/precise, with nomodeset and rescue boot-option. With rescue boot-option I see this in my logs (Intel sandy-bridge ultrabook here): Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module. Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed. I have not checked any MLs... coming from hospital right now. Regards, - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sept 11 (drm related: boot problems on amd64)
On Tue, Sep 11, 2012 at 8:12 PM, Sedat Dilek wrote: > On Tue, Sep 11, 2012 at 8:31 AM, Stephen Rothwell > wrote: >> Hi all, >> >> Changes since 201209010: >> >> New tree: ixp4xx >> >> The pci tree gained a build failure so I used the version from >> next-20120910. >> >> The regulator tree lost its build failure. >> >> The staging tree lost its build failure. >> >> The akpm tree lost a few patches that turned up elsewhere. >> >> >> > > Hi, > > today's and yesterday's Linux-Next is broken for me again. > I tried with systemd and upstart on Ubuntu/precise, with nomodeset and > rescue boot-option. > > With rescue boot-option I see this in my logs (Intel sandy-bridge > ultrabook here): > > Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init] > *ERROR* Cannot initialize the agpgart module. > Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed. > > I have not checked any MLs... coming from hospital right now. > More ERRORs: # grep -A1 "ERROR" /var/log/kern.log Sep 10 17:51:29 fambox kernel: [ 10.205818] [drm:i915_get_bridge_dev] *ERROR* bridge device not found Sep 10 17:51:29 fambox kernel: [ 10.206055] i915: probe of :00:02.0 failed with error -5 -- Sep 10 15:53:00 fambox kernel: [ 10.500387] [drm:i915_get_bridge_dev] *ERROR* bridge device not found Sep 10 15:53:00 fambox kernel: [ 10.500602] i915: probe of :00:02.0 failed with error -5 -- Sep 11 20:41:01 fambox kernel: [9.636010] [drm:i915_get_bridge_dev] *ERROR* bridge device not found Sep 11 20:41:01 fambox kernel: [9.636202] i915: probe of :00:02.0 failed with error -5 -- Sep 11 18:42:18 fambox kernel: [ 10.132229] [drm:i915_get_bridge_dev] *ERROR* bridge device not found Sep 11 18:42:18 fambox kernel: [ 10.132433] i915: probe of :00:02.0 failed with error -5 -- Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module. Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed. -- Sep 11 19:52:10 fambox kernel: [9.545562] [drm:i915_get_bridge_dev] *ERROR* bridge device not found Sep 11 19:52:10 fambox kernel: [9.545798] i915: probe of :00:02.0 failed with error -5 -- Sep 11 20:04:09 fambox kernel: [9.798233] [drm:i915_get_bridge_dev] *ERROR* bridge device not found Sep 11 20:04:09 fambox kernel: [9.798557] i915: probe of :00:02.0 failed with error -5 - Sedat - > Regards, > - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sept 11 (drm related: boot problems on amd64)
On Tue, Sep 11, 2012 at 8:29 PM, Sedat Dilek wrote:
> On Tue, Sep 11, 2012 at 8:12 PM, Sedat Dilek wrote:
>> On Tue, Sep 11, 2012 at 8:31 AM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> Changes since 201209010:
>>>
>>> New tree: ixp4xx
>>>
>>> The pci tree gained a build failure so I used the version from
>>> next-20120910.
>>>
>>> The regulator tree lost its build failure.
>>>
>>> The staging tree lost its build failure.
>>>
>>> The akpm tree lost a few patches that turned up elsewhere.
>>>
>>>
>>>
>>
>> Hi,
>>
>> today's and yesterday's Linux-Next is broken for me again.
>> I tried with systemd and upstart on Ubuntu/precise, with nomodeset and
>> rescue boot-option.
>>
>> With rescue boot-option I see this in my logs (Intel sandy-bridge
>> ultrabook here):
>>
>> Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init]
>> *ERROR* Cannot initialize the agpgart module.
>> Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed.
>>
>> I have not checked any MLs... coming from hospital right now.
>>
>
> More ERRORs:
>
> # grep -A1 "ERROR" /var/log/kern.log
> Sep 10 17:51:29 fambox kernel: [ 10.205818]
> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
> Sep 10 17:51:29 fambox kernel: [ 10.206055] i915: probe of
> :00:02.0 failed with error -5
> --
> Sep 10 15:53:00 fambox kernel: [ 10.500387]
> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
> Sep 10 15:53:00 fambox kernel: [ 10.500602] i915: probe of
> :00:02.0 failed with error -5
> --
> Sep 11 20:41:01 fambox kernel: [9.636010]
> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
> Sep 11 20:41:01 fambox kernel: [9.636202] i915: probe of
> :00:02.0 failed with error -5
> --
> Sep 11 18:42:18 fambox kernel: [ 10.132229]
> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
> Sep 11 18:42:18 fambox kernel: [ 10.132433] i915: probe of
> :00:02.0 failed with error -5
> --
> Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init]
> *ERROR* Cannot initialize the agpgart module.
> Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed.
> --
> Sep 11 19:52:10 fambox kernel: [9.545562]
> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
> Sep 11 19:52:10 fambox kernel: [9.545798] i915: probe of
> :00:02.0 failed with error -5
> --
> Sep 11 20:04:09 fambox kernel: [9.798233]
> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
> Sep 11 20:04:09 fambox kernel: [9.798557] i915: probe of
> :00:02.0 failed with error -5
>
[ CC Bjorn (pci maintainer) ]
I pulled in pci.git#next up to commit
9c2178e6ba49fe48c468edc08ad94b53e1b1 ("Merge branch
'pci/gavin-window-alignment' into next") on top of next-20120911.
This lets my machine boot, but freezes somewhere else.
- Sedat -
> - Sedat -
>
>> Regards,
>> - Sedat -
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sept 11 (drm related: boot problems on amd64)
On Wed, Sep 12, 2012 at 9:52 PM, Bjorn Helgaas wrote:
> On Tue, Sep 11, 2012 at 4:04 PM, Sedat Dilek wrote:
>> On Tue, Sep 11, 2012 at 8:29 PM, Sedat Dilek wrote:
>>> On Tue, Sep 11, 2012 at 8:12 PM, Sedat Dilek wrote:
>>>> On Tue, Sep 11, 2012 at 8:31 AM, Stephen Rothwell
>>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> Changes since 201209010:
>>>>>
>>>>> New tree: ixp4xx
>>>>>
>>>>> The pci tree gained a build failure so I used the version from
>>>>> next-20120910.
>>>>>
>>>>> The regulator tree lost its build failure.
>>>>>
>>>>> The staging tree lost its build failure.
>>>>>
>>>>> The akpm tree lost a few patches that turned up elsewhere.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> today's and yesterday's Linux-Next is broken for me again.
>>>> I tried with systemd and upstart on Ubuntu/precise, with nomodeset and
>>>> rescue boot-option.
>>>>
>>>> With rescue boot-option I see this in my logs (Intel sandy-bridge
>>>> ultrabook here):
>>>>
>>>> Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init]
>>>> *ERROR* Cannot initialize the agpgart module.
>>>> Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed.
>>>>
>>>> I have not checked any MLs... coming from hospital right now.
>>>>
>>>
>>> More ERRORs:
>>>
>>> # grep -A1 "ERROR" /var/log/kern.log
>>> Sep 10 17:51:29 fambox kernel: [ 10.205818]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 10 17:51:29 fambox kernel: [ 10.206055] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 10 15:53:00 fambox kernel: [ 10.500387]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 10 15:53:00 fambox kernel: [ 10.500602] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 11 20:41:01 fambox kernel: [9.636010]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 11 20:41:01 fambox kernel: [9.636202] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 11 18:42:18 fambox kernel: [ 10.132229]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 11 18:42:18 fambox kernel: [ 10.132433] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init]
>>> *ERROR* Cannot initialize the agpgart module.
>>> Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed.
>>> --
>>> Sep 11 19:52:10 fambox kernel: [9.545562]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 11 19:52:10 fambox kernel: [9.545798] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 11 20:04:09 fambox kernel: [9.798233]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 11 20:04:09 fambox kernel: [9.798557] i915: probe of
>>> :00:02.0 failed with error -5
>>>
>>
>> [ CC Bjorn (pci maintainer) ]
>>
>> I pulled in pci.git#next up to commit
>> 9c2178e6ba49fe48c468edc08ad94b53e1b1 ("Merge branch
>> 'pci/gavin-window-alignment' into next") on top of next-20120911.
>> This lets my machine boot, but freezes somewhere else.
>
> We had a PCI bug in an earlier version of this patch:
> http://git.kernel.org/?p=linux/kernel/git/helgaas/pci.git;a=commitdiff;h=b9443f401bb20ae6414e3e68bca0413bad28b689
> that caused lspci to fail.
>
I retested with next-20120912 and my machine boots, so no more
drm-related errors causing boot-failures.
> I suspect this also caused the issue you saw. We've since fixed it,
> but let me know if you see a PCI-related issue again.
>
Immediately after pressing any single key at X-login (Ubuntu/precise
IIRC uses lightdm + unity-greeter), my machine produces a
kernel-panic.
I have taken a photo and will send a separate email on this.
Can't say ATM what is the root-cause for it.
But that is what I have seen after my merging of the "clean"
pci.git/next into yesterday's "nine-eleven" release.
Further questions (not issue related):
While doing a simple grepping for new "pcie-cap" patterns (a list at
[1]) came with commit 8c0d3a02c1309eb6112d2e7c8172e8ceb26ecfca ("PCI:
Add accessors for PCI Express Capability") on drivers/gpu/
directory...more simplifications possible (I had only a quick view)?
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/helgaas/pci.git;a=commitdiff;h=8c0d3a02c1309eb6112d2e7c8172e8ceb26ecfca#patch2
> Bjorn
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sept 12 (kernel-panic after pressing any key at X login)
On Thu, Sep 13, 2012 at 5:18 AM, Sedat Dilek wrote: > On Wed, Sep 12, 2012 at 10:46 AM, Stephen Rothwell > wrote: >> Hi all, >> >> Changes since 201209011: >> >> The pci tree lost its build failure. >> >> The mfd tree gained a conflict against Linus' tree. >> >> The omap_dss2 tree lost its conflict. >> >> The trivial tree gained a conflict against the mfd tree. >> >> The kvm tree gained a conflict against Linus' tree. >> >> The workqueues tree gained a conflict against the omap_dss2 tree. >> >> The usb tree gained conflicts against the usb.current tree. >> >> The staging tree gained a conflict against the thermal tree and a build >> failure for which I applied a merge fix patch. >> >> The tegra tree gained conflicts against the usb and arm-perf trees. >> >> >> > > Hi, > > this weeks linux-next seems to bring new and new issues, yay :-)! > > I have taken a photo, but can't say what can have caused. > The issue is reproducible... > Immediately, after pressing any key (when X-display-manager (lightdm) > and X-greeter are up) my machine panics and is no more usable (cold > rough brutal killer restart). > Note: Using upstart or systemd does not matter. > > Any pointer to an area where to dig into or any feedback in general is > welcome! > > Kind Regards, > - Sedat - [ CC Dmitry Torokhov (linux-input maintainer) plus linux-input ML ] By looking at my screenshot, someone could imagine that there is a problem coming from the input GIT branch(es) merges: input_to_handler() input_pass_values() input_handle_event() input_event() Unfortunately, with those 3 revert-patches I see the same kernel-panic. Dimitry, any idea what can cause this kernel-panic? - Sedat - 0001-Revert-Input-evdev-Add-the-events-callback.patch Description: Binary data 0002-Revert-Input-Send-events-one-packet-at-a-time.patch Description: Binary data 0003-Revert-Input-Move-autorepeat-to-the-event-passing-ph.patch Description: Binary data
Re: linux-next: Tree for Sept 12 (kernel-panic after pressing any key at X login)
On Thu, Sep 13, 2012 at 8:04 AM, Minchan Kim wrote:
> On Thu, Sep 13, 2012 at 07:29:32AM +0200, Sedat Dilek wrote:
>> On Thu, Sep 13, 2012 at 5:18 AM, Sedat Dilek wrote:
>> > On Wed, Sep 12, 2012 at 10:46 AM, Stephen Rothwell
>> > wrote:
>> >> Hi all,
>> >>
>> >> Changes since 201209011:
>> >>
>> >> The pci tree lost its build failure.
>> >>
>> >> The mfd tree gained a conflict against Linus' tree.
>> >>
>> >> The omap_dss2 tree lost its conflict.
>> >>
>> >> The trivial tree gained a conflict against the mfd tree.
>> >>
>> >> The kvm tree gained a conflict against Linus' tree.
>> >>
>> >> The workqueues tree gained a conflict against the omap_dss2 tree.
>> >>
>> >> The usb tree gained conflicts against the usb.current tree.
>> >>
>> >> The staging tree gained a conflict against the thermal tree and a build
>> >> failure for which I applied a merge fix patch.
>> >>
>> >> The tegra tree gained conflicts against the usb and arm-perf trees.
>> >>
>> >>
>> >>
>> >
>> > Hi,
>> >
>> > this weeks linux-next seems to bring new and new issues, yay :-)!
>> >
>> > I have taken a photo, but can't say what can have caused.
>> > The issue is reproducible...
>> > Immediately, after pressing any key (when X-display-manager (lightdm)
>> > and X-greeter are up) my machine panics and is no more usable (cold
>> > rough brutal killer restart).
>> > Note: Using upstart or systemd does not matter.
>> >
>> > Any pointer to an area where to dig into or any feedback in general is
>> > welcome!
>> >
>> > Kind Regards,
>> > - Sedat -
>>
>> [ CC Dmitry Torokhov (linux-input maintainer) plus linux-input ML ]
>>
>> By looking at my screenshot, someone could imagine that there is a
>> problem coming from the input GIT branch(es) merges:
>>
>> input_to_handler()
>> input_pass_values()
>> input_handle_event()
>> input_event()
>>
>> Unfortunately, with those 3 revert-patches I see the same kernel-panic.
>>
>> Dimitry, any idea what can cause this kernel-panic?
>
> Today, I met similar problem in mmotm-2012-09-12-17-36 on my KVM.
> It's hard to reproduce in my mahcine but I confirmed following as
> Hoping it helps you.
>
[ CC more input developers/testers ]
Hi Minchan,
Hey, cool. Thanks for the pointer in the source-code and the call-trace!
I had reverted [1], but anyway input folks should look at this.
Kind Regards,
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=b276fc1e875a51e4a9dc3322ed008bf4ae481baf
> static unsigned int input_to_handler(struct input_handle *handle,
> struct input_value *vals, unsigned int count)
> {
> ...
> ...
> if (handler->events)
> handler->events(handle, vals, count);
> else
> for (v = vals; v != end; v++)
> handler->event(...); <-- handler->event is *ZERO*.
>
> return count;
> }
>
>
> [ 34.667212] BUG: unable to handle kernel NULL pointer dereference at
> (null)
> [ 34.668320] IP: [< (null)>] (null)
> [ 34.669095] PGD 1fe47c067 PUD 1fe47b067 PMD 0
> [ 34.669808] Oops: 0010 [#1] SMP
> [ 34.670316] Modules linked in: i2c_piix4
> [ 34.670618] CPU 6
> [ 34.670618] Pid: 0, comm: swapper/6 Not tainted
> 3.6.0-rc5-mm1-alloc-enhance+ #60 Bochs Bochs[ 34.670618] RIP:
> 0010:[<>] [< (null)>] (null)
> [ 34.670618] RSP: 0018:88021fd83c20 EFLAGS: 00010082
> [ 34.670618] RAX: 0010 RBX: 0002 RCX:
> 000f
> [ 34.670618] RDX: 0004 RSI: 0004 RDI:
> 8802145b4c00
> [ 34.670618] RBP: 88021fd83c68 R08: R09:
>
> [ 34.670618] R10: R11: 0001 R12:
> 880215c21070
> [ 34.670618] R13: 880215c21068 R14: 81a8bfe0 R15:
> 8802145b4c00
> [ 34.670618] FS: () GS:88021fd8()
> knlGS:
> [ 34.670618] CS: 0010 DS: ES: CR0: 8005003b
> [ 34.670618] CR2: CR3: 0001fe46f000 CR4:
> 06e0
> [ 34.670618] DR0
Re: linux-next: Tree for Sept 12 (kernel-panic after pressing any key at X login)
On Thu, Sep 13, 2012 at 9:04 AM, Henrik Rydberg wrote: >> > >> > this weeks linux-next seems to bring new and new issues, yay :-)! >> > >> > >> > >> > I have taken a photo, but can't say what can have caused. >> > >> > The issue is reproducible... >> > >> > Immediately, after pressing any key (when X-display-manager (lightdm) >> > >> > and X-greeter are up) my machine panics and is no more usable (cold >> > >> > rough brutal killer restart). >> > >> > Note: Using upstart or systemd does not matter. >> > >> > >> > >> > Any pointer to an area where to dig into or any feedback in general >> > >> > is welcome! >> > >> > >> > >> > Kind Regards, >> > >> > - Sedat - >> > >> > Hey, cool. Thanks for the pointer in the source-code and the call-trace! >> > I had reverted [1], but anyway input folks should look at this. >> > >> > Kind Regards, >> > - Sedat - >> > >> > [1] >> > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=b276fc1e875a51e4a9dc3322ed008bf4ae481baf >> >> Henrik, >> >> It looks like your changes are causing the panic. > > Indeed, I have pushed the fix below to next already. Thanks for Sedat, > and sorry for not catching this earlier. :-( > Hi Hendrik, Wow, so fast :-). Stephen, can you apply this to today's linux-next (next-20120913), please? Regards, - Sedat - > Henrik > > -- > > From ccc6557bfd02efdca4d9dfda6cfdfe5a08d0193b Mon Sep 17 00:00:00 2001 > From: Henrik Rydberg > Date: Thu, 13 Sep 2012 08:59:40 +0200 > Subject: [PATCH] Input: Fix oops caused by missing null test > > Found in linux-next on September 12, thanks Sedat. > > Reported-by: Sedat Dilek > Signed-off-by: Henrik Rydberg > --- > drivers/input/input.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/input/input.c b/drivers/input/input.c > index 5b66b2f..2dff71b 100644 > --- a/drivers/input/input.c > +++ b/drivers/input/input.c > @@ -114,7 +114,7 @@ static unsigned int input_to_handler(struct input_handle > *handle, > > if (handler->events) > handler->events(handle, vals, count); > - else > + else if (handler->event) > for (v = vals; v != end; v++) > handler->event(handle, v->type, v->code, v->value); > > -- > 1.7.12 > -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] thermal: cpu_cooling.c needs to select CPU_FREQ_TABLE
On Thu, Sep 13, 2012 at 10:46 AM, Amit Kachhap wrote: > On 13 September 2012 03:06, Randy Dunlap wrote: >> From: Randy Dunlap >> >> cpu_cooling.c (CONFIG_CPU_THERMAL) uses cpu frequency table >> intefaces so it should select CPU_FREQ_TABLE. >> Fixes these build errors: >> >> drivers/built-in.o: In function `cpufreq_get_max_state': >> cpu_cooling.c:(.text+0x4e1297): undefined reference to >> `cpufreq_frequency_get_table' >> drivers/built-in.o: In function `cpufreq_set_cur_state': >> cpu_cooling.c:(.text+0x4e138b): undefined reference to >> `cpufreq_frequency_get_table' >> >> Signed-off-by: Randy Dunlap >> Cc: Amit Daniel Feel free to add: Tested-by: Sedat Dilek >> --- >> drivers/thermal/Kconfig |1 + >> 1 file changed, 1 insertion(+) >> >> Also, please add info in the MAINTAINERS file for drivers/thermal/. >> >> --- linux-next-20120912.orig/drivers/thermal/Kconfig >> +++ linux-next-20120912/drivers/thermal/Kconfig >> @@ -22,6 +22,7 @@ config THERMAL_HWMON >> config CPU_THERMAL >> bool "generic cpu cooling support" >> depends on THERMAL && CPU_FREQ >> + select CPU_FREQ_TABLE > > This change looks good to me. Even similar select is present platform > cpufreq drivers which uses the cpufreq API's. > > Thanks, > Amit Daniel >> help >> This implements the generic cpu cooling mechanism through frequency >> reduction, cpu hotplug and any other ways of reducing temperature. >> An > -- > To unsubscribe from this list: send the line "unsubscribe linux-next" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sept 12 (kernel-panic after pressing any key at X login)
On Thu, Sep 13, 2012 at 10:18 AM, Sedat Dilek wrote: > On Thu, Sep 13, 2012 at 9:04 AM, Henrik Rydberg wrote: >>> > >> > this weeks linux-next seems to bring new and new issues, yay :-)! >>> > >> > >>> > >> > I have taken a photo, but can't say what can have caused. >>> > >> > The issue is reproducible... >>> > >> > Immediately, after pressing any key (when X-display-manager (lightdm) >>> > >> > and X-greeter are up) my machine panics and is no more usable (cold >>> > >> > rough brutal killer restart). >>> > >> > Note: Using upstart or systemd does not matter. >>> > >> > >>> > >> > Any pointer to an area where to dig into or any feedback in general >>> > >> > is welcome! >>> > >> > >>> > >> > Kind Regards, >>> > >> > - Sedat - >>> > >>> > Hey, cool. Thanks for the pointer in the source-code and the call-trace! >>> > I had reverted [1], but anyway input folks should look at this. >>> > >>> > Kind Regards, >>> > - Sedat - >>> > >>> > [1] >>> > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=b276fc1e875a51e4a9dc3322ed008bf4ae481baf >>> >>> Henrik, >>> >>> It looks like your changes are causing the panic. >> >> Indeed, I have pushed the fix below to next already. Thanks for Sedat, >> and sorry for not catching this earlier. :-( >> > > Hi Hendrik, > > Wow, so fast :-). > > Stephen, can you apply this to today's linux-next (next-20120913), please? > > Regards, > - Sedat - > >> Henrik >> >> -- >> >> From ccc6557bfd02efdca4d9dfda6cfdfe5a08d0193b Mon Sep 17 00:00:00 2001 >> From: Henrik Rydberg >> Date: Thu, 13 Sep 2012 08:59:40 +0200 >> Subject: [PATCH] Input: Fix oops caused by missing null test >> >> Found in linux-next on September 12, thanks Sedat. >> >> Reported-by: Sedat Dilek Tested-by: Sedat Dilek Unfortunately, the fix will be in tomorrow's Linux-Next (next-20120914). - Sedat - [1] https://github.com/rydberg/linux/commit/ccc6557bfd02efdca4d9dfda6cfdfe5a08d0193b >> Signed-off-by: Henrik Rydberg >> --- >> drivers/input/input.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/input/input.c b/drivers/input/input.c >> index 5b66b2f..2dff71b 100644 >> --- a/drivers/input/input.c >> +++ b/drivers/input/input.c >> @@ -114,7 +114,7 @@ static unsigned int input_to_handler(struct input_handle >> *handle, >> >> if (handler->events) >> handler->events(handle, vals, count); >> - else >> + else if (handler->event) >> for (v = vals; v != end; v++) >> handler->event(handle, v->type, v->code, v->value); >> >> -- >> 1.7.12 >> -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sept 13 (input causes kernel-panic)
On Thu, Sep 13, 2012 at 10:22 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 201209012: > > The staging tree gained a conflict against the tty tree. > > The arm-soc tree gained a conflict against the i2c-embedded tree. > > The tegra tree lost 2 conflicts. > > The akpm tree gained 3 build failures for which I applied a merge fix > patch and reverted 3 commits. > > > Unfortunately, for me an important fix did not make it into today's Linux-Next. So, this is a warning for people (like Minchan) seeing the same kernel-panic. ( Please. follow also the discussion thread in [2] for more details. ) Thanks to all involved people! - Sedat - [1] https://github.com/rydberg/linux/commit/ccc6557bfd02efdca4d9dfda6cfdfe5a08d0193b [2] http://marc.info/?t=13475143511&r=1&w=2 -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sept 14
On Fri, Sep 14, 2012 at 9:38 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 201209013: > > The pci tree lost its conflicts. > > The i2c tree lost its conflict. > > The net-next tree gained conflicts against the net tree. > > The cgroup tree gained a build failure so I used the version from > next-20120913. > > The workqueues tree gained a conflict against the net tree. > > The dma-mapping tree gained conflicts against the libata tree. > > The clk tree lost its conflicts. > > The akpm tree lost 2 build failures, I have still reverted 1 commit. > > > This is a good release (for me), thanks :-). Wonderful, wonderful, wonderful life... [1]. ( If linux-next folks would get all (severe) issues tracked down within a week till Fridays (which is a challenge)... ) - Sedat - [1] http://www.youtube.com/watch?v=pj_qIwQ3V5c -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cgroup: net_cls: Include missing header with sock_update_classid() definition
On Fri, Sep 14, 2012 at 4:33 PM, Daniel Wagner wrote: > From: Daniel Wagner > > commit 1f66c0a8833c3974ab6b35edcf4f8585b2f94592 > Author: Daniel Wagner > Date: Wed Sep 12 16:12:01 2012 +0200 > > cgroup: net_cls: Move sock_update_classid() declaration to cls_cgroup.h > > Claimed that there was only net/socket.c depending on > sock_update_class(). That is not true drivers/net/tun.c needs to > include the cls_cgroup.h header too. > > Signed-off-by: Daniel Wagner > Cc: "David S. Miller" > Cc: "Michael S. Tsirkin" > Cc: Gao feng > Cc: Jamal Hadi Salim > Cc: Joe Perches > Cc: John Fastabend > Cc: Li Zefan > Cc: Neil Horman > Cc: Rick Jones > Cc: Stanislav Kinsbursky > Cc: Tejun Heo > Cc: net...@vger.kernel.org > Cc: cgro...@vger.kernel.org > --- > > This version is on top of the latest cgroup for-3.7 branch. > Thanks for the quick fix. Please honour Reported-by: Stephen Rothwell . If this is the fix for the breakage in today's Linux-Next (next-20120914), please add a "-next" to the subject next time. - Sedat - > drivers/net/tun.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index 3a16d4f..9336b82 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -68,6 +68,7 @@ > #include > #include > #include > +#include > > #include > > -- > 1.7.12.315.g682ce8b > > -- > To unsubscribe from this list: send the line "unsubscribe linux-next" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the cgroup tree
On Fri, Sep 14, 2012 at 7:00 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 14, 2012 at 08:56:29AM +0200, Daniel Wagner wrote:
>> On 14.09.2012 05:17, Stephen Rothwell wrote:
>> >After merging the cgroup tree, today's linux-next build (powerpc
>> >ppc64_defconfig) failed like this:
>> >
>> >drivers/net/tun.c: In function 'tun_alloc_skb':
>> >drivers/net/tun.c:589:2: error: implicit declaration of function
>> >'sock_update_classid' [-Werror=implicit-function-declaration]
>> >
>> >Caused by commit 1f66c0a8833c ("cgroup: net_cls: Move sock_update_classid()
>> >declaration to cls_cgroup.h"). Grep is your friend ...
>
> My apologies. Forgot allmod build.
>
>> >I have used the cgroup tree from next-20120913 for today.
>>
>> Obviously, it is straight forward to fix this but I do not know what
>> is the preferred solution. Shall I spin an updated version of this
>> patch or add a patch on top of the series?
>
> I fixed the commit in tree.
>
> Thanks.
>
Did you pushed this to [1] already?
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/tj/cgroup.git;a=shortlog;h=refs/heads/for-next
> --
> tejun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Announcement of Linux v3.11-rc7?
Hi, I am reading LKML offline (mostly on ). Did you send out an announcement for Linux v3.11-rc7 or am I missing sth.? Regards, - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Aug 28 [ xhci build breakage ]
On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek wrote: > Hi all, > > Changes since 20130827: > > The f2fs tree lost its build failure. > > The md tree gained a conflict against the arm tree. > > The libata tree lost its build failure. > > The spi tree lost its build failure. > > The arm-soc tree gained conflicts against the usb tree. > > The dma-mapping tree gained a conflict against the driver-core tree. > > The akpm-current tree gained a conflict against the net tree. > > > > My build here breaks like this: > > CC drivers/usb/host/xhci-ring.o > CC drivers/video/console/softcursor.o > drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx': > drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of > function 'DEFINE_DYNAMIC_DEBUG_METADATA' > [-Werror=implicit-function-declaration] > drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared > (first use in this function) > drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier > is reported only once for each function it appears in > drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of > function '__dynamic_pr_debug' [-Werror=implicit-function-declaration] > drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare': > drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared > (first use in this function) > cc1: some warnings being treated as errors > make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1 > make[4]: *** [drivers/usb/host] Error 2 > > My kernel-config is attached. > Looks like or is missing. $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr linux/include/ linux/include/linux/device.h:1118: DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ linux/include/linux/device.h:1121: __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\ linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...); linux/include/linux/dynamic_debug.h:63:#define DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \ linux/include/linux/dynamic_debug.h:76: DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ linux/include/linux/dynamic_debug.h:78: __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\ linux/include/linux/dynamic_debug.h:84: DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ linux/include/linux/dynamic_debug.h:92: DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ linux/include/linux/dynamic_debug.h:101: DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, \ Can't say which one is preferred here. - Sedat - -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
