* Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
From: Justin Mattock @ 2011-04-06 16:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, trivial, linux-kernel, Harninder Rai
In-Reply-To: <20110406110335.0f2d5f4c@schlenkerla.am.freescale.net>
On Wed, Apr 6, 2011 at 9:03 AM, Scott Wood <scottwood@freescale.com> wrote:
> On Wed, 6 Apr 2011 08:07:58 -0700
> Justin Mattock <justinmattock@gmail.com> wrote:
>
>> ahh.. so the: =A0fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
>> even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
>>
>> but might be wrong with this.
>
> More like there are plans to use it, or possibly out-of-tree users. =A0We
> should prod people a bit to submit the driver patches that use this befor=
e
> we just yank it out.
>
> -Scott
>
>
well if this is going to be used for something down the line, then
best leave it in..
--=20
Justin P. Mattock
^ permalink raw reply
* known working sata_sil24.c setup on powerpc platforms?
From: Leon Woestenberg @ 2011-04-06 17:00 UTC (permalink / raw)
To: Linux PPC, linux-ide, Tejun Heo, Moffett, Kyle D, Jeff Garzik
Hello,
after investigating problems with sata_sil24.c on a freescale p2020
soc, I wonder if this driver works on powerpc at all?
Does anyone know of a working setup of sata_sil24 on a big endian
powerpc system?
Regards,
--
Leon
^ permalink raw reply
* [PATCH] RapidIO/mpc85xx: Fix possible mport registration problems.
From: Alexandre Bounine @ 2011-04-06 17:16 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
Fix possible problem with mport registration left non cleared after
fsl_rio_setup() exits on link error. Abort mport initialization
if registration failed.
This patch is applicable to 2.6.39-rc1 only. The problem does not exists
for earlier versions.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
---
arch/powerpc/sysdev/fsl_rio.c | 4 +++-
drivers/rapidio/rio.c | 5 +++--
include/linux/rio.h | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 14232d5..4979853 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1457,7 +1457,6 @@ int fsl_rio_setup(struct platform_device *dev)
port->ops = ops;
port->priv = priv;
port->phys_efptr = 0x100;
- rio_register_mport(port);
priv->regs_win = ioremap(regs.start, regs.end - regs.start + 1);
rio_regs_win = priv->regs_win;
@@ -1504,6 +1503,9 @@ int fsl_rio_setup(struct platform_device *dev)
dev_info(&dev->dev, "RapidIO Common Transport System size: %d\n",
port->sys_size ? 65536 : 256);
+ if (rio_register_mport(port))
+ goto err;
+
if (port->host_deviceid >= 0)
out_be32(priv->regs_win + RIO_GCCSR, RIO_PORT_GEN_HOST |
RIO_PORT_GEN_MASTER | RIO_PORT_GEN_DISCOVERED);
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index c29719c..86c9a09 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -1171,16 +1171,17 @@ static int rio_hdid_setup(char *str)
__setup("riohdid=", rio_hdid_setup);
-void rio_register_mport(struct rio_mport *port)
+int rio_register_mport(struct rio_mport *port)
{
if (next_portid >= RIO_MAX_MPORTS) {
pr_err("RIO: reached specified max number of mports\n");
- return;
+ return 1;
}
port->id = next_portid++;
port->host_deviceid = rio_get_hdid(port->id);
list_add_tail(&port->node, &rio_mports);
+ return 0;
}
EXPORT_SYMBOL_GPL(rio_local_get_device_id);
diff --git a/include/linux/rio.h b/include/linux/rio.h
index 4e37a7c..4d50611 100644
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -396,7 +396,7 @@ union rio_pw_msg {
};
/* Architecture and hardware-specific functions */
-extern void rio_register_mport(struct rio_mport *);
+extern int rio_register_mport(struct rio_mport *);
extern int rio_open_inb_mbox(struct rio_mport *, void *, int, int);
extern void rio_close_inb_mbox(struct rio_mport *, int);
extern int rio_open_outb_mbox(struct rio_mport *, void *, int, int);
--
1.7.3.1
^ permalink raw reply related
* Re: sdhc/mpc8536 - SDCard always detected like read-only
From: Carlos Roberto Moratelli @ 2011-04-06 17:18 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20110405234824.GB5611@pengutronix.de>
I will try address the issue in details.
When I insert the SDCard, the same is detect like read-only:
mmcblk0: mmc0:b368 NCard 966 MiB (ro)
mmcblk0:
mmc0: starting CMD18 arg 00000000 flags 000000b5
mmc0: blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
mmc0: CMD12 arg 00000000 flags 0000049d
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0000000a
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD18): 0: 00000900 00000000 00000000 00000000
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): 0: 00000b00 00000000 00000000 00000000
p1
So, I just can mount the filesystem read-only. I can read the fat32
without problems.
I tested your sugestion. I used sdhci,wp-inverted in my dtb. This
changed the behavior. Now the SDCard is detected without the read-only
flag:
mmcblk0: mmc0:b368 NCard 966 MiB
mmcblk0:
mmc0: starting CMD18 arg 00000000 flags 000000b5
mmc0: blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
mmc0: CMD12 arg 00000000 flags 0000049d
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0000000a
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD18): 0: 00000900 00000000 00000000 00000000
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): 0: 00000b00 00000000 00000000 00000000
p1
And, I can mount a rw filesystem:
#mount /dev/mmcblock1 /mnt
#cat /proc/mounts
...
/dev/mmcblock1 /mnt vfat
rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
...
So, I can copy files to the mounted SDCard. But, When I try to umount I
see the following error mensagens:
#cp /etc/shadow /mnt
#ls /mnt
shadow
#umount /mnt
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 5944, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 5944
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 5936, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 5936
Buffer I/O error on device mmcblk0p1, logical block 3888
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 2049, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 2049
Buffer I/O error on device mmcblk0p1, logical block 1
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 2080, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 2080
...
I think I need the sdhci,wp-inverted in my dtb. But, it appears that
more something is necessary.
Has someone faced this situation?
Thanks by the help until here.
Regards,
Moratelli
Em Qua, 2011-04-06 às 01:48 +0200, Wolfram Sang escreveu:
> > sdhci@2e000 {
> > compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
> > reg = <0x2e000 0x1000>;
> > interrupts = <72 0x2>;
> > interrupt-parent = <&mpic>;
> > /* Filled in by U-Boot */
> > clock-frequency = <0>;
> > };
>
> Hmm, I am not too familiar with those SoCs, yet some 83xx needed
>
> sdhci,wp-inverted;
>
> here. Maybe yours, too? Would fit the symptoms.
>
> Regards,
>
> Wolfram
>
^ permalink raw reply
* Re: [PATCH] powerpc/book3e: Fix CPU feature handling on 64-bit e5500
From: Scott Wood @ 2011-04-06 18:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1302092943-10586-1-git-send-email-galak@kernel.crashing.org>
On Wed, 6 Apr 2011 07:29:03 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
> index be3cdf9..9028a9e 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -386,6 +386,10 @@ extern const char *powerpc_base_platform;
> CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
> CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
> CPU_FTR_DBELL)
> +#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
> + CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
E5500 cannot doze or nap in the way meant by existing code (MSR[WE]).
-Scott
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Jeff Garzik @ 2011-04-06 18:12 UTC (permalink / raw)
To: Moffett, Kyle D
Cc: Leon Woestenberg, Linux PPC, Tejun Heo, linux-ide@vger.kernel.org
In-Reply-To: <C3A1EF35-6CB6-4674-8B0B-44CD1657FE87@boeing.com>
On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
>> after investigating problems with sata_sil24.c on a freescale p2020
>> soc, I wonder if this driver works on powerpc at all?
>>
>> Does anyone know of a working setup of sata_sil24 on a big endian
>> powerpc system?
>
> Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil3124 over PCI-E); the only deficiency is that MSI does not seem to work.
>
> I know our MSI *does* work in general because we have an Intel 82571EB chipset also attached via PCI-E with working MSI.
We've definitely had issues with sata_sil24 + MSI, also...
sata_sil24 does work on big endian in general.
Jeff
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Moffett, Kyle D @ 2011-04-06 17:48 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Linux PPC, Tejun Heo, Jeff Garzik, linux-ide@vger.kernel.org
In-Reply-To: <BANLkTimXgi26RHHxyBLoN8YqaDy_PL-hGQ@mail.gmail.com>
On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
> after investigating problems with sata_sil24.c on a freescale p2020
> soc, I wonder if this driver works on powerpc at all?
>=20
> Does anyone know of a working setup of sata_sil24 on a big endian
> powerpc system?
Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil31=
24 over PCI-E); the only deficiency is that MSI does not seem to work.
I know our MSI *does* work in general because we have an Intel 82571EB chip=
set also attached via PCI-E with working MSI.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: Combining multiple NAND MTDs
From: Scott Wood @ 2011-04-06 18:47 UTC (permalink / raw)
To: Barry G; +Cc: linuxppc-dev
In-Reply-To: <BANLkTim=oxHcW-HV5Z062r2p2D1nTL8mcQ@mail.gmail.com>
On Tue, 5 Apr 2011 16:35:10 -0700
Barry G <mr.scada@gmail.com> wrote:
> I want to run UBIFS on the combined 2 gigs of flash. Whats the best
> way to do this?
>
> I tried using the mtdconcat stuff and wrote a small driver
> but I am not sure how to populate the mtd_info structure since do_probe_map
> doesn't work with NAND AFAIK.
>
> I see that fsl_elbc_select_chip says "hardware does not seem to support this".
> Not sure if this is related.
It's not related -- it's talking about a single physical chip with
multiple chip selects, not a logical concatenation of multiple separate
devices.
> I see some comments in mtd-physmap.txt about using multiple reg ranges?
> Does this work with NAND?
No.
I don't know of an out-of-the-box configuration step you can take to do
mtdconcat of eLBC NAND, but you could try creating a custom map driver that
glues things together as you wish. Or if you want to be more ambitious,
perhaps a kernel command line (or other dynamic config) option that lets you
glue arbitrary MTD devices together.
-Scott
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Leon Woestenberg @ 2011-04-06 18:50 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linux PPC, Tejun Heo, Moffett, Kyle D, linux-ide@vger.kernel.org
In-Reply-To: <4D9CAD1F.6060500@garzik.org>
Hello Jeff, all,
On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik <jeff@garzik.org> wrote:
> On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
>> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
>>> after investigating problems with sata_sil24.c on a freescale p2020
>>> soc, I wonder if this driver works on powerpc at all?
>>>
>>> Does anyone know of a working setup of sata_sil24 on a big endian
>>> powerpc system?
>>
>> Our P2020 boards work fine with legacy PCI interrupts (I think it's a
>> sil3124 over PCI-E); the only deficiency is that MSI does not seem to work.
>>
>
> We've definitely had issues with sata_sil24 + MSI, also...
>
> sata_sil24 does work on big endian in general.
>
On my system, I have the contrary to Kyle's experience (thanks for sharing).
PowerPC P2020RDB
vanilla 2.6.38
Sil3132 on mini-PCI Express card
Enabling msi gets me further than disabling it (default).
modprobe sata_sil
[ 8.834613] sata_sil24 0001:03:00.0: version 1.1
[ 8.885581] scsi0 : sata_sil24
[ 8.901420] scsi1 : sata_sil24
[ 8.904642] ata1: SATA max UDMA/100 host m128@0xc0000000 port
0xc0004000 irq 16
[ 8.911961] ata2: SATA max UDMA/100 host m128@0xc0000000 port
0xc0006000 irq 16
[ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 14.906986] eth0: no IPv6 routers present
[ 16.099016] ata1.00: qc timeout (cmd 0xec)
[ 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 28.303026] ata1.00: qc timeout (cmd 0xec)
[ 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 28.313233] ata1: limiting SATA link speed to 1.5 Gbps
[ 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10)
modprobe sata_sil msi=1
[ 92.984120] sata_sil24 0001:03:00.0: version 1.1
[ 92.988897] irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to
virtual irq 41
[ 92.996229] sata_sil24 0001:03:00.0: Using MSI
[ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering
[ 93.011628] scsi2 : sata_sil24
[ 93.022463] scsi3 : sata_sil24
[ 93.025695] ata3: SATA max UDMA/100 host m128@0xc0000000 port
0xc0004000 irq 41
[ 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
0xc0006000 irq 41
[ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag
-84148995 sactive 0x0)
[ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133
[ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32)
[ 95.230905] ata3.00: configured for UDMA/100
[ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL
SSDSA2M080 2CV1 PQ: 0 ANSI: 5
[ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0
[ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
(80.0 GB/74.5 GiB)
[ 95.260219] sd 2:0:0:0: [sda] Write Protect is off
[ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 95.283779] sda: sda1 sda2 sda3 sda4
[ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk
[ 95.965897] EXT3-fs: barriers not enabled
[ 95.977279] kjournald starting. Commit interval 5 seconds
[ 95.983296] EXT3-fs (sda2): using internal journal
[ 95.988143] EXT3-fs (sda2): recovery complete
[ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data mode
[ 96.111587] NTFS volume version 3.1.
[ 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1000
1000+0 records in
1000+0 records out
4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s
root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=10000
10000+0 records in
10000+0 records out
40960000 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s
root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=100000
That stalls, I see the controller fail. See dmesg below:
^C^Cdd: reading `/dev/sda': Input/output error
51804+0 records in
51804+0 records out
212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s
dd: closing input file `/dev/sda': Bad file descriptor
[ 92.984120] sata_sil24 0001:03:00.0: version 1.1
[ 92.988897] irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to
virtual irq 41
[ 92.996229] sata_sil24 0001:03:00.0: Using MSI
[ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering
[ 93.011628] scsi2 : sata_sil24
[ 93.022463] scsi3 : sata_sil24
[ 93.025695] ata3: SATA max UDMA/100 host m128@0xc0000000 port
0xc0004000 irq 41
[ 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
0xc0006000 irq 41
[ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag
-84148995 sactive 0x0)
[ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133
[ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32)
[ 95.230905] ata3.00: configured for UDMA/100
[ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL
SSDSA2M080 2CV1 PQ: 0 ANSI: 5
[ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0
[ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
(80.0 GB/74.5 GiB)
[ 95.260219] sd 2:0:0:0: [sda] Write Protect is off
[ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 95.283779] sda: sda1 sda2 sda3 sda4
[ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk
[ 95.965897] EXT3-fs: barriers not enabled
[ 95.977279] kjournald starting. Commit interval 5 seconds
[ 95.983296] EXT3-fs (sda2): using internal journal
[ 95.988143] EXT3-fs (sda2): recovery complete
[ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data mode
[ 96.111587] NTFS volume version 3.1.
[ 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
[ 285.891036] ata3.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6 frozen
[ 285.898099] ata3.00: failed command: READ FPDMA QUEUED
[ 285.903250] ata3.00: cmd 60/00:00:e0:53:06/01:00:00:00:00/40 tag 0
ncq 131072 in
[ 285.903255] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 285.918028] ata3.00: status: { DRDY }
[ 285.921689] ata3.00: failed command: READ FPDMA QUEUED
[ 285.926836] ata3.00: cmd 60/00:08:e0:52:06/01:00:00:00:00/40 tag 1
ncq 131072 in
[ 285.926841] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 285.941615] ata3.00: status: { DRDY }
[ 285.945281] ata3: hard resetting link
[ 288.055034] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 293.058999] ata3.00: qc timeout (cmd 0xec)
[ 293.063106] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 293.069198] ata3.00: revalidation failed (errno=-5)
[ 293.074077] ata3: hard resetting link
[ 295.259018] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
What can I do next to investigate and help fix this issue?
Regards,
--
Leon
^ permalink raw reply
* Using dmaengine on Freescale P2020 RDB
From: Chuck Ketcham @ 2011-04-06 19:40 UTC (permalink / raw)
To: linuxppc-dev
All,
I have a Freescale P2020 Reference Design Board. I am investigating the possibility of using the dmaengine capability in the 2.6.32.13 kernel to transfer data from memory out onto the PCIe bus. As a first step, I thought I would try the DMA test client (dmatest.ko) to make sure the dmaengine was functioning. I know this doesn't transfer anything over PCIe but only transfers from one memory buffer to another, but I figured I need to get this working first. Anyway I built dmatest.ko and ran it (with insmod), and discovered it didn't do anything. I added some printk's to the kernel to investigate what was going on and I found that all attempts to find a channel within dma_request_channel were unsuccessful. Three of the channels were not used because they were already publicly allocated. One channel was not used because it didn't have DMA_MEMCPY capability.
Here are my questions then:
1. Is the dmaengine the appropriate method to use for transferring data from memory out onto the PCIe bus?
2. If dmaengine is correct, what can I do to free up a channel for my own use?
Thank you.
Chuck
^ permalink raw reply
* Re: Using dmaengine on Freescale P2020 RDB
From: Ira W. Snyder @ 2011-04-06 20:10 UTC (permalink / raw)
To: Chuck Ketcham; +Cc: linuxppc-dev
In-Reply-To: <327152.93855.qm@web36406.mail.mud.yahoo.com>
On Wed, Apr 06, 2011 at 12:40:58PM -0700, Chuck Ketcham wrote:
> All,
>
> I have a Freescale P2020 Reference Design Board. I am investigating the possibility of using the dmaengine capability in the 2.6.32.13 kernel to transfer data from memory out onto the PCIe bus. As a first step, I thought I would try the DMA test client (dmatest.ko) to make sure the dmaengine was functioning. I know this doesn't transfer anything over PCIe but only transfers from one memory buffer to another, but I figured I need to get this working first. Anyway I built dmatest.ko and ran it (with insmod), and discovered it didn't do anything. I added some printk's to the kernel to investigate what was going on and I found that all attempts to find a channel within dma_request_channel were unsuccessful. Three of the channels were not used because they were already publicly allocated. One channel was not used because it didn't have DMA_MEMCPY capability.
>
> Here are my questions then:
> 1. Is the dmaengine the appropriate method to use for transferring data from memory out onto the PCIe bus?
> 2. If dmaengine is correct, what can I do to free up a channel for my own use?
>
I use the Freescale DMA engine to transfer lots of data out to PCI, on
an 8349EA chip. The P2020 DMA engine uses the same driver.
I hunch you have enabled CONFIG_NET_DMA, which will claim the channels.
You should disable it to use the devices for other uses.
If you want an example of using the DMA engine to transfer from DDR
memory to the PowerPC local bus, search the mailing list archives for
"CARMA Board Drivers" (RFCv7 was the latest posting). Transferring from
DDR to PCI works exactly the same way.
Hope it helps,
Ira
^ permalink raw reply
* Re: Using dmaengine on Freescale P2020 RDB
From: Chuck Ketcham @ 2011-04-06 20:29 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev
In-Reply-To: <20110406201029.GC7312@ovro.caltech.edu>
Ira,=0A=0AThanks for the reference to the CARMA drivers. I will have to ta=
ke a look at that.=0A=0AIn my case, CONFIG_NET_DMA is not enabled. However=
, I did notice the following entry in my p2020rdb.dts file that may have so=
mething to do with dma channels being allocated -- can anyone interpret thi=
s?:=0A=0A dma@21300 {=0A #address-cel=
ls =3D <1>;=0A #size-cells =3D <1>;=0A =
compatible =3D "fsl,eloplus-dma";=0A reg =
=3D <0x21300 0x4>;=0A ranges =3D <0x0 0x21100 0x200>=
;=0A cell-index =3D <0>;=0A d=
ma-channel@0 {=0A compatible =3D "fsl,eloplu=
s-dma-channel";=0A reg =3D <0x0 0x80>;=0A =
cell-index =3D <0>;=0A =
interrupt-parent =3D <&mpic>;=0A int=
errupts =3D <20 2>;=0A };=0A =
dma-channel@80 {=0A compatible =3D "fsl,elop=
lus-dma-channel";=0A reg =3D <0x80 0x80>;=0A=
cell-index =3D <1>;=0A =
interrupt-parent =3D <&mpic>;=0A =
interrupts =3D <21 2>;=0A };=0A =
dma-channel@100 {=0A compatible =3D "fsl,=
eloplus-dma-channel";=0A reg =3D <0x100 0x80=
>;=0A cell-index =3D <2>;=0A =
interrupt-parent =3D <&mpic>;=0A =
interrupts =3D <22 2>;=0A };=0A =
dma-channel@180 {=0A compatible =3D =
"fsl,eloplus-dma-channel";=0A reg =3D <0x180=
0x80>;=0A cell-index =3D <3>;=0A =
interrupt-parent =3D <&mpic>;=0A =
interrupts =3D <23 2>;=0A };=0A =
};=0A=0A=0A=0A--- On Wed, 4/6/11, Ira W. Snyder <iws@ovro.caltech.edu>=
wrote:=0A=0A> From: Ira W. Snyder <iws@ovro.caltech.edu>=0A> Subject: Re: =
Using dmaengine on Freescale P2020 RDB=0A> To: "Chuck Ketcham" <chuckk2333@=
yahoo.com>=0A> Cc: linuxppc-dev@lists.ozlabs.org=0A> Date: Wednesday, April=
6, 2011, 1:10 PM=0A> On Wed, Apr 06, 2011 at 12:40:58PM=0A> -0700, Chuck K=
etcham wrote:=0A> > All,=0A> > =0A> > I have a Freescale P2020 Reference De=
sign Board.=A0=0A> I am investigating the possibility of using the dmaengin=
e=0A> capability in the 2.6.32.13 kernel to transfer data from=0A> memory o=
ut onto the PCIe bus.=A0 As a first step, I=0A> thought I would try the DMA=
test client (dmatest.ko) to make=0A> sure the dmaengine was functioning.=
=A0 I know this=0A> doesn't transfer anything over PCIe but only transfers =
from=0A> one memory buffer to another, but I figured I need to get=0A> this=
working first.=A0 Anyway I built dmatest.ko and ran=0A> it (with insmod), =
and discovered it didn't do=0A> anything.=A0 I added some printk's to the k=
ernel to=0A> investigate what was going on and I found that all attempts=0A=
> to find a channel within dma_request_channel were=0A> unsuccessful.=A0 Th=
ree of the channels were not used=0A> because they were already publicly al=
located.=A0 One=0A> channel was not used because it didn't have DMA_MEMCPY=
=0A> capability.=0A> > =0A> > Here are my questions then:=0A> > 1. Is the d=
maengine the appropriate method to use for=0A> transferring data from memor=
y out onto the PCIe bus?=0A> > 2. If dmaengine is correct, what can I do to=
free up a=0A> channel for my own use?=0A> > =0A> =0A> I use the Freescale =
DMA engine to transfer lots of data out=0A> to PCI, on=0A> an 8349EA chip. =
The P2020 DMA engine uses the same driver.=0A> =0A> I hunch you have enable=
d CONFIG_NET_DMA, which will claim=0A> the channels.=0A> You should disable=
it to use the devices for other uses.=0A> =0A> If you want an example of u=
sing the DMA engine to transfer=0A> from DDR=0A> memory to the PowerPC loca=
l bus, search the mailing list=0A> archives for=0A> "CARMA Board Drivers" (=
RFCv7 was the latest posting).=0A> Transferring from=0A> DDR to PCI works e=
xactly the same way.=0A> =0A> Hope it helps,=0A> Ira=0A> __________________=
_____________________________=0A> Linuxppc-dev mailing list=0A> Linuxppc-de=
v@lists.ozlabs.org=0A> https://lists.ozlabs.org/listinfo/linuxppc-dev=0A>
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Gabriel Paubert @ 2011-04-06 20:43 UTC (permalink / raw)
To: Dave Airlie; +Cc: Greg KH, linuxppc-dev, LKML, Uwe Kleine-König
In-Reply-To: <BANLkTimAJ-s_3A3L1YGfoFLmd4bpu2jWVA@mail.gmail.com>
On Wed, Apr 06, 2011 at 06:46:55PM +1000, Dave Airlie wrote:
> 2011/4/6 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> > Hi Gabriel,
> >
> > On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
> >> I've had the following funny crashes on PPC machines, with
> >> cataleptic X server as a consequence:
> >>
> >> kernel: [drm] Setting GART location based on new memory map
> >> kernel: Oops: Exception in kernel mode, sig: 4 [#1]
> >> kernel: CHRP
> >> kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource
> >> kernel: NIP: c05648fc LR: c0226f58 CTR: 00000008
> >> kernel: REGS: ddb53d20 TRAP: 0700 Not tainted (2.6.38)
> >> kernel: MSR: 00089032 <EE,ME,IR,DR> CR: 48044482 XER: 00000000
> >> kernel: TASK = ddab12b0[3040] 'Xorg' THREAD: ddb52000
> >> kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 00000000 c0509e6c 00000000 00000000 00000000
> >> kernel: GPR08: 00000000 00000000 00000000 00000000 28044488 101f3d8c bf8166b4 00002c00
> >> kernel: GPR16: 101b9458 1006f1a0 101ebe0c 00000001 101ebe08 00000000 df9efc20 df9efc00
> >> kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a00000 df9ef800
> >> kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4
> >> kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4
> >> kernel: Call Trace:
> >> kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable)
> >> kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4
> >> kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710
> >> kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70
> >> kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38
> >> kernel: --- Exception: c01 at 0xfc54a78
> >> kernel: LR = 0xfc549dc
> >> kernel: Instruction dump:
> >> kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6f2e3132
> >> kernel: 006c6962 786b6266 696c652e 736f2e31 <002f7573> 722f6c69 622f6c69 62786b62
> >> kernel: ---[ end trace ed79daba161e31d9 ]---
> >>
> >> As you can see, the processor is trying to execute ASCII strings like
> >> "/usr/lib/libxkb" and has trouble digesting them :-)
> >>
> >> The backtrace is actually missing radeon_cp_init_microcode and radeon_do_init_cp
> >> which are inlined inside radeon_cp_init.
> >>
> >> The trouble is that radeon_cp_init_microcode calls platform_device_register_simple
> >> which is a simple inline wrapper around platform_device_register_resndata, which
> >> happens to be already freed and overwritten with something looking like a list
> >> of filenames, since I have a non modular kernel.
> >>
> >> For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8
> >> which simply added an _init_or_module section attribute to
> >> platform_device_register_resndata, and X is up again...
> >>
> >> Now it may be that it is the ioctl that does not have the right to do
> >> this. Actually I thought that the name radeon_cp that is registered there
> >> would appear somwhere under /sys (or /proc) but failed to find it...
> > I don't know for sure, but it looks strange to me that an ioctl can
> > register a device. But the fear for such code in the kernel made me
> > choose not to squash 737a3bb941 into 44f28bdea094. So my POV is that if
> > the maintainer of the radeon driver thinks registering the device is OK,
> > reverting 737a3bb9416 is fine for me.
>
> This is the old DRM driver for radeon, which relies on userspace to
> start X then calls the kernel
> to initialise the hardware. Due to this model, there is no device we
> can hang off (the PCI device
> might already be bound to fbdev), so we are forced to create a
> platform device to load the firmware.
>
> So its ugly, unless someone can suggest a better device to hang things
> off I don't know of another way.
>
The probem is that, at least on one of my machines, the new driver
does not work: the system hangs (apparently solid, but it's before
networking starts up and I've not yet hooked up a serial console),
after the "radeon: ib pool ready" message.
With the old driver, I've found some combinations of configuration
options that works. They all fail when DRM_RADEON_KMS is enabled.
Gabriel
> Dave.
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Felix Radensky @ 2011-04-06 20:49 UTC (permalink / raw)
To: linuxppc-dev, leon.woestenberg
In-Reply-To: <BANLkTinjn5nt4-0cSo6nUfG8Vt1UrL2Q0g@mail.gmail.com>
Hi Leon,
I think there's a hardware problem with mini PCI-E slot
on P2020RDB related to legacy IRQ routing. See this
thread for details
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html
You may have better luck with PCI-E slot and mini PCI-E to
PCI-E adapter.
Felix.
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Leon Woestenberg @ 2011-04-06 20:58 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev
In-Reply-To: <4D9CD1D6.6030600@embedded-sol.com>
Hello Felix,
On Wed, Apr 6, 2011 at 10:49 PM, Felix Radensky <felix@embedded-sol.com> wrote:
> I think there's a hardware problem with mini PCI-E slot
> on P2020RDB related to legacy IRQ routing. See this
> thread for details
> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html
>
Thanks for the heads-up.
> You may have better luck with PCI-E slot and mini PCI-E to
> PCI-E adapter.
>
Unfortunately the PCIe is slot already occupied, so that's why I
searched for and found the Mini PCIe Sil3132 card.
Legacy IRQ routing on PCIe is broken in what sense? Software (device
tree, kernel) or silicon (p2020) ?
On the MSI side, I'm getting quite far on transfers, but at one point
the device stalls. Maybe a race condition in interrupt handling in
sata_sil24.c?
Regards,
--
Leon
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Felix Radensky @ 2011-04-06 21:05 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: linuxppc-dev
In-Reply-To: <BANLkTimMatkioUudyaiy+r68=MyrJqiYQg@mail.gmail.com>
Hi Leon,
On 04/06/2011 11:58 PM, Leon Woestenberg wrote:
> Hello Felix,
>
> On Wed, Apr 6, 2011 at 10:49 PM, Felix Radensky<felix@embedded-sol.com> wrote:
>> I think there's a hardware problem with mini PCI-E slot
>> on P2020RDB related to legacy IRQ routing. See this
>> thread for details
>> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html
>>
>
> Unfortunately the PCIe is slot already occupied, so that's why I
> searched for and found the Mini PCIe Sil3132 card.
>
> Legacy IRQ routing on PCIe is broken in what sense? Software (device
> tree, kernel) or silicon (p2020) ?
It's a board design problem specific to P2020RDB. Maybe it's
fixed in latest board revisions. I have P2020RDB rev C and the
problem is still there. Freescale people on the list should know
better.
> On the MSI side, I'm getting quite far on transfers, but at one point
> the device stalls. Maybe a race condition in interrupt handling in
> sata_sil24.c?
Sorry, cannot help you with that. I have no experience with
sata_sil24.
Felix.
^ permalink raw reply
* Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Eric B Munson @ 2011-04-06 21:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <1301551476.2407.61.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]
On Thu, 31 Mar 2011, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-30 at 14:36 -0400, Eric B Munson wrote:
> > On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
> >
> > > On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
> > > > Here I made the assumption that the hardware would never remove more events in
> > > > a speculative roll back than it had added. This is not a situation I
> > > > encoutered in my limited testing, so I didn't think underflow was possible. I
> > > > will send out a V2 using the signed 32 bit delta and remeber to CC stable
> > > > this time.
> > >
> > > I'm not thinking about underflow but rollover... or that isn't possible
> > > with those counters ? IE. They don't wrap back to 0 after hitting
> > > ffffffff ?
> > >
> >
> > They do roll over to 0 after ffffffff, but I thought that case was already
> > covered by the perf_event_interrupt. Are you concerned that we will reset a
> > counter and speculative roll back will underflow that counter?
>
> No, but take this part of the patch:
>
> > --- a/arch/powerpc/kernel/perf_event.c
> > +++ b/arch/powerpc/kernel/perf_event.c
> > @@ -416,6 +416,15 @@ static void power_pmu_read(struct perf_event *event)
> > prev = local64_read(&event->hw.prev_count);
> > barrier();
> > val = read_pmc(event->hw.idx);
> > + /*
> > + * POWER7 can roll back counter values, if the new value is
> > + * smaller than the previous value it will cause the delta
> > + * and the counter to have bogus values. If this is the
> > + * case skip updating anything until the counter grows again.
> > + * This can lead to a small lack of precision in the counters.
> > + */
> > + if (val < prev)
> > + return;
> > } while (local64_cmpxchg(&event->hw.prev_count, prev, val) != prev);
>
> Doesn't that mean that power_pmu_read() can only ever increase the value of
> the perf_event and so will essentially -stop- once the counter rolls over ?
>
> Similar comments every where you do this type of comparison.
>
> Cheers,
> Ben.
Sorry for the nag, but am I missing something about the way the register and
the previous values are reset in the overflow interrupt handler?
Thanks,
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Using dmaengine on Freescale P2020 RDB
From: Ira W. Snyder @ 2011-04-06 21:28 UTC (permalink / raw)
To: Chuck Ketcham; +Cc: linuxppc-dev
In-Reply-To: <523835.3776.qm@web36403.mail.mud.yahoo.com>
On Wed, Apr 06, 2011 at 01:29:05PM -0700, Chuck Ketcham wrote:
> Ira,
>
> Thanks for the reference to the CARMA drivers. I will have to take a look at that.
>
> In my case, CONFIG_NET_DMA is not enabled. However, I did notice the following entry in my p2020rdb.dts file that may have something to do with dma channels being allocated -- can anyone interpret this?:
>
> dma@21300 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,eloplus-dma";
> reg = <0x21300 0x4>;
> ranges = <0x0 0x21100 0x200>;
> cell-index = <0>;
> dma-channel@0 {
> compatible = "fsl,eloplus-dma-channel";
> reg = <0x0 0x80>;
> cell-index = <0>;
> interrupt-parent = <&mpic>;
> interrupts = <20 2>;
> };
> dma-channel@80 {
> compatible = "fsl,eloplus-dma-channel";
> reg = <0x80 0x80>;
> cell-index = <1>;
> interrupt-parent = <&mpic>;
> interrupts = <21 2>;
> };
> dma-channel@100 {
> compatible = "fsl,eloplus-dma-channel";
> reg = <0x100 0x80>;
> cell-index = <2>;
> interrupt-parent = <&mpic>;
> interrupts = <22 2>;
> };
> dma-channel@180 {
> compatible = "fsl,eloplus-dma-channel";
> reg = <0x180 0x80>;
> cell-index = <3>;
> interrupt-parent = <&mpic>;
> interrupts = <23 2>;
> };
> };
>
>
Your DTS file looks fine. It is what I would expect to see. The channels
are not allocated by anything here.
Turning on CONFIG_DMADEVICES_DEBUG may give you some insight into how
the dmaengine core is allocating the channels. I don't have any better
advice. I'm afraid you'll have to figure out who is requesting all of
the channels on your own.
Ira
> --- On Wed, 4/6/11, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
>
> > From: Ira W. Snyder <iws@ovro.caltech.edu>
> > Subject: Re: Using dmaengine on Freescale P2020 RDB
> > To: "Chuck Ketcham" <chuckk2333@yahoo.com>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Date: Wednesday, April 6, 2011, 1:10 PM
> > On Wed, Apr 06, 2011 at 12:40:58PM
> > -0700, Chuck Ketcham wrote:
> > > All,
> > >
> > > I have a Freescale P2020 Reference Design Board.
> > I am investigating the possibility of using the dmaengine
> > capability in the 2.6.32.13 kernel to transfer data from
> > memory out onto the PCIe bus. As a first step, I
> > thought I would try the DMA test client (dmatest.ko) to make
> > sure the dmaengine was functioning. I know this
> > doesn't transfer anything over PCIe but only transfers from
> > one memory buffer to another, but I figured I need to get
> > this working first. Anyway I built dmatest.ko and ran
> > it (with insmod), and discovered it didn't do
> > anything. I added some printk's to the kernel to
> > investigate what was going on and I found that all attempts
> > to find a channel within dma_request_channel were
> > unsuccessful. Three of the channels were not used
> > because they were already publicly allocated. One
> > channel was not used because it didn't have DMA_MEMCPY
> > capability.
> > >
> > > Here are my questions then:
> > > 1. Is the dmaengine the appropriate method to use for
> > transferring data from memory out onto the PCIe bus?
> > > 2. If dmaengine is correct, what can I do to free up a
> > channel for my own use?
> > >
> >
> > I use the Freescale DMA engine to transfer lots of data out
> > to PCI, on
> > an 8349EA chip. The P2020 DMA engine uses the same driver.
> >
> > I hunch you have enabled CONFIG_NET_DMA, which will claim
> > the channels.
> > You should disable it to use the devices for other uses.
> >
> > If you want an example of using the DMA engine to transfer
> > from DDR
> > memory to the PowerPC local bus, search the mailing list
> > archives for
> > "CARMA Board Drivers" (RFCv7 was the latest posting).
> > Transferring from
> > DDR to PCI works exactly the same way.
> >
> > Hope it helps,
> > Ira
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
>
^ permalink raw reply
* Re: sdhc/mpc8536 - SDCard always detected like read-only - SOLVED.
From: Carlos Roberto Moratelli @ 2011-04-06 21:57 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <1302110338.2647.21.camel@moratelli-host.digitel.com.br>
Wolfram,
Reading the MPC8536E Chip Errata I saw the SDHC_WP signal polarity is
reversed to the silicon revision 1.0.
Unfortunately my prototype board is using revision 1.0. So, I asked to
my hardware team workaround putting an extra inverter for the SDHC_WP
signal.
Now its working fine!
Thanks,
Moratelli
Em Qua, 2011-04-06 às 14:18 -0300, Carlos Roberto Moratelli escreveu:
> I will try address the issue in details.
>
> When I insert the SDCard, the same is detect like read-only:
>
> mmcblk0: mmc0:b368 NCard 966 MiB (ro)
> mmcblk0:
> mmc0: starting CMD18 arg 00000000 flags 000000b5
> mmc0: blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
> mmc0: CMD12 arg 00000000 flags 0000049d
> sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
> sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0000000a
> sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
> mmc0: req done (CMD18): 0: 00000900 00000000 00000000 00000000
> mmc0: 4096 bytes transferred: 0
> mmc0: (CMD12): 0: 00000b00 00000000 00000000 00000000
> p1
>
> So, I just can mount the filesystem read-only. I can read the fat32
> without problems.
>
> I tested your sugestion. I used sdhci,wp-inverted in my dtb. This
> changed the behavior. Now the SDCard is detected without the read-only
> flag:
>
> mmcblk0: mmc0:b368 NCard 966 MiB
> mmcblk0:
> mmc0: starting CMD18 arg 00000000 flags 000000b5
> mmc0: blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
> mmc0: CMD12 arg 00000000 flags 0000049d
> sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
> sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0000000a
> sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
> mmc0: req done (CMD18): 0: 00000900 00000000 00000000 00000000
> mmc0: 4096 bytes transferred: 0
> mmc0: (CMD12): 0: 00000b00 00000000 00000000 00000000
> p1
>
> And, I can mount a rw filesystem:
>
> #mount /dev/mmcblock1 /mnt
> #cat /proc/mounts
> ...
> /dev/mmcblock1 /mnt vfat
> rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
> ...
>
> So, I can copy files to the mounted SDCard. But, When I try to umount I
> see the following error mensagens:
>
> #cp /etc/shadow /mnt
> #ls /mnt
> shadow
> #umount /mnt
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 5944, nr 1, card status
> 0x900
> end_request: I/O error, dev mmcblk0, sector 5944
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 5936, nr 1, card status
> 0x900
> end_request: I/O error, dev mmcblk0, sector 5936
> Buffer I/O error on device mmcblk0p1, logical block 3888
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 2049, nr 1, card status
> 0x900
> end_request: I/O error, dev mmcblk0, sector 2049
> Buffer I/O error on device mmcblk0p1, logical block 1
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 2080, nr 1, card status
> 0x900
> end_request: I/O error, dev mmcblk0, sector 2080
> ...
>
> I think I need the sdhci,wp-inverted in my dtb. But, it appears that
> more something is necessary.
>
> Has someone faced this situation?
>
> Thanks by the help until here.
>
> Regards,
>
> Moratelli
>
>
>
> Em Qua, 2011-04-06 às 01:48 +0200, Wolfram Sang escreveu:
> > > sdhci@2e000 {
> > > compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
> > > reg = <0x2e000 0x1000>;
> > > interrupts = <72 0x2>;
> > > interrupt-parent = <&mpic>;
> > > /* Filled in by U-Boot */
> > > clock-frequency = <0>;
> > > };
> >
> > Hmm, I am not too familiar with those SoCs, yet some 83xx needed
> >
> > sdhci,wp-inverted;
> >
> > here. Maybe yours, too? Would fit the symptoms.
> >
> > Regards,
> >
> > Wolfram
> >
>
^ permalink raw reply
* [PATCH 1/1] powerpc/eeh: Add support for ibm,configure-pe RTAS call
From: Richard A Lary @ 2011-04-06 22:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rlary
From: Richard A. Lary <rlary@linux.vnet.ibm.com>
Added support for ibm,configure-pe RTAS call introduced with
PAPR 2.2.
Signed-off-by: Richard A. Lary <rlary@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/eeh.c | 13 12 + 1 - 0 !
1 file changed, 12 insertions(+), 1 deletion(-)
Index: b/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -95,6 +95,7 @@ static int ibm_slot_error_detail;
static int ibm_get_config_addr_info;
static int ibm_get_config_addr_info2;
static int ibm_configure_bridge;
+static int ibm_configure_pe;
int eeh_subsystem_enabled;
EXPORT_SYMBOL(eeh_subsystem_enabled);
@@ -263,6 +264,8 @@ void eeh_slot_error_detail(struct pci_dn
pci_regs_buf[0] = 0;
rtas_pci_enable(pdn, EEH_THAW_MMIO);
+ rtas_configure_bridge(pdn);
+ eeh_restore_bars(pdn);
loglen = gather_pci_data(pdn, pci_regs_buf, EEH_PCI_REGS_LOG_LEN);
rtas_slot_error_detail(pdn, severity, pci_regs_buf, loglen);
@@ -896,6 +899,7 @@ void
rtas_configure_bridge(struct pci_dn *pdn)
{
int config_addr;
+ int token;
int rc;
/* Use PE configuration address, if present */
@@ -903,7 +907,13 @@ rtas_configure_bridge(struct pci_dn *pdn
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;
- rc = rtas_call(ibm_configure_bridge,3,1, NULL,
+ /* Use new configure-pe function, if supported */
+ if (ibm_configure_pe != RTAS_UNKNOWN_SERVICE)
+ token = ibm_configure_pe;
+ else
+ token = ibm_configure_bridge;
+
+ rc = rtas_call(token, 3, 1, NULL,
config_addr,
BUID_HI(pdn->phb->buid),
BUID_LO(pdn->phb->buid));
@@ -1079,6 +1089,7 @@ void __init eeh_init(void)
ibm_get_config_addr_info = rtas_token("ibm,get-config-addr-info");
ibm_get_config_addr_info2 = rtas_token("ibm,get-config-addr-info2");
ibm_configure_bridge = rtas_token ("ibm,configure-bridge");
+ ibm_configure_pe = rtas_token("ibm,configure-pe");
if (ibm_set_eeh_option == RTAS_UNKNOWN_SERVICE)
return;
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/eeh: Add support for ibm,configure-pe RTAS call
From: Benjamin Herrenschmidt @ 2011-04-07 3:35 UTC (permalink / raw)
To: Richard A Lary; +Cc: linuxppc-dev
In-Reply-To: <4D9CEE45.9000904@linux.vnet.ibm.com>
On Wed, 2011-04-06 at 15:50 -0700, Richard A Lary wrote:
> From: Richard A. Lary <rlary@linux.vnet.ibm.com>
>
> Added support for ibm,configure-pe RTAS call introduced with
> PAPR 2.2.
Care to tell us a bit about the difference ? :-) There's nothing obvious
in the code.... Also you added calls to rtas_configure_bridge() and
eeh_restore_bars() to eeh_slot_error_Detail(), that might want some
explanation as well.
Cheers,
Ben.
> Signed-off-by: Richard A. Lary <rlary@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/eeh.c | 13 12 + 1 - 0 !
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> Index: b/arch/powerpc/platforms/pseries/eeh.c
> ===================================================================
> --- a/arch/powerpc/platforms/pseries/eeh.c
> +++ b/arch/powerpc/platforms/pseries/eeh.c
> @@ -95,6 +95,7 @@ static int ibm_slot_error_detail;
> static int ibm_get_config_addr_info;
> static int ibm_get_config_addr_info2;
> static int ibm_configure_bridge;
> +static int ibm_configure_pe;
>
> int eeh_subsystem_enabled;
> EXPORT_SYMBOL(eeh_subsystem_enabled);
> @@ -263,6 +264,8 @@ void eeh_slot_error_detail(struct pci_dn
> pci_regs_buf[0] = 0;
>
> rtas_pci_enable(pdn, EEH_THAW_MMIO);
> + rtas_configure_bridge(pdn);
> + eeh_restore_bars(pdn);
> loglen = gather_pci_data(pdn, pci_regs_buf, EEH_PCI_REGS_LOG_LEN);
>
> rtas_slot_error_detail(pdn, severity, pci_regs_buf, loglen);
> @@ -896,6 +899,7 @@ void
> rtas_configure_bridge(struct pci_dn *pdn)
> {
> int config_addr;
> + int token;
> int rc;
>
> /* Use PE configuration address, if present */
> @@ -903,7 +907,13 @@ rtas_configure_bridge(struct pci_dn *pdn
> if (pdn->eeh_pe_config_addr)
> config_addr = pdn->eeh_pe_config_addr;
>
> - rc = rtas_call(ibm_configure_bridge,3,1, NULL,
> + /* Use new configure-pe function, if supported */
> + if (ibm_configure_pe != RTAS_UNKNOWN_SERVICE)
> + token = ibm_configure_pe;
> + else
> + token = ibm_configure_bridge;
> +
> + rc = rtas_call(token, 3, 1, NULL,
> config_addr,
> BUID_HI(pdn->phb->buid),
> BUID_LO(pdn->phb->buid));
> @@ -1079,6 +1089,7 @@ void __init eeh_init(void)
> ibm_get_config_addr_info = rtas_token("ibm,get-config-addr-info");
> ibm_get_config_addr_info2 = rtas_token("ibm,get-config-addr-info2");
> ibm_configure_bridge = rtas_token ("ibm,configure-bridge");
> + ibm_configure_pe = rtas_token("ibm,configure-pe");
>
> if (ibm_set_eeh_option == RTAS_UNKNOWN_SERVICE)
> return;
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc: Use new CPU feature bit to select 2.06 tlbie
From: Michael Neuling @ 2011-04-07 4:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1301986248.2549.141.camel@pasglop>
This removes MMU_FTR_TLBIE_206 as we can now use CPU_FTR_HVMODE_206. It
also changes the logic to select which tlbie to use to be based on this
new CPU feature bit.
This also duplicates the ASM_FTR_IF/SET/CLR defines for CPU features
(copied from MMU features).
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Subject: Re: [PATCH 04/15] powerpc: Define CPU feature for Architected 2.06 HV mode
> > > +#define CPU_FTR_HVMODE_206 LONG_ASM_CONST(0x00000008000000
00)
> >
> > FYI With this patch we could remove MMU_FTR_TLBIE_206.
>
> We could... care to send a patch ? :-)
Sure... How about this?
Mikey
arch/powerpc/include/asm/feature-fixups.h | 13 +++++++++++++
arch/powerpc/include/asm/mmu.h | 5 -----
arch/powerpc/kernel/cputable.c | 9 +++------
arch/powerpc/mm/hash_native_64.c | 8 ++++----
4 files changed, 20 insertions(+), 15 deletions(-)
Index: clone1/arch/powerpc/include/asm/feature-fixups.h
===================================================================
--- clone1.orig/arch/powerpc/include/asm/feature-fixups.h
+++ clone1/arch/powerpc/include/asm/feature-fixups.h
@@ -146,6 +146,19 @@
#ifndef __ASSEMBLY__
+#define ASM_FTR_IF(section_if, section_else, msk, val) \
+ stringify_in_c(BEGIN_FTR_SECTION) \
+ section_if "; " \
+ stringify_in_c(FTR_SECTION_ELSE) \
+ section_else "; " \
+ stringify_in_c(ALT_FTR_SECTION_END((msk), (val)))
+
+#define ASM_FTR_IFSET(section_if, section_else, msk) \
+ ASM_FTR_IF(section_if, section_else, (msk), (msk))
+
+#define ASM_FTR_IFCLR(section_if, section_else, msk) \
+ ASM_FTR_IF(section_if, section_else, (msk), 0)
+
#define ASM_MMU_FTR_IF(section_if, section_else, msk, val) \
stringify_in_c(BEGIN_MMU_FTR_SECTION) \
section_if "; " \
Index: clone1/arch/powerpc/include/asm/mmu.h
===================================================================
--- clone1.orig/arch/powerpc/include/asm/mmu.h
+++ clone1/arch/powerpc/include/asm/mmu.h
@@ -56,11 +56,6 @@
*/
#define MMU_FTR_NEED_DTLB_SW_LRU ASM_CONST(0x00200000)
-/* This indicates that the processor uses the ISA 2.06 server tlbie
- * mnemonics
- */
-#define MMU_FTR_TLBIE_206 ASM_CONST(0x00400000)
-
/* Enable use of TLB reservation. Processor should support tlbsrx.
* instruction and MAS0[WQ].
*/
Index: clone1/arch/powerpc/kernel/cputable.c
===================================================================
--- clone1.orig/arch/powerpc/kernel/cputable.c
+++ clone1/arch/powerpc/kernel/cputable.c
@@ -417,8 +417,7 @@
.cpu_name = "POWER7 (architected)",
.cpu_features = CPU_FTRS_POWER7,
.cpu_user_features = COMMON_USER_POWER7,
- .mmu_features = MMU_FTR_HPTE_TABLE |
- MMU_FTR_TLBIE_206,
+ .mmu_features = MMU_FTR_HPTE_TABLE,
.icache_bsize = 128,
.dcache_bsize = 128,
.oprofile_type = PPC_OPROFILE_POWER4,
@@ -433,8 +432,7 @@
.cpu_name = "POWER7 (raw)",
.cpu_features = CPU_FTRS_POWER7,
.cpu_user_features = COMMON_USER_POWER7,
- .mmu_features = MMU_FTR_HPTE_TABLE |
- MMU_FTR_TLBIE_206,
+ .mmu_features = MMU_FTR_HPTE_TABLE,
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
@@ -451,8 +449,7 @@
.cpu_name = "POWER7+ (raw)",
.cpu_features = CPU_FTRS_POWER7,
.cpu_user_features = COMMON_USER_POWER7,
- .mmu_features = MMU_FTR_HPTE_TABLE |
- MMU_FTR_TLBIE_206,
+ .mmu_features = MMU_FTR_HPTE_TABLE,
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
Index: clone1/arch/powerpc/mm/hash_native_64.c
===================================================================
--- clone1.orig/arch/powerpc/mm/hash_native_64.c
+++ clone1/arch/powerpc/mm/hash_native_64.c
@@ -50,9 +50,9 @@
case MMU_PAGE_4K:
va &= ~0xffful;
va |= ssize << 8;
- asm volatile(ASM_MMU_FTR_IFCLR("tlbie %0,0", PPC_TLBIE(%1,%0),
+ asm volatile(ASM_FTR_IFCLR("tlbie %0,0", PPC_TLBIE(%1,%0),
%2)
- : : "r" (va), "r"(0), "i" (MMU_FTR_TLBIE_206)
+ : : "r" (va), "r"(0), "i" (CPU_FTR_HVMODE_206)
: "memory");
break;
default:
@@ -61,9 +61,9 @@
va |= penc << 12;
va |= ssize << 8;
va |= 1; /* L */
- asm volatile(ASM_MMU_FTR_IFCLR("tlbie %0,1", PPC_TLBIE(%1,%0),
+ asm volatile( ASM_FTR_IFCLR("tlbie %0,1", PPC_TLBIE(%1,%0),
%2)
- : : "r" (va), "r"(0), "i" (MMU_FTR_TLBIE_206)
+ : : "r" (va), "r"(0), "i" (CPU_FTR_HVMODE_206)
: "memory");
break;
}
^ permalink raw reply
* Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Benjamin Herrenschmidt @ 2011-04-07 4:22 UTC (permalink / raw)
To: Eric B Munson
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <20110406212733.GB2596@mgebm.net>
> > Doesn't that mean that power_pmu_read() can only ever increase the value of
> > the perf_event and so will essentially -stop- once the counter rolls over ?
> >
> > Similar comments every where you do this type of comparison.
> >
> > Cheers,
> > Ben.
>
> Sorry for the nag, but am I missing something about the way the register and
> the previous values are reset in the overflow interrupt handler?
Well, not all counters get interrupts right ? Some counters are just
free running... I'm not sure when that power_pmu_read() function is
actually used by the core, I'm not that familiar with perf, but I'd say
better safe than sorry. When comparing counter values, doing in a way
that is generally safe vs. wraparounds. Eventually do a helper for that.
Cheers,
Ben.
^ permalink raw reply
* Re: sdhc/mpc8536 - SDCard always detected like read-only - SOLVED.
From: Wolfram Sang @ 2011-04-07 4:51 UTC (permalink / raw)
To: Carlos Roberto Moratelli; +Cc: linuxppc-dev
In-Reply-To: <1302127065.2647.60.camel@moratelli-host.digitel.com.br>
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
> Reading the MPC8536E Chip Errata I saw the SDHC_WP signal polarity is
> reversed to the silicon revision 1.0.
>
> Unfortunately my prototype board is using revision 1.0. So, I asked to
> my hardware team workaround putting an extra inverter for the SDHC_WP
> signal.
>
> Now its working fine!
OK, nice. I fail to see from a glimpse how all this is related to the
timeout-errors you were seeing (-110), but if it works now, all is fine, I
guess.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RE: known working sata_sil24.c setup on powerpc platforms?
From: Kushwaha Prabhakar-B32579 @ 2011-04-07 4:48 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Linux PPC, Tejun Heo, Jeff Garzik, Moffett, Kyle D,
linux-ide@vger.kernel.org
In-Reply-To: <BANLkTinjn5nt4-0cSo6nUfG8Vt1UrL2Q0g@mail.gmail.com>
Hi Leon,
Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
In order to work in legacy mode, IDSEL entries are required.=20
--Prabhakar
> -----Original Message-----
> From: linux-ide-owner@vger.kernel.org [mailto:linux-ide-
> owner@vger.kernel.org] On Behalf Of Leon Woestenberg
> Sent: Thursday, April 07, 2011 12:20 AM
> To: Jeff Garzik
> Cc: Moffett, Kyle D; Linux PPC; linux-ide@vger.kernel.org; Tejun Heo
> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>=20
> Hello Jeff, all,
>=20
> On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik <jeff@garzik.org> wrote:
> > On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
> >> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
> >>> after investigating problems with sata_sil24.c on a freescale p2020
> >>> soc, I wonder if this driver works on powerpc at all?
> >>>
> >>> Does anyone know of a working setup of sata_sil24 on a big endian
> >>> powerpc system?
> >>
> >> Our P2020 boards work fine with legacy PCI interrupts (I think it's a
> >> sil3124 over PCI-E); the only deficiency is that MSI does not seem to
> work.
> >>
> >
> > We've definitely had issues with sata_sil24 + MSI, also...
> >
> > sata_sil24 does work on big endian in general.
> >
>=20
> On my system, I have the contrary to Kyle's experience (thanks for
> sharing).
>=20
> PowerPC P2020RDB
> vanilla 2.6.38
> Sil3132 on mini-PCI Express card
>=20
>=20
> Enabling msi gets me further than disabling it (default).
>=20
> modprobe sata_sil
>=20
> [ 8.834613] sata_sil24 0001:03:00.0: version 1.1
> [ 8.885581] scsi0 : sata_sil24
> [ 8.901420] scsi1 : sata_sil24
> [ 8.904642] ata1: SATA max UDMA/100 host m128@0xc0000000 port
> 0xc0004000 irq 16
> [ 8.911961] ata2: SATA max UDMA/100 host m128@0xc0000000 port
> 0xc0006000 irq 16
> [ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
> [ 14.906986] eth0: no IPv6 routers present
> [ 16.099016] ata1.00: qc timeout (cmd 0xec)
> [ 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=3D0x4)
> [ 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
> [ 28.303026] ata1.00: qc timeout (cmd 0xec)
> [ 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=3D0x4)
> [ 28.313233] ata1: limiting SATA link speed to 1.5 Gbps
> [ 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10)
>=20
>=20
> modprobe sata_sil msi=3D1
>=20
> [ 92.984120] sata_sil24 0001:03:00.0: version 1.1
> [ 92.988897] irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to
> virtual irq 41
> [ 92.996229] sata_sil24 0001:03:00.0: Using MSI
> [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering
> [ 93.011628] scsi2 : sata_sil24
> [ 93.022463] scsi3 : sata_sil24
> [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc0000000 port
> 0xc0004000 irq 41
> [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
> 0xc0006000 irq 41
> [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
> [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag
> -84148995 sactive 0x0)
> [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max
> UDMA/133
> [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth
> 31/32)
> [ 95.230905] ata3.00: configured for UDMA/100
> [ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL
> SSDSA2M080 2CV1 PQ: 0 ANSI: 5
> [ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0
> [ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
> (80.0 GB/74.5 GiB)
> [ 95.260219] sd 2:0:0:0: [sda] Write Protect is off
> [ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [ 95.283779] sda: sda1 sda2 sda3 sda4
> [ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk
> [ 95.965897] EXT3-fs: barriers not enabled
> [ 95.977279] kjournald starting. Commit interval 5 seconds
> [ 95.983296] EXT3-fs (sda2): using internal journal
> [ 95.988143] EXT3-fs (sda2): recovery complete
> [ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data
> mode
> [ 96.111587] NTFS volume version 3.1.
> [ 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
>=20
> root@p1020rdb:~# dd if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D1000
> 1000+0 records in
> 1000+0 records out
> 4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s root@p1020rdb:~# dd
> if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D10000
> 10000+0 records in
> 10000+0 records out
> 40960000 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s
>=20
> root@p1020rdb:~# dd if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D100000
>=20
> That stalls, I see the controller fail. See dmesg below:
>=20
> ^C^Cdd: reading `/dev/sda': Input/output error
> 51804+0 records in
> 51804+0 records out
> 212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s
> dd: closing input file `/dev/sda': Bad file descriptor
>=20
>=20
> [ 92.984120] sata_sil24 0001:03:00.0: version 1.1
> [ 92.988897] irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to
> virtual irq 41
> [ 92.996229] sata_sil24 0001:03:00.0: Using MSI
> [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering
> [ 93.011628] scsi2 : sata_sil24
> [ 93.022463] scsi3 : sata_sil24
> [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc0000000 port
> 0xc0004000 irq 41
> [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
> 0xc0006000 irq 41
> [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
> [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag
> -84148995 sactive 0x0)
> [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max
> UDMA/133
> [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth
> 31/32)
> [ 95.230905] ata3.00: configured for UDMA/100
> [ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL
> SSDSA2M080 2CV1 PQ: 0 ANSI: 5
> [ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0
> [ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
> (80.0 GB/74.5 GiB)
> [ 95.260219] sd 2:0:0:0: [sda] Write Protect is off
> [ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [ 95.283779] sda: sda1 sda2 sda3 sda4
> [ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk
> [ 95.965897] EXT3-fs: barriers not enabled
> [ 95.977279] kjournald starting. Commit interval 5 seconds
> [ 95.983296] EXT3-fs (sda2): using internal journal
> [ 95.988143] EXT3-fs (sda2): recovery complete
> [ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data
> mode
> [ 96.111587] NTFS volume version 3.1.
> [ 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
> [ 285.891036] ata3.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6
> frozen [ 285.898099] ata3.00: failed command: READ FPDMA QUEUED [
> 285.903250] ata3.00: cmd 60/00:00:e0:53:06/01:00:00:00:00/40 tag 0 ncq
> 131072 in
> [ 285.903255] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
> 0x4 (timeout)
> [ 285.918028] ata3.00: status: { DRDY } [ 285.921689] ata3.00: failed
> command: READ FPDMA QUEUED [ 285.926836] ata3.00: cmd
> 60/00:08:e0:52:06/01:00:00:00:00/40 tag 1 ncq 131072 in
> [ 285.926841] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
> 0x4 (timeout)
> [ 285.941615] ata3.00: status: { DRDY } [ 285.945281] ata3: hard
> resetting link [ 288.055034] ata3: SATA link up 3.0 Gbps (SStatus 123
> SControl 0) [ 293.058999] ata3.00: qc timeout (cmd 0xec) [ 293.063106]
> ata3.00: failed to IDENTIFY (I/O error, err_mask=3D0x4) [ 293.069198]
> ata3.00: revalidation failed (errno=3D-5) [ 293.074077] ata3: hard
> resetting link [ 295.259018] ata3: SATA link up 3.0 Gbps (SStatus 123
> SControl 0)
>=20
> What can I do next to investigate and help fix this issue?
>=20
>=20
> Regards,
> --
> Leon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox