Raspberry Pi 3 SD Card errors

English Install/Boot/Login
1

Hi there,
I’m using Tumbleweed JeOS on a Raspberry Pi 3.
After the last [zypper dup] and reboot, I got these errors since boot process:


nov 27 14:27:42 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:42 archive kernel: mmcblk0: error -22 transferring data, sector 3368922, nr 966, cmd response 0x900, card status 0x0
nov 27 14:27:42 archive kernel: mmcblk0: retrying using single block read
nov 27 14:27:42 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:42 archive kernel: mmcblk0: error -22 transferring data, sector 3370912, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:42 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:43 archive kernel: mmcblk0: error -22 transferring data, sector 3370912, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:43 archive kernel: mmcblk0: retrying using single block read
nov 27 14:27:43 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:43 archive kernel: mmcblk0: error -22 transferring data, sector 3371936, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:43 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:43 archive kernel: mmcblk0: error -22 transferring data, sector 3371936, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:43 archive kernel: mmcblk0: retrying using single block read
nov 27 14:27:43 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:43 archive kernel: mmcblk0: error -22 transferring data, sector 3372960, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:43 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:43 archive kernel: mmcblk0: error -22 transferring data, sector 3372960, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:43 archive kernel: mmcblk0: retrying using single block read
nov 27 14:27:44 archive kernel: swiotlb_tbl_map_single: 8 callbacks suppressed
nov 27 14:27:44 archive kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 442356 bytes)
nov 27 14:27:44 archive kernel: swiotlb_full: 8 callbacks suppressed
nov 27 14:27:44 archive kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 442356 bytes
nov 27 14:27:44 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:44 archive kernel: mmcblk0: error -22 transferring data, sector 3373984, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:44 archive kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 442356 bytes)
nov 27 14:27:44 archive kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 442356 bytes
nov 27 14:27:44 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:44 archive kernel: mmcblk0: error -22 transferring data, sector 3373984, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:44 archive kernel: mmcblk0: retrying using single block read
nov 27 14:27:44 archive kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 458752 bytes)
nov 27 14:27:44 archive kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 458752 bytes
nov 27 14:27:44 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:44 archive kernel: mmcblk0: error -22 transferring data, sector 3375008, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:45 archive kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 458752 bytes)
nov 27 14:27:45 archive kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 458752 bytes
nov 27 14:27:45 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:45 archive kernel: mmcblk0: error -22 transferring data, sector 3375008, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:45 archive kernel: mmcblk0: retrying using single block read
nov 27 14:27:45 archive kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 417780 bytes)
nov 27 14:27:45 archive kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 417780 bytes
nov 27 14:27:45 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:45 archive kernel: mmcblk0: error -22 transferring data, sector 3376032, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:45 archive kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 417780 bytes)
nov 27 14:27:45 archive kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 417780 bytes
nov 27 14:27:45 archive kernel: mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
nov 27 14:27:45 archive kernel: mmcblk0: error -22 transferring data, sector 3376032, nr 1024, cmd response 0x900, card status 0x0
nov 27 14:27:45 archive kernel: mmcblk0: retrying using single block read

I already tried to dd again the standard image (openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.06.10-Build2.7.raw.xz) on the SD Card and [zypper dup], but errors came up again.
Before the upgrade, no errors are written in the logs or console.
Is there anyone that is facing this issue? How can I solve?

Many thanks in advance,
Best regards

2

Maybe try downloading and writing the latest image?

When was the last time you did a dup? It looks like your original image is quite some time ago. I sometimes find even on big Desktops that if the system hasn’t been upgraded for many, many months I get unresolvable upgrade errors… eg 8 months since last upgrade in my experience. TW seems to upgrade more smoothly when done often.

This might be a good time to recommend that if you have a configuration you want to preserve, you may want to commit its setup to an install script so that your setup can be re-built quickly on a different/new install.

TSU

3

