Re: [uml-devel] [PATCH] um: link with -lpthread

Am 31.12.2015 5:06 nachm. schrieb Vegard Nossum : > > Similarly to commit fb1770aa78a43530940d0c2dd161e77bc705bdac, with gcc 5 > on Ubuntu and CONFIG_STATIC_LINK=y I was seeing these linker errors: Hi, Oops, yes this patch looks good to me. Honestly I did never test

Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram

Am Sonntag, den 26.04.2015, 20:32 +0200 schrieb Richard Weinberger: > On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote: > > Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: > >> Am 20.10.2014 um 11:51 schrieb Thomas Meyer: > >> >

Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram

Am Sonntag, den 26.04.2015, 20:32 +0200 schrieb Richard Weinberger: On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer tho...@m3y3r.de wrote: Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: Am 20.10.2014 um 11:51 schrieb Thomas Meyer: Hmm, does this always happen? Yes

Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram

Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: > Am 20.10.2014 um 11:51 schrieb Thomas Meyer: > >> Hmm, does this always happen? > > > > Yes, my single core system seems to trigger this every time after resume > > from ram. > > What i

Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram

Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: Am 20.10.2014 um 11:51 schrieb Thomas Meyer: Hmm, does this always happen? Yes, my single core system seems to trigger this every time after resume from ram. What is your host kernel? At least on my notebook

Re: [4.0.0-rc3-24042-g5fb0f7fa] BUG: NULL pointer dereference in DRM

Am Sonntag, den 22.03.2015, 17:46 +0100 schrieb Thomas Meyer: > Hi, > another hard lock-up of the graphic system. this time with 4.0.0-rc4-24381-gb314aca I previously did use the Fedora default kernel, i.e. 3.18.x. with those I didn't encounter these kind of lock-ups. Mär 25 09

Re: [4.0.0-rc3-24042-g5fb0f7fa] BUG: NULL pointer dereference in DRM

Am Sonntag, den 22.03.2015, 17:46 +0100 schrieb Thomas Meyer: Hi, another hard lock-up of the graphic system. this time with 4.0.0-rc4-24381-gb314aca I previously did use the Fedora default kernel, i.e. 3.18.x. with those I didn't encounter these kind of lock-ups. Mär 25 09:02:41

[4.0.0-rc3-24042-g5fb0f7fa] BUG: NULL pointer dereference in DRM

Hi, two things: 1.) the i915 drivers seemed to have crashed, and/or Xorg somehow got stuck. But I could ssh into the machine and extract below the kernel log. See the below "BUG: unable to handle kernel NULL pointer dereference at (null)" and "BUG: scheduling while atomic:

[4.0.0-rc3-24042-g5fb0f7fa] BUG: NULL pointer dereference in DRM

Hi, two things: 1.) the i915 drivers seemed to have crashed, and/or Xorg somehow got stuck. But I could ssh into the machine and extract below the kernel log. See the below BUG: unable to handle kernel NULL pointer dereference at (null) and BUG: scheduling while atomic: Xorg.bin/1398/0x0003

[4.0] cryptsetup fails

Hi, I wanted to give the new kernel a try, but the cryptsetup fails with: [8.747114] localhost.localdomain systemd-cryptsetup[280]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/[...] [9.265258] localhost.localdomain kernel: device-mapper: table: 254:0: crypt:

[4.0] cryptsetup fails

Hi, I wanted to give the new kernel a try, but the cryptsetup fails with: [8.747114] localhost.localdomain systemd-cryptsetup[280]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/[...] [9.265258] localhost.localdomain kernel: device-mapper: table: 254:0: crypt:

[PATCH] netfilter: fix compile of nft_reject_bridge

Von: Stephen Hemminger > An: Thomas Meyer > Betreff: Re: [PATCH] netfilter: fix compile of nft_reject_bridge > Datum: Mon, 3 Nov 2014 12:44:06 -0800 > > On Sat, 01 Nov 2014 16:21:39 +0100 > Thomas Meyer wrote: > > > Module uses csum_ipv6_magic(), so incl

[PATCH] netfilter: fix compile of nft_reject_bridge

Von: Stephen Hemminger step...@networkplumber.org An: Thomas Meyer tho...@m3y3r.de Betreff: Re: [PATCH] netfilter: fix compile of nft_reject_bridge Datum: Mon, 3 Nov 2014 12:44:06 -0800 On Sat, 01 Nov 2014 16:21:39 +0100 Thomas Meyer tho...@m3y3r.de wrote: Module uses csum_ipv6_magic

