* Re: pvops Dom0 graphics doesnt work with Intel i915
From: sanjay kushwaha @ 2010-10-07 19:12 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Jeremy Fitzhardinge, xen-devel
In-Reply-To: <20101007180518.GA11383@dumpdata.com>
[-- Attachment #1.1: Type: text/plain, Size: 10805 bytes --]
Hi Konrad,
Unfortunately T410 doesnt have a serial port and neither does the docking
station. I havent had any success with USB-to-Serial port dongles in the
past. is there any way to get the serial port output?
Thanks,
Sanjay
On Thu, Oct 7, 2010 at 11:05 AM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:
> On Thu, Oct 07, 2010 at 10:36:34AM -0700, sanjay kushwaha wrote:
> > Hi Konrad,
> > I tried your tree. It created a 2.6.32.15 based pvops kernel but graphics
> > with VT-d still doesn't work. when I give iommu=0 on xen kernel command
> line
> > in grub menu, graphics works but with iommu=1 it doesnt work (The whole
> > screen is garbage).
>
> Are there any warnings/debug messages in the serial log? Please follow
> the PVOPS Wiki on how to enable all the debug options.
> >
> >
> > On Wed, Oct 6, 2010 at 6:07 PM, Konrad Rzeszutek Wilk <
> > konrad.wilk@oracle.com> wrote:
> >
> > > On Wed, Oct 06, 2010 at 04:02:51PM -0700, sanjay kushwaha wrote:
> > > > Thanks Pasi.
> > > >
> > > > Hi Konrad,
> > > > Could you please let me know how to get these backported drivers as
> > > > indicated by Pasi? This is the tree that I have.
> > >
> > > Just follow the Wiki. Oh, I need to update it.
> > >
> > > Here do this:
> > >
> > > git remote add konrad git://
> > > git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > >
> > > git pull konrad
> > > git checkout konrad/devel/next.drm
> > >
> > > make
> > >
> > > >
> > > > [evans@vwifi0 linux-2.6.32.x]$ git show
> > > > commit b297cdac0373625d3cd0e6f2b393570dcf2edba6
> > > > Merge: c6cfd01 64392f6
> > > > Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > > > Date: Mon Sep 13 14:27:24 2010 -0700
> > > >
> > > > Merge branch 'xen/next' into xen/next-2.6.32
> > > >
> > > > * xen/next:
> > > > xen/netfront: Fix another potential race condition
> > > > Revert "xen/netfront: default smartpoll to on"
> > > >
> > > > [evans@vwifi0 linux-2.6.32.x]$
> > > >
> > > >
> > > > Thanks,
> > > > Sanjay
> > > >
> > > > On Wed, Oct 6, 2010 at 1:12 PM, Pasi Kärkkäinen <pasik@iki.fi>
> wrote:
> > > >
> > > > > On Wed, Oct 06, 2010 at 10:50:57AM -0700, sanjay kushwaha wrote:
> > > > > > Hi,
> > > > > > I have run into more problems now. This time with VT-d.
> > > > > > When I enable VT-d on this laptop, graphics again stops
> working in
> > > > > dom0
> > > > > > with pvops (linux 2.6.32.21). the screen starts showing
> garbage as
> > > > > soon as
> > > > > > it switches into graphics mode.this happens when I boot the
> pvops
> > > > > kernel
> > > > > > both as dom0 and native linux. However, when I try 2.6.33
> based
> > > pvops
> > > > > > kernel (stable-2.6.33.x) graphics seems to work fine with VT-d
> > > when
> > > > > > running native but it doesnt work when running as Dom0.
> > > > > >
> > > > > > so now the problem is:
> > > > > >
> > > > > > with stable-2.6.32.x: graphics works in Dom0 without Vt-d but
> not
> > > with
> > > > > > VT-d (neither native nor Dom0).
> > > > > > with stable-2.6.33.x: graphics works with VT-d when running
> native
> > > but
> > > > > > doesnt work when running as Dom0 (with or without VT-d).
> > > > > >
> > > > >
> > > > > stable-2.6.33.x is not maintained, and you shouldn't use it.
> > > > >
> > > > > I think Konrad has a backport of the 2.6.34 drm/dri drivers
> > > > > to stable-2.6.32.x somewhere.. that might help.
> > > > >
> > > > > http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> > > > >
> > > > > -- Pasi
> > > > >
> > > > > > I am experiencing this problem both with Lenovo T410, and Dell
> > > > > latitude
> > > > > > E6410.
> > > > > > Has anybody experienced this problem?
> > > > > >
> > > > > > Thanks,
> > > > > > Sanjay
> > > > > >
> > > > > > On Fri, Oct 1, 2010 at 11:06 AM, sanjay kushwaha
> > > > > > <[1]sanjay.kushwaha@gmail.com> wrote:
> > > > > >
> > > > > > havent tried stable-2.6.32.x on Radeon. It works with
> nomodeset
> > > and
> > > > > > nopat options with stable-2.6.33.x branch.
> > > > > >
> > > > > > On Fri, Oct 1, 2010 at 10:57 AM, Konrad Rzeszutek Wilk
> > > > > > <[2]konrad.wilk@oracle.com> wrote:
> > > > > >
> > > > > > On Fri, Oct 01, 2010 at 10:06:48AM -0700, sanjay kushwaha
> > > wrote:
> > > > > > > When I dont use nomodeset option, dom0 boots fine X runs
> > > > > properly.
> > > > > > So Fedora
> > > > > > > 13 (X86_64) distro with stable-2.6.32.x pvops kernel and
> > > > > > xen-unstable works
> > > > > > > fine for i915 without nomodeset option.
> > > > > >
> > > > > > Good to hear it works for you.
> > > > > >
> > > > > > What about your radeon laptop?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Sanjay
> > > > > > >
> > > > > > > On Wed, Sep 29, 2010 at 3:56 PM, sanjay kushwaha
> > > > > > > <[3]sanjay.kushwaha@gmail.com>wrote:
> > > > > > >
> > > > > > > > Hi Jeremy,
> > > > > > > > I switched to stable-2.6.32.x branch (which is
> 2.6.32.21
> > > > > based)
> > > > > > but I get
> > > > > > > > the same problem. Attached is the Xorg.0.log file when
> I
> > > > > booted
> > > > > > with
> > > > > > > > nomodeset option.
> > > > > > > >
> > > > > > > > interestingly I did not see any kernel or driver crash
> > > > > messages in
> > > > > > the
> > > > > > > > dmesg output. I do see these messages multiple times
> in
> > > > > > /var/log/messages
> > > > > > > > *
> > > > > > > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > > GdmDisplay:
> > > > > > display
> > > > > > > > lasted 0.048984 seconds
> > > > > > > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > > > > > GdmLocalDisplayFactory:
> > > > > > > > maximum number of X display failures reached: check X
> > > server
> > > > > log
> > > > > > for errors
> > > > > > > > *
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Sanjay
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Sep 29, 2010 at 11:57 AM, Jeremy Fitzhardinge
> > > > > > <[4]jeremy@goop.org>wrote:
> > > > > > > >
> > > > > > > >> On 09/29/2010 11:12 AM, sanjay kushwaha wrote:
> > > > > > > >> > Hi Folks,
> > > > > > > >> > I am trying to boot latest xen-unstable on my
> laptop
> > > which
> > > > > has
> > > > > > Intel
> > > > > > > >> > i915 graphics. PVOPS dom0 is 2.6.33.6 based (from
> > > branch
> > > > > > > >> > xen/stable-2.6.33.x)
> > > > > > > >>
> > > > > > > >> Don't use that branch; it isn't supported (in fact, I
> > > deleted
> > > > > it
> > > > > > a while
> > > > > > > >> ago). Use xen/stable-2.6.32.x for now.
> > > > > > > >>
> > > > > > > >> J
> > > > > > > >>
> > > > > > > >> > and the distro is fedora 13 64-bit. The graphics
> doesnt
> > > > > come up
> > > > > > and it
> > > > > > > >> > seems that i915 driver is crashing multiple times.
> If I
> > > > > boot in
> > > > > > > >> > run-level 3 (without X) dom0 boots fine.
> > > > > > > >> > I tried booting the dom0 kernel with nomodeset and
> > > nopat
> > > > > > options
> > > > > > > >> > without any success. I searched on internet and
> found
> > > that
> > > > > > multiple
> > > > > > > >> > people have reported similar problem but I could
> not
> > > find
> > > > > any
> > > > > > solution.
> > > > > > > >> >
> > > > > > > >> > Has anybody found a solution or workaround to this
> > > problem?
> > > > > > > >> >
> > > > > > > >> > Thanks,
> > > > > > > >> > Sanjay
> > > > > > > >> >
> > > > > > > >> > PS: I have another laptop with same version of xen
> and
> > > > > pvops
> > > > > > dom0 but
> > > > > > > >> > it has ATI radeon graphics card. This laptop boots
> dom0
> > > > > with
> > > > > > graphics
> > > > > > > >> > when I give nomodeset and nopat options (but fails
> if I
> > > > > dont
> > > > > > give
> > > > > > > >> > either of those two options).
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > _______________________________________________
> > > > > > > >> > Xen-devel mailing list
> > > > > > > >> > [5]Xen-devel@lists.xensource.com
> > > > > > > >> > [6]http://lists.xensource.com/xen-devel
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > >
> > > > > > > _______________________________________________
> > > > > > > Xen-devel mailing list
> > > > > > > [7]Xen-devel@lists.xensource.com
> > > > > > > [8]http://lists.xensource.com/xen-devel
> > > > > >
> > > > > > --
> > > > > > ----------------------
> > > > > > Dr. Sanjay Kumar
> > > > > > Research Scientist
> > > > > > Intel Corporation
> > > > > >
> > > > > > --
> > > > > > ----------------------
> > > > > > Dr. Sanjay Kumar
> > > > > > Research Scientist
> > > > > > Intel Corporation
> > > > > >
> > > > > > References
> > > > > >
> > > > > > Visible links
> > > > > > 1. mailto:sanjay.kushwaha@gmail.com
> > > > > > 2. mailto:konrad.wilk@oracle.com
> > > > > > 3. mailto:sanjay.kushwaha@gmail.com
> > > > > > 4. mailto:jeremy@goop.org
> > > > > > 5. mailto:Xen-devel@lists.xensource.com
> > > > > > 6. http://lists.xensource.com/xen-devel
> > > > > > 7. mailto:Xen-devel@lists.xensource.com
> > > > > > 8. http://lists.xensource.com/xen-devel
> > > > >
> > > > > > _______________________________________________
> > > > > > Xen-devel mailing list
> > > > > > Xen-devel@lists.xensource.com
> > > > > > http://lists.xensource.com/xen-devel
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ----------------------
> > > > Dr. Sanjay Kumar
> > > > Research Scientist
> > > > Intel Corporation
> > >
> >
> >
> >
> > --
> > ----------------------
> > Dr. Sanjay Kumar
> > Research Scientist
> > Intel Corporation
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>
--
----------------------
Dr. Sanjay Kumar
Research Scientist
Intel Corporation
[-- Attachment #1.2: Type: text/html, Size: 16917 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [Qemu-devel] Re: [PATCH] configure: Send error message from spice check to /dev/null
From: Stefan Weil @ 2010-10-07 19:11 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: QEMU Developers
In-Reply-To: <4CAE1A0D.7000704@redhat.com>
Am 07.10.2010 21:05, schrieb Gerd Hoffmann:
> On 10/07/10 17:58, Stefan Weil wrote:
>> pkg-config is not always available (e.g. on win32 hosts),
>> but we don't want to see the 'command not found' error message.
>
>> compile_object() {
>> + echo>>config.log
>> + cat $TMPC>>config.log
>> + echo>>config.log
>
> This looks unrelated.
Ups, that was the wrong patch (some test code).
Sorry - I'll fix that immediately.
Thanks for your feedback.
>
>> @@ -28,6 +31,9 @@ compile_object() {
>> compile_prog() {
>> local_cflags="$1"
>> local_ldflags="$2"
>> + echo>>config.log
>> + cat $TMPC>>config.log
>> + echo>>config.log
>
> This too.
>
>> spice_cflags=$($pkgconfig --cflags spice-protocol spice-server
>> 2>/dev/null)
>> spice_libs=$($pkgconfig --libs spice-protocol spice-server
>> 2>/dev/null)
>> - if $pkgconfig --atleast-version=0.5.3 spice-server&&\
>> + if $pkgconfig --atleast-version=0.5.3 spice-server>/dev/null
>> 2>&1&& \
>
> Fine with me, the other pkgconfig calls are covered already, the third
> missing is just an oversight and the fix is ObliviouslyCorrect[tm].
>
> cheers,
> Gerd
>
>
^ permalink raw reply
* Re: [PATCH] iovmm: IVA2 MMU range is from 0x11000000 to 0xFFFFFFFF
From: Hiroshi DOYU @ 2010-10-07 19:14 UTC (permalink / raw)
To: x0095840
Cc: felipe.contreras, ameya.palande, david.cohen, linux-kernel,
andy.shevchenko, linux-omap
In-Reply-To: <1286477021-23169-1-git-send-email-x0095840@ti.com>
From: ext Fernando Guzman Lugo <x0095840@ti.com>
Subject: [PATCH] iovmm: IVA2 MMU range is from 0x11000000 to 0xFFFFFFFF
Date: Thu, 7 Oct 2010 20:43:41 +0200
> IV2 MMU capable addresses start from 0x11000000
Wouldn't it be better to add an general API to configure the valid
'da' range in advance?
I don't think that it's a good idea to introduce the iommu
instance("iva2:iommu") specific code here.
^ permalink raw reply
* [Qemu-devel] Re: [PATCH] configure: Send error message from spice check to /dev/null
From: Gerd Hoffmann @ 2010-10-07 19:05 UTC (permalink / raw)
To: Stefan Weil; +Cc: QEMU Developers
In-Reply-To: <1286467084-5110-1-git-send-email-weil@mail.berlios.de>
On 10/07/10 17:58, Stefan Weil wrote:
> pkg-config is not always available (e.g. on win32 hosts),
> but we don't want to see the 'command not found' error message.
> compile_object() {
> + echo>>config.log
> + cat $TMPC>>config.log
> + echo>>config.log
This looks unrelated.
> @@ -28,6 +31,9 @@ compile_object() {
> compile_prog() {
> local_cflags="$1"
> local_ldflags="$2"
> + echo>>config.log
> + cat $TMPC>>config.log
> + echo>>config.log
This too.
> spice_cflags=$($pkgconfig --cflags spice-protocol spice-server 2>/dev/null)
> spice_libs=$($pkgconfig --libs spice-protocol spice-server 2>/dev/null)
> - if $pkgconfig --atleast-version=0.5.3 spice-server&&\
> + if $pkgconfig --atleast-version=0.5.3 spice-server>/dev/null 2>&1&& \
Fine with me, the other pkgconfig calls are covered already, the third
missing is just an oversight and the fix is ObliviouslyCorrect[tm].
cheers,
Gerd
^ permalink raw reply
* Re: memory clobber in rx path, maybe related to ath9k.
From: Ben Greear @ 2010-10-07 19:14 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <4CAE1553.1070900@candelatech.com>
On 10/07/2010 11:45 AM, Ben Greear wrote:
> On 10/07/2010 11:42 AM, Luis R. Rodriguez wrote:
>> On Thu, Oct 7, 2010 at 11:39 AM, Ben Greear<greearb@candelatech.com>
>> wrote:
>>> On 10/07/2010 11:29 AM, Luis R. Rodriguez wrote:
>>>>
>>>> On Thu, Oct 7, 2010 at 11:14 AM, Johannes Berg
>>>> <johannes@sipsolutions.net> wrote:
>>>>>
>>>>> On Thu, 2010-10-07 at 10:33 -0700, Ben Greear wrote:
>>>>>>
>>>>>> In case it helps, here is a dump of where the corrupted SKB was
>>>>>> deleted.
>>>>>
>>>>> I wonder, do you have a machine with a decent IOMMU? Adding IOMMU
>>>>> debugging into the mix could help you figure out if it's a DMA
>>>>> problem.
>>>>
>>>> Ben, how much traffic are you RX'ing on these virtual interfaces?
>>>
>>> I disabled my user-space application, and this script alone can
>>> reproduce
>>> the problem fairly quickly on my system. You will need to change some
>>> of those first variables. Just start it and wait a few minutes and
>>> watch the splats show on the console :)
>>>
>>> Note that I am not generating any traffic, but the wpa_supplicants are
>>> doing their thing of course...
>>>
>>> I'm using the kernel found here:
>>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux.wireless-testing.ct/.git;a=summary
>>>
>>>
>>> It's latest wireless-testing with some of my own patches, and some
>>> I've gathered from here an there. I doubt I'm causing this problem,
>>> but if you can't reproduce it with this script on your kernels,
>>> I can try with base wireless-testing or whatever you are using.
>>
>> I'll run this now, but can you try a vanilla wireless-testing? I hear
>> the latest wireless-testing is borked so maybe try (git reset --hard
>> master-2010-09-29), its what I'm on.
>
> You are liable to hit a bunch of those crashes I've been reporting
> before you hit the DMA thing if you don't use latest (with Johanne's scan
> locking patch).
>
> I'm going to poke at IOMMU debugging and see what I find.
>
> I'll start a compile of vanilla wireless-testing + scan fix as well.
Well, vanilla + scan patch locked pretty hard when I started the script.
I was able to get sysrq to dump the locks, but it didn't seem to complete
that and couldn't even dump more sysrq info after that.
Might be something entirely different, of course, and no idea if
this lock dump shows any real problem.
Oct 7 12:08:43 localhost kernel: SysRq : Show Locks Held
Oct 7 12:08:43 localhost kernel:
Oct 7 12:08:43 localhost kernel: Showing all locks held in the system:
Oct 7 12:08:43 localhost kernel: 3 locks held by kworker/0:0/4:
Oct 7 12:08:43 localhost kernel: #0: (events){+.+.+.}, at: [<c0443cea>] process_one_work+0x145/0x295
Oct 7 12:08:43 localhost kernel: #1: ((linkwatch_work).work){+.+.+.}, at: [<c0443cea>] process_one_work+0x145/0x295
Oct 7 12:08:43 localhost kernel: #2: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 3 locks held by kworker/u:1/38:
Oct 7 12:08:43 localhost kernel: #0: ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<c0443cea>] process_one_work+0x145/0x295
Oct 7 12:08:43 localhost kernel: #1: ((&sta->ampdu_mlme.work)){+.+...}, at: [<c0443cea>] process_one_work+0x145/0x295
Oct 7 12:08:43 localhost kernel: #2: (&sta->ampdu_mlme.mtx){+.+...}, at: [<f8887180>] ieee80211_ba_session_work+0x52/0xbe [mac80211]
Oct 7 12:08:43 localhost kernel: 1 lock held by mingetty/1584:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by mingetty/1586:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by mingetty/1589:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by mingetty/1593:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by mingetty/1596:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by mingetty/1598:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by bash/1683:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by bash/1728:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by bash/1752:
Oct 7 12:08:43 localhost kernel: #0: (&tty->atomic_read_lock){+.+...}, at: [<c05f5e91>] n_tty_read+0x1d1/0x5ed
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2840:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2842:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2844:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2846:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2848:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2850:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2852:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2854:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
Oct 7 12:08:43 localhost kernel: 1 lock held by wpa_supplicant/2856:
Oct 7 12:08:43 localhost kernel: #0: (rtnl_mutex){+.+.+.}, at: [<c06da190>] rtnl_lock+0xf/0x11
OcSysRq : Show State
Process wpa_supplicant (pid: 2904, ti=f3946000 task=f4124a60 task.ti=f3946000)
Stack:
Call Trace:
Code: 73 18 8b 75 08 01 73 14 88 4c 02 1c 5b 5e 5d c3 55 89 e5 57 56 53 8b 5d 08 6b 72 04 3c ff 84 30 70 11 00 00 8b 79 10 6b 72 04 3c <8b> 7f 50 01 bc 30
SysRq : Show Locks Held
Process wpa_supplicant (pid: 2904, ti=f3946000 task=f4124a60 task.ti=f3946000)
Stack:
Call Trace:
Code: 73 18 8b 75 08 01 73 14 88 4c 02 1c 5b 5e 5d c3 55 89 e5 57 56 53 8b 5d 08 6b 72 04 3c ff 84 30 70 11 00 00 8b 79 10 6b 72 04 3c <8b> 7f 50 01 bc 30
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 10/11] ppc: avoid write only variables
From: Blue Swirl @ 2010-10-07 18:59 UTC (permalink / raw)
To: Alexander Graf; +Cc: qemu-devel
In-Reply-To: <F8695B94-598B-4794-8257-BF0B6059104B@suse.de>
On Wed, Oct 6, 2010 at 9:39 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 06.10.2010, at 23:34, Blue Swirl wrote:
>
>> Compiling with GCC 4.6.0 20100925 produced warnings:
>> /src/qemu/target-ppc/op_helper.c: In function 'helper_icbi':
>> /src/qemu/target-ppc/op_helper.c:351:14: error: variable 'tmp' set but
>> not used [-Werror=unused-but-set-variable]
>> /src/qemu/target-ppc/op_helper.c: In function 'do_6xx_tlb':
>> /src/qemu/target-ppc/op_helper.c:3805:28: error: variable 'EPN' set
>> but not used [-Werror=unused-but-set-variable]
>> /src/qemu/target-ppc/op_helper.c: In function 'do_74xx_tlb':
>> /src/qemu/target-ppc/op_helper.c:3838:28: error: variable 'EPN' set
>> but not used [-Werror=unused-but-set-variable]
>>
>> Fix by making the variable declarations and their uses also conditional
>> to debug definition. Delete tmp.
>
> Maybe it would make more sense to get those LOG_* macros into static inline functions. But for the issue at hand, the solution looks good to me.
Perhaps all conditionally enabled debug printf stuff should be
transformed into tracepoints? That would be more flexible than
uncommenting DEBUG_foobar. Would it help with bitrot too?
> Signed-off-by: Alexander Graf <agraf@suse.de>
Thanks.
^ permalink raw reply
* [Qemu-devel] [PATCH v2] configure: Send error message from spice check to /dev/null
From: Stefan Weil @ 2010-10-07 19:15 UTC (permalink / raw)
To: QEMU Developers; +Cc: Gerd Hoffmann
In-Reply-To: <4CAE1A0D.7000704@redhat.com>
pkg-config is not always available (e.g. on win32 hosts),
but we don't want to see the 'command not found' error message.
Redirect stdout and stderr to /dev/null.
v2:
* Removed changes which should not have been here.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
configure | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index e67d076..cc19d82 100755
--- a/configure
+++ b/configure
@@ -2089,7 +2089,7 @@ int main(void) { spice_server_new(); return 0; }
EOF
spice_cflags=$($pkgconfig --cflags spice-protocol spice-server 2>/dev/null)
spice_libs=$($pkgconfig --libs spice-protocol spice-server 2>/dev/null)
- if $pkgconfig --atleast-version=0.5.3 spice-server &&\
+ if $pkgconfig --atleast-version=0.5.3 spice-server >/dev/null 2>&1 && \
compile_prog "$spice_cflags" "$spice_libs" ; then
spice="yes"
libs_softmmu="$libs_softmmu $spice_libs"
--
1.7.1
^ permalink raw reply related
* Re: Error message on RV710: reserve failed for wait
From: Jerome Glisse @ 2010-10-07 18:32 UTC (permalink / raw)
To: Jean Delvare; +Cc: dri-devel
In-Reply-To: <20101007172305.271620e7@endymion.delvare>
----- "Jean Delvare" <khali@linux-fr.org> wrote:
> Hi again,
>
> On Thu, 30 Sep 2010 15:18:27 +0200, Jean Delvare wrote:
> > I am running kernel 2.6.36-rc6 on a Radeon HD4350 (RV710), and I
> see
> > the following error messages in the logs:
> >
> > Sep 30 14:09:27 endymion kernel: [21556.560593] radeon 0000:07:00.0:
> ffff88007c334000 reserve failed for wait
> > Sep 30 14:09:29 endymion kernel: [21558.253859] radeon 0000:07:00.0:
> ffff88007c334000 reserve failed for wait
> >
> > Sometimes that's just one or two of these, sometimes a bunch of
> them. I
> > didn't notice any major problem so far. What kind of issue may
> result
> > from this error? I see the message comes from function
> radeon_bo_wait()
> > but I have no idea what this function does.
>
> Problem still present in 2.6.36-rc7. I have investigated it myself,
> and
> here's what I found.
>
> The error code returned by ttm_bo_reserve() to radeon_bo_wait() when
> I
> get this error message is EBUSY. This can only happen when
> ttm_bo_reserve() isn't allowed to wait (no_wait=true). The only
> caller
> passing no_wait=true is radeon_gem_busy_ioctl(). So, as a summary, I
> see an error message in the kernel log whenever
> radeon_gem_busy_ioctl()
> tries to process some ioctl but can't get access to some kernel data
> it
> needs. Sorry for being vague here but I'm not familiar with the code
> at
> all, so that's the best I can say.
>
> I don't know who exactly is calling radeon_gem_busy_ioctl(), as it
> can
> only be reached through a function pointer. I presume this is the X11
> radeon driver, in user-space?
>
> Jerome, you wrote that part of the code, maybe you could suggest a
> course of action? Is it OK for the radeon kernel driver to return
> -EBUSY to user-space in that case? If it is OK, then the error
> message
> shouldn't be printed, or maybe it should be degraded to a debugging
> message. If it isn't OK, what can be done to avoid it?
>
> Thanks,
> --
> Jean Delvare
Your analyze is correct we should not print the error message.
I let you do a patch to remove the error message. Thanks for
looking into this.
Cheers,
Jerome
^ permalink raw reply
* [RFC] tidspbridge: use a parameter to allocate shared memory
From: Omar Ramirez Luna @ 2010-10-07 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim8H0ibSucP3Nq=q19t0QY0pvijim1kOZSbygY1@mail.gmail.com>
On 10/7/2010 1:22 PM, Felipe Contreras wrote:
...
>
> Note that the "shared memory" described in the document you share has
> nothing to do with the SHM pool. AFAIK that memory is used for other
> things, like MMU PTEs, and storing the base image and socket-nodes,
> thus it needs to be contiguous.
hmmm, no. it is the same memory. i.e.: we propagate the current opp
through the shared memory so the dsp can read it if it went to sleep,
with the proper offset you can read that variable starting from the
mempool base address.
"storing the base image and socket-nodes" symbols is also donde in the
shared memory but this is done in different sections of the SHM.
>
> Right now allocating contiguous memory can only be done with memblock
> (bootmem), but in the future it could be done with CMA/VCMM. But the
> cacheability is a separate issue.
yes
>
> I don't see any problem flushing the SHM area when needed, which
> probably has performance implications when mmaping/unmapping buffers,
> at which point you need to flush bigger memory areas anyway, so that's
> not an issue.
well, you would have to flush when loading the base image, or allocating
a socket node, but also minor flushes for opp propagation, SHM messages
to DSP, chnl params, those are the ones I can quickly think of.
>
> Anyway, we will not know for sure until we try... Right?
yes we can try, at least we now for sure arm side can be done.
Regards,
omar
^ permalink raw reply
* Re: [RFC] tidspbridge: use a parameter to allocate shared memory
From: Omar Ramirez Luna @ 2010-10-07 19:16 UTC (permalink / raw)
To: Felipe Contreras
Cc: Laurent Pinchart, linux-arm-kernel@lists.infradead.org,
Tony Lindgren, Ohad Ben-Cohen, Greg Kroah-Hartman, Russell King,
Gomez Castellanos, Ivan, Ramos Falcon, Ernesto,
linux-omap@vger.kernel.org, Ameya Palande
In-Reply-To: <AANLkTim8H0ibSucP3Nq=q19t0QY0pvijim1kOZSbygY1@mail.gmail.com>
On 10/7/2010 1:22 PM, Felipe Contreras wrote:
...
>
> Note that the "shared memory" described in the document you share has
> nothing to do with the SHM pool. AFAIK that memory is used for other
> things, like MMU PTEs, and storing the base image and socket-nodes,
> thus it needs to be contiguous.
hmmm, no. it is the same memory. i.e.: we propagate the current opp
through the shared memory so the dsp can read it if it went to sleep,
with the proper offset you can read that variable starting from the
mempool base address.
"storing the base image and socket-nodes" symbols is also donde in the
shared memory but this is done in different sections of the SHM.
>
> Right now allocating contiguous memory can only be done with memblock
> (bootmem), but in the future it could be done with CMA/VCMM. But the
> cacheability is a separate issue.
yes
>
> I don't see any problem flushing the SHM area when needed, which
> probably has performance implications when mmaping/unmapping buffers,
> at which point you need to flush bigger memory areas anyway, so that's
> not an issue.
well, you would have to flush when loading the base image, or allocating
a socket node, but also minor flushes for opp propagation, SHM messages
to DSP, chnl params, those are the ones I can quickly think of.
>
> Anyway, we will not know for sure until we try... Right?
yes we can try, at least we now for sure arm side can be done.
Regards,
omar
^ permalink raw reply
* Re: [PATCH] mtd/nand.h: cleanups
From: Artem Bityutskiy @ 2010-10-07 19:17 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: linux-mtd
In-Reply-To: <20101005104101.GA18714@www.tglx.de>
On Tue, 2010-10-05 at 12:41 +0200, Sebastian Andrzej Siewior wrote:
> - *var instead of * var
> - proper multiline comment
> - func(args) instead of func (args)
> - 80 lines
>
> So from
> |total: 2 errors, 37 warnings, 654 lines checked
> we got to one warning.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Pushed both patches to l2-mtd-2.6.git, thanks.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* Re: memory clobber in rx path, maybe related to ath9k.
From: Johannes Berg @ 2010-10-07 19:17 UTC (permalink / raw)
To: Ben Greear; +Cc: Luis R. Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <4CAE1C02.7090405@candelatech.com>
On Thu, 2010-10-07 at 12:14 -0700, Ben Greear wrote:
> > I'll start a compile of vanilla wireless-testing + scan fix as well.
>
> Well, vanilla + scan patch locked pretty hard when I started the script.
>
> I was able to get sysrq to dump the locks, but it didn't seem to complete
> that and couldn't even dump more sysrq info after that.
>
> Might be something entirely different, of course, and no idea if
> this lock dump shows any real problem.
Don't see any issues in this part of the dump -- heavy contention on the
RTNL but that was expected with your usage.
johannes
^ permalink raw reply
* [PATCH 1/1] SQUASHME: pnfs-submit: do not get_lseg in pnfs_has_layout
From: Benny Halevy @ 2010-10-07 19:17 UTC (permalink / raw)
To: linux-nfs
In-Reply-To: <4CAE16FA.9040606@panasas.com>
let its caller do that if necessary
Signed-off-by: Benny Halevy <bhalevy@panasas.com>
---
fs/nfs/pnfs.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
index 40d1dc6..a27df2b 100644
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -844,8 +844,6 @@ pnfs_has_layout(struct pnfs_layout_hdr *lo,
list_for_each_entry(lseg, &lo->segs, fi_list) {
if (is_matching_lseg(lseg, range)) {
ret = lseg;
- if (lseg->valid)
- get_lseg(ret);
break;
}
if (cmp_layout(range, &lseg->range) > 0)
@@ -857,7 +855,6 @@ pnfs_has_layout(struct pnfs_layout_hdr *lo,
ret ? ret->valid : 0);
return ret;
}
-EXPORT_SYMBOL_GPL(pnfs_has_layout);
/*
* Layout segment is retreived from the server if not cached.
@@ -897,6 +894,7 @@ pnfs_update_layout(struct inode *ino,
if (lseg) {
dprintk("%s: Using cached lseg %p for iomode %d)\n",
__func__, lseg, iomode);
+ get_lseg(lseg);
goto out_unlock;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] SQUASHME: pnfs: get_lseg in nfs4_layoutget_prepare rather than in pnfs_has_layout
From: Benny Halevy @ 2010-10-07 19:17 UTC (permalink / raw)
To: linux-nfs
In-Reply-To: <4CAE16FA.9040606@panasas.com>
pnfs_has_layout does not get_lref on its return value anymore
Signed-off-by: Benny Halevy <bhalevy@panasas.com>
---
fs/nfs/nfs4proc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 25bc169..97cc539 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5442,12 +5442,12 @@ nfs4_layoutget_prepare(struct rpc_task *task, void *calldata)
return;
}
if (!lseg->valid) {
- put_lseg_locked(lseg);
spin_unlock(&ino->i_lock);
dprintk("%s: invalid lseg found, waiting\n", __func__);
rpc_sleep_on(&nfsi->lo_rpcwaitq, task, NULL);
return;
}
+ get_lseg(lseg);
*lgp->lsegpp = lseg;
spin_unlock(&ino->i_lock);
dprintk("%s: valid lseg found, no rpc required\n", __func__);
--
1.7.2.3
^ permalink raw reply related
* RE: [PATCH RESEND][MTD]MLC device check in OneNAND driver
From: Artem Bityutskiy @ 2010-10-07 19:18 UTC (permalink / raw)
To: Rohit Hassan Sathyanarayan; +Cc: v.dalal, gupta.raghav, linux-mtd
In-Reply-To: <000f01cb65d8$984b15b0$c8e14110$%hs@samsung.com>
On Thu, 2010-10-07 at 10:02 +0530, Rohit Hassan Sathyanarayan wrote:
> We made changes as per your comments and have posted two patches,
> Links of two patches,
> http://lists.infradead.org/pipermail/linux-mtd/2010-September/032333.html
> http://lists.infradead.org/pipermail/linux-mtd/2010-September/032334.html
Yes, I have them in my l2-mtd-2.6.git tree.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* + sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch added to -mm tree
From: akpm @ 2010-10-07 19:18 UTC (permalink / raw)
To: mm-commits; +Cc: eric.dumazet, ebiederm, xiyou.wangcong
The patch titled
sysctl: fix min/max handling in __do_proc_doulongvec_minmax()
has been added to the -mm tree. Its filename is
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: sysctl: fix min/max handling in __do_proc_doulongvec_minmax()
From: Eric Dumazet <eric.dumazet@gmail.com>
When proc_doulongvec_minmax() is used with an array of longs, and no
min/max check requested (.extra1 or .extra2 being NULL), we dereference a
NULL pointer for the second element of the array.
Noticed while doing some changes in network stack for the "16TB problem"
Fix is to not change min & max pointers in __do_proc_doulongvec_minmax(),
so that all elements of the vector share an unique min/max limit, like
proc_dointvec_minmax().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Americo Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/sysctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN kernel/sysctl.c~sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2 kernel/sysctl.c
--- a/kernel/sysctl.c~sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2
+++ a/kernel/sysctl.c
@@ -2485,7 +2485,7 @@ static int __do_proc_doulongvec_minmax(v
kbuf[left] = 0;
}
- for (; left && vleft--; i++, min++, max++, first=0) {
+ for (; left && vleft--; i++, first=0) {
unsigned long val;
if (write) {
_
Patches currently in -mm which might be from eric.dumazet@gmail.com are
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
linux-next.patch
net-avoid-limits-overflow.patch
fs-allow-for-more-than-231-files.patch
signals-annotate-lock_task_sighand.patch
^ permalink raw reply
* Re: [PATCH] Documentation: update-index: -z applies also to --index-info
From: Jonathan Nieder @ 2010-10-07 19:15 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Štěpán Němec, Junio C Hamano, git
In-Reply-To: <AANLkTikiOmM0q=XoAJ0nOnr6SChj7PZZJfmXzaihGZMu@mail.gmail.com>
Bert Wesarg wrote:
> On Thu, Oct 7, 2010 at 20:52, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>> On Thu, Oct 7, 2010 at 20:33, Štěpán Němec <stepnem@gmail.com> wrote:
>>> There is actually at least one more problem with the current SYNOPSIS of
>>> `update-index'. Obviously the `*' on the third line of the Asciidoc
>>> source makes the whole `--cacheinfo' line disappear and the rest bold
>>> (cf. e.g. the result at
>>> <http://www.kernel.org/pub/software/scm/git/docs/git-update-index.html>).
>
> ls-files too:
> http://www.kernel.org/pub/software/scm/git/docs/git-ls-files.html
Hmph, this is from v1.7.3-rc0~15^2~9 (Documentation: remove backslashes
in manpage synopses, 2010-08-20). And it still works for me locally
(for both manpage and HTML generation). :(
Anyway, the "..." fix sounds good to me (or {asterisk} if the stars are
still wanted).
^ permalink raw reply
* RE: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
From: Savoy, Pavan @ 2010-10-07 19:19 UTC (permalink / raw)
To: Alan Cox
Cc: Jiri Slaby, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org
In-Reply-To: <20101007203801.1c55a1d3@lxorguk.ukuu.org.uk>
Alan,
> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Thursday, October 07, 2010 2:38 PM
> To: Savoy, Pavan
> Cc: Jiri Slaby; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@driverdev.osuosl.org
> Subject: Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
>
> > The situation here was to access the UART from a kernel driver. Say we have
> > a V4L2 FM radio over the UART, How can I write a v4L2 driver? I has to be a
> > line discipline driver correct?
>
> Why would you want to ? you can just control it from user space. If you
> did want to drive it from the kernel then an ldisc would be one way to do
> it I guess.
ldisc is the ONLY way to do it, isn't it? Do I have any other option?
The situation was something similar here.
What I was trying to get to is how we can have a per-device context if a driver is just a line discipline driver?
Few months ago, something similar was discussed....
I have 3 sub-devices if you will on a device which is interfaced over UART,
One of them is Bluetooth which requires any UART Bluetooth device to have its
Own line discipline - N_HCI.
Another is FM, which needs to be a V4L2 device.
Now being V4L2 device, I need to access the UART from kernel, but I cannot
since BT would be using it via the N_HCI ldisc.
Coming to what Jiri, was commenting was about the ldisc_ops structure, which
Just needs to be static and not really kmalloc-ed in heap.
I did it because, I imagined some day TTY ldisc drivers had capability to have
It's own per-device context/private_data (in addition to) tty driver_data or
Something like tty ldisc_data would be good.
> Alan
^ permalink raw reply
* + sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2-checkpatch-fixes.patch added to -mm tree
From: akpm @ 2010-10-07 19:19 UTC (permalink / raw)
To: mm-commits; +Cc: akpm, eric.dumazet
The patch titled
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2-checkpatch-fixes
has been added to the -mm tree. Its filename is
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2-checkpatch-fixes.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2-checkpatch-fixes
From: Andrew Morton <akpm@linux-foundation.org>
ERROR: spaces required around that '=' (ctx:VxV)
#30: FILE: kernel/sysctl.c:2488:
+ for (; left && vleft--; i++, first=0) {
^
total: 1 errors, 0 warnings, 8 lines checked
./patches/sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/sysctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN kernel/sysctl.c~sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2-checkpatch-fixes kernel/sysctl.c
--- a/kernel/sysctl.c~sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2-checkpatch-fixes
+++ a/kernel/sysctl.c
@@ -2485,7 +2485,7 @@ static int __do_proc_doulongvec_minmax(v
kbuf[left] = 0;
}
- for (; left && vleft--; i++, first=0) {
+ for (; left && vleft--; i++, first = 0) {
unsigned long val;
if (write) {
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
memcg-fix-thresholds-with-use_hierarchy-==-1-fix.patch
maintainers-haavard-has-moved.patch
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2-checkpatch-fixes.patch
linux-next.patch
next-remove-localversion.patch
fs-inodec-work-around-bug.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
arch-mips-include-asm-fcntlh-needs-typesh.patch
arch-x86-kernel-entry_64s-fix-build-with-gas-2161.patch
arch-x86-kernel-entry_32s-i386-too.patch
gcc-46-btrfs-clean-up-unused-variables-bugs.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
drivers-media-video-cx23885-cx23885-corec-fix-cx23885_dev_checkrevision.patch
fs-notify-fanotify-fanotify_userc-fix-warnings.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-low-threshold-to-pwm-backlight.patch
serial8250-ratelimit-too-much-work-error-fix.patch
serial8250-ratelimit-too-much-work-error-fix-fix.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
drivers-message-fusion-mptsasc-fix-warning.patch
vfs-allow-mnt_want_write-to-sleep-fix.patch
mm.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix-fix.patch
oom-rewrite-error-handling-for-oom_adj-and-oom_score_adj-tunables.patch
oom-fix-locking-for-oom_adj-and-oom_score_adj.patch
mm-only-build-per-node-scan_unevictable-functions-when-numa-is-enabled-cleanup.patch
memory-hotplug-unify-is_removable-and-offline-detection-code-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-checkpatch-fixes.patch
vmstat-include-compactionh-when-config_compaction-fix.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
hpet-factor-timer-allocate-from-open-fix.patch
m68k-__pa-cast-arg-to-long.patch
kernelh-add-minmax3-macros-fix.patch
include-linux-kernelh-add-__must_check-to-strict_strto.patch
printk-declare-printk_ratelimit_state-in-ratelimith-fix.patch
vsprintfc-use-default-pointer-field-size-for-null-strings-fix.patch
scripts-get_maintainerpl-add-git-blame-rolestats-authored-lines-information.patch
idr-fix-idr_pre_get-locking-description-fix.patch
checkpatch-returning-errno-typically-should-be-negative.patch
select-rename-estimate_accuracy-to-select_estimate_accuracy.patch
vcs-add-poll-fasync-support-fix-fix.patch
cgroup_freezer-update_freezer_state-does-incorrect-state-transitions-checkpatch-fixes.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection-checkpatch-fixes.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2-checkpatch-fixes.patch
drivers-char-hvc_consolec-remove-unneeded-__set_current_statetask_running.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
fuse-use-release_pages.patch
pps-add-async-pps-event-handler-fix.patch
memstick-add-driver-for-ricoh-r5c592-card-reader-fix.patch
kernel-resourcec-handle-reinsertion-of-an-already-inserted-resource.patch
ramoops-use-the-platform-data-structure-instead-of-module-params-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
getblk-handle-2tb-devices.patch
^ permalink raw reply
* Re: [PATCH] sysctl: fix min/max handling in __do_proc_doulongvec_minmax()
From: Andrew Morton @ 2010-10-07 19:18 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric W. Biederman, Américo Wang, Robin Holt, linux-kernel,
Willy Tarreau, David S. Miller, netdev, James Morris,
Pekka Savola (ipv6), Patrick McHardy, Alexey Kuznetsov
In-Reply-To: <1286470743.2912.276.camel@edumazet-laptop>
On Thu, 07 Oct 2010 18:59:03 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 07 octobre 2010 __ 09:37 -0700, Eric W. Biederman a __crit :
>
> > The difference between long handling and int handling is a
> > usability issue. I don't expect we will be exporting new
> > vectors via sysctl, so the conversion of a handful of vectors
> > from int to long is where this is most likely to be used.
> >
> > I skimmed through all of what I presume are the current users
> > aka linux-2.6.36-rcX and there don't appear to be any users
> > of proc_dounlongvec_minmax that use it's vector properties there.
> >
> > Which doubly tells me that incrementing the min and max pointers
> > is not what we want to do.
> >
>
> Thats fine by me, thanks Eric.
>
> Andrew, please remove previous patch from your tree and replace it by
> following one :
>
> [PATCH v2] sysctl: fix min/max handling in __do_proc_doulongvec_minmax()
>
> When proc_doulongvec_minmax() is used with an array of longs,
> and no min/max check requested (.extra1 or .extra2 being NULL), we
> dereference a NULL pointer for the second element of the array.
>
> Noticed while doing some changes in network stack for the "16TB problem"
>
> Fix is to not change min & max pointers in
> __do_proc_doulongvec_minmax(), so that all elements of the vector share
> an unique min/max limit, like proc_dointvec_minmax().
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> kernel/sysctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index f88552c..8e45451 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -2485,7 +2485,7 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
> kbuf[left] = 0;
> }
>
> - for (; left && vleft--; i++, min++, max++, first=0) {
> + for (; left && vleft--; i++, first=0) {
> unsigned long val;
>
> if (write) {
Did we check to see whether any present callers are passing in pointers
to arrays of min/max values?
I wonder if there's any documentation for this interface which just
became wrong.
^ permalink raw reply
* Re: [PATCH] xfs: fix bogus m_maxagi check in xfs_iget
From: Alex Elder @ 2010-10-07 19:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006183123.GA2166@lst.de>
On Wed, 2010-10-06 at 14:31 -0400, Christoph Hellwig wrote:
> These days inode64 should only control which AGs we allocate new inodes
> from, while we still try to support reading all existing inodes. To make
> this actually work the check ontop of xfs_iget needs to be relaxed to allow
> inodes in all allocation groups instead of just those that we allow
> allocating inodes from. Note that we can't simply remove the check - it
> prevents us from accessing invalid data when fed invalid inode numbers
> from NFS or bulkstat.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [tip:core/memblock] x86, memblock: Fix crashkernel allocation
From: Vivek Goyal @ 2010-10-07 19:21 UTC (permalink / raw)
To: H. Peter Anvin
Cc: caiqian@redhat.com, linux-tip-commits@vger.kernel.org,
Kexec Mailing List, linux-kernel@vger.kernel.org,
mingo@redhat.com, tglx@linutronix.de, yinghai@kernel.org
In-Reply-To: <4CAE1767.5040409@intel.com>
On Thu, Oct 07, 2010 at 11:54:31AM -0700, H. Peter Anvin wrote:
> On 10/07/2010 11:18 AM, Vivek Goyal wrote:
> >
> > Ok, I was browsing through kexec-tools, x86 bzImage code and trying to
> > refresh my memory what segments were being loaded and what were memory
> > address concerns.
> >
> > - relocatable bzImage (max addr 0x37ffffff, 896MB).
> > Though I don't know/understand where that 896MB come from.
> >
> > - initrd (max addr 0x37ffffff, 896MB)
> > Don't know why 896MB as upper limit
>
> 896 MB is presumably the (default!!) LOWMEM limit on 32 bits. This is
> actually wrong if vmalloc= is also specified on command line, though, or
> with nonstandard compile-time options.
>
> > - Purgatory (max addr 2G)
> >
> > - A segment to keep elf headers (no limit)
> > These are accessed when second kernel as fully booted so can be
> > addressed in higher addresses.
> >
> > - A backup segment to copy first 640K of memory (not aware of any limit)
> > - Setup/parameter segment (no limit)
> > - We don't really execute anything here and just access it for
> > command line.
>
> Probably has a 4 GB limit, since I believe it only has a 32-bit pointer.
>
> > So atleast for bzImage it looks that if we specify crashkernel=128M<896M, it
> > will work.
> >
> > So I am fine with above additional syntax for crashkernel=. May be we shall
> > have to the deprecate the crashkernel=X<@0 syntax.
> >
> > CCing kexec list, in case others have any comments.
>
> It would be easy enough to either deprecate or make it an alias for
> crashkernel=...<896M, which is basically what Yinghai's patch does.
Agreed.
So Yinghai's patch is fine. I need to write a patch for introducing
crashkernel=X<Y syntax to make the behavior explicit. Will do...
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [tip:core/memblock] x86, memblock: Fix crashkernel allocation
From: Vivek Goyal @ 2010-10-07 19:21 UTC (permalink / raw)
To: H. Peter Anvin
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org,
yinghai@kernel.org, caiqian@redhat.com, tglx@linutronix.de,
linux-tip-commits@vger.kernel.org, Kexec Mailing List
In-Reply-To: <4CAE1767.5040409@intel.com>
On Thu, Oct 07, 2010 at 11:54:31AM -0700, H. Peter Anvin wrote:
> On 10/07/2010 11:18 AM, Vivek Goyal wrote:
> >
> > Ok, I was browsing through kexec-tools, x86 bzImage code and trying to
> > refresh my memory what segments were being loaded and what were memory
> > address concerns.
> >
> > - relocatable bzImage (max addr 0x37ffffff, 896MB).
> > Though I don't know/understand where that 896MB come from.
> >
> > - initrd (max addr 0x37ffffff, 896MB)
> > Don't know why 896MB as upper limit
>
> 896 MB is presumably the (default!!) LOWMEM limit on 32 bits. This is
> actually wrong if vmalloc= is also specified on command line, though, or
> with nonstandard compile-time options.
>
> > - Purgatory (max addr 2G)
> >
> > - A segment to keep elf headers (no limit)
> > These are accessed when second kernel as fully booted so can be
> > addressed in higher addresses.
> >
> > - A backup segment to copy first 640K of memory (not aware of any limit)
> > - Setup/parameter segment (no limit)
> > - We don't really execute anything here and just access it for
> > command line.
>
> Probably has a 4 GB limit, since I believe it only has a 32-bit pointer.
>
> > So atleast for bzImage it looks that if we specify crashkernel=128M<896M, it
> > will work.
> >
> > So I am fine with above additional syntax for crashkernel=. May be we shall
> > have to the deprecate the crashkernel=X<@0 syntax.
> >
> > CCing kexec list, in case others have any comments.
>
> It would be easy enough to either deprecate or make it an alias for
> crashkernel=...<896M, which is basically what Yinghai's patch does.
Agreed.
So Yinghai's patch is fine. I need to write a patch for introducing
crashkernel=X<Y syntax to make the behavior explicit. Will do...
Thanks
Vivek
^ permalink raw reply
* Re: memory clobber in rx path, maybe related to ath9k.
From: Ben Greear @ 2010-10-07 19:22 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimEZ5GY7WFz-F4YyC+6MEwNn2Dki4tonp645XrS@mail.gmail.com>
On 10/07/2010 11:42 AM, Luis R. Rodriguez wrote:
> On Thu, Oct 7, 2010 at 11:39 AM, Ben Greear<greearb@candelatech.com> wrote:
>> On 10/07/2010 11:29 AM, Luis R. Rodriguez wrote:
>>>
>>> On Thu, Oct 7, 2010 at 11:14 AM, Johannes Berg
>>> <johannes@sipsolutions.net> wrote:
>>>>
>>>> On Thu, 2010-10-07 at 10:33 -0700, Ben Greear wrote:
>>>>>
>>>>> In case it helps, here is a dump of where the corrupted SKB was deleted.
>>>>
>>>> I wonder, do you have a machine with a decent IOMMU? Adding IOMMU
>>>> debugging into the mix could help you figure out if it's a DMA problem.
>>>
>>> Ben, how much traffic are you RX'ing on these virtual interfaces?
>>
>> I disabled my user-space application, and this script alone can reproduce
>> the problem fairly quickly on my system. You will need to change some
>> of those first variables. Just start it and wait a few minutes and
>> watch the splats show on the console :)
>>
>> Note that I am not generating any traffic, but the wpa_supplicants are
>> doing their thing of course...
>>
>> I'm using the kernel found here:
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux.wireless-testing.ct/.git;a=summary
>>
>> It's latest wireless-testing with some of my own patches, and some
>> I've gathered from here an there. I doubt I'm causing this problem,
>> but if you can't reproduce it with this script on your kernels,
>> I can try with base wireless-testing or whatever you are using.
>
> I'll run this now, but can you try a vanilla wireless-testing? I hear
> the latest wireless-testing is borked so maybe try (git reset --hard
> master-2010-09-29), its what I'm on.
After reboot, and re-run of the script,
I saw this in the logs, and shortly after,
the SLUB poison warning dumped to screen.
Maybe those DMA errors are serious?
Also, I enabled CONFIG_DMA_API_DEBUG, but saw no
indication it detected any problems.
DDRCONF(NETDEV_UP): sta29: link is not ready
ADDRCONF(NETDEV_UP): sta30: link is not ready
ADDRCONF(NETDEV_UP): sta31: link is not ready
sta0: authenticate with 00:14:d1:c6:d2:54 (try 1)
sta0: authenticated
ieee80211 phy0: device now idle
ieee80211 phy0: device no longer idle - working
sta0: associate with 00:14:d1:c6:d2:54 (try 1)
sta18: authenticate with 00:14:d1:c6:d2:54 (try 1)
sta0: associate with 00:14:d1:c6:d2:54 (try 2)
sta18: authenticate with 00:14:d1:c6:d2:54 (try 2)
sta0: associate with 00:14:d1:c6:d2:54 (try 3)
sta18: authenticate with 00:14:d1:c6:d2:54 (try 3)
sta0: association with 00:14:d1:c6:d2:54 timed out
sta18: authentication with 00:14:d1:c6:d2:54 timed out
ath: Failed to stop TX DMA in 100 msec after killing last frame
ath: Failed to stop TX DMA. Resetting hardware!
ieee80211 phy0: device now idle
ieee80211 phy0: device no longer idle - scanning
ieee80211 phy0: device now idle
ieee80211 phy0: device no longer idle - working
sta1: authenticate with 00:14:d1:c6:d2:54 (try 1)
sta1: authenticated
sta1: associate with 00:14:d1:c6:d2:54 (try 1)
sta1: RX AssocResp from 00:14:d1:c6:d2:54 (capab=0x431 status=0 aid=18)
sta1: associated
ieee80211 phy0: Allocated STA 00:14:d1:c6:d2:54
ieee80211 phy0: Inserted STA 00:14:d1:c6:d2:54
ieee80211 phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0 uapsd=0
ieee80211 phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 uapsd=0
ieee80211 phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 uapsd=0
ieee80211 phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 uapsd=0
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM
From: Russell King - ARM Linux @ 2010-10-07 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286444662-16843-1-git-send-email-felipe.contreras@gmail.com>
On Thu, Oct 07, 2010 at 12:44:22PM +0300, Felipe Contreras wrote:
> Many drivers are broken, and there's no alternative in sight. Such a big
> change should stay as a warning for now, and only later should it
> actually fail.
>
> The drivers are not doing something correct, we get it, but for now it's
> better to allow them to work (they do 99% of the time anyway) rather
> than to force everyone to revert this patch in their internal trees
> until there's a solution. A slightly broken functionality is better than
> no functionality at all.
>
> A warning lets people know that what they are doing is not right, and
> they should fix it.
So what are _you_ going to do to fix these drivers? Continue reverting
this patch? Or are you just going to ignore the issue entirely?
Unless people can come up with a plan to fix their drivers using ioremap
on system RAM thereby violating the architecture specification, I'm
_not_ going to apply this patch.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.