Hi
The OP is using the latest image… 2017.6.10.
http://download.opensuse.org/ports/aarch64/tumbleweed/images/

4

Hi and welcome to the Forum :slight_smile:
I’m using a USB device these days for Tumbleweed, do you have any non-standard repos active?

Else I would try a zypper up if only the standard openSUSE-Ports-Tumbleweed-repo-oss a few less packages and not removing any;


zypper up

393 packages to upgrade, 164 new, 1 to change arch.
Overall download size: 370.3 MiB. Already cached: 0 B. After the operation,
additional 552.7 MiB will be used.

zypper dup

394 packages to upgrade, 172 new, 21 to remove, 1 to change arch.
Overall download size: 372.8 MiB. Already cached: 0 B. After the operation,
additional 531.6 MiB will be used.

If that works, then try a zypper dup.

I’m just dupping one of my test RPI’s now to see where it goes.

5

Hi
After a dup from the base image, all is good on my RPI3;

http://thumbs2.imagebam.com/12/36/5d/6bd735670275313.jpg](http://www.imagebam.com/image/6bd735670275313)

6

Hi
I also see a thread on the arm ML;
https://lists.opensuse.org/opensuse-arm/2017-11/msg00012.html

I tried the osc get binaries (image is too small)… but looks like a build is still going on;
https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS

Then there is;
http://download.opensuse.org/ports/aarch64/tumbleweed/images/?C=M;O=D

7

Hi all,
I tried more or less everything you wrote, included zypper up & dup from an older image.
To have the confirm, I overwrote the SD with the last image available (openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.11.22-Build1.13.raw.xz): it fails to boot just after the kernel is loaded (at least, I think the step should be that…), via Serial pinout I didn’t see anything, only via HDMI:http://www.imagebam.com/image/c5e53c670507123

To be sure, I putted the older image (openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.06.10-Build2.7.raw.xz) on the same SD, to use the same hw and everything seems to be fully working, until I execute the [zypper dup] & [reboot].
These the boot processes details:

Boot process from the newer image:


U-Boot 2017.11 (Nov 16 2017 - 12:27:27 +0000)

DRAM:  896 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e300000: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 5 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
22840 bytes read in 171 ms (129.9 KiB/s)
Found EFI removable media binary efi/boot/bootaa64.efi
Scanning disk sdhci@7e300000.blk...
Found 1 disks
reading efi/boot/bootaa64.efi
731648 bytes read in 62 ms (11.3 MiB/s)
## Starting EFI application at 01000000 ...
Welcome to GRUB!

error: terminal `gfxterm' isn't found.
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

##Attached photo messages came here, but only via HDMI, nothing on console##

Boot process from the older image:


U-Boot 2017.05 (May 08 2017 - 15:27:50 +0000)

DRAM:  880 MiB
RPI 3 Model B (0xa02082)
MMC:   bcm2835_sdhci: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In:    serial
Out:   lcd
Err:   lcd
Net:   Net Initialization Skipped
No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 5 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
20731 bytes read in 189 ms (106.4 KiB/s)
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
731136 bytes read in 61 ms (11.4 MiB/s)
## Starting EFI application at 01000000 ...
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 5 disks
Welcome to GRUB!

error: terminal `gfxterm' isn't found.
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: ERROR: Could not determine UEFI Secure Boot status.
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
setterm: cannot (un)set powersave mode: Inappropriate ioctl for device
Sat Jun 17 00:00:00 UTC 2017
[1497657598.956222] Searching for boot device...
[1497657601.053000] startMultipathd: multipathd not found
[1497657601.063238] Found boot device: /dev/mmcblk0
[1497657603.019543] Partition the disk according to real geometry  parted ]
[1497657604.487184] Partition the disk according to real geometry  parted ]
[1497657609.045957] Creating swap space on /dev/mmcblk0p3
[1497657609.866122] Activating swap space on /dev/mmcblk0p3
[1497657609.899578] Filesystem of OEM system is: ext4 -> /dev/mmcblk0p2
[1497657609.977422] Checking ext4 filesystem on /dev/mmcblk0p2...
ROOT: Superblock last mount time is in the future.
        (by less than a day, probably due to the hardware clock being incorrectly set)