Re: [uml-devel] kernel stalls in balance_dirty_pages_ratelimited()

Am Sonntag, den 19.10.2014, 21:35 +0200 schrieb Thomas Meyer: > Am Sonntag, den 19.10.2014, 17:02 +0100 schrieb Anton Ivanov: > > On 19/10/14 15:59, Thomas Meyer wrote: > > > Am Dienstag, den 14.10.2014, 08:31 +0100 schrieb Anton Ivanov: > > >> I see a very similar st

Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram

Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: > Am 20.10.2014 um 11:51 schrieb Thomas Meyer: > >> Hmm, does this always happen? > > > > Yes, my single core system seems to trigger this every time after resume > > from ram. > > What is yo

Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram

Am 20.10.2014 10:27 schrieb Richard Weinberger : > > On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer wrote: > > Hello, > > > > in UML kernel I get a long cpu using loop in __getnstimeofday() > > (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), &

Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram

Am 20.10.2014 10:27 schrieb Richard Weinberger richard.weinber...@gmail.com: On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer tho...@m3y3r.de wrote: Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns

Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram

Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: Am 20.10.2014 um 11:51 schrieb Thomas Meyer: Hmm, does this always happen? Yes, my single core system seems to trigger this every time after resume from ram. What is your host kernel? The standard Fedora kernel

Re: [uml-devel] kernel stalls in balance_dirty_pages_ratelimited()

Am Sonntag, den 19.10.2014, 21:35 +0200 schrieb Thomas Meyer: Am Sonntag, den 19.10.2014, 17:02 +0100 schrieb Anton Ivanov: On 19/10/14 15:59, Thomas Meyer wrote: Am Dienstag, den 14.10.2014, 08:31 +0100 schrieb Anton Ivanov: I see a very similar stall on writeout to ubd with my patches

Re: [uml-devel] kernel stalls in balance_dirty_pages_ratelimited()

Am Sonntag, den 19.10.2014, 17:02 +0100 schrieb Anton Ivanov: > On 19/10/14 15:59, Thomas Meyer wrote: > > Am Dienstag, den 14.10.2014, 08:31 +0100 schrieb Anton Ivanov: > >> I see a very similar stall on writeout to ubd with my patches (easy) and > >> without (diff

Re: [uml-devel] kernel stalls in balance_dirty_pages_ratelimited()

irty" should be a unsigned long. Two's complement of above value is 332... I'm not sure what's going on here... any ideas? > > A. > > > On 14/10/14 08:21, Thomas Meyer wrote: > > Am Dienstag, den 14.10.2014, 07:43 +0100 schrieb Anton Ivanov: > >> On 14

[UM] Long loop in __getnsdayoftime() after resume from ram

Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), when I left the host kernel suspended to ram for a few hours and resume again. this is because it seems like the tk->xtime_sec wasn't updated yet, but the nsecs

[UM] Long loop in __getnsdayoftime() after resume from ram

Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), when I left the host kernel suspended to ram for a few hours and resume again. this is because it seems like the tk-xtime_sec wasn't updated yet, but the nsecs

Re: [uml-devel] kernel stalls in balance_dirty_pages_ratelimited()

of above value is 332... I'm not sure what's going on here... any ideas? A. On 14/10/14 08:21, Thomas Meyer wrote: Am Dienstag, den 14.10.2014, 07:43 +0100 schrieb Anton Ivanov: On 14/10/14 06:38, Anton Ivanov wrote: How does the stall manifest itself? Do you have the journal thread

Re: [uml-devel] kernel stalls in balance_dirty_pages_ratelimited()

