* Re: opkg install gdbserver
From: Tom Rini @ 2010-10-07 23:38 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <4E064324-2FF0-4F2B-BCB7-04AFD285689B@mac.com>
Elvis Dowson wrote:
> Hi,
> I have a target board that is not connected to the internet.
>
> What should I do to get gdbserver onto the target?
>
> I have built gdb-cross. Is there another recipe I can add to omap3-console-image, to make sure that gdbserver gets pulled in?
There is a gdbserver recipe for the target.
--
Tom Rini
Mentor Graphics Corporation
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Rafael J. Wysocki @ 2010-10-07 23:37 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Alan Stern, Linux-pm mailing list, Partha Basak, linux-omap
In-Reply-To: <8762xd4msy.fsf@deeprootsystems.com>
On Friday, October 08, 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Thursday, October 07, 2010, Alan Stern wrote:
> >> On Thu, 7 Oct 2010, Kevin Hilman wrote:
> >>
> >> > My confusion is not about the use of spinlocks, it's a question of what
> >> > is being busy-waited for, and the thread that is being waited for is
> >> > going to complete when interrupts are disabled.
> >> >
> >> > Sorry to be dense, but can you (re)summarize what you're proposing as I
> >> > think I'm getting mixed up with all the various options we've been
> >> > tossing around.
> >> >
> >> > If it can work, I'm certainly in favor of a busy-wait approach as it
> >> > really ensures that sync requests are handled quickly.
> >>
> >> Okay, here's the story in a nutshell. Allowing a subsystem's or
> >> driver's runtime-PM callbacks to run with interrupts disabled faces two
> >> obstacles:
> >>
> >> (1): We don't want two different CPUs to run callbacks for the
> >> same device at the same time. So if a callback is already
> >> running on one CPU (i.e., if the device's runtime status is
> >> either SUSPENDING or RESUMING) then another CPU can't be
> >> allowed to invoke a callback.
> >>
> >> Thus, you can't do a synchronous pm_runtime_resume_irq()
> >> if the device is in the middle of a suspend or resume
> >> operation. We're left with two choices: Fail the synchronous
> >> call and force the driver to defer matters to a workqueue
> >> (possibly masking an IRQ line in the meantime), or busy-wait
> >> until the concurrent operation finishes.
> >>
> >> If the PM core simply avoids releasing dev->power.lock before
> >> invoking the runtime_suspend or runtime_resume callback, the
> >> end result is almost the same as with busy-waiting.
> >
> > This is slightly more complicated, because suspend is a bit different from
> > resume. I think it's generally acceptable to refuse to do a "fast path" suspend
> > if the device state is not RPM_ACTIVE at the moment, but refusing to do
> > a "fast path" resume may be more problematic (more on that later).
> >
> >> (2): In general we can't resume a device if its parent is suspended.
> >> If the parent's runtime_resume routine needs to run with
> >> interrupts enabled then there's no way to resume the device
> >> while keeping interrupts disabled.
> >>
> >> Possible solutions involve, again, deferring matters to a
> >> workqueue, or else simply not allowing the situation to arise
> >> in the first place (forbid a device to have interrupt-disabled
> >> callbacks unless its parent does too or the parent doesn't use
> >> runtime PM at all).
> >>
> >> In general I'm against the solutions that require a workqueue.
> >
> > OK
> >
> >> Raphael appears to favor workqueues for (1) and be against them for (2).
> >
> > The particular case we need to handle (I think) is that some devices need to be
> > resumed "atomically" as a part of bringing a CPU package out of a C-like-state
> > (Kevin, is that correct?).
>
> Correct, but there is more than one problematic case.
>
> Another problem is in devices that are not atomic with C-states, but
> receive wakeup IRQs while they're suspended and thus need to
> pm_runtime_get() from their ISRs, without having an essentially
> unbounded interrupt latency before the ISR can be handled.
>
> Consider the following sequence for a given device
>
> - device: ->runtime_suspend() /* registers not accessible */
> - pm_idle
> - IRQs disabled
> - idle
> - wakeup event
> - idle loop finishes
> - IRQs enabled
> - device: ->runtime_resume()
>
> Now, consider the 'wakeup event' is an IRQ for that device. That means
> as soon as IRQs are (re)enabled (and before some other activity has
> triggered a ->runtime_resume), the device's ISR is called. Since it is
> RPM_SUSPENDED, it's registers are not accessible so it needs to do a
> pm_runtime_get().
>
> The case that raised this initially was a GPIO IRQ demux, where the
> initial ISR is just a chained handler whichfigures out which GPIO
> fired and then call genirq for that IRQ.
>
> All that being said, while I've currently described these as two
> different problems, the second one could be solved by converting it to
> the first one. IOW, make GPIO be one of those devices that are
> suspended/resumed atomically with the CPU so that it is guaranteed to be
> awake when IRQs are re-enabled.
>
> While that would work, I've been trying to move in the opposite
> direction by trying to dis-connect them from CPU idle.
>
> > In that case not only we can't defer the resume (by
> > using a workqueue), but also we have to finish the resume within strict time
> > constraints (the time to leave the given C-like-state is one of the parameters
> > used by cpuidle governors to decide which state to choose).
> >
> > On the other hand, busy waiting (by looping) in the case the state is
> > RPM_RESUMING is as though the callbacks were executed under a spinlock and we
> > happened to wait on it. I'd prefer to avoid that. Moreover, if the state is
> > RPM_SUSPENDING at the time a "fast path" resume is started, we are almost
> > guaranteed to violate the time constraints (by busy waiting for the suspend to
> > complete and carrying out the resume).
> >
> > So, here's an idea:
> >
> > First, let's introduce two flags in struct dev_pm_info, irq_safe and
> > fast_resume. The former has to be set so that the things above work.
> >
> > Second, let's add a new flag to pass to __pm_runtime_{suspend|resume}(),
> > RPM_FAST_RESUME such that if it is passed to __pm_runtime_suspend(), it
> > causes fast_resume to be set for the given device (if the status is already
> > RPM_SUSPENDED, it just sets the flag, otherwise it suspends the device
> > normally and then sets the flag). Now, if fast_resume is set,
> > __pm_runtime_resume() has to be passed RPM_FAST_RESUME, or it will
> > fail (it also will fail if passed RPM_FAST_RESUME and fast_resume isn't
> > set). In that case the status has to be RPM_SUSPENDED or RPM_RESUMING
> > (otherwise fast_resume won't be set) and if it is RPM_RESUMING, this means
> > that the other resume has been called with RPM_FAST_RESUME too (it would
> > fail otherwise), so it's fine to busy loop until the status is RPM_SUSPENDED
> > (it's the caller's problem to avoid that). RPM_FAST_RESUME causes
> > __pm_runtime_resume() to avod turning interrupts on.
> >
> > If necessary, there may be a flag for __pm_runtime_suspend() that will
> > carry out "atomic" suspend, but I'm not sure if that's necessary. Kevin?
>
> I think we'll need both "atomic" suspend & resume.
>
> One of the devices I'm currently managing in this atomic fashion (inside
> pm_idle) is the UARTs (of course, I'm not currently using runtime PM for
> this, I'm calling platform-specific hooks directly since IRQs are
> disabled.) For the UARTs I'm using both atomic suspend and resume,
> primarily for debug so I am sure UARTs are awake to see any panics
> during the last parts of the suspend/idle process and the early parts of
> the resume path. This UART case is a bit of a hack until the driver is
> converted to runtime PM, but illustrates some debug related reasons we
> might also need atomic suspend and resume.
>
> We also have some workarounds for hardware errata that require
> putting certain devices in a specific state just before (and after)
> idle. The drivers for these devices will need both suspend and resume.
OK, thanks for the info.
Do you need "normal" resume to work after "atomic" suspend, or is it
sufficient that "atomic" suspend will require "atomic" resume?
Rafael
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Rafael J. Wysocki @ 2010-10-07 23:37 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Partha Basak, Linux-pm mailing list, linux-omap
In-Reply-To: <8762xd4msy.fsf@deeprootsystems.com>
On Friday, October 08, 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Thursday, October 07, 2010, Alan Stern wrote:
> >> On Thu, 7 Oct 2010, Kevin Hilman wrote:
> >>
> >> > My confusion is not about the use of spinlocks, it's a question of what
> >> > is being busy-waited for, and the thread that is being waited for is
> >> > going to complete when interrupts are disabled.
> >> >
> >> > Sorry to be dense, but can you (re)summarize what you're proposing as I
> >> > think I'm getting mixed up with all the various options we've been
> >> > tossing around.
> >> >
> >> > If it can work, I'm certainly in favor of a busy-wait approach as it
> >> > really ensures that sync requests are handled quickly.
> >>
> >> Okay, here's the story in a nutshell. Allowing a subsystem's or
> >> driver's runtime-PM callbacks to run with interrupts disabled faces two
> >> obstacles:
> >>
> >> (1): We don't want two different CPUs to run callbacks for the
> >> same device at the same time. So if a callback is already
> >> running on one CPU (i.e., if the device's runtime status is
> >> either SUSPENDING or RESUMING) then another CPU can't be
> >> allowed to invoke a callback.
> >>
> >> Thus, you can't do a synchronous pm_runtime_resume_irq()
> >> if the device is in the middle of a suspend or resume
> >> operation. We're left with two choices: Fail the synchronous
> >> call and force the driver to defer matters to a workqueue
> >> (possibly masking an IRQ line in the meantime), or busy-wait
> >> until the concurrent operation finishes.
> >>
> >> If the PM core simply avoids releasing dev->power.lock before
> >> invoking the runtime_suspend or runtime_resume callback, the
> >> end result is almost the same as with busy-waiting.
> >
> > This is slightly more complicated, because suspend is a bit different from
> > resume. I think it's generally acceptable to refuse to do a "fast path" suspend
> > if the device state is not RPM_ACTIVE at the moment, but refusing to do
> > a "fast path" resume may be more problematic (more on that later).
> >
> >> (2): In general we can't resume a device if its parent is suspended.
> >> If the parent's runtime_resume routine needs to run with
> >> interrupts enabled then there's no way to resume the device
> >> while keeping interrupts disabled.
> >>
> >> Possible solutions involve, again, deferring matters to a
> >> workqueue, or else simply not allowing the situation to arise
> >> in the first place (forbid a device to have interrupt-disabled
> >> callbacks unless its parent does too or the parent doesn't use
> >> runtime PM at all).
> >>
> >> In general I'm against the solutions that require a workqueue.
> >
> > OK
> >
> >> Raphael appears to favor workqueues for (1) and be against them for (2).
> >
> > The particular case we need to handle (I think) is that some devices need to be
> > resumed "atomically" as a part of bringing a CPU package out of a C-like-state
> > (Kevin, is that correct?).
>
> Correct, but there is more than one problematic case.
>
> Another problem is in devices that are not atomic with C-states, but
> receive wakeup IRQs while they're suspended and thus need to
> pm_runtime_get() from their ISRs, without having an essentially
> unbounded interrupt latency before the ISR can be handled.
>
> Consider the following sequence for a given device
>
> - device: ->runtime_suspend() /* registers not accessible */
> - pm_idle
> - IRQs disabled
> - idle
> - wakeup event
> - idle loop finishes
> - IRQs enabled
> - device: ->runtime_resume()
>
> Now, consider the 'wakeup event' is an IRQ for that device. That means
> as soon as IRQs are (re)enabled (and before some other activity has
> triggered a ->runtime_resume), the device's ISR is called. Since it is
> RPM_SUSPENDED, it's registers are not accessible so it needs to do a
> pm_runtime_get().
>
> The case that raised this initially was a GPIO IRQ demux, where the
> initial ISR is just a chained handler whichfigures out which GPIO
> fired and then call genirq for that IRQ.
>
> All that being said, while I've currently described these as two
> different problems, the second one could be solved by converting it to
> the first one. IOW, make GPIO be one of those devices that are
> suspended/resumed atomically with the CPU so that it is guaranteed to be
> awake when IRQs are re-enabled.
>
> While that would work, I've been trying to move in the opposite
> direction by trying to dis-connect them from CPU idle.
>
> > In that case not only we can't defer the resume (by
> > using a workqueue), but also we have to finish the resume within strict time
> > constraints (the time to leave the given C-like-state is one of the parameters
> > used by cpuidle governors to decide which state to choose).
> >
> > On the other hand, busy waiting (by looping) in the case the state is
> > RPM_RESUMING is as though the callbacks were executed under a spinlock and we
> > happened to wait on it. I'd prefer to avoid that. Moreover, if the state is
> > RPM_SUSPENDING at the time a "fast path" resume is started, we are almost
> > guaranteed to violate the time constraints (by busy waiting for the suspend to
> > complete and carrying out the resume).
> >
> > So, here's an idea:
> >
> > First, let's introduce two flags in struct dev_pm_info, irq_safe and
> > fast_resume. The former has to be set so that the things above work.
> >
> > Second, let's add a new flag to pass to __pm_runtime_{suspend|resume}(),
> > RPM_FAST_RESUME such that if it is passed to __pm_runtime_suspend(), it
> > causes fast_resume to be set for the given device (if the status is already
> > RPM_SUSPENDED, it just sets the flag, otherwise it suspends the device
> > normally and then sets the flag). Now, if fast_resume is set,
> > __pm_runtime_resume() has to be passed RPM_FAST_RESUME, or it will
> > fail (it also will fail if passed RPM_FAST_RESUME and fast_resume isn't
> > set). In that case the status has to be RPM_SUSPENDED or RPM_RESUMING
> > (otherwise fast_resume won't be set) and if it is RPM_RESUMING, this means
> > that the other resume has been called with RPM_FAST_RESUME too (it would
> > fail otherwise), so it's fine to busy loop until the status is RPM_SUSPENDED
> > (it's the caller's problem to avoid that). RPM_FAST_RESUME causes
> > __pm_runtime_resume() to avod turning interrupts on.
> >
> > If necessary, there may be a flag for __pm_runtime_suspend() that will
> > carry out "atomic" suspend, but I'm not sure if that's necessary. Kevin?
>
> I think we'll need both "atomic" suspend & resume.
>
> One of the devices I'm currently managing in this atomic fashion (inside
> pm_idle) is the UARTs (of course, I'm not currently using runtime PM for
> this, I'm calling platform-specific hooks directly since IRQs are
> disabled.) For the UARTs I'm using both atomic suspend and resume,
> primarily for debug so I am sure UARTs are awake to see any panics
> during the last parts of the suspend/idle process and the early parts of
> the resume path. This UART case is a bit of a hack until the driver is
> converted to runtime PM, but illustrates some debug related reasons we
> might also need atomic suspend and resume.
>
> We also have some workarounds for hardware errata that require
> putting certain devices in a specific state just before (and after)
> idle. The drivers for these devices will need both suspend and resume.
OK, thanks for the info.
Do you need "normal" resume to work after "atomic" suspend, or is it
sufficient that "atomic" suspend will require "atomic" resume?
Rafael
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: Minchan Kim @ 2010-10-07 23:35 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007152422.c5919517.kamezawa.hiroyu@jp.fujitsu.com>
Hi Kame,
On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> But set_page_writeback() requires it...
> (Maybe adding a special function for clear_page_writeback() is better rather than
> adding some complex to switch() in update_page_stat())
>
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> points to a cgroup where someone is moving charges from.
>
> At supporing dirty-page accounting, one of troubles is writeback bit.
> In general, writeback can be cleared via IRQ context. To update writeback bit
> with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> ....or do something.
>
> This patch waits for completion of writeback under lock_page() and do
> lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
>
> By this, writeback-accounting will never see race with account_move() and
> it can trust pc->mem_cgroup always _without_ any lock.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> mm/memcontrol.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> Index: mmotm-0928/mm/memcontrol.c
> ===================================================================
> --- mmotm-0928.orig/mm/memcontrol.c
> +++ mmotm-0928/mm/memcontrol.c
> @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> /*
> * check whether the @pc is valid for moving account and call
> * __mem_cgroup_move_account()
> + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> + * the end of I/O.
> */
> static int mem_cgroup_move_account(struct page_cgroup *pc,
> struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> {
> int ret = -EINVAL;
> +
> + /*
> + * We move severl flags and accounting information here. So we need to
> + * avoid the races with update_stat routines. For most of routines,
> + * lock_page_cgroup() is enough for avoiding race. But we need to take
> + * care of IRQ context. If flag updates comes from IRQ context, This
> + * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> + *
> + * Now, the only race we have is Writeback flag. We wait for it cleared
> + * before starting our jobs.
> + */
> +
> + lock_page(pc->page);
> + wait_on_page_writeback(pc->page);
> +
> lock_page_cgroup(pc);
> if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> __mem_cgroup_move_account(pc, from, to, uncharge);
> ret = 0;
> }
> unlock_page_cgroup(pc);
> + unlock_page(pc->page);
> /*
> * check events
> */
>
>
Looks good to me.
But let me ask a question.
Why do only move_account need this logic?
Is deadlock candidate is only this place?
How about mem_cgroup_prepare_migration?
unmap_and_move
lock_page
mem_cgroup_prepare_migration
lock_page_cgroup
...
softirq happen
lock_page_cgroup
If race happens only where move_account and writeback, please describe
it as comment.
It would help to review the code in future.
--
Kind regards,
Minchan Kim
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: Minchan Kim @ 2010-10-07 23:35 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007152422.c5919517.kamezawa.hiroyu@jp.fujitsu.com>
Hi Kame,
On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> But set_page_writeback() requires it...
> (Maybe adding a special function for clear_page_writeback() is better rather than
> adding some complex to switch() in update_page_stat())
>
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> points to a cgroup where someone is moving charges from.
>
> At supporing dirty-page accounting, one of troubles is writeback bit.
> In general, writeback can be cleared via IRQ context. To update writeback bit
> with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> ....or do something.
>
> This patch waits for completion of writeback under lock_page() and do
> lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
>
> By this, writeback-accounting will never see race with account_move() and
> it can trust pc->mem_cgroup always _without_ any lock.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> mm/memcontrol.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> Index: mmotm-0928/mm/memcontrol.c
> ===================================================================
> --- mmotm-0928.orig/mm/memcontrol.c
> +++ mmotm-0928/mm/memcontrol.c
> @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> /*
> * check whether the @pc is valid for moving account and call
> * __mem_cgroup_move_account()
> + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> + * the end of I/O.
> */
> static int mem_cgroup_move_account(struct page_cgroup *pc,
> struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> {
> int ret = -EINVAL;
> +
> + /*
> + * We move severl flags and accounting information here. So we need to
> + * avoid the races with update_stat routines. For most of routines,
> + * lock_page_cgroup() is enough for avoiding race. But we need to take
> + * care of IRQ context. If flag updates comes from IRQ context, This
> + * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> + *
> + * Now, the only race we have is Writeback flag. We wait for it cleared
> + * before starting our jobs.
> + */
> +
> + lock_page(pc->page);
> + wait_on_page_writeback(pc->page);
> +
> lock_page_cgroup(pc);
> if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> __mem_cgroup_move_account(pc, from, to, uncharge);
> ret = 0;
> }
> unlock_page_cgroup(pc);
> + unlock_page(pc->page);
> /*
> * check events
> */
>
>
Looks good to me.
But let me ask a question.
Why do only move_account need this logic?
Is deadlock candidate is only this place?
How about mem_cgroup_prepare_migration?
unmap_and_move
lock_page
mem_cgroup_prepare_migration
lock_page_cgroup
...
softirq happen
lock_page_cgroup
If race happens only where move_account and writeback, please describe
it as comment.
It would help to review the code in future.
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [RFC] CONFIG_NET_DMA can hang the system if DMA engine driver uses tasklets
From: Ilya Yanok @ 2010-10-07 23:14 UTC (permalink / raw)
To: linux-kernel, dan.j.williams, 'Vladimir K'; +Cc: Wolfgang Denk
Hi Dan, everybody.
I use mpc512x_dma driver which utilizes tasklet to free completed
descriptors. With CONFIG_NET_DMA enabled the whole system hangs during
network throughput testing. I've done some investigation and found that
at some point we run out of descriptors and for some reason my tasklet
is not executed. After doing some more investigation I've found this
reason. Here is a stack dump at the moment of hang:
[ 1220.884981] BUG: soft lockup - CPU#0 stuck for 61s! [syslogd:1177]
[ 1220.891143] Modules linked in:
[ 1220.894192] NIP: c02739c0 LR: c027222c CTR: c0273950
[ 1220.899144] REGS: c7ffbbf0 TRAP: 0901 Not tainted
(2.6.36-rc5-00159-gf3beefd-dirty)
[ 1220.907029] MSR: 00009032 <EE,ME,IR,DR> CR: 88284482 XER: 20000000
[ 1220.913408] TASK = c78723e0[1177] 'syslogd' THREAD: c7ada000
[ 1220.918870] GPR00: c78a40ac c7ffbca0 c78723e0 00000000 000005a8
07b22892 00000000 c78a4084
[ 1220.927245] GPR08: 00009032 c78a40ac 10056948 c059f960 00000000
[ 1220.933460] NIP [c02739c0] mpc_dma_prep_memcpy+0x70/0x22c
[ 1220.938849] LR [c027222c] dma_async_memcpy_buf_to_pg+0xd4/0x1c0
[ 1220.944745] Call Trace:
[ 1220.947186] [c7ffbca0] [00009032] 0x9032 (unreliable)
[ 1220.952234] [c7ffbcb0] [20000000] 0x20000000
[ 1220.956502] [c7ffbcd0] [c0273398] dma_memcpy_to_iovec+0xe8/0x180
[ 1220.962511] [c7ffbd10] [c029f040] dma_skb_copy_datagram_iovec+0x200/0x218
[ 1220.969292] [c7ffbd50] [c02c2b9c] tcp_rcv_established+0x6c4/0x7c4
[ 1220.975380] [c7ffbd80] [c02c8ffc] tcp_v4_do_rcv+0xc0/0x1d0
[ 1220.980861] [c7ffbdb0] [c02caffc] tcp_v4_rcv+0x530/0x7b4
[ 1220.986175] [c7ffbde0] [c02ab494] ip_local_deliver+0x9c/0x1fc
[ 1220.991914] [c7ffbe00] [c02ab928] ip_rcv+0x334/0x5a8
[ 1220.996877] [c7ffbe30] [c028adf0] __netif_receive_skb+0x2bc/0x318
[ 1221.002966] [c7ffbe60] [c020aff4] gfar_clean_rx_ring+0x2b0/0x4cc
[ 1221.008965] [c7ffbec0] [c020de94] gfar_poll+0x378/0x5e0
[ 1221.014187] [c7ffbf80] [c028e444] net_rx_action+0x9c/0x1ac
[ 1221.019669] [c7ffbfb0] [c0025e84] __do_softirq+0xa8/0x120
[ 1221.025068] [c7ffbff0] [c000ee04] call_do_softirq+0x14/0x24
[ 1221.030641] [c7adbd10] [c00061a0] do_softirq+0x78/0x84
[ 1221.035773] [c7adbd30] [c0025bd0] irq_exit+0x98/0x9c
[ 1221.040734] [c7adbd40] [c000627c] do_IRQ+0xd0/0x140
[ 1221.045612] [c7adbd70] [c000fad4] ret_from_except+0x0/0x14
[ 1221.051120] --- Exception: 501 at __srcu_read_lock+0x18/0x24
[ 1221.051132] LR = fsnotify+0x25c/0x26c
[ 1221.060752] [c7adbe30] [3c4a7839] 0x3c4a7839 (unreliable)
[ 1221.066150] [c7adbe90] [c00896d4] do_readv_writev+0x144/0x1e4
[ 1221.071889] [c7adbf10] [c008a13c] sys_writev+0x4c/0x90
[ 1221.077024] [c7adbf40] [c000f43c] ret_from_syscall+0x0/0x38
[ 1221.082588] --- Exception: c01 at 0x20316098
[ 1221.082598] LR = 0x203c98a8
[ 1221.089962] Instruction dump:
[ 1221.092920] 814c0034 3d200020 60000100 816c0030 61290200 916a0000
914b0004 900c0030
[ 1221.100684] 912c0034 7d000124 2f8c0000 38600000 <419e00cc> 7ca0fb78
814c0024 7c0b2378
We can see that the network stack calls dma_memcpy_to_iovec() function
from the softirq context and it never returns in case of DMA driver runs
out of descriptors and thus blocks the tasklet from being executed. We
have a deadlock.
Dan, I'd like to ask your opinion, do you think this is a problem of
CONFIG_NET_DMA feature implementation or should the DMA engine drivers
be aware of it? How should we fix it?
I can imagine the following possible solutions:
1. Add a possibility to return a failure to the dma_memcpy_to_iovec()
function (and reschedule it from the upper level) to give tasklets a
chance to be executed.
2. Place a restriction on the DMA drivers that descriptors should be
freed from the hard-irq context, not soft-irq and fix the existing drivers.
3. Try to free the descriptors not only from tasklet but also from the
place they get requested.
Maybe somebody has a better solution.
Some additional details on my configuration (pretty PowerPC-specific
though I think this issue is generic one).
I use MPC8308RDB development board based on MPC8308, mpc512x_dma driver
with my fixes and added support for MPC8308.
Kernel version: v2.6.36-rc5-151-g32163f4 + some my patches that is not
accepted into mainline yet.
This issue can be easily reproduced with the integrated eTSEC Ethernet
controller (gianfar driver) but I can't reproduce it with Intel PCIE
card (e1000e driver).
Regards, Ilya.
^ permalink raw reply
* Re: [RFC] CONFIG_NET_DMA can hang the system if DMA engine driver uses tasklets
From: Dan Williams @ 2010-10-07 23:33 UTC (permalink / raw)
To: Ilya Yanok
Cc: linux-kernel@vger.kernel.org, 'Vladimir K', Wolfgang Denk
In-Reply-To: <4CAE5445.4020106@emcraft.com>
On 10/7/2010 4:14 PM, Ilya Yanok wrote:
[..]
> We can see that the network stack calls dma_memcpy_to_iovec() function
> from the softirq context and it never returns in case of DMA driver runs
> out of descriptors and thus blocks the tasklet from being executed. We
> have a deadlock.
>
> Dan, I'd like to ask your opinion, do you think this is a problem of
> CONFIG_NET_DMA feature implementation or should the DMA engine drivers
> be aware of it? How should we fix it?
>
> I can imagine the following possible solutions:
> 1. Add a possibility to return a failure to the dma_memcpy_to_iovec()
> function (and reschedule it from the upper level) to give tasklets a
> chance to be executed.
> 2. Place a restriction on the DMA drivers that descriptors should be
> freed from the hard-irq context, not soft-irq and fix the existing drivers.
> 3. Try to free the descriptors not only from tasklet but also from the
> place they get requested.
This is what ioatdma and iop-adma do i.e. process descriptor reclaim
from the allocation failure path. For example in ioat2_check_space_lock():
/* progress reclaim in the allocation failure case we may be
* called under bh_disabled so we need to trigger the timer
* event directly
*/
if (jiffies > chan->timer.expires && timer_pending(&chan->timer)) {
struct ioatdma_device *device = chan->device;
mod_timer(&chan->timer, jiffies + COMPLETION_TIMEOUT);
device->timer_fn((unsigned long) &chan->common);
}
The assumption is that a free descriptor is always a short time delay.
> Maybe somebody has a better solution.
Not really, but extending dmatest with a test for this expectation would
help make this more clear but it would need a config option that injects
descriptor allocation failures.
--
Dan
^ permalink raw reply
* Re: [PATCH] sdhci: highspeed: check for mmc as well as sd cards
From: Philip Rakity @ 2010-10-07 23:27 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org
In-Reply-To: <41A82D88-6200-469C-986D-EF46B0C6A773@marvell.com>
validated code when testing eMMC dual data rate.
On Oct 6, 2010, at 11:57 AM, Philip Rakity wrote:
>
> when examining the code in the mmc directory the SD and MMC code
> set highspeed using a different constant. Change the sd driver
> to recognize this and switch to high speed.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
> ---
> drivers/mmc/host/sdhci.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index d3f924b..1d3f4d8 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1194,8 +1194,9 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> else
> ctrl &= ~SDHCI_CTRL_4BITBUS;
>
> - if (ios->timing == MMC_TIMING_SD_HS &&
> - !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> + if ((ios->timing == MMC_TIMING_SD_HS
> + || ios->timing == MMC_TIMING_MMC_HS)
> + && !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> ctrl |= SDHCI_CTRL_HISPD;
> else
> ctrl &= ~SDHCI_CTRL_HISPD;
> --
> 1.6.0.4
>
^ permalink raw reply
* Re: [rtc-linux] RE: [PATCH 5/5] rtc: rtc-s3c: Fix debug message format on RTC
From: Andrew Morton @ 2010-10-07 23:28 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Wan ZongShun', rtc-linux, p_gortmaker, linux-samsung-soc,
linux-arm-kernel, 'Ben Dooks', a.zummo
In-Reply-To: <00c101cb6675$bb8e67f0$32ab37d0$%kim@samsung.com>
On Fri, 08 Oct 2010 08:16:44 +0900
Kukjin Kim <kgene.kim@samsung.com> wrote:
> Updated patch 1/5 has been tested on S3C24XX and its working fine.
> Its remained issue is that Ben was wondering its working on S3C24XX.
>
> And about the patch 4/5, I did address comments from Ben Dooks and Wan
> ZongShun.
ok...
> So could you please handle this series?
> If any problems, please kindly let me know.
>
> They are since commit cb655d0f3d57c23db51b981648e452988c0223f9:
> Linux 2.6.36-rc7 (2010-10-06 13:39:52 -0700)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> next-rtc-s3c
Can you please email them all out in the old-fashioned way? Because a)
I don't manage patches with git and b) that way people will actually
look at the code.
Thanks.
^ permalink raw reply
* [rtc-linux] RE: [PATCH 5/5] rtc: rtc-s3c: Fix debug message format on RTC
From: Andrew Morton @ 2010-10-07 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00c101cb6675$bb8e67f0$32ab37d0$%kim@samsung.com>
On Fri, 08 Oct 2010 08:16:44 +0900
Kukjin Kim <kgene.kim@samsung.com> wrote:
> Updated patch 1/5 has been tested on S3C24XX and its working fine.
> Its remained issue is that Ben was wondering its working on S3C24XX.
>
> And about the patch 4/5, I did address comments from Ben Dooks and Wan
> ZongShun.
ok...
> So could you please handle this series?
> If any problems, please kindly let me know.
>
> They are since commit cb655d0f3d57c23db51b981648e452988c0223f9:
> Linux 2.6.36-rc7 (2010-10-06 13:39:52 -0700)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> next-rtc-s3c
Can you please email them all out in the old-fashioned way? Because a)
I don't manage patches with git and b) that way people will actually
look at the code.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] procfs: fix numbering in /proc/locks
From: Andrew Morton @ 2010-10-07 23:27 UTC (permalink / raw)
To: Jerome Marchand
Cc: Matthew Wilcox, Pavel Emelyanov, Linux Kernel Mailing List,
xiyou.wangcong
In-Reply-To: <4CAB1693.2080301@redhat.com>
On Tue, 05 Oct 2010 14:14:11 +0200
Jerome Marchand <jmarchan@redhat.com> wrote:
> On 09/30/2010 02:38 PM, Jerome Marchand wrote:
> >
> > The lock number in /proc/locks (first field) is implemented by a counter
> > (private field of struct seq_file) which is incremented at each call of
> > locks_show() and reset to 1 in locks_start() whatever the offset is. It
> > should be reset according to the actual position in the list.
> >
> > Moreover, locks_show() can be called twice to print a single line thus
> > skipping a number. The counter should be incremented in locks_next().
> >
> > Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
> > ---
> > locks.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/locks.c b/fs/locks.c
> > index ab24d49..49d7343 100644
> > --- a/fs/locks.c
> > +++ b/fs/locks.c
> > @@ -2166,19 +2166,19 @@ static int locks_show(struct seq_file *f, void *v)
> > list_for_each_entry(bfl, &fl->fl_block, fl_block)
> > lock_get_status(f, bfl, (long)f->private, " ->");
> >
> > - f->private++;
> > return 0;
> > }
> >
> > static void *locks_start(struct seq_file *f, loff_t *pos)
> > {
> > lock_kernel();
> > - f->private = (void *)1;
> > + f->private = (void *) (*pos + 1);
>
> That cast trigger a warning on some arch:
> "warning: cast to pointer from integer of different size"
>
> There is no real risk here. At worst /proc/locks will show wrong number
> if there is more than 2^32 locks, but should I mute the warning it with
> something like:
> f->private = (void *) (size_t) (*pos + 1);
> ?
Putting a loff_t into a void* is a pretty alarming thing to do. If
we're really going to do that then use a (long) cast and put a very
good comment at the code site explaining why the bug doesn't matter, so
people aren't misled.
But really, why sweat it? kmalloc the eight bytes, make ->private
point at that and we never have to think about it again. Bonus points
for doing this without any typecasts ;)
^ permalink raw reply
* Re: 2.6.36-rc5 i915 regression
From: Seblu @ 2010-10-07 23:24 UTC (permalink / raw)
To: Zhenyu Wang, Seblu, Chris Wilson, intel-gfx
In-Reply-To: <20101002090753.GB3265@zhen-devel.sh.intel.com>
On Sat, Oct 2, 2010 at 11:07 AM, Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> On 2010.10.01 22:27:45 +0200, Seblu wrote:
>> On Fri, Oct 1, 2010 at 3:22 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> > On Fri, 1 Oct 2010 12:55:56 +0000 (UTC), Seblu <seblu@seblu.net> wrote:
>> >> I've the same kind trouble with -rc6 and my dell e6410. When module i915 is
>> >> loaded screen become black and i loose the hand on the system.
>> >
>> > Nope, completely different bug. eDP being the issue here. Though I think
>> > the Dell 6410 is one of the few that Jesse has been able to get working
>> > (in drm-intel--next)
>>
>> You speek about eDP, but i don't use the external DisplayPort. Despite
>> that you think, this can be linked?
>
> eDP is embedded DP link to your laptop panel, it's an alternative replacement
> for LVDS.
thx
>
> I sent mail before to ask if ajax's eDP connector type change for PCH/eDP
> has caused regression for that, but one e6410 owner replied no effect by
> revert that patch. You may help by bisect drm/i915.
Ok i can try (first time). To understand correclty what you want, i
have to download linux 2.6.36-rc6 git, bisect, compile an run kernel
until i found the commit cause the issue?
I will test new rc7 in near time to show if my display come back.
--
Sébastien Luttringer
www.seblu.net
^ permalink raw reply
* Re: fallocate() on XFS clobbers S*ID-bits
From: Dave Chinner @ 2010-10-07 23:24 UTC (permalink / raw)
To: Andreas Wiese; +Cc: Linux Kernel Mailing List, Ciaran McCreesh, xfs
In-Reply-To: <20101007183418.GC5621@incendiary.meterriblecrew.net>
[ added xfs list on cc ]
On Thu, Oct 07, 2010 at 08:34:19PM +0200, Andreas Wiese wrote:
> Hello.
>
> I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
> fallocate() on XFS. After open()ing some file and setting it S*ID via
> fchmod(), S*ID bits vanish after calling fallocate() — as supposed to
> for non-root users, but it also happens for root.
>
> Is this intended behaviour or did we spot a bug here?
>
> At least on ext2 it works as expected, thus I guess it's the latter one.
ext2 does not support the fallocate syscall. How does ext4 behave?
> I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master
> doesn't seem to address this issue.
XFS has always cleared SUID/SGID bits when doing preallocation (via
XFS_IOC_RESVSP). Given that that XFS ioctl formed the model for
fallocate, I'd argue that the XFS behaviour is the on that should be
followed.
It'd be a bit silly for two different preallocation interfaces to
have different behaviour w.r.t. SUID bits, but it's not clear to me
which behaviour is correct. I'm happy to defer to whoever can say
what the behaviour is supposed to be here...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* [PATCH] ehea: simplify conditional
From: Nicolas Kaiser @ 2010-10-07 23:14 UTC (permalink / raw)
To: Breno Leitao; +Cc: netdev, linux-kernel
Simplify: ((a && b) || (!a && !b)) => (a == b)
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
---
drivers/net/ehea/ehea_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 190fb69..ef305f3 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1914,7 +1914,7 @@ static void ehea_promiscuous(struct net_device *dev, int enable)
struct hcp_ehea_port_cb7 *cb7;
u64 hret;
- if ((enable && port->promisc) || (!enable && !port->promisc))
+ if (enable == port->promisc)
return;
cb7 = (void *)get_zeroed_page(GFP_ATOMIC);
--
1.7.2.2
^ permalink raw reply related
* Re: fallocate() on XFS clobbers S*ID-bits
From: Dave Chinner @ 2010-10-07 23:24 UTC (permalink / raw)
To: Andreas Wiese; +Cc: xfs, Linux Kernel Mailing List, Ciaran McCreesh
In-Reply-To: <20101007183418.GC5621@incendiary.meterriblecrew.net>
[ added xfs list on cc ]
On Thu, Oct 07, 2010 at 08:34:19PM +0200, Andreas Wiese wrote:
> Hello.
>
> I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
> fallocate() on XFS. After open()ing some file and setting it S*ID via
> fchmod(), S*ID bits vanish after calling fallocate() — as supposed to
> for non-root users, but it also happens for root.
>
> Is this intended behaviour or did we spot a bug here?
>
> At least on ext2 it works as expected, thus I guess it's the latter one.
ext2 does not support the fallocate syscall. How does ext4 behave?
> I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master
> doesn't seem to address this issue.
XFS has always cleared SUID/SGID bits when doing preallocation (via
XFS_IOC_RESVSP). Given that that XFS ioctl formed the model for
fallocate, I'd argue that the XFS behaviour is the on that should be
followed.
It'd be a bit silly for two different preallocation interfaces to
have different behaviour w.r.t. SUID bits, but it's not clear to me
which behaviour is correct. I'm happy to defer to whoever can say
what the behaviour is supposed to be here...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
To: Ian Munsie
Cc: linux-kernel, linuxppc-dev, benh, paulus, Stefan Weil,
Jiri Kosina, Sean MacLennan, Greg Kroah-Hartman, Michal Simek,
David S. Miller, devicetree-discuss
In-Reply-To: <1285916771-18033-15-git-send-email-imunsie@au1.ibm.com>
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
>
> Also fix other device tree references in the legacy serial code.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Applied, thanks.
I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.
As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.
g.
> ---
> arch/powerpc/kernel/legacy_serial.c | 22 +++++++++++-----------
> drivers/serial/of_serial.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> phys_addr_t taddr, unsigned long irq,
> upf_t flags, int irq_check_parent)
> {
> - const u32 *clk, *spd;
> + const __be32 *clk, *spd;
> u32 clock = BASE_BAUD * 16;
> int index;
>
> /* get clock freq. if present */
> clk = of_get_property(np, "clock-frequency", NULL);
> if (clk && *clk)
> - clock = *clk;
> + clock = be32_to_cpup(clk);
>
> /* get default speed if present */
> spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> legacy_serial_infos[index].taddr = taddr;
> legacy_serial_infos[index].np = of_node_get(np);
> legacy_serial_infos[index].clock = clock;
> - legacy_serial_infos[index].speed = spd ? *spd : 0;
> + legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
> legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>
> printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
> static int __init add_legacy_isa_port(struct device_node *np,
> struct device_node *isa_brg)
> {
> - const u32 *reg;
> + const __be32 *reg;
> const char *typep;
> int index = -1;
> u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> return -1;
>
> /* Verify it's an IO port, we don't support anything else */
> - if (!(reg[0] & 0x00000001))
> + if (!(be32_to_cpu(reg[0]) & 0x00000001))
> return -1;
>
> /* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> taddr = 0;
>
> /* Add port, irq will be dealt with later */
> - return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> + return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
> NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>
> }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
> * we get to their "reg" property
> */
> if (np != pci_dev) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg && (*reg < 4))
> - index = lindex = *reg;
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> + if (reg && (be32_to_cpup(reg) < 4))
> + index = lindex = be32_to_cpup(reg);
> }
>
> /* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
> struct device_node *prom_stdout = NULL;
> int i, speed = 0, offset = 0;
> const char *name;
> - const u32 *spd;
> + const __be32 *spd;
>
> DBG(" -> check_legacy_serial_console()\n");
>
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
> }
> spd = of_get_property(prom_stdout, "current-speed", NULL);
> if (spd)
> - speed = *spd;
> + speed = be32_to_cpup(spd);
>
> if (strcmp(name, "serial") != 0)
> goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->dev.of_node;
> - const unsigned int *clk, *spd;
> - const u32 *prop;
> + const __be32 *clk, *spd;
> + const __be32 *prop;
> int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> /* Check for shifted address mapping */
> prop = of_get_property(np, "reg-offset", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->mapbase += *prop;
> + port->mapbase += be32_to_cpup(prop);
>
> /* Check for registers offset within the devices address range */
> prop = of_get_property(np, "reg-shift", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->regshift = *prop;
> + port->regshift = be32_to_cpup(prop);
>
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
> - port->uartclk = *clk;
> + port->uartclk = be32_to_cpup(clk);
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
> /* If current-speed was set, then try not to change it. */
> if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>
> return 0;
> }
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
To: Ian Munsie
Cc: Greg Kroah-Hartman, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Sean MacLennan, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Weil,
Jiri Kosina, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, David S. Miller
In-Reply-To: <1285916771-18033-15-git-send-email-imunsie-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
>
> Also fix other device tree references in the legacy serial code.
>
> Signed-off-by: Ian Munsie <imunsie-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
Applied, thanks.
I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.
As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.
g.
> ---
> arch/powerpc/kernel/legacy_serial.c | 22 +++++++++++-----------
> drivers/serial/of_serial.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> phys_addr_t taddr, unsigned long irq,
> upf_t flags, int irq_check_parent)
> {
> - const u32 *clk, *spd;
> + const __be32 *clk, *spd;
> u32 clock = BASE_BAUD * 16;
> int index;
>
> /* get clock freq. if present */
> clk = of_get_property(np, "clock-frequency", NULL);
> if (clk && *clk)
> - clock = *clk;
> + clock = be32_to_cpup(clk);
>
> /* get default speed if present */
> spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> legacy_serial_infos[index].taddr = taddr;
> legacy_serial_infos[index].np = of_node_get(np);
> legacy_serial_infos[index].clock = clock;
> - legacy_serial_infos[index].speed = spd ? *spd : 0;
> + legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
> legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>
> printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
> static int __init add_legacy_isa_port(struct device_node *np,
> struct device_node *isa_brg)
> {
> - const u32 *reg;
> + const __be32 *reg;
> const char *typep;
> int index = -1;
> u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> return -1;
>
> /* Verify it's an IO port, we don't support anything else */
> - if (!(reg[0] & 0x00000001))
> + if (!(be32_to_cpu(reg[0]) & 0x00000001))
> return -1;
>
> /* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> taddr = 0;
>
> /* Add port, irq will be dealt with later */
> - return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> + return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
> NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>
> }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
> * we get to their "reg" property
> */
> if (np != pci_dev) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg && (*reg < 4))
> - index = lindex = *reg;
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> + if (reg && (be32_to_cpup(reg) < 4))
> + index = lindex = be32_to_cpup(reg);
> }
>
> /* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
> struct device_node *prom_stdout = NULL;
> int i, speed = 0, offset = 0;
> const char *name;
> - const u32 *spd;
> + const __be32 *spd;
>
> DBG(" -> check_legacy_serial_console()\n");
>
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
> }
> spd = of_get_property(prom_stdout, "current-speed", NULL);
> if (spd)
> - speed = *spd;
> + speed = be32_to_cpup(spd);
>
> if (strcmp(name, "serial") != 0)
> goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->dev.of_node;
> - const unsigned int *clk, *spd;
> - const u32 *prop;
> + const __be32 *clk, *spd;
> + const __be32 *prop;
> int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> /* Check for shifted address mapping */
> prop = of_get_property(np, "reg-offset", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->mapbase += *prop;
> + port->mapbase += be32_to_cpup(prop);
>
> /* Check for registers offset within the devices address range */
> prop = of_get_property(np, "reg-shift", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->regshift = *prop;
> + port->regshift = be32_to_cpup(prop);
>
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
> - port->uartclk = *clk;
> + port->uartclk = be32_to_cpup(clk);
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
> /* If current-speed was set, then try not to change it. */
> if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>
> return 0;
> }
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
To: Ian Munsie
Cc: Michal Simek, Greg Kroah-Hartman, devicetree-discuss,
Sean MacLennan, linux-kernel, Stefan Weil, paulus, Jiri Kosina,
linuxppc-dev, David S. Miller
In-Reply-To: <1285916771-18033-15-git-send-email-imunsie@au1.ibm.com>
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
>
> Also fix other device tree references in the legacy serial code.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Applied, thanks.
I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.
As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.
g.
> ---
> arch/powerpc/kernel/legacy_serial.c | 22 +++++++++++-----------
> drivers/serial/of_serial.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> phys_addr_t taddr, unsigned long irq,
> upf_t flags, int irq_check_parent)
> {
> - const u32 *clk, *spd;
> + const __be32 *clk, *spd;
> u32 clock = BASE_BAUD * 16;
> int index;
>
> /* get clock freq. if present */
> clk = of_get_property(np, "clock-frequency", NULL);
> if (clk && *clk)
> - clock = *clk;
> + clock = be32_to_cpup(clk);
>
> /* get default speed if present */
> spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> legacy_serial_infos[index].taddr = taddr;
> legacy_serial_infos[index].np = of_node_get(np);
> legacy_serial_infos[index].clock = clock;
> - legacy_serial_infos[index].speed = spd ? *spd : 0;
> + legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
> legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>
> printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
> static int __init add_legacy_isa_port(struct device_node *np,
> struct device_node *isa_brg)
> {
> - const u32 *reg;
> + const __be32 *reg;
> const char *typep;
> int index = -1;
> u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> return -1;
>
> /* Verify it's an IO port, we don't support anything else */
> - if (!(reg[0] & 0x00000001))
> + if (!(be32_to_cpu(reg[0]) & 0x00000001))
> return -1;
>
> /* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> taddr = 0;
>
> /* Add port, irq will be dealt with later */
> - return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> + return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
> NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>
> }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
> * we get to their "reg" property
> */
> if (np != pci_dev) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg && (*reg < 4))
> - index = lindex = *reg;
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> + if (reg && (be32_to_cpup(reg) < 4))
> + index = lindex = be32_to_cpup(reg);
> }
>
> /* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
> struct device_node *prom_stdout = NULL;
> int i, speed = 0, offset = 0;
> const char *name;
> - const u32 *spd;
> + const __be32 *spd;
>
> DBG(" -> check_legacy_serial_console()\n");
>
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
> }
> spd = of_get_property(prom_stdout, "current-speed", NULL);
> if (spd)
> - speed = *spd;
> + speed = be32_to_cpup(spd);
>
> if (strcmp(name, "serial") != 0)
> goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->dev.of_node;
> - const unsigned int *clk, *spd;
> - const u32 *prop;
> + const __be32 *clk, *spd;
> + const __be32 *prop;
> int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> /* Check for shifted address mapping */
> prop = of_get_property(np, "reg-offset", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->mapbase += *prop;
> + port->mapbase += be32_to_cpup(prop);
>
> /* Check for registers offset within the devices address range */
> prop = of_get_property(np, "reg-shift", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->regshift = *prop;
> + port->regshift = be32_to_cpup(prop);
>
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
> - port->uartclk = *clk;
> + port->uartclk = be32_to_cpup(clk);
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
> /* If current-speed was set, then try not to change it. */
> if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>
> return 0;
> }
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH] wireless: Set some stats used by /proc/net/wireless (wext)
From: Johannes Berg @ 2010-10-07 23:19 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1286493275-18364-1-git-send-email-greearb@candelatech.com>
On Thu, 2010-10-07 at 16:14 -0700, greearb@candelatech.com wrote:
> @@ -468,6 +468,7 @@ struct rate_info {
> * @tx_packets: packets transmitted to this station
> * @tx_retries: cumulative retry counts
> * @tx_failed: number of failed transmissions (retries exceeded, no ACK)
> + * @rx_dropped_misc: Dropped for un-specified reason.
also need to use/adjust "filled" throughout.
johannes
^ permalink raw reply
* Re: [PATCH] Make it possible to set a uuid if one was not set during DM_DEV_CREATE.
From: Jonathan Brassow @ 2010-10-07 23:19 UTC (permalink / raw)
To: device-mapper development
In-Reply-To: <1286479718-18274-1-git-send-email-pjones@redhat.com>
Minor nits below
brassow
On Oct 7, 2010, at 2:28 PM, Peter Jones wrote:
> This makes it possible to use DM_DEV_RENAME to add a uuid to a
> device so
> long as one has not been previously set either with DM_DEV_CREATE or
> with DM_DEV_RENAME.
Seems like a sensible thing. Is there a reason this is coming up now?
>
> Also bump the minor number to 19.
> ---
> drivers/md/dm-ioctl.c | 113 +++++++++++++++++++++++++++++++
> +-------------
> include/linux/dm-ioctl.h | 9 +++-
> 2 files changed, 87 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
> index 3e39193..bd76846 100644
> --- a/drivers/md/dm-ioctl.c
> +++ b/drivers/md/dm-ioctl.c
> @@ -298,7 +298,7 @@ retry:
> static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
>
<snip>
> /*
> @@ -333,19 +347,42 @@ static struct mapped_device
> *dm_hash_rename(struct dm_ioctl *param,
> DMWARN("asked to rename a non-existent device %s -> %s",
> param->name, new);
> up_write(&_hash_lock);
> - kfree(new_name);
> + kfree(new_data);
> return ERR_PTR(-ENXIO);
> }
>
> - /*
> - * rename and move the name cell.
> - */
> - list_del(&hc->name_list);
> - old_name = hc->name;
> - mutex_lock(&dm_hash_cells_mutex);
> - hc->name = new_name;
> - mutex_unlock(&dm_hash_cells_mutex);
> - list_add(&hc->name_list, _name_buckets + hash_str(new_name));
> + if (param->flags & DM_NEW_UUID_FLAG) {
> + /*
> + * Does this device already have a uuid?
> + */
> + if (hc->uuid) {
> + DMWARN("asked to change uuid of device with uuid "
> + "already set %s %s -> %s",
> + param->name, hc->uuid, param->uuid);
Message doesn't imply this is illegal... Perhaps "Unable to change...
set"?
> + up_write(&_hash_lock);
> + kfree(new_uuid);
Will patch compile? s/new_uuid/new_data/
> + return ERR_PTR(-EINVAL);
> + }
> + /*
> + * reuuid and move the uuid cell.
> + */
> + list_del(&hc->uuid_list);
> + old_data = hc->uuid;
> + mutex_lock(&dm_hash_cells_mutex);
> + hc->uuid = new_data;
> + mutex_unlock(&dm_hash_cells_mutex);
> + list_add(&hc->uuid_list, _uuid_buckets + hash_str(new_data));
> + } else {
> + /*
> + * rename and move the name cell.
> + */
> + list_del(&hc->name_list);
> + old_data = hc->name;
> + mutex_lock(&dm_hash_cells_mutex);
> + hc->name = new_data;
> + mutex_unlock(&dm_hash_cells_mutex);
> + list_add(&hc->name_list, _name_buckets + hash_str(new_data));
> + }
>
> /*
> * Wake up any dm event waiters.
> @@ -361,7 +398,7 @@ static struct mapped_device
> *dm_hash_rename(struct dm_ioctl *param,
>
> md = hc->md;
> up_write(&_hash_lock);
> - kfree(old_name);
> + kfree(old_data);
>
> return md;
> }
> @@ -774,21 +811,31 @@ static int invalid_str(char *str, void *end)
> static int dev_rename(struct dm_ioctl *param, size_t param_size)
> {
> int r;
> - char *new_name = (char *) param + param->data_start;
> + char *new_data = (char *) param + param->data_start;
> struct mapped_device *md;
>
> - if (new_name < param->data ||
> - invalid_str(new_name, (void *) param + param_size) ||
> - strlen(new_name) > DM_NAME_LEN - 1) {
> - DMWARN("Invalid new logical volume name supplied.");
> - return -EINVAL;
> - }
> + if (param->flags & DM_NEW_UUID_FLAG) {
> + struct hash_cell *hc;
Is this newly declared variable needed?
> + if (new_data < param->data ||
> + invalid_str(new_data, (void *) param + param_size) ||
> + strlen(new_data) > DM_UUID_LEN - 1) {
> + DMWARN("Invalid new logical volume uuid supplied.");
I wonder why we were using "logical volume" instead of "device" like
everywhere else... can we change it now?
> + return -EINVAL;
> + }
> + } else {
> + if (new_data < param->data ||
> + invalid_str(new_data, (void *) param + param_size) ||
> + strlen(new_data) > DM_NAME_LEN - 1) {
> + DMWARN("Invalid new logical volume name supplied.");
s/logical volume/device/
> + return -EINVAL;
> + }
>
> - r = check_name(new_name);
> - if (r)
> - return r;
> + r = check_name(new_data);
> + if (r)
> + return r;
> + }
>
> - md = dm_hash_rename(param, new_name);
> + md = dm_hash_rename(param, new_data);
> if (IS_ERR(md))
> return PTR_ERR(md);
>
> diff --git a/include/linux/dm-ioctl.h b/include/linux/dm-ioctl.h
> index 49eab36..e369460 100644
> --- a/include/linux/dm-ioctl.h
> +++ b/include/linux/dm-ioctl.h
> @@ -267,9 +267,9 @@ enum {
> #define DM_DEV_SET_GEOMETRY _IOWR(DM_IOCTL, DM_DEV_SET_GEOMETRY_CMD,
> struct dm_ioctl)
>
> #define DM_VERSION_MAJOR 4
> -#define DM_VERSION_MINOR 18
> +#define DM_VERSION_MINOR 19
> #define DM_VERSION_PATCHLEVEL 0
> -#define DM_VERSION_EXTRA "-ioctl (2010-06-29)"
> +#define DM_VERSION_EXTRA "-ioctl (2010-10-07)"
>
> /* Status bits */
> #define DM_READONLY_FLAG (1 << 0) /* In/Out */
> @@ -322,4 +322,9 @@ enum {
> */
> #define DM_UEVENT_GENERATED_FLAG (1 << 13) /* Out */
>
> +/*
> + * If set, rename operates on uuid, not name.
> + */
> +#define DM_NEW_UUID_FLAG (1 << 14) /* In */
> +
> #endif /* _LINUX_DM_IOCTL_H */
> --
> 1.7.2.2
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply
* task blocked for more than 120 seconds.
From: Shawn Bohrer @ 2010-10-07 23:18 UTC (permalink / raw)
To: linux-nfs; +Cc: linux-kernel
Hello,
I've got some machines with nfs mounted home directories and recently
had the machines lock up with the following output below from the
kernel logs. This machine was running 2.6.32.21 at the time, and
was locked up for at least 20 minutes before we rebooted. We've had
this happen to us twice now, so while I haven't tried I believe we can
reproduce it in about a day.
Does anyone have any insight on what may be happening here or any
suggestions for debugging?
Thanks,
Shawn
INFO: task java:24970 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff88189c50e198 0 24970 24239 0x00000000
ffff88205b7339c8 0000000000000086 0000000000000000 000000005ae2d09c
0000000000000286 0000000000000030 ffff88205b733988 000000010174a797
ffff88205acd4a80 ffff88205b733fd8 000000000000e198 ffff88205acd4a80
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff8100c9ce>] ? common_interrupt+0xe/0x13
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff81047774>] ? __enqueue_entity+0x84/0x90
[<ffffffff8104f7d5>] ? enqueue_task_fair+0x45/0x90
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24982 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff8800283ee198 0 24982 24239 0x00000000
ffff88104f6339c8 0000000000000086 0000000000000000 00000000ffffff10
0000000000000286 0000000000000030 0000000000000282 000000010174a681
ffff88105a592580 ffff88104f633fd8 000000000000e198 ffff88105a592580
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff810ffef9>] ? do_wp_page+0x109/0x7c0
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task hbitimestamp:23184 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
hbitimestamp D ffff88109c6ae198 0 23184 23175 0x00000000
ffff880855d179c8 0000000000000086 0000000000000000 000000005bb2d600
0000000000000282 0000000000000030 0000000000000282 00000001017445ab
ffff8808577bc640 ffff880855d17fd8 000000000000e198 ffff8808577bc640
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8100cb4e>] ? apic_timer_interrupt+0xe/0x20
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8141c74e>] ? do_device_not_available+0xe/0x10
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24970 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff88189c50e198 0 24970 24239 0x00000000
ffff88205b7339c8 0000000000000086 0000000000000000 000000005ae2d09c
0000000000000286 0000000000000030 ffff88205b733988 000000010174a797
ffff88205acd4a80 ffff88205b733fd8 000000000000e198 ffff88205acd4a80
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff8100c9ce>] ? common_interrupt+0xe/0x13
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff81047774>] ? __enqueue_entity+0x84/0x90
[<ffffffff8104f7d5>] ? enqueue_task_fair+0x45/0x90
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24982 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff8800283ee198 0 24982 24239 0x00000000
ffff88104f6339c8 0000000000000086 0000000000000000 00000000ffffff10
0000000000000286 0000000000000030 0000000000000282 000000010174a681
ffff88105a592580 ffff88104f633fd8 000000000000e198 ffff88105a592580
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff810ffef9>] ? do_wp_page+0x109/0x7c0
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task tail:22115 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
tail D ffff88189c4ee198 0 22115 14494 0x00000000
ffff88085b95bbd8 0000000000000086 0000000000000000 ffffffffa035d896
ffff88205be57cc8 ffff88205be57cc8 ffff88205be57cc8 000000010174d70e
ffff8808564fe400 ffff88085b95bfd8 000000000000e198 ffff8808564fe400
Call Trace:
[<ffffffffa035d896>] ? __rpc_execute+0xd6/0x2a0 [sunrpc]
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa04037d2>] nfs_sync_mapping_wait+0x122/0x260 [nfs]
[<ffffffffa0403aa9>] nfs_write_mapping+0x79/0xb0 [nfs]
[<ffffffffa0403afa>] nfs_wb_nocommit+0x1a/0x20 [nfs]
[<ffffffffa03f60f8>] nfs_getattr+0x128/0x140 [nfs]
[<ffffffff811351d1>] vfs_getattr+0x51/0x80
[<ffffffff8113548f>] vfs_fstat+0x3f/0x60
[<ffffffff811354d4>] sys_newfstat+0x24/0x40
[<ffffffff810841a4>] ? sys_nanosleep+0x74/0x80
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task hbitimestamp:23184 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
hbitimestamp D ffff88109c6ae198 0 23184 23175 0x00000000
ffff880855d179c8 0000000000000086 0000000000000000 000000005bb2d600
0000000000000282 0000000000000030 0000000000000282 00000001017445ab
ffff8808577bc640 ffff880855d17fd8 000000000000e198 ffff8808577bc640
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8100cb4e>] ? apic_timer_interrupt+0xe/0x20
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8141c74e>] ? do_device_not_available+0xe/0x10
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24970 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff88189c50e198 0 24970 24239 0x00000000
ffff88205b7339c8 0000000000000086 0000000000000000 000000005ae2d09c
0000000000000286 0000000000000030 ffff88205b733988 000000010174a797
ffff88205acd4a80 ffff88205b733fd8 000000000000e198 ffff88205acd4a80
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff8100c9ce>] ? common_interrupt+0xe/0x13
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff81047774>] ? __enqueue_entity+0x84/0x90
[<ffffffff8104f7d5>] ? enqueue_task_fair+0x45/0x90
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24982 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff8800283ee198 0 24982 24239 0x00000000
ffff88104f6339c8 0000000000000086 0000000000000000 00000000ffffff10
0000000000000286 0000000000000030 0000000000000282 000000010174a681
ffff88105a592580 ffff88104f633fd8 000000000000e198 ffff88105a592580
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff810ffef9>] ? do_wp_page+0x109/0x7c0
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task hbitimestamp:24427 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
hbitimestamp D ffff88089c40e198 0 24427 24317 0x00000000
ffff88205a0b3c88 0000000000000082 0000000000000000 0000000000000000
ffff88205a0b3ca8 ffffffff814196a8 0000000000000000 00000001017777de
ffff88205a6ec8c0 ffff88205a0b3fd8 000000000000e198 ffff88205a6ec8c0
Call Trace:
[<ffffffff814196a8>] ? thread_return+0x4e/0x726
[<ffffffff8141aac1>] __mutex_lock_slowpath+0xf1/0x170
[<ffffffff8141a9ab>] mutex_lock+0x2b/0x50
[<ffffffff810e2879>] generic_file_aio_write+0x59/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff810fcb91>] ? __do_fault+0x3e1/0x4c0
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8116a68f>] ? inotify_inode_queue_event+0x2f/0x120
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8141c74e>] ? do_device_not_available+0xe/0x10
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* [PATCH] ehea: Fix a checksum issue on the receive path
From: leitao @ 2010-10-07 23:17 UTC (permalink / raw)
To: davem; +Cc: netdev, Breno Leitao, Jay Vosburgh
Currently we set all skbs with CHECKSUM_UNNECESSARY, even
those whose protocol we don't know. This patch just
add the CHECKSUM_COMPLETE tag for non TCP/UDP packets.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
---
drivers/net/ehea/ehea_main.c | 9 ++++++++-
drivers/net/ehea/ehea_qmr.h | 1 +
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 0471cae..45fd045 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -533,8 +533,15 @@ static inline void ehea_fill_skb(struct net_device *dev,
int length = cqe->num_bytes_transfered - 4; /*remove CRC */
skb_put(skb, length);
- skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->protocol = eth_type_trans(skb, dev);
+
+ /* The packet was not an IPV4 packet so a complemented checksum was
+ calculated. The value is found in the Internet Checksum field. */
+ if (cqe->status & EHEA_CQE_BLIND_CKSUM) {
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ skb->csum = csum_unfold(~cqe->inet_checksum_value);
+ } else
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
}
static inline struct sk_buff *get_skb_by_index(struct sk_buff **skb_array,
diff --git a/drivers/net/ehea/ehea_qmr.h b/drivers/net/ehea/ehea_qmr.h
index f608a6c..3810473 100644
--- a/drivers/net/ehea/ehea_qmr.h
+++ b/drivers/net/ehea/ehea_qmr.h
@@ -150,6 +150,7 @@ struct ehea_rwqe {
#define EHEA_CQE_TYPE_RQ 0x60
#define EHEA_CQE_STAT_ERR_MASK 0x700F
#define EHEA_CQE_STAT_FAT_ERR_MASK 0xF
+#define EHEA_CQE_BLIND_CKSUM 0x8000
#define EHEA_CQE_STAT_ERR_TCP 0x4000
#define EHEA_CQE_STAT_ERR_IP 0x2000
#define EHEA_CQE_STAT_ERR_CRC 0x1000
--
1.6.5
^ permalink raw reply related
* + alpha-use-single-hae-window-on-t2-core-logic-gamma-sable.patch added to -mm tree
From: akpm @ 2010-10-07 23:16 UTC (permalink / raw)
To: mm-commits; +Cc: ink, mattst88, rth
The patch titled
alpha: use single HAE window on T2 core logic (gamma, sable)
has been added to the -mm tree. Its filename is
alpha-use-single-hae-window-on-t2-core-logic-gamma-sable.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: alpha: use single HAE window on T2 core logic (gamma, sable)
From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
T2 are the only alpha SMP systems that do HAE switching at runtime, which
is fundamentally racy on SMP. This patch limits MMIO space on T2 to HAE0
only, like we did on MCPCIA (rawhide) long ago. This leaves us with only
112 Mb of PCI MMIO (128 Mb HAE aperture minus 16 Mb reserved for EISA),
but since linux PCI allocations are reasonably tight, it should be enough
for sane hardware configurations.
Also, fix a typo in MCPCIA_FROB_MMIO macro which shouldn't call set_hae()
if MCPCIA_ONE_HAE_WINDOW is defined. It's more for correctness, as
set_hae() is a no-op anyway in that case.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/alpha/include/asm/core_mcpcia.h | 2
arch/alpha/include/asm/core_t2.h | 54 ++++++++-----------------
arch/alpha/kernel/core_t2.c | 11 +++--
arch/alpha/kernel/machvec_impl.h | 3 +
4 files changed, 30 insertions(+), 40 deletions(-)
diff -puN arch/alpha/include/asm/core_mcpcia.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable arch/alpha/include/asm/core_mcpcia.h
--- a/arch/alpha/include/asm/core_mcpcia.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable
+++ a/arch/alpha/include/asm/core_mcpcia.h
@@ -247,7 +247,7 @@ struct el_MCPCIA_uncorrected_frame_mchec
#define vip volatile int __force *
#define vuip volatile unsigned int __force *
-#ifdef MCPCIA_ONE_HAE_WINDOW
+#ifndef MCPCIA_ONE_HAE_WINDOW
#define MCPCIA_FROB_MMIO \
if (__mcpcia_is_mmio(hose)) { \
set_hae(hose & 0xffffffff); \
diff -puN arch/alpha/include/asm/core_t2.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable arch/alpha/include/asm/core_t2.h
--- a/arch/alpha/include/asm/core_t2.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable
+++ a/arch/alpha/include/asm/core_t2.h
@@ -1,6 +1,9 @@
#ifndef __ALPHA_T2__H__
#define __ALPHA_T2__H__
+/* Fit everything into one 128MB HAE window. */
+#define T2_ONE_HAE_WINDOW 1
+
#include <linux/types.h>
#include <linux/spinlock.h>
#include <asm/compiler.h>
@@ -19,7 +22,7 @@
*
*/
-#define T2_MEM_R1_MASK 0x07ffffff /* Mem sparse region 1 mask is 26 bits */
+#define T2_MEM_R1_MASK 0x07ffffff /* Mem sparse region 1 mask is 27 bits */
/* GAMMA-SABLE is a SABLE with EV5-based CPUs */
/* All LYNX machines, EV4 or EV5, use the GAMMA bias also */
@@ -85,7 +88,9 @@
#define T2_DIR (IDENT_ADDR + GAMMA_BIAS + 0x38e0004a0UL)
#define T2_ICE (IDENT_ADDR + GAMMA_BIAS + 0x38e0004c0UL)
+#ifndef T2_ONE_HAE_WINDOW
#define T2_HAE_ADDRESS T2_HAE_1
+#endif
/* T2 CSRs are in the non-cachable primary IO space from 3.8000.0000 to
3.8fff.ffff
@@ -429,13 +434,15 @@ extern inline void t2_outl(u32 b, unsign
*
*/
+#ifdef T2_ONE_HAE_WINDOW
+#define t2_set_hae
+#else
#define t2_set_hae { \
- msb = addr >> 27; \
+ unsigned long msb = addr >> 27; \
addr &= T2_MEM_R1_MASK; \
set_hae(msb); \
}
-
-extern raw_spinlock_t t2_hae_lock;
+#endif
/*
* NOTE: take T2_DENSE_MEM off in each readX/writeX routine, since
@@ -446,28 +453,22 @@ extern raw_spinlock_t t2_hae_lock;
__EXTERN_INLINE u8 t2_readb(const volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long result, msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long result;
t2_set_hae;
result = *(vip) ((addr << 5) + T2_SPARSE_MEM + 0x00);
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
return __kernel_extbl(result, addr & 3);
}
__EXTERN_INLINE u16 t2_readw(const volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long result, msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long result;
t2_set_hae;
result = *(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x08);
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
return __kernel_extwl(result, addr & 3);
}
@@ -478,59 +479,47 @@ __EXTERN_INLINE u16 t2_readw(const volat
__EXTERN_INLINE u32 t2_readl(const volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long result, msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long result;
t2_set_hae;
result = *(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x18);
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
return result & 0xffffffffUL;
}
__EXTERN_INLINE u64 t2_readq(const volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long r0, r1, work, msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long r0, r1, work;
t2_set_hae;
work = (addr << 5) + T2_SPARSE_MEM + 0x18;
r0 = *(vuip)(work);
r1 = *(vuip)(work + (4 << 5));
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
return r1 << 32 | r0;
}
__EXTERN_INLINE void t2_writeb(u8 b, volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long msb, w;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long w;
t2_set_hae;
w = __kernel_insbl(b, addr & 3);
*(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x00) = w;
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
}
__EXTERN_INLINE void t2_writew(u16 b, volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long msb, w;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long w;
t2_set_hae;
w = __kernel_inswl(b, addr & 3);
*(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x08) = w;
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
}
/*
@@ -540,29 +529,22 @@ __EXTERN_INLINE void t2_writew(u16 b, vo
__EXTERN_INLINE void t2_writel(u32 b, volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
t2_set_hae;
*(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x18) = b;
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
}
__EXTERN_INLINE void t2_writeq(u64 b, volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long msb, work;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long work;
t2_set_hae;
work = (addr << 5) + T2_SPARSE_MEM + 0x18;
*(vuip)work = b;
*(vuip)(work + (4 << 5)) = b >> 32;
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
}
__EXTERN_INLINE void __iomem *t2_ioportmap(unsigned long addr)
diff -puN arch/alpha/kernel/core_t2.c~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable arch/alpha/kernel/core_t2.c
--- a/arch/alpha/kernel/core_t2.c~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable
+++ a/arch/alpha/kernel/core_t2.c
@@ -74,8 +74,6 @@
# define DBG(args)
#endif
-DEFINE_RAW_SPINLOCK(t2_hae_lock);
-
static volatile unsigned int t2_mcheck_any_expected;
static volatile unsigned int t2_mcheck_last_taken;
@@ -406,6 +404,7 @@ void __init
t2_init_arch(void)
{
struct pci_controller *hose;
+ struct resource *hae_mem;
unsigned long temp;
unsigned int i;
@@ -433,7 +432,13 @@ t2_init_arch(void)
*/
pci_isa_hose = hose = alloc_pci_controller();
hose->io_space = &ioport_resource;
- hose->mem_space = &iomem_resource;
+ hae_mem = alloc_resource();
+ hae_mem->start = 0;
+ hae_mem->end = T2_MEM_R1_MASK;
+ hae_mem->name = pci_hae0_name;
+ if (request_resource(&iomem_resource, hae_mem) < 0)
+ printk(KERN_ERR "Failed to request HAE_MEM\n");
+ hose->mem_space = hae_mem;
hose->index = 0;
hose->sparse_mem_base = T2_SPARSE_MEM - IDENT_ADDR;
diff -puN arch/alpha/kernel/machvec_impl.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable arch/alpha/kernel/machvec_impl.h
--- a/arch/alpha/kernel/machvec_impl.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable
+++ a/arch/alpha/kernel/machvec_impl.h
@@ -25,6 +25,9 @@
#ifdef MCPCIA_ONE_HAE_WINDOW
#define MCPCIA_HAE_ADDRESS (&alpha_mv.hae_cache)
#endif
+#ifdef T2_ONE_HAE_WINDOW
+#define T2_HAE_ADDRESS (&alpha_mv.hae_cache)
+#endif
/* Only a few systems don't define IACK_SC, handling all interrupts through
the SRM console. But splitting out that one case from IO() below
_
Patches currently in -mm which might be from ink@jurassic.park.msu.ru are
linux-next.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
alpha-enable-arch_dma_addr_t_64bit.patch
alpha-use-single-hae-window-on-t2-core-logic-gamma-sable.patch
add-the-common-dma_addr_t-typedef-to-include-linux-typesh.patch
make-sure-nobodys-leaking-resources.patch
^ permalink raw reply
* [rtc-linux] RE: [PATCH 5/5] rtc: rtc-s3c: Fix debug message format on RTC
From: Kukjin Kim @ 2010-10-07 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20100910162354.9b96f1df.akpm@linux-foundation.org>
Andrew Morton wrote:
>
> On Fri, 10 Sep 2010 20:38:39 +0900
> Kukjin Kim <kgene.kim@samsung.com> wrote:
>
> > Wan ZongShun wrote:
> > >
> > > 2010/9/9 Kukjin Kim <kgene.kim@samsung.com>:
> > > > Ben Dooks wrote:
> > > >>
> > > >> On 07/09/10 06:29, Kukjin Kim wrote:
> > > >> > This patch fixes debug message format on rtc-s3c.
> > > >> >
> > > >> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> > > >> > Cc: Ben Dooks <ben-linux@fluff.org>
> > > >> > ---
> > > >> > drivers/rtc/rtc-s3c.c | 18 +++++++++---------
> > > >> > 1 files changed, 9 insertions(+), 9 deletions(-)
> > > >> >
> > > >>
> > > >> how long has this lot been broken for?
> > > >>
> > > > Haha...we don't know :-)
> > > >
> > > >> Acked-by: Ben Dooks <ben-linux@fluff.org>
> > > >
> > > > Thanks for your ack...so...
> > > >
> > > > Hi Alessandro Zummo,
> > > > Is it possible to send this to upstream through your tree?
> > > > Or which tree is better to care this.
> > >
> > >
> > > Please get help from Andrew.
> > >
> > Ok ;-)
> >
> > Hello Andrew,
> >
> > Could you please handle following items which have been got Ben's ack?
> >
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025387.
html
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025388.
html
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025391.
html
> >
> > And it's available in the git repository at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-rtc-
> s3c
> >
> > If any problems, please let me know.
> >
>
> I'd prefer to handle the whole series rather than cherrypick a subset
> of it.
>
> Patch 1/5 has a question from Ben which hasn't been responded to yet.
>
> Patch 4/5 is due to be updated.
>
> So please let's fix those things up, resend the entire series and cc me
> on the emails?
Hi Andrew,
Sorry for late response.
Updated patch 1/5 has been tested on S3C24XX and its working fine.
Its remained issue is that Ben was wondering its working on S3C24XX.
And about the patch 4/5, I did address comments from Ben Dooks and Wan
ZongShun.
So could you please handle this series?
If any problems, please kindly let me know.
They are since commit cb655d0f3d57c23db51b981648e452988c0223f9:
Linux 2.6.36-rc7 (2010-10-06 13:39:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-rtc-s3c
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [dm-crypt] What happen if hard drive has a read error?
From: Arno Wagner @ 2010-10-07 23:16 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <4CAE3B9E.3060604@redhat.com>
On Thu, Oct 07, 2010 at 11:29:02PM +0200, Milan Broz wrote:
> On 10/07/2010 10:20 PM, octane indice wrote:
> > It's just a theorical question. I encrypted some data with dm-crypt on an
> > hard drive.
> > But what happens if the hard drive has an error? Not a kind of a big error
> > which cause the hard drive hangs, but just a small error that make the
> > system doesn't read the bytes all right?
> >
> > Obviously, dm-crypt won't decrypt the data. But what happens next?
>
> Basically the same like if you have IO error on plain disk - the
> IO operation returns IO error. Upper layer decides what to do next.
Just to clarify this a bit further: disk error correction
capability is limited, an unrecoverable read error is a real
possibility. The datasheets say once every 10^15 bits read,
which whould translate to an unreadable sector once every
125 TB read. I think this is realistic, but still a bit of a
worst case scenario. Also keep in mind that this is for a
healthy disk only.
The error detection capabilities of the coding uses is far, far
larger. An undetected unrecovrable error (i.e. you get wrong
data but no error even on retry) is something unlikely enough
that you can safely ignore the possibility. There are special
safeguards against this, as error correction by itself can
correct to the wrong value.
Nonetheless, you can find wrong data on disks without any
explanation or detected errors. The reason is typically
corruption in RAM or in busses before the data is written.
For a complex data aquisition system (compression ->
network -> disk-buffer -> tape-library), I have observed
something like one unexplained bit error every 5-10TB
written. This number may vary wildly in practice. Especially
overclocking and cheap non-ECC RAM may drive it up.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ 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.