Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi again,
sorry for having taken so long, but university-work called :-)
Am Montag 20 Juni 2011, 21:34:53 schrieb Andrei Warkentin:
> On Sun, Jun 19, 2011 at 9:23 AM, Heiko Stübner wrote:
> > Am Samstag 18 Juni 2011, 22:56:11 schrieb Daniel Mack:
> The log you sent out seems a bit short (it's covers < 1s of boot time
> - usb0: no IPv6 routers present is the last line ). Can you send -
> 1) A full log with errors without any of my patches.
> 2) A full log with just the first patch.
> 3) A full log with just the second patch.
I have attached a log with mmc-debugging enabled.
The relevant parts start around line 2634 ("waiting for /dev to be fully
populated" - the udev start). The culprit (Hynix-nand) is mmc1.
Switching the patches on and off will have to wait until the weekend. But I can
say the error (irq message and register dump [and them looping endlessly]) has
not not changed from before your patches.
I'm curious, is mmc_blk_resume (which is modified by your second patch) called
at other times than when waking up from system suspend? [i.e. during system
startup]
> I'm interested in knowing what the pattern of access to boot0 and
> boot1 is that causes these failures - does it only report I/O errors
> for for certain blocks (say, above some number) or for all of them.
it doesn't report io-errors at all. It send endless loops of CMD13 calls with
the same argument and receives interrupts it does not expect :-)
Thanks again for your time
Heiko
dmesg-debug_20110629.txt.gz
Description: GNU Zip compressed data
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Heiko, On Sun, Jun 19, 2011 at 9:23 AM, Heiko Stübner wrote: > Am Samstag 18 Juni 2011, 22:56:11 schrieb Daniel Mack: The log you sent out seems a bit short (it's covers < 1s of boot time - usb0: no IPv6 routers present is the last line ). Can you send - 1) A full log with errors without any of my patches. 2) A full log with just the first patch. 3) A full log with just the second patch. I'm interested in knowing what the pattern of access to boot0 and boot1 is that causes these failures - does it only report I/O errors for for certain blocks (say, above some number) or for all of them. A -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Am Samstag 18 Juni 2011, 22:56:11 schrieb Daniel Mack:
> On Thu, Jun 2, 2011 at 9:49 PM, Heiko Stübner wrote:
> > Hi,
> >
> > after upgrading my development kernel from 2.6.38 to 3.0rc1 I get flooded
> > (i.e.
>
> > it never stops) by messages of the form:
> Even though it's not really related to SDIO, does reverting 06e8935
> ("mmc: sdio: optimized SDIO IRQ handling for single irq") fix your
> problem?
sadly reverting this commit didn't fix the problem.
It still floods everything with CMD13s and interrupts
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
On Thu, Jun 2, 2011 at 9:49 PM, Heiko Stübner wrote:
> Hi,
>
> after upgrading my development kernel from 2.6.38 to 3.0rc1 I get flooded
> (i.e.
> it never stops) by messages of the form:
Even though it's not really related to SDIO, does reverting 06e8935
("mmc: sdio: optimized SDIO IRQ handling for single irq") fix your
problem?
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi again, Am Donnerstag 16 Juni 2011, 22:35:52 schrieb Andrei Warkentin: > On Thu, Jun 16, 2011 at 3:14 PM, Heiko Stübner wrote: > > Am Dienstag 14 Juni 2011, 22:32:41 schrieb Andrei Warkentin: > >> Hi Heiko, > >> > >> On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner wrote: > >> > nope, no updates yet. The flood also only starts when udev wants to > >> > create its device nodes, meaning the initial detection seems not to > >> > produce this problem > >> > > >> > But when I disable the whole boot partition stuff, it works as before > >> > without irq storms. > >> > > >> > As there don't seem to exist reports from other emmc users about this > >> > I guess the problem lays somewhere between the boot-partitions-patch > >> > and the sdhci-s3c driver (for s3c2416 at least). > >> > >> Alright. Curious. Can you let me know what eMMC device you are > >> connecting to the controller? What is the eMMC revision? > > > > hmm ... how do I find these? > > The simplest is probably knowing what part is in your platform. The > slightly more involved is adding a relevant printk for > card->ext_csd.rev inside drivers/mmc/core/mmc.c. ext_csd.rev is 3 > Can you provide me dmesg for both patches? I've attached a dmesg from booting with both of your patches. To get meaningful output I disabled the "got data interrupt xxx even though no data ..." message flood. But it seems your code isn't called (I'm not seeing the ">>>" line) But I did find other peculiarities after enabling mmc-debugging - a log full of the following three lines repeating endlessly: (i.e. it never stops) [...] mmc1: starting CMD13 arg 0001 flags 0195 sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0001 mmc1: req done (CMD13): 0: 0e00 [...] repeat exactly the same lines over and over As I wrote, this whole thing happens when udev starts and if I let it run long enough udev produces the following error messages: udevadm settle - timeout of 180 seconds reached, the event queue contains: /sys/devices/platform/s3c- sdhci.1/mmc_host/mmc1/mmc1:0001/block/mmcblk1/mmcblk1boot0 (470) /sys/devices/platform/s3c- sdhci.1/mmc_host/mmc1/mmc1:0001/block/mmcblk1/mmcblk1boot1 (471) /sys/devices/platform/s3c- sdhci.1/mmc_host/mmc1/mmc1:0001/block/mmcblk1/mmcblk1p1 (472) /sys/devices/platform/s3c- sdhci.1/mmc_host/mmc1/mmc1:0001/block/mmcblk1/mmcblk1p2 (473) /sys/devices/platform/s3c- sdhci.1/mmc_host/mmc1/mmc1:0001/block/mmcblk1/mmcblk1p3 (474) udevd[362]: worker [379] unexpectedly returned with status 0x0100 udevd[362]: worker [379] failed while handling '/devices/platform/s3c- sdhci.1/mmc_host/mmc1/mmc1:0001/block/mmcblk1/mmcblk1boot0' Heiko Linux version 3.0.0-rc1+ (hstuebner@marty) (gcc version 4.3.5 (Debian 4.3.5-2) ) #134 Sat Jun 18 21:22:31 CEST 2011 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: SG060 Ignoring unrecognised tag 0x23520001 Ignoring unrecognised tag 0x23520002 Ignoring unrecognised tag 0x23520003 Ignoring unrecognised tag 0x23520004 Memory policy: ECC disabled, Data cache writeback CPU S3C2416/S3C2450 (id 0x32450003) S3C24XX Clocks, Copyright 2004 Simtec Electronics CPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 MHz CPU: EPLL on 96.000 MHz, usb-bus 48.000 MHz i2sepll_div 96.000 MHz, i2s 96.000 MHz, iis 66.666 MHz On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c02bebec, node_mem_map c02eb000 Normal zone: 256 pages used for memmap Normal zone: 0 pages reserved Normal zone: 32512 pages, LIFO batch:7 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/nfs nfsroot=192.168.0.200:/home/devel/hstuebner/debianroot ip=192.168.0.202:192.168.0.200:192.168.0.200:255.255.255.0:ezx:usb0:off rootdelay=5 console=ttySAC0,115200 ro init=/sbin/init PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 125112k/125112k available, 5960k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc880 - 0xf600 ( 728 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc0026000 ( 120 kB) .text : 0xc0026000 - 0xc02a5000 (2556 kB) .data : 0xc02a6000 - 0xc02c1180 ( 109 kB) SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS:99 irq: clearing pending ext status 0200 irq: clearing subpending status 0402 irq: clearing subpending status 0002 timer tcon=0050, tcnt d902, tcfg 0200,, usec 170a Console: colour
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi, On Thu, Jun 16, 2011 at 3:14 PM, Heiko Stübner wrote: > Am Dienstag 14 Juni 2011, 22:32:41 schrieb Andrei Warkentin: >> Hi Heiko, >> >> On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner wrote: >> > nope, no updates yet. The flood also only starts when udev wants to >> > create its device nodes, meaning the initial detection seems not to >> > produce this problem >> > >> > But when I disable the whole boot partition stuff, it works as before >> > without irq storms. >> > >> > As there don't seem to exist reports from other emmc users about this >> > I guess the problem lays somewhere between the boot-partitions-patch >> > and the sdhci-s3c driver (for s3c2416 at least). >> >> Alright. Curious. Can you let me know what eMMC device you are >> connecting to the controller? What is the eMMC revision? > hmm ... how do I find these? The simplest is probably knowing what part is in your platform. The slightly more involved is adding a relevant printk for card->ext_csd.rev inside drivers/mmc/core/mmc.c. > The real device providing the storage is a 2GB NAND Flash from Hynix. > > And sadly both of your patches didn't change anything. > Can you provide me dmesg for both patches? Thanks again, A -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Am Dienstag 14 Juni 2011, 22:32:41 schrieb Andrei Warkentin: > Hi Heiko, > > On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner wrote: > > nope, no updates yet. The flood also only starts when udev wants to > > create its device nodes, meaning the initial detection seems not to > > produce this problem > > > > But when I disable the whole boot partition stuff, it works as before > > without irq storms. > > > > As there don't seem to exist reports from other emmc users about this > > I guess the problem lays somewhere between the boot-partitions-patch > > and the sdhci-s3c driver (for s3c2416 at least). > > Alright. Curious. Can you let me know what eMMC device you are > connecting to the controller? What is the eMMC revision? hmm ... how do I find these? The real device providing the storage is a 2GB NAND Flash from Hynix. And sadly both of your patches didn't change anything. I made two interessting observations: during boot the initial detection works ok - I can even mount the normal partitions without hickup when I stop it before the udev stage. The irq storm seems to be caused by something udev does during its population of the /dev filesystem. And second the mentioned irq storm never stops during the runtime of the device. When I let it boot through it spews what must be millions of the irq messages and does so until I shut it down. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi Heiko,
On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner wrote:
> Hi Andrei,
>
> Am Dienstag 14 Juni 2011 schrieb Andrei Warkentin:
>> I recently came back from vacation (which is why I didn't pitch in
>> before). Has there been any further update on this? I want to exclude
>> my EMMC partitioning changes as the possible culprit here.
>
> nope, no updates yet. The flood also only starts when udev wants to
> create its device nodes, meaning the initial detection seems not to
> produce this problem
>
> But when I disable the whole boot partition stuff, it works as before
> without irq storms.
>
> As there don't seem to exist reports from other emmc users about this
> I guess the problem lays somewhere between the boot-partitions-patch
> and the sdhci-s3c driver (for s3c2416 at least).
>
> As my knowledge about the whole mmc-subsystem is quite spare I also
> don't really know where to start looking for the culprit yet.
Alright. Curious. Can you let me know what eMMC device you are
connecting to the controller? What is the eMMC revision?
Can you also apply the following and let me know the results? This
adds an error message if the partition switch fails, and forces the
device to ALWAYS switch back to main user area after every completed
RQ.
start
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 71da564..74e1029 100755
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -450,9 +450,12 @@ static inline int mmc_blk_part_switch(struct
mmc_card *card,
ret = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_PART_CONFIG, card->ext_csd.part_config,
card->ext_csd.part_time);
- if (ret)
+ if (ret) {
+ printk(KERN_ERR ">>> error switching to part_type %d\n",
+ md->part_type);
return ret;
-}
+ }
+ }
main_md->part_curr = md->part_type;
return 0;
@@ -964,6 +967,13 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq,
struct request *req)
}
out:
+
+ /* Switch to main_md (type = 0) */
+ ret = mmc_blk_part_switch(card, (struct mmc_blk_data *)
mmc_get_drvdata(card));
+ if (ret) {
+ ret = 0;
+ }
+
mmc_release_host(card->host);
return ret;
}
end
I am curious about the results. Here is another thing to try out. This
forces a switch to user area (main partition) every time blk resume is
invoked -
>>> start
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 71da564..f7be8f7 100755
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1318,6 +1318,7 @@ static int mmc_blk_suspend(struct mmc_card
*card, pm_message_t state)
static int mmc_blk_resume(struct mmc_card *card)
{
+ int ret;
struct mmc_blk_data *part_md;
struct mmc_blk_data *md = mmc_get_drvdata(card);
@@ -1325,10 +1326,13 @@ static int mmc_blk_resume(struct mmc_card *card)
mmc_blk_set_blksize(md, card);
/*
-* Resume involves the card going into idle state,
-* so current partition is always the main one.
+* Force main user area on resume. Technically
+* card should have switched itself during reset.
*/
- md->part_curr = md->part_type;
+ ret = mmc_blk_part_switch(card, md);
+ if (ret)
+ return ret;
+
mmc_queue_resume(&md->queue);
list_for_each_entry(part_md, &md->part, part) {
mmc_queue_resume(&part_md->queue);
>>> end
Thanks for helping tracking this down,
A
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi Andrei,
Am Dienstag 14 Juni 2011 schrieb Andrei Warkentin:
> I recently came back from vacation (which is why I didn't pitch in
> before). Has there been any further update on this? I want to exclude
> my EMMC partitioning changes as the possible culprit here.
nope, no updates yet. The flood also only starts when udev wants to
create its device nodes, meaning the initial detection seems not to
produce this problem
But when I disable the whole boot partition stuff, it works as before
without irq storms.
As there don't seem to exist reports from other emmc users about this
I guess the problem lays somewhere between the boot-partitions-patch
and the sdhci-s3c driver (for s3c2416 at least).
As my knowledge about the whole mmc-subsystem is quite spare I also
don't really know where to start looking for the culprit yet.
Heiko
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 71da564..32290c5 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1136,7 +1136,7 @@ static int mmc_blk_alloc_parts(struct mmc_card *card,
struct mmc_blk_data *md)
if (!mmc_card_mmc(card))
return 0;
-
+/*
if (card->ext_csd.boot_size) {
ret = mmc_blk_alloc_part(card, md,
EXT_CSD_PART_CONFIG_ACC_BOOT0,
card->ext_csd.boot_size >> 9,
@@ -1151,7 +1151,7 @@ static int mmc_blk_alloc_parts(struct mmc_card *card,
struct mmc_blk_data *md)
if (ret)
return ret;
}
-
+*/
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi Everybody, On Fri, Jun 3, 2011 at 2:56 AM, Heiko Stübner wrote: > > Hi, > > Am Freitag 03 Juni 2011, 01:48:05 schrieb Kyungmin Park: > > As I don't have the s3c2416 user manaul, I'm not sure it's support > > AUTO CMD12 or not. but at least it's support at s3c6410 and later. > According to the manual, the 2416 supports AUTO CMD12. > > As I wrote disabling auto cmd12 only works sometimes and other times the irq > storm happens like with auto cmd12 enabled - always after the first reboot. > So it seems auto cmd12 is not the real reason for the error. > > Do you also encounter the second error later on (for me in udev stage): > > mmcblk1boot0: retrying using single block read > > mmc1: ADMA error > > mmcblk1boot0: error -5 transferring data, sector 448, nr 32, card status > > 0x900 > > end_request: I/O error, dev mmcblk1boot0, sector 448 > > Buffer I/O error on device mmcblk1boot0, logical block 56 > > mmcblk1boot1: retrying using single block read > > mmc1: ADMA error > > mmcblk1boot1: error -5 transferring data, sector 448, nr 32, card status > > 0x900 > > end_request: I/O error, dev mmcblk1boot1, sector 448 > > I recently came back from vacation (which is why I didn't pitch in before). Has there been any further update on this? I want to exclude my EMMC partitioning changes as the possible culprit here. A -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi, Am Freitag 03 Juni 2011, 01:48:05 schrieb Kyungmin Park: > As I don't have the s3c2416 user manaul, I'm not sure it's support > AUTO CMD12 or not. but at least it's support at s3c6410 and later. According to the manual, the 2416 supports AUTO CMD12. As I wrote disabling auto cmd12 only works sometimes and other times the irq storm happens like with auto cmd12 enabled - always after the first reboot. So it seems auto cmd12 is not the real reason for the error. Do you also encounter the second error later on (for me in udev stage): > mmcblk1boot0: retrying using single block read > mmc1: ADMA error > mmcblk1boot0: error -5 transferring data, sector 448, nr 32, card status > 0x900 > end_request: I/O error, dev mmcblk1boot0, sector 448 > Buffer I/O error on device mmcblk1boot0, logical block 56 > mmcblk1boot1: retrying using single block read > mmc1: ADMA error > mmcblk1boot1: error -5 transferring data, sector 448, nr 32, card status > 0x900 > end_request: I/O error, dev mmcblk1boot1, sector 448 Thanks Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
On 6/3/2011 5:18 AM, Kyungmin Park wrote: Hi, Interesting, I also use the latest kernel and boot well. As I don't have the s3c2416 user manaul, I'm not sure it's support AUTO CMD12 or not. but at least it's support at s3c6410 and later. [1.355000] sdhci: Secure Digital Host Controller Interface driver [1.36] sdhci: Copyright(c) Pierre Ossman [1.365000] s3c-sdhci s3c-sdhci.0: clock source 2: sclk_mmc (5000 Hz) [1.375000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA [1.38] s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (5000 Hz) [1.385000] mmc1: no vmmc regulator found [1.39] mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.2] using ADMA [1.40] s3c-sdhci s3c-sdhci.3: clock source 2: sclk_mmc (5000 Hz) [1.405000] mmc2: no vmmc regulator found [1.41] mmc2: SDHCI controller on samsung-hsmmc [s3c-sdhci.3] using ADMA ... [1.435000] Waiting for root device /dev/mmcblk0p3... [1.65] mmc0: new high speed MMC card at address 0001 [1.655000] mmcblk0: mmc0:0001 SEM08G 7.39 GiB [1.66] mmcblk0boot0: mmc0:0001 SEM08G partition 1 1.00 MiB [1.665000] mmcblk0boot1: mmc0:0001 SEM08G partition 2 1.00 MiB [1.675000] mmcblk0: p1 p2 p3 p4< p5 p6> [1.68] mmcblk0boot1: unknown partition table [1.685000] mmcblk0boot0: unknown partition table I also check the external SD card. There seems to some regression in MMC statck. I too observed lot of interrupts from MMC and I2C with V3.0-rc1 on OMAP. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi, Interesting, I also use the latest kernel and boot well. As I don't have the s3c2416 user manaul, I'm not sure it's support AUTO CMD12 or not. but at least it's support at s3c6410 and later. [1.355000] sdhci: Secure Digital Host Controller Interface driver [1.36] sdhci: Copyright(c) Pierre Ossman [1.365000] s3c-sdhci s3c-sdhci.0: clock source 2: sclk_mmc (5000 Hz) [1.375000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA [1.38] s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (5000 Hz) [1.385000] mmc1: no vmmc regulator found [1.39] mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.2] using ADMA [1.40] s3c-sdhci s3c-sdhci.3: clock source 2: sclk_mmc (5000 Hz) [1.405000] mmc2: no vmmc regulator found [1.41] mmc2: SDHCI controller on samsung-hsmmc [s3c-sdhci.3] using ADMA ... [1.435000] Waiting for root device /dev/mmcblk0p3... [1.65] mmc0: new high speed MMC card at address 0001 [1.655000] mmcblk0: mmc0:0001 SEM08G 7.39 GiB [1.66] mmcblk0boot0: mmc0:0001 SEM08G partition 1 1.00 MiB [1.665000] mmcblk0boot1: mmc0:0001 SEM08G partition 2 1.00 MiB [1.675000] mmcblk0: p1 p2 p3 p4 < p5 p6 > [1.68] mmcblk0boot1: unknown partition table [1.685000] mmcblk0boot0: unknown partition table I also check the external SD card. Thank you, Kyungmin Park On Fri, Jun 3, 2011 at 4:49 AM, Heiko Stübner wrote: > Hi, > > after upgrading my development kernel from 2.6.38 to 3.0rc1 I get flooded > (i.e. > it never stops) by messages of the form: > > mmc1: Got data interrupt 0x0010 even though no data operation was in > progress. > sdhci: === REGISTER DUMP (mmc1)=== > sdhci: Sys addr: 0x37b1b000 | Version: 0x0401 > sdhci: Blk size: 0x7200 | Blk cnt: 0x > sdhci: Argument: 0x0001 | Trn mode: 0x0033 > sdhci: Present: 0x01e70002 | Host ctl: 0x0012 > sdhci: Power: 0x000a | Blk gap: 0x > sdhci: Wake-up: 0x | Clock: 0x020f > sdhci: Timeout: 0x000e | Int stat: 0x00108000 > sdhci: Int enab: 0x02ff000b | Sig enab: 0x02ff000b > sdhci: AC12 err: 0x | Slot int: 0x0001 > sdhci: Caps: 0x05e80080 | Caps_1: 0x > sdhci: Cmd: 0x0d1a | Max curr: 0x > sdhci: Host ctl2: 0x > sdhci: ADMA Err: 0x | ADMA Ptr: 0x37846808 > sdhci: === > > > hardware: S3C2416 based board, mmc0 is an external micro-SD and mmc1 is a > mmc1: new high speed MMC card at address 0001 > mmcblk1: mmc1:0001 HYNIX 1.88 GiB > mmcblk1boot0: mmc1:0001 HYNIX partition 1 256 KiB > mmcblk1boot1: mmc1:0001 HYNIX partition 2 256 KiB > mmcblk1: p1 p2 p3 > mmcblk1boot1: unknown partition table > mmcblk1boot0: unknown partition table > > it uses therefore the sdhci-s3c driver. > > > I did some prodding in the code and found the following peculiarities: > > - When I remove Kyungmins AUTO_CMD12-quirk in sdhci-s3c it seems I get one > functional boot and have only the following messages in the kernel log > > mmcblk1boot0: retrying using single block read > mmc1: ADMA error > mmcblk1boot0: error -5 transferring data, sector 448, nr 32, card status > 0x900 > end_request: I/O error, dev mmcblk1boot0, sector 448 > Buffer I/O error on device mmcblk1boot0, logical block 56 > mmcblk1boot1: retrying using single block read > mmc1: ADMA error > mmcblk1boot1: error -5 transferring data, sector 448, nr 32, card status > 0x900 > end_request: I/O error, dev mmcblk1boot1, sector 448 > > But after a soft reset the irq message flood seems to return. > > - When I completely remove the boot partition registration in > mmc_blk_alloc_parts() in card/block.c it seems that everything return to > normal, i.e. no strange messages at all > > > I'm not sure if this is a problem of only my board or if it happens on more > hardware. > > > Heiko > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi, after upgrading my development kernel from 2.6.38 to 3.0rc1 I get flooded (i.e. it never stops) by messages of the form: mmc1: Got data interrupt 0x0010 even though no data operation was in progress. sdhci: === REGISTER DUMP (mmc1)=== sdhci: Sys addr: 0x37b1b000 | Version: 0x0401 sdhci: Blk size: 0x7200 | Blk cnt: 0x sdhci: Argument: 0x0001 | Trn mode: 0x0033 sdhci: Present: 0x01e70002 | Host ctl: 0x0012 sdhci: Power:0x000a | Blk gap: 0x sdhci: Wake-up: 0x | Clock:0x020f sdhci: Timeout: 0x000e | Int stat: 0x00108000 sdhci: Int enab: 0x02ff000b | Sig enab: 0x02ff000b sdhci: AC12 err: 0x | Slot int: 0x0001 sdhci: Caps: 0x05e80080 | Caps_1: 0x sdhci: Cmd: 0x0d1a | Max curr: 0x sdhci: Host ctl2: 0x sdhci: ADMA Err: 0x | ADMA Ptr: 0x37846808 sdhci: === hardware: S3C2416 based board, mmc0 is an external micro-SD and mmc1 is a mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 HYNIX 1.88 GiB mmcblk1boot0: mmc1:0001 HYNIX partition 1 256 KiB mmcblk1boot1: mmc1:0001 HYNIX partition 2 256 KiB mmcblk1: p1 p2 p3 mmcblk1boot1: unknown partition table mmcblk1boot0: unknown partition table it uses therefore the sdhci-s3c driver. I did some prodding in the code and found the following peculiarities: - When I remove Kyungmins AUTO_CMD12-quirk in sdhci-s3c it seems I get one functional boot and have only the following messages in the kernel log mmcblk1boot0: retrying using single block read mmc1: ADMA error mmcblk1boot0: error -5 transferring data, sector 448, nr 32, card status 0x900 end_request: I/O error, dev mmcblk1boot0, sector 448 Buffer I/O error on device mmcblk1boot0, logical block 56 mmcblk1boot1: retrying using single block read mmc1: ADMA error mmcblk1boot1: error -5 transferring data, sector 448, nr 32, card status 0x900 end_request: I/O error, dev mmcblk1boot1, sector 448 But after a soft reset the irq message flood seems to return. - When I completely remove the boot partition registration in mmc_blk_alloc_parts() in card/block.c it seems that everything return to normal, i.e. no strange messages at all I'm not sure if this is a problem of only my board or if it happens on more hardware. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