Am Sonntag, den 19.10.2014, 17:02 +0100 schrieb Anton Ivanov: On 19/10/14 15:59, Thomas Meyer wrote: Am Dienstag, den 14.10.2014, 08:31 +0100 schrieb Anton Ivanov: I see a very similar stall on writeout to ubd with my patches (easy) and without (difficult - takes running an IO soak

[PATCH] x86, spinlock: Include threads.h

NR_CPUS is used, but not included. Fix this. Signed-off-by: Thomas Meyer --- diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 54f1c80..db586f0 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -3,6 +3,7 @@ #include

[PATCH] x86, spinlock: Include threads.h

NR_CPUS is used, but not included. Fix this. Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 54f1c80..db586f0 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -3,6 +3,7

Re: [UML] 3.16 build without optimization fails

Yes, it's still there. Am 19.08.2014 22:26 schrieb Richard Weinberger : > > On Tue, Aug 19, 2014 at 10:19 PM, Thomas Meyer wrote: > > Hi. > > > > Thanks for your answer. > > > > There goes my plan to better understand an UML kernel lock up by usin

Re: [UML] 3.16 build without optimization fails

...@vt.edu: > > On Tue, 19 Aug 2014 21:12:10 +0200, Thomas Meyer said: > > > Hi, > > > > > > the build with -O0 fails with: > > > > bug or feature? > > > > > > any ideas? > > Feature.  The kernel is *known* to not build wi

[UML] 3.16 build without optimization fails

> Hi, > > the build with -O0 fails with: > > make -f scripts/Makefile.build obj=init > gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem > /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include -I./arch/um/include > -Iarch/um/include/generated -Iinclude -I./arch/um/include/uapi >

[UML] 3.16 build without optimization fails

Hi, the build with -O0 fails with: make -f scripts/Makefile.build obj=init gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include -I./arch/um/include -Iarch/um/include/generated -Iinclude -I./arch/um/include/uapi

Re: [UML] 3.16 build without optimization fails

...@vt.edu: On Tue, 19 Aug 2014 21:12:10 +0200, Thomas Meyer said: Hi, the build with -O0 fails with: bug or feature? any ideas? Feature.  The kernel is *known* to not build with -O0, because that disables *all* function inlining, and there's several functions that *have

Re: [UML] 3.16 build without optimization fails

Yes, it's still there. Am 19.08.2014 22:26 schrieb Richard Weinberger richard.weinber...@gmail.com: On Tue, Aug 19, 2014 at 10:19 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi. Thanks for your answer. There goes my plan to better understand an UML kernel lock up by using

Re: [Intel-gfx] Linux 3.16-rc2

Am Montag, den 30.06.2014, 11:09 +0100 schrieb Chris Wilson: > On Mon, Jun 30, 2014 at 12:02:20PM +0200, Pavel Machek wrote: > > On Tue 2014-06-24 13:27:37, Chris Wilson wrote: > > > On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote: > > > > Am Diensta

Re: [Intel-gfx] Linux 3.16-rc2

Am Montag, den 30.06.2014, 11:09 +0100 schrieb Chris Wilson: On Mon, Jun 30, 2014 at 12:02:20PM +0200, Pavel Machek wrote: On Tue 2014-06-24 13:27:37, Chris Wilson wrote: On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote: Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris

Re: [Intel-gfx] Linux 3.16-rc2

Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson: > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote: > > On Tue, 24 Jun 2014, Thomas Meyer wrote: > > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the > > > X serve

Re: [Intel-gfx] Linux 3.16-rc2

Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson: On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote: On Tue, 24 Jun 2014, Thomas Meyer tho...@m3y3r.de wrote: the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the X server. This is not new

Re: Linux 3.16-rc2

Am Samstag, den 21.06.2014, 19:22 -1000 schrieb Linus Torvalds: > It's a day early, but tomorrow ends up being inconvenient for me due > to being on the road most of the day, so here you are. These days most > people send me their pull requests and patches during the week, so > it's not like I

Re: Linux 3.16-rc2

Am Samstag, den 21.06.2014, 19:22 -1000 schrieb Linus Torvalds: It's a day early, but tomorrow ends up being inconvenient for me due to being on the road most of the day, so here you are. These days most people send me their pull requests and patches during the week, so it's not like I expect

Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

Am Montag, den 19.05.2014, 09:07 +0200 schrieb Daniel Vetter: > On Sun, May 18, 2014 at 08:13:38PM +0100, Chris Wilson wrote: > > On Sun, May 18, 2014 at 09:08:40PM +0200, Thomas Meyer wrote: > > > Am Montag, den 12.05.2014, 07:33 +0100 schrieb Chris Wilson: > > > >

Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

Am Montag, den 19.05.2014, 09:07 +0200 schrieb Daniel Vetter: On Sun, May 18, 2014 at 08:13:38PM +0100, Chris Wilson wrote: On Sun, May 18, 2014 at 09:08:40PM +0200, Thomas Meyer wrote: Am Montag, den 12.05.2014, 07:33 +0100 schrieb Chris Wilson: On Sun, May 11, 2014 at 07:40:57PM +0200

Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

Am Montag, den 12.05.2014, 07:33 +0100 schrieb Chris Wilson: > On Sun, May 11, 2014 at 07:40:57PM +0200, Daniel Vetter wrote: > > On Sun, May 11, 2014 at 11:02 AM, Dave Airlie wrote: > > > On 11 May 2014 18:28, Thomas Meyer wrote: > > >> Hi, > > >> &g

Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

Am Montag, den 12.05.2014, 07:33 +0100 schrieb Chris Wilson: On Sun, May 11, 2014 at 07:40:57PM +0200, Daniel Vetter wrote: On Sun, May 11, 2014 at 11:02 AM, Dave Airlie airl...@gmail.com wrote: On 11 May 2014 18:28, Thomas Meyer tho...@m3y3r.de wrote: Hi, 3.14.3 works as expected

Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

11:02 AM, Dave Airlie wrote: > > >> On 11 May 2014 18:28, Thomas Meyer wrote: > > >>> Hi, > > >>> > > >>> 3.14.3 works as expected. > > >>> 3.15-rc5 shows a strange behaviour: When resuming from ram the X server > > &

Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

, 2014 at 11:02 AM, Dave Airlie airl...@gmail.com wrote: On 11 May 2014 18:28, Thomas Meyer tho...@m3y3r.de wrote: Hi, 3.14.3 works as expected. 3.15-rc5 shows a strange behaviour: When resuming from ram the X server seems to be disfunctional. I see this WARNING

3.15-rc5: Regression in i915 driver?

Hi, 3.14.3 works as expected. 3.15-rc5 shows a strange behaviour: When resuming from ram the X server seems to be disfunctional. I see this WARNING in the kernel log before suspend to ram in the early boot process: - Fresh boot 3.15-rc5: Mai 10 15:24:43 localhost.localdomain kernel: [drm]

3.15-rc5: Regression in i915 driver?

Hi, 3.14.3 works as expected. 3.15-rc5 shows a strange behaviour: When resuming from ram the X server seems to be disfunctional. I see this WARNING in the kernel log before suspend to ram in the early boot process: - Fresh boot 3.15-rc5: Mai 10 15:24:43 localhost.localdomain kernel: [drm]

Re: [i915] BUG: Bad page state in process Xorg

Am Samstag, den 30.11.2013, 08:55 -0500 schrieb Rob Clark: > On Sat, Nov 30, 2013 at 3:33 AM, Thomas Meyer wrote: > > Am Montag, den 25.11.2013, 08:23 -0500 schrieb Rob Clark: > >> oh, hmm.. are you importing buffers from i915? It looks like this part: > > > > M

Re: [i915] BUG: Bad page state in process Xorg

Am Samstag, den 30.11.2013, 08:55 -0500 schrieb Rob Clark: On Sat, Nov 30, 2013 at 3:33 AM, Thomas Meyer tho...@m3y3r.de wrote: Am Montag, den 25.11.2013, 08:23 -0500 schrieb Rob Clark: oh, hmm.. are you importing buffers from i915? It looks like this part: My computer has an i915

Re: [i915] BUG: Bad page state in process Xorg

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=5dc9e1e87229cb786a5bb58ddd0d60fee6eb4641 > > > > With kind regards > > Thomas > > > > Am 22.11.2013 17:18 schrieb Daniel Vetter : > >> > >> On Fri, Nov 22, 2013 at 4:54 PM, Tho

Re: [i915] BUG: Bad page state in process Xorg

=5dc9e1e87229cb786a5bb58ddd0d60fee6eb4641 With kind regards Thomas Am 22.11.2013 17:18 schrieb Daniel Vetter dan...@ffwll.ch: On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer tho...@m3y3r.de wrote: Am 22.11.2013 um 11:55 schrieb Daniel Vetter dan...@ffwll.ch: On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie airl

Re: [i915] BUG: Bad page state in process Xorg

> Am 22.11.2013 um 11:55 schrieb Chris Wilson : > >> On Wed, Nov 20, 2013 at 09:55:28PM +0100, Thomas Meyer wrote: >> Hi, >> >> I reported this bug a few days ago, but nobody did respond to my bug >> report: >> http://lkml.indiana.edu/hypermail/linux/

Re: [i915] BUG: Bad page state in process Xorg

> Am 22.11.2013 um 11:55 schrieb Daniel Vetter : > > On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie wrote: >>> Hi, >> >> cc'ing mailing list, >> >> Daniel any ideas? > > Nope, not really :( And no ideas how to triage this further - if it > takes 9 days to hit it eventually we'll have a real

Re: [i915] BUG: Bad page state in process Xorg

Am 22.11.2013 um 11:55 schrieb Daniel Vetter dan...@ffwll.ch: On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie airl...@linux.ie wrote: Hi, cc'ing mailing list, Daniel any ideas? Nope, not really :( And no ideas how to triage this further - if it takes 9 days to hit it eventually

Re: [i915] BUG: Bad page state in process Xorg

Am 22.11.2013 um 11:55 schrieb Chris Wilson ch...@chris-wilson.co.uk: On Wed, Nov 20, 2013 at 09:55:28PM +0100, Thomas Meyer wrote: Hi, I reported this bug a few days ago, but nobody did respond to my bug report: http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00058.html Every

[i915] BUG: Bad page state in process Xorg

Hi, I reported this bug a few days ago, but nobody did respond to my bug report: http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00058.html Every time I restart the X server I will run into this bug with 3.12.0. Help is welcome. [ 9913.719551] BUG: Bad page state in process Xorg

[i915] BUG: Bad page state in process Xorg

Hi, I reported this bug a few days ago, but nobody did respond to my bug report: http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00058.html Every time I restart the X server I will run into this bug with 3.12.0. Help is welcome. [ 9913.719551] BUG: Bad page state in process Xorg

915] BUG: Bad page state in process Xorg