ROOT: Superblock last write time is in the future.
        (by less than a day, probably due to the hardware clock being incorrectly set)
ROOT: 29157/90432 files (0.1% non-contiguous), 318092/361712 blocks
[1497657613.413154] Resizing  filesystem on /dev/mmcblk0p2...
Resizing the filesystem on /dev/mmcblk0p2 to 775635 (4k) blocks.
The filesystem on /dev/mmcblk0p2 is now 775635 (4k) blocks long.

/dev/mmcblk0p2: LABEL="ROOT" UUID="e1c89131-e6c3-4ad6-85fa-5fb4fab04c0e" TYPE="ext4" PARTUUID="a7d16a20-02"
[1497657635.922062] Creating boot loader configuration
[1497657638.573483] Activating Image: [/dev/mmcblk0p2]
[1497657639.240976] Preparing preinit phase...

[1497657641.242431] Booting System: 
    0.161333] Calling pre-init stage in system image
   50.116879] Creating dracut based initrd
  367.822418] No bootloader installation required
skiped writing MBR ID for aarch64
GPT fdisk (gdisk) version 1.0.1

Caution! After loading partitions, the CRC doesn't check out!
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 
Command (? for help): 
Recovery/transformation command (? for help): 
MBR command (? for help): Partition to change type code: Enter an MBR hex code: 
MBR command (? for help): 
Converted 4 partitions. Finalize and exit? (Y/N): Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.

Welcome to openSUSE Tumbleweed!

  OK  ] Listening on LVM2 metadata daemon socket.
  OK  ] Listening on udev Control Socket.
...
## System fully working in a couple of minutes##

With the same HW (rasp, SD, power supply) the newer image fails where the older boots without any issue: for the older image, the problem arise only after the upgrade.
Could it be a kernel trouble?
I also noticed that the older image didn’t find the [uboot.env], maybe something is wrong here since is present in the latest image?
Please let me know your suggests

Thanks again,
Best regards

8

Hi
I have no issues with the older image and the dup… however I noticed the serial connection fails now (as in no console access after the system is up)… so only ssh or hdmi access :frowning:

That new JEOS image is broken… the file size should be ~600MB not ~260MB

9

Hi Malcom,
are you sure about that? The “old” ISO, the working one dated 2017-06-10 that I was using until 2 weeks ago, is ~250 MB: more or less as the latest available on the repo. The images at ~600MB usually include also the GUI environment (LXQT, XFCE, etc. etc.).
Anyway these days I’m doing some experiments with the upgrade, but with no success…
I’ll keep you updated once I get some results.

10

On Wed 29 Nov 2017 10:06:01 PM CST, Silver Hawk wrote:

malcolmlewis;2846405 Wrote:
>
> That new JEOS image is broken… the file size should be ~600MB not
> ~260MB

Hi Malcom,
are you sure about that? The “old” ISO, the working one dated 2017-06-10
that I was using until 2 weeks ago, is ~250 MB: more or less as the
latest available on the repo. The images at ~600MB usually include also
the GUI environment (LXQT, XFCE, etc. etc.).
Anyway these days I’m doing some experiments with the upgrade, but with
no success…
I’ll keep you updated once I get some results.

Hi
I’ve created a bug report;
https://bugzilla.opensuse.org/show_bug.cgi?id=1070470

All the images I tried failed with this error…

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.92-18.36-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

11

Hi,
Following TSU’s input, I’ve created another bug for the mmc and bmc2835-dma errors: https://bugzilla.opensuse.org/show_bug.cgi?id=1070872

I’ll update/close this thread once the bug will be updated.

Thanks again