RE: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
Thanks Jeff and Sergei,
As your suggestion, I will separate the patch into smaller patches and
support more features on the SATA DWC driver. The patches I intend to do
on the SATA DWC are as below:
- Support hardreset: currently the hardreset is not supported. This
causes sometime the SATA driver does cause kernel crash because of
not-determined state.
- Let device tree specified DMA channel: currently only channel 0 is
supported (number of channel is set to 1). If device tree not specified
DMA channel, channel 0 will be used as default.
- Support ATAPI.
- Remove dma_interrupt_count. for each DMA transfer, we need 2 interrupts
for QC completion: transfer completion and DMA transfer completion
interrupt. The current code wait for both 2 interrupts occur before
calling qc_complete. This will make out-of-sync state when an interrupt
lost or when errors occur. The change will process DMA register when DMA
transfer complete interrupt occur and call qc_issue when command
completion interrupt occur.
- Fix NCQ issue and set .can_queue back to ATA_MAX_QUEUE.
- Support Port Multiplier.
- Support 2 SATA ports on Maui.
Regards,
Thang Nguyen-
-Original Message-
From: Jeff Garzik [mailto:jgpo...@gmail.com] On Behalf Of Jeff Garzik
Sent: Friday, April 13, 2012 3:05 AM
To: Sergei Shtylyov
Cc: Thang Q. Nguyen; Benjamin Herrenschmidt; Paul Mackerras; Grant Likely;
Rob Herring; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org;
linux-...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org
Subject: Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change
filename from sata_dwc_460ex.c to sata_dwc_4xx.c
On 04/03/2012 07:56 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 03-04-2012 14:12, Thang Q. Nguyen wrote:
>
>> Signed-off-by: Thang Q. Nguyen
>> ---
>> Changes for v2:
>> - Use git rename feature to change the driver to the newname and for
>> easier review.
>
>> arch/powerpc/boot/dts/bluestone.dts | 21 +
>> drivers/ata/Makefile | 2 +-
>> drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} | 1371
>> ++
>> 3 files changed, 904 insertions(+), 490 deletions(-)
>> rename drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} (56%)
>
> You submitted a magapatch doing several things at once (some even
> needlessly) and even in two areas of the kernel. This needs proper
> splitting/description.
Agreed...
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its
subsidiaries.
It is to be used solely for the purpose of furthering the parties' business
relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply
e-mail
and destroy all copies of the original message.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: boot failures with next-20120411
On 04/13/2012 04:30 AM, Michael Neuling wrote:
> Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Some (not all) of my PowerPC boot tests have failed like this after
>> getting into user mode (this one was just after udev started, but others
>> are after other processes getting going):
>>
>> Unable to handle kernel paging request for data at address 0xc003f9d550
>> Faulting instruction address: 0xc01b7f40
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=32 NUMA pSeries
>> Modules linked in: ehea
>> NIP: c01b7f40 LR: c01b7f14 CTR: c00e04f0
>> REGS: c003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
>> MSR: 8280b032 CR: 24422424 XER:
>> 2001
>> SOFTE: 1
>> CFAR: 562c
>> DAR: 00c003f9d550, DSISR: 4000
>> TASK = c003f8818000[3192] 'kdump' THREAD: c003f68bc000 CPU: 5
>> GPR00: c003f68bf930 c0ce1d40 c003fe00ec00
>> GPR04: 02d0 0038 c003f8f935e8 c0e55280
>> GPR08: 0011 c0bcb280 c0bcb1e8 0028a000
>> GPR12: 24422424 cf33bc80 0fffdd90a770 00081000
>> GPR16: c003f846c000 0de4f7a0 fde4f7a0
>> GPR20: c003f8365408 c003f8365480 c003f8e5d110
>> GPR24: 0100 c003f8365400 c01e5424 02d0
>> GPR28: 0800 00c003f9d550 c0c5b718 c003fe00ec00
>> NIP [c01b7f40] .__kmalloc+0x70/0x230
>> LR [c01b7f14] .__kmalloc+0x44/0x230
>> Call Trace:
>> [c003f68bf930] [c003f68bf9b0] 0xc003f68bf9b0 (unreliable)
>> [c003f68bf9e0] [c01e5424] .alloc_fdmem+0x24/0x70
>> [c003f68bfa60] [c01e54f8] .alloc_fdtable+0x88/0x130
>> [c003f68bfaf0] [c01e5924] .dup_fd+0x384/0x450
>> [c003f68bfbd0] [c009a310] .copy_process+0x880/0x11d0
>> [c003f68bfcd0] [c009aee0] .do_fork+0x70/0x400
>> [c003f68bfdc0] [c00141c4] .sys_clone+0x54/0x70
>> [c003f68bfe30] [c0009aa0] .ppc_clone+0x8/0xc
>> Instruction dump:
>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f 7ce95a14 e9070008
>> 7fa9582a 2fbd 41de0054 e81f0022 <7f3d002a> 3800 886d01f2 980d01f2
>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>
>> This did not happen yesterday. Just wondering if anyone can think of
>> anything obvious. Full console log at
>> http://ozlabs.org/~sfr/next-20120411.log.bz2
>
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
>
> commit 85bbc003b24335e253a392f6a9874103b77abb36
> Author: Jiri Slaby
> Date: Mon Apr 2 13:54:22 2012 +0200
>
> TTY: HVC, use tty from tty_port
>
> The driver already used refcounting. So we just switch it to tty_port
> helpers. And switch to tty_port->lock for tty.
>
> Signed-off-by: Jiri Slaby
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Greg Kroah-Hartman
>
> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.
>
> I'm assuming we got the ref count changes wrong somewhere in the patch
> but the tty code is beyond me. Jiri, can you take a look?
Yeah, I see. I forgot to remove a couple of tty reference drops. The
reference is dropped by tty_port_tty_set in open/close/hangup now. Does
the attached patch help?
thanks,
--
js
suse labs
>From cc51efe721f5aa184e119c52c661a1faf865e492 Mon Sep 17 00:00:00 2001
From: Jiri Slaby
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting
Signed-off-by: Jiri Slaby
---
drivers/tty/hvc/hvc_console.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..260d4f2 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -338,7 +338,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +392,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +431,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.9.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: boot failures with next-20120411
On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> On 04/13/2012 04:30 AM, Michael Neuling wrote:
>> Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Some (not all) of my PowerPC boot tests have failed like this after
>>> getting into user mode (this one was just after udev started, but others
>>> are after other processes getting going):
>>>
>>> Unable to handle kernel paging request for data at address 0xc003f9d550
>>> Faulting instruction address: 0xc01b7f40
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> SMP NR_CPUS=32 NUMA pSeries
>>> Modules linked in: ehea
>>> NIP: c01b7f40 LR: c01b7f14 CTR: c00e04f0
>>> REGS: c003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
>>> MSR: 8280b032 CR: 24422424 XER:
>>> 2001
>>> SOFTE: 1
>>> CFAR: 562c
>>> DAR: 00c003f9d550, DSISR: 4000
>>> TASK = c003f8818000[3192] 'kdump' THREAD: c003f68bc000 CPU: 5
>>> GPR00: c003f68bf930 c0ce1d40 c003fe00ec00
>>> GPR04: 02d0 0038 c003f8f935e8 c0e55280
>>> GPR08: 0011 c0bcb280 c0bcb1e8 0028a000
>>> GPR12: 24422424 cf33bc80 0fffdd90a770 00081000
>>> GPR16: c003f846c000 0de4f7a0 fde4f7a0
>>> GPR20: c003f8365408 c003f8365480 c003f8e5d110
>>> GPR24: 0100 c003f8365400 c01e5424 02d0
>>> GPR28: 0800 00c003f9d550 c0c5b718 c003fe00ec00
>>> NIP [c01b7f40] .__kmalloc+0x70/0x230
>>> LR [c01b7f14] .__kmalloc+0x44/0x230
>>> Call Trace:
>>> [c003f68bf930] [c003f68bf9b0] 0xc003f68bf9b0 (unreliable)
>>> [c003f68bf9e0] [c01e5424] .alloc_fdmem+0x24/0x70
>>> [c003f68bfa60] [c01e54f8] .alloc_fdtable+0x88/0x130
>>> [c003f68bfaf0] [c01e5924] .dup_fd+0x384/0x450
>>> [c003f68bfbd0] [c009a310] .copy_process+0x880/0x11d0
>>> [c003f68bfcd0] [c009aee0] .do_fork+0x70/0x400
>>> [c003f68bfdc0] [c00141c4] .sys_clone+0x54/0x70
>>> [c003f68bfe30] [c0009aa0] .ppc_clone+0x8/0xc
>>> Instruction dump:
>>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f 7ce95a14 e9070008
>>> 7fa9582a 2fbd 41de0054 e81f0022 <7f3d002a> 3800 886d01f2 980d01f2
>>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>>
>>> This did not happen yesterday. Just wondering if anyone can think of
>>> anything obvious. Full console log at
>>> http://ozlabs.org/~sfr/next-20120411.log.bz2
>>
>> I managed to bisect this down using pseries_defconfig with next-20120412
>> to this patch:
>>
>> commit 85bbc003b24335e253a392f6a9874103b77abb36
>> Author: Jiri Slaby
>> Date: Mon Apr 2 13:54:22 2012 +0200
>>
>> TTY: HVC, use tty from tty_port
>>
>> The driver already used refcounting. So we just switch it to tty_port
>> helpers. And switch to tty_port->lock for tty.
>>
>> Signed-off-by: Jiri Slaby
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Greg Kroah-Hartman
>>
>> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
>> otherwise git barfs) fixes the problem on next-20120412.
>>
>> I'm assuming we got the ref count changes wrong somewhere in the patch
>> but the tty code is beyond me. Jiri, can you take a look?
>
> Yeah, I see. I forgot to remove a couple of tty reference drops. The
> reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> the attached patch help?
And the patch is incomplete. Now we have a leak. This one should work.
> thanks,
--
js
suse labs
>From 7a55e2976cb5a47e499a6db335ad30ecac2e621c Mon Sep 17 00:00:00 2001
From: Jiri Slaby
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting
Signed-off-by: Jiri Slaby
---
drivers/tty/hvc/hvc_console.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc
Re: linux-next: boot failures with next-20120411
Jiri Slaby wrote: > On 04/13/2012 10:02 AM, Jiri Slaby wrote: > > On 04/13/2012 04:30 AM, Michael Neuling wrote: > >> Stephen Rothwell wrote: > >> > >>> Hi all, > >>> > >>> Some (not all) of my PowerPC boot tests have failed like this after > >>> getting into user mode (this one was just after udev started, but others > >>> are after other processes getting going): > >>> > >>> Unable to handle kernel paging request for data at address > >>> 0xc003f9d550 > >>> Faulting instruction address: 0xc01b7f40 > >>> Oops: Kernel access of bad area, sig: 11 [#1] > >>> SMP NR_CPUS=32 NUMA pSeries > >>> Modules linked in: ehea > >>> NIP: c01b7f40 LR: c01b7f14 CTR: c00e04f0 > >>> REGS: c003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1) > >>> MSR: 8280b032 CR: 24422424 XER: > >>> 2001 > >>> SOFTE: 1 > >>> CFAR: 562c > >>> DAR: 00c003f9d550, DSISR: 4000 > >>> TASK = c003f8818000[3192] 'kdump' THREAD: c003f68bc000 CPU: 5 > >>> GPR00: c003f68bf930 c0ce1d40 > >>> c003fe00ec00 > >>> GPR04: 02d0 0038 c003f8f935e8 > >>> c0e55280 > >>> GPR08: 0011 c0bcb280 c0bcb1e8 > >>> 0028a000 > >>> GPR12: 24422424 cf33bc80 0fffdd90a770 > >>> 00081000 > >>> GPR16: c003f846c000 0de4f7a0 fde4f7a0 > >>> > >>> GPR20: c003f8365408 c003f8365480 c003f8e5d110 > >>> > >>> GPR24: 0100 c003f8365400 c01e5424 > >>> 02d0 > >>> GPR28: 0800 00c003f9d550 c0c5b718 > >>> c003fe00ec00 > >>> NIP [c01b7f40] .__kmalloc+0x70/0x230 > >>> LR [c01b7f14] .__kmalloc+0x44/0x230 > >>> Call Trace: > >>> [c003f68bf930] [c003f68bf9b0] 0xc003f68bf9b0 (unreliable) > >>> [c003f68bf9e0] [c01e5424] .alloc_fdmem+0x24/0x70 > >>> [c003f68bfa60] [c01e54f8] .alloc_fdtable+0x88/0x130 > >>> [c003f68bfaf0] [c01e5924] .dup_fd+0x384/0x450 > >>> [c003f68bfbd0] [c009a310] .copy_process+0x880/0x11d0 > >>> [c003f68bfcd0] [c009aee0] .do_fork+0x70/0x400 > >>> [c003f68bfdc0] [c00141c4] .sys_clone+0x54/0x70 > >>> [c003f68bfe30] [c0009aa0] .ppc_clone+0x8/0xc > >>> Instruction dump: > >>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f 7ce95a14 e9070008 > >>> 7fa9582a 2fbd 41de0054 e81f0022 <7f3d002a> 3800 886d01f2 980d01f2 > >>> ---[ end trace 366fe6c7ced3bfb0 ]--- > >>> > >>> This did not happen yesterday. Just wondering if anyone can think of > >>> anything obvious. Full console log at > >>> http://ozlabs.org/~sfr/next-20120411.log.bz2 > >> > >> I managed to bisect this down using pseries_defconfig with next-20120412 > >> to this patch: > >> > >> commit 85bbc003b24335e253a392f6a9874103b77abb36 > >> Author: Jiri Slaby > >> Date: Mon Apr 2 13:54:22 2012 +0200 > >> > >> TTY: HVC, use tty from tty_port > >> > >> The driver already used refcounting. So we just switch it to tty_port > >> helpers. And switch to tty_port->lock for tty. > >> > >> Signed-off-by: Jiri Slaby > >> Cc: linuxppc-dev@lists.ozlabs.org > >> Signed-off-by: Greg Kroah-Hartman > >> > >> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812 > >> otherwise git barfs) fixes the problem on next-20120412. > >> > >> I'm assuming we got the ref count changes wrong somewhere in the patch > >> but the tty code is beyond me. Jiri, can you take a look? > > > > Yeah, I see. I forgot to remove a couple of tty reference drops. The > > reference is dropped by tty_port_tty_set in open/close/hangup now. Does > > the attached patch help? > > And the patch is incomplete. Now we have a leak. This one should work. Fixes the problem here.. Thanks. Tested-by: Michael Neuling ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] TTY: hvc, fix TTY refcounting
A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc003f9d550
Faulting instruction address: 0xc01b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c01b7f40 LR: c01b7f14 CTR: c00e04f0
...
NIP [c01b7f40] .__kmalloc+0x70/0x230
LR [c01b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c003f68bf930] [c003f68bf9b0] 0xc003f68bf9b0 (unreliable)
[c003f68bf9e0] [c01e5424] .alloc_fdmem+0x24/0x70
[c003f68bfa60] [c01e54f8] .alloc_fdtable+0x88/0x130
[c003f68bfaf0] [c01e5924] .dup_fd+0x384/0x450
[c003f68bfbd0] [c009a310] .copy_process+0x880/0x11d0
[c003f68bfcd0] [c009aee0] .do_fork+0x70/0x400
[c003f68bfdc0] [c00141c4] .sys_clone+0x54/0x70
[c003f68bfe30] [c0009aa0] .ppc_clone+0x8/0xc
Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.
Signed-off-by: Jiri Slaby
Reported-and-tested-by: Michael Neuling
Cc: Stephen Rothwell
Cc: ppc-dev
---
drivers/tty/hvc/hvc_console.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file *
filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file *
filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n",
rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file *
filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.9.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
userspace o/p to kernel buffer
Hi, How do I capture all the output of user-space programs into a kernel buffer so that I can later read it using debugger ? My board doesn't have a console (no serial, no network). Any direction would be of great help. sumesh. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: userspace o/p to kernel buffer
> How do I capture all the output of user-space programs into > a kernel buffer so that I can later read it using debugger ? > My board doesn't have a console (no serial, no network). Assuming you are using a shell to start your user-space programs, you could easily redirect output to /dev/kmsg then find it in the dmesg buffer afterwards. You may need to increase the buffer size. Clive ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
On 04/13/2012 03:18 AM, Thang Nguyen wrote: Thanks Jeff and Sergei, As your suggestion, I will separate the patch into smaller patches and support more features on the SATA DWC driver. The patches I intend to do on the SATA DWC are as below: - Support hardreset: currently the hardreset is not supported. This causes sometime the SATA driver does cause kernel crash because of not-determined state. - Let device tree specified DMA channel: currently only channel 0 is supported (number of channel is set to 1). If device tree not specified DMA channel, channel 0 will be used as default. - Support ATAPI. - Remove dma_interrupt_count. for each DMA transfer, we need 2 interrupts for QC completion: transfer completion and DMA transfer completion interrupt. The current code wait for both 2 interrupts occur before calling qc_complete. This will make out-of-sync state when an interrupt lost or when errors occur. The change will process DMA register when DMA transfer complete interrupt occur and call qc_issue when command completion interrupt occur. - Fix NCQ issue and set .can_queue back to ATA_MAX_QUEUE. - Support Port Multiplier. - Support 2 SATA ports on Maui. Sounds good, thanks for splitting up the patch into smaller pieces. The main goal is that separate logical changes should go into separate patches. Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/e6500: add CPU_FTR_EMB_HV to CPU table
On Apr 11, 2012, at 3:27 PM, Scott Wood wrote: > e6500 support (commit 10241842fbe900276634fee8d37ec48a7d8a762f, > "powerpc: Add initial e6500 cpu support" and the introduction of > CPU_FTR_EMB_HV (commit 73196cd364a2d972d73fa08da9d81ca3215bed68, > "KVM: PPC: e500mc support") collided during merge, leaving e6500's CPU > table entry missing CPU_FTR_EMB_HV. > > Signed-off-by: Scott Wood > --- > Fixup patch for the KVM merge as requested by Marcelo. > > arch/powerpc/include/asm/cputable.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Acked-by: Kumar Gala - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
patch "TTY: hvc, fix TTY refcounting" added to tty tree
This is a note to let you know that I've just added the patch titled
TTY: hvc, fix TTY refcounting
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also will be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From a2f892060f174e5f90041167ca00eb9e68badcb8 Mon Sep 17 00:00:00 2001
From: Jiri Slaby
Date: Fri, 13 Apr 2012 10:31:32 +0200
Subject: TTY: hvc, fix TTY refcounting
A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc003f9d550
Faulting instruction address: 0xc01b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c01b7f40 LR: c01b7f14 CTR: c00e04f0
...
NIP [c01b7f40] .__kmalloc+0x70/0x230
LR [c01b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c003f68bf930] [c003f68bf9b0] 0xc003f68bf9b0 (unreliable)
[c003f68bf9e0] [c01e5424] .alloc_fdmem+0x24/0x70
[c003f68bfa60] [c01e54f8] .alloc_fdtable+0x88/0x130
[c003f68bfaf0] [c01e5924] .dup_fd+0x384/0x450
[c003f68bfbd0] [c009a310] .copy_process+0x880/0x11d0
[c003f68bfcd0] [c009aee0] .do_fork+0x70/0x400
[c003f68bfdc0] [c00141c4] .sys_clone+0x54/0x70
[c003f68bfe30] [c0009aa0] .ppc_clone+0x8/0xc
Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.
Signed-off-by: Jiri Slaby
Reported-and-tested-by: Michael Neuling
Cc: Stephen Rothwell
Cc: ppc-dev
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/hvc/hvc_console.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file *
filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file *
filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n",
rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file *
filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.10
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
P4080 target has 16G memory stability issues ...
Dear list(s), Our P4080 target board is using 2 SODIMM's on each of 2 Controllers (4x4G DDR3), and we are seeing some memory problems (linux panics) when beating up large amounts of memory (just under the 16G), on multiple threads (7 or 8 CPUs). Our DDR3 configuration is derived from the SPD dump of U-Boot, and we are using a version based upon the 2011.09 release of U-Boot. Our firmware memory test, limited as it is to 2G chunks, and a single CPU shows no problem, it is only using a small test program under Linux and using multiple cpu's that we see the problems, and we can reproduce the problem at will, although reducing our memory speed via the RCW does seem to ameliorate the problem somewhat. Questions: - is anyone using a similar configuration? - is anyone aware of limitations in the U-Boot 2011.09R version of the mpc8xxx/ddr/* code we need to be aware of? - any ideas? We've been pounding our heads on this for a while now, and I'm just wondering if we are covering old territory here. Cheers, Rob. Robert Sciuk Senior Designer, R&D. 905.738.3741 xt 22621 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl: Distribute interrupts on all CPUs by default
At least for crypto/IPSec, doing so provides users with a better performance experience out of the box. Signed-off-by: Kim Phillips --- arch/powerpc/configs/corenet32_smp_defconfig |1 + arch/powerpc/configs/corenet64_smp_defconfig |1 + arch/powerpc/configs/mpc85xx_smp_defconfig |1 + 3 files changed, 3 insertions(+) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index f8aef20..13e7f3c 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -32,6 +32,7 @@ CONFIG_HIGH_RES_TIMERS=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_BINFMT_MISC=m CONFIG_KEXEC=y +CONFIG_IRQ_ALL_CPUS=y CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_FSL_LBC=y CONFIG_PCI=y diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 7ed8d4c..00c49b9 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -23,6 +23,7 @@ CONFIG_P5020_DS=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BINFMT_MISC=m +CONFIG_IRQ_ALL_CPUS=y CONFIG_RAPIDIO=y CONFIG_FSL_RIO=y CONFIG_NET=y diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index abdcd31..608ccc6 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -45,6 +45,7 @@ CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BINFMT_MISC=m CONFIG_MATH_EMULATION=y +CONFIG_IRQ_ALL_CPUS=y CONFIG_FORCE_MAX_ZONEORDER=12 CONFIG_PCI=y CONFIG_PCI_MSI=y -- 1.7.10 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