Hi, After 9 days uptime, I wanted to restart my Gnome-Session, but this fails because Xorg is hitting a kernel bug. Xorg server isn't kill-able. I see these log entries: [126489.697509] CPU: 0 PID: 690 Comm: Xorg Tainted: GB3.12.0+ #95 [126489.697511] Hardware name: Acer Aspire

915] BUG: Bad page state in process Xorg

Hi, After 9 days uptime, I wanted to restart my Gnome-Session, but this fails because Xorg is hitting a kernel bug. Xorg server isn't kill-able. I see these log entries: [126489.697509] CPU: 0 PID: 690 Comm: Xorg Tainted: GB3.12.0+ #95 [126489.697511] Hardware name: Acer Aspire

Re: Copy on write hard links?

Am Mittwoch, den 25.09.2013, 08:59 -0500 schrieb Rob Landley: > On 09/24/2013 01:36:56 PM, Thomas Meyer wrote: > > Hi, > > > > Is there such a thing? > > In the kernel's vfs layer? Yes, that would be a nice feature! > No, although some filesystems

Re: Copy on write hard links?

Am Mittwoch, den 25.09.2013, 08:59 -0500 schrieb Rob Landley: On 09/24/2013 01:36:56 PM, Thomas Meyer wrote: Hi, Is there such a thing? In the kernel's vfs layer? Yes, that would be a nice feature! No, although some filesystems (ala btrfs) do things like that with snapshots

