irq flood with mmc boot partitions on s3c2416 with 3.0rc1

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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 0x00100000 even though no data operation was in 
progress.
  sdhci: =========== REGISTER DUMP (mmc1)===========
  sdhci: Sys addr: 0x37b1b000 | Version:  0x00000401
  sdhci: Blk size: 0x00007200 | Blk cnt:  0x00000000
  sdhci: Argument: 0x00010000 | Trn mode: 0x00000033
  sdhci: Present:  0x01e70002 | Host ctl: 0x00000012
  sdhci: Power:    0x0000000a | Blk gap:  0x00000000
  sdhci: Wake-up:  0x00000000 | Clock:    0x0000020f
  sdhci: Timeout:  0x0000000e | Int stat: 0x00108000
  sdhci: Int enab: 0x02ff000b | Sig enab: 0x02ff000b
  sdhci: AC12 err: 0x00000000 | Slot int: 0x00000001
  sdhci: Caps:     0x05e80080 | Caps_1:   0x00000000
  sdhci: Cmd:      0x00000d1a | Max curr: 0x00000000
  sdhci: Host ctl2: 0x00000000
  sdhci: ADMA Err: 0x00000000 | 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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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 0x00100000 even though no data operation was in 
progress.
  sdhci: =========== REGISTER DUMP (mmc1)===========
  sdhci: Sys addr: 0x37b1b000 | Version:  0x00000401
  sdhci: Blk size: 0x00007200 | Blk cnt:  0x00000000
  sdhci: Argument: 0x00010000 | Trn mode: 0x00000033
  sdhci: Present:  0x01e70002 | Host ctl: 0x00000012
  sdhci: Power:    0x0000000a | Blk gap:  0x00000000
  sdhci: Wake-up:  0x00000000 | Clock:    0x0000020f
  sdhci: Timeout:  0x0000000e | Int stat: 0x00108000
  sdhci: Int enab: 0x02ff000b | Sig enab: 0x02ff000b
  sdhci: AC12 err: 0x00000000 | Slot int: 0x00000001
  sdhci: Caps:     0x05e80080 | Caps_1:   0x00000000
  sdhci: Cmd:      0x00000d1a | Max curr: 0x00000000
  sdhci: Host ctl2: 0x00000000
  sdhci: ADMA Err: 0x00000000 | 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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Kyungmin Park]

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.360000] sdhci: Copyright(c) Pierre Ossman
[    1.365000] s3c-sdhci s3c-sdhci.0: clock source 2: sclk_mmc (50000000 Hz)
[    1.375000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
[    1.380000] s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (50000000 Hz)
[    1.385000] mmc1: no vmmc regulator found
[    1.390000] mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.2] using ADMA
[    1.400000] s3c-sdhci s3c-sdhci.3: clock source 2: sclk_mmc (50000000 Hz)
[    1.405000] mmc2: no vmmc regulator found
[    1.410000] mmc2: SDHCI controller on samsung-hsmmc [s3c-sdhci.3] using ADMA
...
[    1.435000] Waiting for root device /dev/mmcblk0p3...
[    1.650000] mmc0: new high speed MMC card at address 0001
[    1.655000] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
[    1.660000] 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.680000]  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 <heiko@sntech.de> 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 0x00100000 even though no data operation was in
> progress.
>  sdhci: =========== REGISTER DUMP (mmc1)===========
>  sdhci: Sys addr: 0x37b1b000 | Version:  0x00000401
>  sdhci: Blk size: 0x00007200 | Blk cnt:  0x00000000
>  sdhci: Argument: 0x00010000 | Trn mode: 0x00000033
>  sdhci: Present:  0x01e70002 | Host ctl: 0x00000012
>  sdhci: Power:    0x0000000a | Blk gap:  0x00000000
>  sdhci: Wake-up:  0x00000000 | Clock:    0x0000020f
>  sdhci: Timeout:  0x0000000e | Int stat: 0x00108000
>  sdhci: Int enab: 0x02ff000b | Sig enab: 0x02ff000b
>  sdhci: AC12 err: 0x00000000 | Slot int: 0x00000001
>  sdhci: Caps:     0x05e80080 | Caps_1:   0x00000000
>  sdhci: Cmd:      0x00000d1a | Max curr: 0x00000000
>  sdhci: Host ctl2: 0x00000000
>  sdhci: ADMA Err: 0x00000000 | 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-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Kyungmin Park]

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.360000] sdhci: Copyright(c) Pierre Ossman
[    1.365000] s3c-sdhci s3c-sdhci.0: clock source 2: sclk_mmc (50000000 Hz)
[    1.375000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
[    1.380000] s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (50000000 Hz)
[    1.385000] mmc1: no vmmc regulator found
[    1.390000] mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.2] using ADMA
[    1.400000] s3c-sdhci s3c-sdhci.3: clock source 2: sclk_mmc (50000000 Hz)
[    1.405000] mmc2: no vmmc regulator found
[    1.410000] mmc2: SDHCI controller on samsung-hsmmc [s3c-sdhci.3] using ADMA
...
[    1.435000] Waiting for root device /dev/mmcblk0p3...
[    1.650000] mmc0: new high speed MMC card at address 0001
[    1.655000] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
[    1.660000] 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.680000]  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 <heiko@sntech.de> 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 0x00100000 even though no data operation was in
> progress.
> ?sdhci: =========== REGISTER DUMP (mmc1)===========
> ?sdhci: Sys addr: 0x37b1b000 | Version: ?0x00000401
> ?sdhci: Blk size: 0x00007200 | Blk cnt: ?0x00000000
> ?sdhci: Argument: 0x00010000 | Trn mode: 0x00000033
> ?sdhci: Present: ?0x01e70002 | Host ctl: 0x00000012
> ?sdhci: Power: ? ?0x0000000a | Blk gap: ?0x00000000
> ?sdhci: Wake-up: ?0x00000000 | Clock: ? ?0x0000020f
> ?sdhci: Timeout: ?0x0000000e | Int stat: 0x00108000
> ?sdhci: Int enab: 0x02ff000b | Sig enab: 0x02ff000b
> ?sdhci: AC12 err: 0x00000000 | Slot int: 0x00000001
> ?sdhci: Caps: ? ? 0x05e80080 | Caps_1: ? 0x00000000
> ?sdhci: Cmd: ? ? ?0x00000d1a | Max curr: 0x00000000
> ?sdhci: Host ctl2: 0x00000000
> ?sdhci: ADMA Err: 0x00000000 | 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-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Santosh Shilimkar]

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.360000] sdhci: Copyright(c) Pierre Ossman
> [    1.365000] s3c-sdhci s3c-sdhci.0: clock source 2: sclk_mmc (50000000 Hz)
> [    1.375000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
> [    1.380000] s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (50000000 Hz)
> [    1.385000] mmc1: no vmmc regulator found
> [    1.390000] mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.2] using ADMA
> [    1.400000] s3c-sdhci s3c-sdhci.3: clock source 2: sclk_mmc (50000000 Hz)
> [    1.405000] mmc2: no vmmc regulator found
> [    1.410000] mmc2: SDHCI controller on samsung-hsmmc [s3c-sdhci.3] using ADMA
> ...
> [    1.435000] Waiting for root device /dev/mmcblk0p3...
> [    1.650000] mmc0: new high speed MMC card at address 0001
> [    1.655000] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> [    1.660000] 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.680000]  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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Santosh Shilimkar]

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.360000] sdhci: Copyright(c) Pierre Ossman
> [    1.365000] s3c-sdhci s3c-sdhci.0: clock source 2: sclk_mmc (50000000 Hz)
> [    1.375000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
> [    1.380000] s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (50000000 Hz)
> [    1.385000] mmc1: no vmmc regulator found
> [    1.390000] mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.2] using ADMA
> [    1.400000] s3c-sdhci s3c-sdhci.3: clock source 2: sclk_mmc (50000000 Hz)
> [    1.405000] mmc2: no vmmc regulator found
> [    1.410000] mmc2: SDHCI controller on samsung-hsmmc [s3c-sdhci.3] using ADMA
> ...
> [    1.435000] Waiting for root device /dev/mmcblk0p3...
> [    1.650000] mmc0: new high speed MMC card at address 0001
> [    1.655000] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> [    1.660000] 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.680000]  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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Andrei Warkentin]

