With gparted, I have unmounted both partitions and then resized these.
Now it mounts fine from USB adapter, but still nothing alive when using SD Card slot…
I would think gdisk could modify any partition of the device which is not currently mounted. Not sure what gparted does with respect to mounted partitions. I think it is also possible to force a gdisk write and cause corruption on a mounted partition, but are you saying the unmounted device special file can only be accessed when mounted? If so, then this would probably indicate an automount program is using sudo to change effective ownership while you are logged in (the ownership would fail for a different user or after logout of the GUI if it is the GUI doing the automount).
FYI, auto_64-bit_support won’t harm anything. “metadata_csum” or “64bit” will cause the boot loader (and perhaps kernel?) to not be able to read the partition (and the boot loader must read the partition if it is the root partition, though non-rootfs mounts probably shouldn’t care).
I don’t know what the “Problem opening /dev/sda for reading! Error is 123” error is, but I could see this being plausible that permission changes from automount could refuse even root to mount. On an SElinux system I might even suspect SElinux, but SElinux is not enabled in the Jetson file system, nor in the kernel (at least the last time I looked it wasn’t present…it is highly unlikely this could be transferred in an ordinary flash image since the kernel itself would also have to be altered).
Another option is that the card is actually failing, though I have no idea what the error 123 is. There are some indications I found which might imply there simply isn’t any accessible medium (“ENOMEDIUM”). One information source I saw says this means it is a removable device but the device isn’t installed, e.g., an SD card reader with no SD card in it. If something locked the device file then removing the SD card might leave the device special file still there with no medium. I know it sounds silly, but do be sure the card is completely seated and that the spring loaded toggle between seated/unseated is toggled to seated.
Finally, what does a pure gdisk listing show (versus an open)? Use “sudo gdisk -l /dev/sda”.
I have deleted partitions and recreated only one with gdisk and formatted with gparted as ext4.
I get now a normal behavior with USB adapter:
sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sda: 15523840 sectors, 7.4 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 184EA91A-7F34-4760-9D4E-5B1E3AXXXXXX
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15523806
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 15523806 7.4 GiB 8300 Linux filesystem
but still dead when using SD card slot.
I never tried the SD card slot on R27.0.1, but it does work on R28.1. It’s an interesting problem, but I am at a loss without physically looking at the signal on the SD card with an oscilloscope to see if perhaps there is an electrical issue. Thus I keep mentioning to make sure it is truly seated…this is about the last test which is simple. Is this something you can clone and then flash to R28.1 for testing, or is there a need to stay at R27.0.1?
Well, booting with or without the SD card doesn’t make a difference, apart from tap delay changing from 19 (SD plugged) to 61 (SD unplugged):
dmesg |grep mmc
[ 0.000000] Kernel command line: fbcon=map:0 net.ifnames=0 console=tty0 OS=l4t console=ttyS0,115200n8 memtype=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x03100000 gpt tegraid=18.1.2.0.0 tegra_keep_boot_clocks maxcpus=6 android.kerneltype=normal androidboot.serialno=0335115020673 vpr_resize root=/dev/mmcblk0p1 rw rootwait
[ 1.149500] GPIO line 445 (sdmmc-wake-input) hogged as input
[ 1.155445] GPIO line 446 (sdmmc-wake-output) hogged as output/low
[ 1.505471] vddio-sdmmc1: 1800 <--> 3300 mV at 3300 mV
[ 1.703697] tegra186-pmc-iopower pmc-iopower: Rail iopower-sdmmc4 is having fixed voltage 1800000
[ 1.703761] tegra186-pmc-iopower pmc-iopower: Rail iopower-sdmmc1-hv is having voltages: 1800000:3300000
[ 1.704185] tegra186-pmc-iopower pmc-iopower: Rail iopower-sdmmc2-hv is having fixed voltage 3300000
[ 1.704275] tegra186-pmc-iopower pmc-iopower: Rail iopower-sdmmc3-hv is having voltages: 1800000:3300000
[ 3.644464] mmc0: SDHCI controller on 3460000.sdhci [3460000.sdhci] using ADMA 64-bit with 64 bit addr
[ 3.680469] mmc1: SDHCI controller on 3440000.sdhci [3440000.sdhci] using ADMA 64-bit with 64 bit addr
[ 3.714493] mmc0: MAN_BKOPS_EN bit is not set
[ 3.720560] mmc2: SDHCI controller on 3400000.sdhci [3400000.sdhci] using ADMA 64-bit with 64 bit addr
[ 3.721647] mmc0: Skipping tuning since strobe enabled
[ 3.729026] mmc0: periodic cache flush enabled
[ 3.729032] mmc0: new HS400 MMC card at address 0001
[ 3.729282] mmcblk0: mmc0:0001 032G34 29.1 GiB
[ 3.729392] mmcblk0rpmb: mmc0:0001 032G34 partition 3 4.00 MiB
[ 3.730495] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17
[ 3.768827] mmc1: queuing unknown CIS tuple 0x80 (5 bytes)
[ 3.964873] mmc1 tuning done saved <b>tap delay=19</b>
[ 3.964875] mmc1: hw tuning done ...
[ 3.964881] mmc1: tuning_window[0]: 0xffffffff
[ 3.964885] mmc1: tuning_window[1]: 0xfffffcff
[ 3.964888] mmc1: tuning_window[2]: 0xffe3ffff
[ 3.964892] mmc1: tuning_window[3]: 0x1fffffff
[ 3.964895] mmc1: tuning_window[4]: 0x0
[ 3.964899] mmc1: tuning_window[5]: 0x0
[ 3.964921] mmc1: tuning_window[6]: 0x0
[ 3.964925] mmc1: tuning_window[7]: 0x0
[ 3.969130] mmc1: queuing unknown CIS tuple 0x91 (3 bytes)
[ 3.969162] mmc1: new ultra high speed SDR104 SDIO card at address 0001
[ 12.255018] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
I’ll try to look at the connectors in detail, so far it looked normal.
I currently lack a PC for the upgrade to R28, but I plan to update my TX2 with last JetPack maybe next week.
Thanks for your help.
Upgraded to R28.1, SD slot still looks dead :-(
So far as I can see, the connectors looks fine and everything looks actually soldered.
I have tried different microSD cards with different dapters, it works with USB adapter, but SD slot doesn’t see anything with any adapter.
The good thing is that I don’t get the Ethernet poll/interrupt message anymore.
I’ve just got this fault from compiz:
[ 431.629589] compiz[3331]: unhandled level 2 translation fault (11) at 0x7f8d52acd0, esr 0x92000006
[ 431.638590] pgd = ffffffc1c4b52000
[ 431.642019] [7f8d52acd0] *pgd=000000024861f003, *pud=000000024861f003, *pmd=0000000000000000
[ 431.652008] CPU: 0 PID: 3331 Comm: compiz Not tainted 4.4.38-tegra #1
[ 431.658449] Hardware name: quill (DT)
[ 431.662116] task: ffffffc1c86d1900 ti: ffffffc1e1448000 task.ti: ffffffc1e1448000
[ 431.669596] PC is at 0x7f8a9d4604
[ 431.672914] LR is at 0x7f8a9d5328
[ 431.676231] pc : [<0000007f8a9d4604>] lr : [<0000007f8a9d5328>] pstate: 20000000
[ 431.683619] sp : 0000007ff0b34ea0
[ 431.686936] x29: 0000007ff0b34ea0 x28: 000000000296ee40
[ 431.692264] x27: 0000007f8aaa79f8 x26: 0000007f8aaa79a0
[ 431.697594] x25: fffffffffffffffa x24: 0000007f8aaa70d0
[ 431.703014] x23: 0000007f8aaa79a8 x22: 0000000000000030
[ 431.708387] x21: 0000000002a832d0 x20: 0000007f8d52acc8
[ 431.713757] x19: 0000007f8aaa79f8 x18: 0000000000000000
[ 431.719117] x17: 0000007f81cd15c8 x16: 0000007f882a7c50
[ 431.724484] x15: 0000007f8ad86000 x14: 0000000000000000
[ 431.729836] x13: 0000000000467020 x12: 0000000000465b20
[ 431.735214] x11: 0000000000000020 x10: 0101010101010101
[ 431.740577] x9 : 0000000000c31720 x8 : 00000000004309d0
[ 431.745943] x7 : 0000000000000000 x6 : 0000007ff0b34f2c
[ 431.751302] x5 : 0000000000000000 x4 : 0000000000d6fe30
[ 431.756670] x3 : 0000000000000001 x2 : 0000000000000000
[ 431.762031] x1 : 0000000000006091 x0 : 0000000002a832d0
[ 431.768886] Library at 0x7f8a9d4604: 0x7f8a966000 /lib/aarch64-linux-gnu/libc-2.23.so
[ 431.776756] Library at 0x7f8a9d5328: 0x7f8a966000 /lib/aarch64-linux-gnu/libc-2.23.so
[ 431.784617] vdso base = 0x7f8ad85000
I have no oscilloscope with me, only a multimeter.
Any idea how I can figure out what’s going wrong ?
Thanks
Did that particular OOPS appear upon logout? I get the same thing at times logging out of the GUI. When I do remote ssh it doesn’t do it. Compiz is of course GUI stuff, and this one has been reported already. The fortunate thing (assuming this behaves the same for you as for me) is that there is no issue since the OOPS occurs only on logout.
So far as testing the SD slot goes I don’t think there is much you can tell without some sort of breakout board. The pins are not something simple to get to like on a 0.1" header. It might be possible to test for VDD (carrier board shows this if interested). This is listed as pin 4, and common/ground is listed on several pins (2, 3, 6, 11, plus two on shell are connected to common ground for power). An issue though would be that if something doesn’t show up at the socket there isn’t a whole lot you can do about it. First, you don’t know if it is the carrier board or the module failing. Wiring for use over USB external SD card reader is different than for SD card slot…about all you can confirm is that the controller itself is working correctly.
There is also pin 10 listed as detect…this should ground or break from ground depending on whether the card is inserted or not…but I’m not sure which since it isn’t something easy to physically access to test.
I hate to ask, but is this something you can RMA?
Yes, the OOPS happen on logout. I had missed that being reported. How harmless is it if relogging ?
One extra problem with my R28.1 install is that if I log as ubuntu (installed as nvidia) from the GUI, I have no top bar nor launcher bar, and any graphical app has no border, so I guess it’s a dm problem, but I have not investigated that.
I am thinking to plug my TX2 module into my TX1 board that has SD working. Is it compatible for any revision of boards/modules ? I am thinking mostly yes, but I am not sure.
Not sure I can go for RMA… I’ll probably have to live without SD card for this board.
Thanks again for your comments.
I can’t say definitively about the Compiz bug, but I doubt there is any harm even in relogging. Compiz is shutting down anyway and it is intended to stop when the error occurs…it’s just that it is a bit abrupt on stopping. I do not know of any temp files which it might fail to write on exit.
I have not seen the missing launcher bar or other issues when logged in as user nvidia, but I also have run apt update and apt-get upgrade (along with fixing libglx.so). If “sha1sum -c /etc/nv_tegra_release” shows as ok, then it seems like it might be a permissions issue. It is possible dmesg or “/var/log/Xorg.0.log” might show some additional information on login. Issues on the host PC during unpacking of the sample rootfs could conceivably transfer over to the Jetson.
As far as I know all TX1 can be put in a newer TX2 carrier board. And mostly TX2 can be put in TX1 carrier boards. However, I believe some of the earliest TX1 carrier boards may not have implemented all addtional I/O of a more recent carrier board. Certainly no harm would come to a TX1 or TX2 in any of the carrier board versions. My TX1 carrier board was actually from the first shipment NVIDIA had received so it has at least one notable difference…no LED light next to the module for power…I am unsure what other differences may exist between older and newer TX1 carrier boards. It should be ok to find out if the other carrier does the job…odds are in favor that both carrier boards will be interchangeable and completely functional.
Well, I had updated through apt but without breaking the libglx.so link. sha1sum says it’s ok.
Previously, for installation, I have used JetPack3.1 on a PC running Ubuntu 14.04 as specified in host requirements with plenty of disk space on a USB drive, on an ext4 filesystem.
I have to say here that I have taken from the dead an old PC (AGP2 motherboard with 1GB RAM and single core Athlon64), not fast at all (in such case, cross-compiling has no advantage), but it runs fine 14.04 (while 16.04 is too slow).
Basically everything went ok except flashing. I got tegrarcm making timeout (same trace as [url]https://devtalk.nvidia.com/default/topic/900378/tegra-tools/flashing-jetson-tx1-with-tegraflash-py/post/4746346/#4746346[/url]).
Finally I flashed from command line (worked fine on first trial), and performed post-install with JetPack again.
For JetPack installation, when asked I have selected nvidia user. And nvidia user works fine, the problem is only with user ubuntu in the GUI.
That’s for the JetPack/GUI. If nvidia wants to investigate this, I’m ok for some tests, but I understand such old computers are not a topic for future (albeit they sometimes exhibit bugs unseen on fast targets). Mainly for reporting. I guess it’s just slow like a VM.
Back to my SD card, I have swapped TX1 and TX2 modules, and it appears the problem is in my TX2 devboard…TX2 module sees the SD card on TX1 board (the old one like you without red leds), while TX1 module doesn’t on TX2 board.
The thing is that there is absolutely no message at all, so I wonder if there is power. It seems the connector has a mechanical switch…I’ll try to test the power and detect point you mentioned as well.
It’s interesting that a little Jetson probably now outperforms the old Athlon64 (once upon a time this was the star performer in the desktop world and could probably heat an entire room when under load). I’m assuming it is single core, is this correct? I’m not surprised to see a timeout, which in turn is not really a crash so much as an assumption that because something took so long it was suspicious as a possible failure:
INFO: task tegradevflash:5626 blocked for more than 120 seconds.
I wonder if there is some sort of flag which could be set to run single-threaded…this might help in such a circumstance. I know there is a flag for single-threaded downloading, but I’m thinking of program threads other than downloads.
If you run “tail -f /var/log/Xorg.0.log”, or “dmesg --follow” or “tail -f /var/log/auth.log”, do you see anything interesting during the login failure for ubuntu?
I think you are right about the SD card, there is a mechanical switch used to detect if the card is inserted. If that switch does not trigger, then it is doubtful any log would show anything, and no driver or other software would react to the SD card. I’ve never tried to manually trigger that switch, and I don’t even know if the pins are exposed, but you could possibly measure if there is a contact made or broken between pin 10 and the ground shield around the card slot…this is what gets monitored by software to detect SD card present or not.