Copy on write hard links?

Hi, Is there such a thing? With kind regards Thomas -- 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/

Copy on write hard links?

Hi, Is there such a thing? With kind regards Thomas -- 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 0/10] Cocci spatch "noderef" - v3.11-7547-g44598f9

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Run against version v3.11-7547-g44598f9 Let me know when you as a maintainer are not interested in these kind of patches. I can exclude you by path; all cocci

[PATCH 1/10] MIPS: BCM47XX: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/arch/mips/bcm47xx/sprom.c b/arch/mips/bcm47xx/sprom.c --- a/arch/mips/bcm47xx/sprom.c +++ b/arch/mips/bcm47

[PATCH 1/10] MIPS: BCM47XX: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/arch/mips/bcm47xx/sprom.c b/arch/mips/bcm47xx/sprom.c --- a/arch/mips/bcm47xx/sprom.c +++ b/arch/mips

[PATCH 0/10] Cocci spatch noderef - v3.11-7547-g44598f9

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Run against version v3.11-7547-g44598f9 Let me know when you as a maintainer are not interested in these kind of patches. I can exclude you by path; all cocci findings

[PATCH 9/10] staging: r8188eu: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c --- a/drive

[PATCH 8/10] staging: r8188eu: Add files for new drive: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c --- a/drive

[PATCH 4/10] [SCSI] csiostor: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/scsi/csiostor/csio_mb.c b/drivers/scsi/csiostor/csio_mb.c --- a/drivers/scsi/csiostor/csio_mb.c +++