Hi Everybody,

On Fri, Jun 3, 2011 at 2:56 AM, Heiko Stübner <heiko@sntech.de> 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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Andrei Warkentin]

Hi Everybody,

On Fri, Jun 3, 2011 at 2:56 AM, Heiko St?bner <heiko@sntech.de> 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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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;
 }

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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;
 }

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Andrei Warkentin]

Hi Heiko,

On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner <heiko@sntech.de> 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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Andrei Warkentin]

Hi Heiko,

On Tue, Jun 14, 2011 at 9:10 AM, Heiko St?bner <heiko@sntech.de> 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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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 <heiko@sntech.de> 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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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 <heiko@sntech.de> 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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Andrei Warkentin]

Hi,

On Thu, Jun 16, 2011 at 3:14 PM, Heiko Stübner <heiko@sntech.de> 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 <heiko@sntech.de> 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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Andrei Warkentin]

Hi,

On Thu, Jun 16, 2011 at 3:14 PM, Heiko St?bner <heiko@sntech.de> 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 <heiko@sntech.de> 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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

[-- Attachment #1: Type: Text/Plain, Size: 2797 bytes --]

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 <heiko@sntech.de> 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 <heiko@sntech.de> 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 00010000 flags 00000195
sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000001
mmc1: req done (CMD13): 0: 00000e00 00000000 00000000 00000000
[...]
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

[-- Attachment #2: dmesg_20110618.txt --]
[-- Type: text/plain, Size: 8380 bytes --]

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  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc8800000 - 0xf6000000   ( 728 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  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 00000200
irq: clearing subpending status 00000402
irq: clearing subpending status 00000002
timer tcon=00500000, tcnt d902, tcfg 00000200,00000000, usec 0000170a
Console: colour dummy device 80x30
console [ttySAC0] enabled
Calibrating delay loop... 199.47 BogoMIPS (lpj=498688)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
devtmpfs: initialized
print_constraints: dummy: 
NET: Registered protocol family 16
s3c2416_spi_set_info: Invalid SPI configuration
S3C Power Management, Copyright 2004 Simtec Electronics
S3C2416: Initializing architecture
S3C2416: IRQ Support
S3C24XX DMA Driver, Copyright 2003-2006 Simtec Electronics
DMA channel 0 at c8804000, irq 88
DMA channel 1 at c8804100, irq 89
DMA channel 2 at c8804200, irq 90
DMA channel 3 at c8804300, irq 91
DMA channel 4 at c8804400, irq 92
DMA channel 5 at c8804500, irq 93
s3c-adc s3c24xx-adc: attached adc driver
bio: create slab <bio-0> at 0
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 1784K
msgmni has been set to 247
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
s3c2440-uart.0: ttySAC0 at MMIO 0x50000000 (irq = 70) is a S3C2440
s3c2440-uart.1: ttySAC1 at MMIO 0x50004000 (irq = 73) is a S3C2440
s3c2440-uart.2: ttySAC2 at MMIO 0x50008000 (irq = 76) is a S3C2440
brd: module loaded
gpio-vbus gpio-vbus: can't get vbus_draw regulator, err: -19
mousedev: PS/2 mouse device common for all mice
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
s3c-sdhci s3c-sdhci.0: clock source 0: hsmmc (133333333 Hz)
s3c-sdhci s3c-sdhci.0: clock source 1: hsmmc (133333333 Hz)
s3c-sdhci s3c-sdhci.0: clock source 2: hsmmc-if (96000000 Hz)
mmc0: no vmmc regulator found
Registered led device: mmc0::
mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
s3c-sdhci s3c-sdhci.1: clock source 0: hsmmc (133333333 Hz)
s3c-sdhci s3c-sdhci.1: clock source 1: hsmmc (133333333 Hz)
s3c-sdhci s3c-sdhci.1: clock source 2: hsmmc-if (96000000 Hz)
mmc1: no vmmc regulator found
Registered led device: mmc1::
mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.1] using ADMA
TCP cubic registered
NET: Registered protocol family 17
VFP support v0.3: not present
Kernel not built with RTC support, ALARM timers will not wake from suspend
Freeing init memory: 120K
mmc0: new SDHC card at address 9c57
mmcblk0: mmc0:9c57 SU04G 3.69 GiB 
 mmcblk0: p1 p2
mmc1: found EXT_CSD revision 3
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
udevd (32): /proc/32/oom_adj is deprecated, please use /proc/32/oom_score_adj instead.
EXT3-fs: barriers not enabled
kjournald starting.  Commit interval 5 seconds
EXT3-fs (mmcblk0p2): using internal journal
EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
udev: starting version 154
s3c-i2c s3c2410-i2c: slave address 0x10
s3c-i2c s3c2410-i2c: bus frequency set to 378 KHz
s3c-i2c s3c2410-i2c: i2c-0: S3C I2C adapter
Registered led device: led4
Registered led device: led5
Registered led device: led6
Registered led device: led7
s3c64xx-spi s3c64xx-spi.0: Board init must call s3c64xx_spi_set_info()
s3c64xx-spi: probe of s3c64xx-spi.0 failed with error -22
input: auo_pixcir_ts as /devices/platform/s3c2410-i2c/i2c-0/0-005c/input/input0
auo_pixcir_ts: Firmware Version is 0x14
snd-soc-dummy snd-soc-dummy: platform register snd-soc-dummy
Registered platform 'snd-soc-dummy'
samsung-audio samsung-audio: platform register samsung-audio
Registered platform 'samsung-audio'
samsung-i2s samsung-i2s: dai register samsung-i2s
Registered DAI 'samsung-i2s'
alc562x-codec 0-0018: Found codec id : alc5620
alc562x-codec 0-0018: codec register 0-0018
alc562x-codec 0-0018: dai register 0-0018 #1
Registered DAI 'alc5624-hifi'
Registered codec 'alc562x-codec.0-0018'
EXT3-fs (mmcblk0p2): using internal journal
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC 1e:96:62:b4:93:dd
usb0: HOST MAC a2:91:d0:61:f0:a5
g_ether gadget: adding config #2 'RNDIS'/bf0b9378
g_ether gadget: adding 'rndis'/c79fbd80 to config 'RNDIS'/bf0b9378
rndis_register: configNr = 0
rndis_set_param_medium: 0 0
g_ether gadget: RNDIS: dual speed IN/ep1in OUT/ep2out NOTIFY/ep3in
g_ether gadget: cfg 2/bf0b9378 speeds: high full
g_ether gadget:   interface 0 = rndis/c79fbd80
g_ether gadget:   interface 1 = rndis/c79fbd80
g_ether gadget: adding config #1 'CDC Ethernet (ECM)'/bf0b9308
g_ether gadget: adding 'cdc_ethernet'/c79fbb40 to config 'CDC Ethernet (ECM)'/bf0b9308
g_ether gadget: CDC Ethernet: dual speed IN/ep1in OUT/ep2out NOTIFY/ep3in
g_ether gadget: cfg 1/bf0b9308 speeds: high full
g_ether gadget:   interface 0 = cdc_ethernet/c79fbb40
g_ether gadget:   interface 1 = cdc_ethernet/c79fbb40
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
g_ether gadget: suspend
s3c-hsudc s3c-hsudc: bound driver g_ether
g_ether gadget: suspend
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
g_ether gadget: high speed config #1: CDC Ethernet (ECM)
g_ether gadget: init ecm
g_ether gadget: notify connect false
g_ether gadget: notify speed 425984000
g_ether gadget: activate ecm
usb0: qlen 10
g_ether gadget: ecm_close
usb0: eth_open
usb0: eth_start
g_ether gadget: ecm_open
NET: Registered protocol family 10
usb0: no IPv6 routers present

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

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 <heiko@sntech.de> 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 <heiko@sntech.de> 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 00010000 flags 00000195
sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000001
mmc1: req done (CMD13): 0: 00000e00 00000000 00000000 00000000
[...]
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
-------------- next part --------------
Linux version 3.0.0-rc1+ (hstuebner at 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  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc8800000 - 0xf6000000   ( 728 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  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 00000200
irq: clearing subpending status 00000402
irq: clearing subpending status 00000002
timer tcon=00500000, tcnt d902, tcfg 00000200,00000000, usec 0000170a
Console: colour dummy device 80x30
console [ttySAC0] enabled
Calibrating delay loop... 199.47 BogoMIPS (lpj=498688)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
devtmpfs: initialized
print_constraints: dummy: 
NET: Registered protocol family 16
s3c2416_spi_set_info: Invalid SPI configuration
S3C Power Management, Copyright 2004 Simtec Electronics
S3C2416: Initializing architecture
S3C2416: IRQ Support
S3C24XX DMA Driver, Copyright 2003-2006 Simtec Electronics
DMA channel 0 at c8804000, irq 88
DMA channel 1 at c8804100, irq 89
DMA channel 2 at c8804200, irq 90
DMA channel 3 at c8804300, irq 91
DMA channel 4 at c8804400, irq 92
DMA channel 5 at c8804500, irq 93
s3c-adc s3c24xx-adc: attached adc driver
bio: create slab <bio-0> at 0
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 1784K
msgmni has been set to 247
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
s3c2440-uart.0: ttySAC0 at MMIO 0x50000000 (irq = 70) is a S3C2440
s3c2440-uart.1: ttySAC1 at MMIO 0x50004000 (irq = 73) is a S3C2440
s3c2440-uart.2: ttySAC2 at MMIO 0x50008000 (irq = 76) is a S3C2440
brd: module loaded
gpio-vbus gpio-vbus: can't get vbus_draw regulator, err: -19
mousedev: PS/2 mouse device common for all mice
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
s3c-sdhci s3c-sdhci.0: clock source 0: hsmmc (133333333 Hz)
s3c-sdhci s3c-sdhci.0: clock source 1: hsmmc (133333333 Hz)
s3c-sdhci s3c-sdhci.0: clock source 2: hsmmc-if (96000000 Hz)
mmc0: no vmmc regulator found
Registered led device: mmc0::
mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
s3c-sdhci s3c-sdhci.1: clock source 0: hsmmc (133333333 Hz)
s3c-sdhci s3c-sdhci.1: clock source 1: hsmmc (133333333 Hz)
s3c-sdhci s3c-sdhci.1: clock source 2: hsmmc-if (96000000 Hz)
mmc1: no vmmc regulator found
Registered led device: mmc1::
mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.1] using ADMA
TCP cubic registered
NET: Registered protocol family 17
VFP support v0.3: not present
Kernel not built with RTC support, ALARM timers will not wake from suspend
Freeing init memory: 120K
mmc0: new SDHC card at address 9c57
mmcblk0: mmc0:9c57 SU04G 3.69 GiB 
 mmcblk0: p1 p2
mmc1: found EXT_CSD revision 3
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
udevd (32): /proc/32/oom_adj is deprecated, please use /proc/32/oom_score_adj instead.
EXT3-fs: barriers not enabled
kjournald starting.  Commit interval 5 seconds
EXT3-fs (mmcblk0p2): using internal journal
EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
udev: starting version 154
s3c-i2c s3c2410-i2c: slave address 0x10
s3c-i2c s3c2410-i2c: bus frequency set to 378 KHz
s3c-i2c s3c2410-i2c: i2c-0: S3C I2C adapter
Registered led device: led4
Registered led device: led5
Registered led device: led6
Registered led device: led7
s3c64xx-spi s3c64xx-spi.0: Board init must call s3c64xx_spi_set_info()
s3c64xx-spi: probe of s3c64xx-spi.0 failed with error -22
input: auo_pixcir_ts as /devices/platform/s3c2410-i2c/i2c-0/0-005c/input/input0
auo_pixcir_ts: Firmware Version is 0x14
snd-soc-dummy snd-soc-dummy: platform register snd-soc-dummy
Registered platform 'snd-soc-dummy'
samsung-audio samsung-audio: platform register samsung-audio
Registered platform 'samsung-audio'
samsung-i2s samsung-i2s: dai register samsung-i2s
Registered DAI 'samsung-i2s'
alc562x-codec 0-0018: Found codec id : alc5620
alc562x-codec 0-0018: codec register 0-0018
alc562x-codec 0-0018: dai register 0-0018 #1
Registered DAI 'alc5624-hifi'
Registered codec 'alc562x-codec.0-0018'
EXT3-fs (mmcblk0p2): using internal journal
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC 1e:96:62:b4:93:dd
usb0: HOST MAC a2:91:d0:61:f0:a5
g_ether gadget: adding config #2 'RNDIS'/bf0b9378
g_ether gadget: adding 'rndis'/c79fbd80 to config 'RNDIS'/bf0b9378
rndis_register: configNr = 0
rndis_set_param_medium: 0 0
g_ether gadget: RNDIS: dual speed IN/ep1in OUT/ep2out NOTIFY/ep3in
g_ether gadget: cfg 2/bf0b9378 speeds: high full
g_ether gadget:   interface 0 = rndis/c79fbd80
g_ether gadget:   interface 1 = rndis/c79fbd80
g_ether gadget: adding config #1 'CDC Ethernet (ECM)'/bf0b9308
g_ether gadget: adding 'cdc_ethernet'/c79fbb40 to config 'CDC Ethernet (ECM)'/bf0b9308
g_ether gadget: CDC Ethernet: dual speed IN/ep1in OUT/ep2out NOTIFY/ep3in
g_ether gadget: cfg 1/bf0b9308 speeds: high full
g_ether gadget:   interface 0 = cdc_ethernet/c79fbb40
g_ether gadget:   interface 1 = cdc_ethernet/c79fbb40
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
g_ether gadget: suspend
s3c-hsudc s3c-hsudc: bound driver g_ether
g_ether gadget: suspend
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
g_ether gadget: high speed config #1: CDC Ethernet (ECM)
g_ether gadget: init ecm
g_ether gadget: notify connect false
g_ether gadget: notify speed 425984000
g_ether gadget: activate ecm
usb0: qlen 10
g_ether gadget: ecm_close
usb0: eth_open
usb0: eth_start
g_ether gadget: ecm_open
NET: Registered protocol family 10
usb0: no IPv6 routers present

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Daniel Mack]

On Thu, Jun 2, 2011 at 9:49 PM, Heiko Stübner <heiko@sntech.de> 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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Daniel Mack]

On Thu, Jun 2, 2011 at 9:49 PM, Heiko St?bner <heiko@sntech.de> 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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

Am Samstag 18 Juni 2011, 22:56:11 schrieb Daniel Mack:
> On Thu, Jun 2, 2011 at 9:49 PM, Heiko Stübner <heiko@sntech.de> 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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

Am Samstag 18 Juni 2011, 22:56:11 schrieb Daniel Mack:
> On Thu, Jun 2, 2011 at 9:49 PM, Heiko St?bner <heiko@sntech.de> 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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Andrei Warkentin]

Heiko,

On Sun, Jun 19, 2011 at 9:23 AM, Heiko Stübner <heiko@sntech.de> 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

irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Andrei Warkentin]

Heiko,

On Sun, Jun 19, 2011 at 9:23 AM, Heiko St?bner <heiko@sntech.de> 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

Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1

[Heiko Stübner]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

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 <heiko@sntech.de> 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

[-- Attachment #2: dmesg-debug_20110629.txt.gz --]
[-- Type: application/x-gzip, Size: 11750 bytes --]