[PATCH 5/10] staging: lustre: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/staging/lustre/lustre/obdecho/echo_client.c b/drivers/staging/lustre/lustre/obdecho/echo_client.c ---

[PATCH 6/10] staging: octeon-usb: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/staging/octeon-usb/cvmx-usb.c b/drivers/staging/octeon-usb/cvmx-usb.c --- a/drivers/staging/octeo

[PATCH 2/2] [SCSI] aic7xxx: Cocci spatch "kzalloc-simple"

Use kzalloc rather than kmalloc followed by memset with 0. Found by coccinelle spatch "api/alloc/kzalloc-simple.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c --- a/drivers/scsi/aic7xxx/aic79xx_osm.c +++

[PATCH 0/2] Cocci spatch "kzalloc-simple" - v3.11-7547-g44598f9

Use kzalloc rather than kmalloc followed by memset with 0. Found by coccinelle spatch "api/alloc/kzalloc-simple.cocci" Run against version v3.11-7547-g44598f9 Let me know when you as a maintainer are not interested in these kind of patches. I can exclude you by path; all cocci findings in e.g.

[PATCH 7/10] staging: r8188eu: Add files for new drive: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/staging/rtl8188eu/core/rtw_mp.c b/drivers/staging/rtl8188eu/core/rtw_mp.c --- a/drivers/staging/rtl8

[PATCH 1/2] NVMe: Cocci spatch "kzalloc-simple"

Use kzalloc rather than kmalloc followed by memset with 0. Found by coccinelle spatch "api/alloc/kzalloc-simple.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/block/nvme-scsi.c b/drivers/block/nvme-scsi.c --- a/drivers/block/nvme-scsi.c +++ b/drivers/block/nvme-scsi.c

[PATCH 2/10] xtensa: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/arch/xtensa/platforms/iss/network.c b/arch/xtensa/platforms/iss/network.c --- a/arch/xtensa/platforms/iss

[PATCH 3/10] iio: at91_adc: Cocci spatch "noderef"

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch "misc/noderef.cocci" Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c --- a/drivers/iio/adc/at91_adc.c +++ b/drivers/iio/adc/

[PATCH 3/10] iio: at91_adc: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c --- a/drivers/iio/adc/at91_adc.c +++ b/drivers/iio

[PATCH 2/10] xtensa: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/arch/xtensa/platforms/iss/network.c b/arch/xtensa/platforms/iss/network.c --- a/arch/xtensa/platforms/iss

[PATCH 0/2] Cocci spatch kzalloc-simple - v3.11-7547-g44598f9

Use kzalloc rather than kmalloc followed by memset with 0. Found by coccinelle spatch api/alloc/kzalloc-simple.cocci Run against version v3.11-7547-g44598f9 Let me know when you as a maintainer are not interested in these kind of patches. I can exclude you by path; all cocci findings in e.g.

[PATCH 7/10] staging: r8188eu: Add files for new drive: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/staging/rtl8188eu/core/rtw_mp.c b/drivers/staging/rtl8188eu/core/rtw_mp.c --- a/drivers/staging

[PATCH 1/2] NVMe: Cocci spatch kzalloc-simple

Use kzalloc rather than kmalloc followed by memset with 0. Found by coccinelle spatch api/alloc/kzalloc-simple.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/block/nvme-scsi.c b/drivers/block/nvme-scsi.c --- a/drivers/block/nvme-scsi.c +++ b/drivers/block/nvme-scsi.c

[PATCH 9/10] staging: r8188eu: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c

[PATCH 8/10] staging: r8188eu: Add files for new drive: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c --- a/drivers

[PATCH 4/10] [SCSI] csiostor: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/scsi/csiostor/csio_mb.c b/drivers/scsi/csiostor/csio_mb.c --- a/drivers/scsi/csiostor/csio_mb.c

[PATCH 5/10] staging: lustre: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/staging/lustre/lustre/obdecho/echo_client.c b/drivers/staging/lustre/lustre/obdecho/echo_client.c

[PATCH 6/10] staging: octeon-usb: Cocci spatch noderef

sizeof when applied to a pointer typed expression gives the size of the pointer. Found by coccinelle spatch misc/noderef.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/staging/octeon-usb/cvmx-usb.c b/drivers/staging/octeon-usb/cvmx-usb.c --- a/drivers/staging/octeon

[PATCH 2/2] [SCSI] aic7xxx: Cocci spatch kzalloc-simple

Use kzalloc rather than kmalloc followed by memset with 0. Found by coccinelle spatch api/alloc/kzalloc-simple.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c --- a/drivers/scsi/aic7xxx/aic79xx_osm.c

3.10.10-rt7: inconsistent lock state (iwlwifi)

Hi, lockdep complains about this: [ 92.041513] iwlwifi :02:00.0: L1 Enabled; Disabling L0S [ 92.090910] iwlwifi :02:00.0: Radio type=0x1-0x2-0x0 [ 92.094779] = [ 92.094780] [ INFO: inconsistent lock state ] [ 92.094782] 3.10.10-rt7 #5 Not

[PATCH] drm/msm: Odd PTR_ERR usage

The variable priv->kms is not initialized yet. Found by "scripts/coccinelle/tests/odd_ptr_err.cocci". PTR_ERR should access the value just tested by IS_ERR. Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c --- a/driver

[PATCH] drm/msm: Odd PTR_ERR usage

The variable priv-kms is not initialized yet. Found by scripts/coccinelle/tests/odd_ptr_err.cocci. PTR_ERR should access the value just tested by IS_ERR. Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c --- a/drivers/gpu

3.10.10-rt7: inconsistent lock state (iwlwifi)

Hi, lockdep complains about this: [ 92.041513] iwlwifi :02:00.0: L1 Enabled; Disabling L0S [ 92.090910] iwlwifi :02:00.0: Radio type=0x1-0x2-0x0 [ 92.094779] = [ 92.094780] [ INFO: inconsistent lock state ] [ 92.094782] 3.10.10-rt7 #5 Not

i915_gem_unmap_dma_buf: BUG: unable to handle kernel NULL pointer dereference

[165517.046291] [drm] wait for urb interrupted: ffc2 available: 4 [165517.046454] BUG: unable to handle kernel NULL pointer dereference at 0941 [165517.047217] IP: [] i915_gem_unmap_dma_buf+0x2f/0x60 [i915] [165517.047217] PGD 0 [165517.047217] Oops: [#1] SMP

i915_gem_unmap_dma_buf: BUG: unable to handle kernel NULL pointer dereference

[165517.046291] [drm] wait for urb interrupted: ffc2 available: 4 [165517.046454] BUG: unable to handle kernel NULL pointer dereference at 0941 [165517.047217] IP: [a00ddfbf] i915_gem_unmap_dma_buf+0x2f/0x60 [i915] [165517.047217] PGD 0 [165517.047217] Oops: [#1] SMP

BUG in i915_gem_unmap_dma_buf?

Jul 08 23:37:33 localhost.localdomain kernel: BUG: unable to handle kernel paging request at 000113b10038 Jul 08 23:37:33 localhost.localdomain kernel: IP: [] i915_gem_unmap_dma_buf+0x2f/0x60 [i915] Jul 08 23:37:33 localhost.localdomain kernel: PGD 1135e0067 PUD 0 Jul 08 23:37:33

BUG in i915_gem_unmap_dma_buf?

Jul 08 23:37:33 localhost.localdomain kernel: BUG: unable to handle kernel paging request at 000113b10038 Jul 08 23:37:33 localhost.localdomain kernel: IP: [a00f1eaf] i915_gem_unmap_dma_buf+0x2f/0x60 [i915] Jul 08 23:37:33 localhost.localdomain kernel: PGD 1135e0067 PUD 0 Jul 08

[PATCH] NVMe: Cocci spatch "kzalloc-simple.spatch"

Use kzalloc rather than kmalloc followed by memset with 0. The coccinelle spatch that created this patch is available in the linux source tree at file://scripts/coccinelle/api/alloc/kzalloc-simple.cocci Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/block/nvme-scsi.c b/drivers/block/nvme

[PATCH] NVMe: Cocci spatch kzalloc-simple.spatch

Use kzalloc rather than kmalloc followed by memset with 0. The coccinelle spatch that created this patch is available in the linux source tree at file://scripts/coccinelle/api/alloc/kzalloc-simple.cocci Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -u -p a/drivers/block/nvme-scsi.c b

[PATCH] usb: dwc3: core: Cocci spatch "odd_ptr_err.spatch"

Signed-off-by: Thomas Meyer --- diff -u -p a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -450,7 +450,7 @@ static int dwc3_probe(struct platform_de } if (IS_ERR(dwc->usb3_phy)) { - ret = PTR_

<    1   2   3   4   5   6   7   >