Error Tx1 ISO

Autonomous Machines Jetson & Embedded Systems Jetson TX1
122

Was this log from the Jetson? I see this:

[518894.323285] scsi 19:0:0:0: CD-ROM HUAHEI Mass Storage 2.31 PD: 0 ANSI: 2
[518894.323285] scsi 19:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2
[518894.441314] sr 19:0:0:0: scsi-1 drive
[518894.441708] sr 19:0:0:0: Attached scsi CD-ROM so
[518894.447997] scsi 20:0:0:0: Direct-Access HUAHEI TF CARD Storage 2.31 PQ: 0 ANSI: 2
[518894.451681] sd 20:0:0:0: [sda] Attached ScsI removable disk
[518894.441814] sr 19:0:0:0: Isro] scsi-1 drive
[518894.4417087] sr 19:0:0:0: Attached scoi CD-ROM SPO
[518894.447997] scsi 20:0:0:0: Direct-Access HUAWEI TF CARD Storage 2.81 PR: O ANSI: 2
[518894.451631] sd 20:0:0:0: [sda] Attached scsI removable disk

The above indicates the Huawei is emulating a CDROM (an ISO9660 filesystem, /dev/sr), plus “/dev/sda” (a regular hard drive emulation). If this is from the Huawei device on the Jetson, can you record the Jetson’s (or PC if on the PC, but we have to stick to just one device and not mix PC and Jetson info) output of “lsblk -f” prior to plugging in the Huawei, then again after the Huawei is plugged in, and look for what differs between the two plugins? Then show me which part of “lsblk -f” is new and from the Huawei device?

123

Yes, this information was taken from TX1, I am sending you the output of the lsblk -f command below, also taken from TX1
log.log (586 Bytes)

124

Which part of the “lsblk -f” was added once the Huawei device was added? For example, all of “mmcblk0” is part of the Jetson itself and not related to the Huawei device. Also, it sounds like “mmcblk1” (the “/data” device) is not part of the Huawei device. Because mmcblk1 is not from your device (at least as far as I can guess from the conversation) it is hard to tell what is actually from the Huawei device.

Incidentally, if you can answer the same exact question on the host PC where it works, whereby you show only what is added to “lsblk -f” when the Huawei device is added, then it could say what we expect to see on the Jetson, and we’d know more details about why or where it failed on the Jetson. It is key though to know what changes upon plugin of the Huawei device. One expected addition is that of an ISO9660 device, but I can’t see this from the listed “lsblk -f” on the Jetson.

125

pc_log_huawei.log (2.3 KB)
Pc log with huawei /\

lsblk.log (707 Bytes)
TX1 log with huawei /\

the /data directory is the microssd

126

You have “/data” on both PC and Jetson. Is this something you can guarantee is from another device (you said it is, but I have to know for certain or it will be a lot of work…and I see it on both PC and Jetson)?

sr0 is listed with partition label “VIVO INTERNET”. Is it correct that this is from the Huawei device? If so, then on the Jetson we can conclude that there is sufficient USB failure on the Jetson (not necessarily failed hardware, but it is possible) that the block device is not even visible.

127

I think there’s a confusion, on the pc I can’t find any /data directory, because of that, I say that on TX1 the /data directory is the microssd

Yes sr0 would be HUAWEI

128

On the last log you posted as “lblk.log” it sounds like the PC log. I see this:

mmcblk1
└─mmcblk1p1  ext4                  be336b8e-08f8-4b1d-9aed-eaa5e6f669ef /data

Is the previous “lsblk -f” log not from the PC? If it is from the Jetson, then I do see USB has succeeded in finding an ISO9660 device.

129

lblk is the TX1 log

pc_log_huawei is the PC log

130

Ok, so I can verify “/data” is unrelated to this, and that an ISO9660 system is involved. This would be the “VIVO INTERNET” label device. This device does show up on the Jetson, but earlier attempts to read the device metadata failed. On both the Jetson and the PC, can you post the output of this? I’m including adding a log named after the platform (pick the log name based on whether you run the command on the PC versus the Jetson):

sudo gdisk -l /dev/sr0 2>&1 | tee log_jetson_sr0.txt
sudo gdisk -l /dev/sr1 2>&1 | tee log_pc_sr1.txt
131

log_pc_sr1.txt (658 Bytes)
log_jetson_sr0.txt (563 Bytes)

132

Could you check it?

133

Is the gdisk command for the PC to “sr1”, or “sr0”? I see success on the Jetson, and this is the GUID:
EDF0FC8E-06A2-440C-9B80-D7895DAEB9F6

This same GUID would show up under “lsblk -f”, but I don’t see this (or any

On the PC I see this different GUID:
05890E47-6AE7-4C75-8117-D639BD810065

This could be from swapping between the two devices, the actual CD/DVD ROM, and the Huawei device’s “synthetic” CD/DVD (this is what ISO9660 is for). It might also be about UID of the device as a whole versus the Partition UID (PUID instead of GUID). Either way though, it shows success for both USB and metadata read on the Jetson (this is good, the function validates).

What I wanted to do, which requires using the correct PC device (with UID EDF0FC8E-06A2-440C-9B80-D7895DAEB9F6 (the UID from the Jetson’s ISO9660 partition), is to see if we can copy the PC content to the Jetson and manually trigger it. If we get the wrong device, then it won’t help.

However, since the device is reading on the Jetson, let’s see if we can skip this (though I think we tried once before). On the Jetson, what do you see from:
sudo mount /dev/sr0 /mnt

Following this, on the Jetson, run “lsblk -f” again, and show what appears after the mount command takes place. If this actually mounts, then we can skip the PC copy.

134

the command lsblk -f was performed before plugging the USB-Modem, after plugging in, the command sudo mount /dev/sr0 /mnt was given and then lsblk -f. You can see in the log file… this is referring to Jetson.
tx1.log (1.5 KB)

135

I guess “/dev/sr0” is unrelated to the Huawei device, and the Huawei device is the one in question. Similar for “/dev/mmcblk1”, the source of “/data”. You’ve said the “/data” is another disk/microssd, can I verify that the “VIVO INTERNET” device is also unrelated? Both devices show up both before and after the Huawei plugin.

Anything mmcblk0 is the built-in eMMC, and so this can also be ignored. This means that 100% of all items showing up in “lsblk -f” are unrelated to the Huawei device, and that the requirement for the ISO9660 driver either (A) is for the “VIVO INTERNET” device, or else (B) the ISO9660 device of the Huawei has failed.

If we go back in the past and look at the original missing ISO9660 function/driver popping up, can I verify that this was occurring upon plugin of the Huawei device and not occurring either (A) by itself, or (B) with some other device?

This is looking more like USB failure, and I think it was said that it did not matter if the device were plugged in to either a direct port on the Jetson USB or via a HUB. Can you verify this as well? If we can verify all of these then I’m thinking there is a USB error on the Jetson side (it would help though to add one more list of only the part of “dmesg --follow” that occurs upon plugin of the Huawei device).

136

looking at the log file sent earlier, you can see that /data already exists even before plugging in the USB-Modem. So I believe there is no relationship.
Before plugging:
before_plugging.log (683 Bytes)

After plugging:
before_plugging.log (683 Bytes)

here you can see the outputs of the dmesg --follow command
dmesg.log (2.5 KB)

137

This is not in a particular order, I’m just writing notes as I go through the log.

It is odd because the device itself shows up, and so USB is able to query this:
[779801.399710] usb 1-4.3: New USB device found, idVendor=12d1, idProduct=14fe

The USB registry shows idVendor sa Huawei, and idProduct as 14fe Modem (Mass Storage Mode). There is no doubt that a mass storage device should show up, and this matches the earlier search for the ISO9660 driver, which is now present. I don’t know what the VIVO INTERNET device is, but it shows up as an ISO9660 device, although not mounted (it isn’t until mount that we’d know the ISO9660 driver works or fails).

Further logs do show “[779801.492358] usb-storage 1-4.3:1.0: USB Mass Storage device detected”, and names this as an ISO9660 device from the Huawei, becoming “/dev/sr1” (“sr0” is something else, the VIVO INTERNET):

[779802.520590] scsi 35:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[779802.585623] scsi 36:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[779802.641543] sr 35:0:0:0: [sr1] scsi-1 drive
[779802.654614] sr 35:0:0:0: Attached scsi CD-ROM sr1

This also shows a SCSI device created by the Huawei plugin:

[779802.669342] sd 36:0:0:0: [sda] Attached SCSI removable disk
[779802.741866] usb-storage 1-4.3:1.0: USB Mass Storage device detected

Note that this device is different, and would produce “/dev/sda”. The “lsblk -f” fails to show either “/dev/sr1” or “/dev/sda”. Both devices fail to show up from “lsblk -f”. This tends to say the error is not exactly USB, but might still be related to USB. Right after sda is detected it is also disconnected, and claims the device is “offline”, meaning unpowered:
[779802.781265] scsi 36:0:0:0: rejecting I/O to offline device

Power issues can be from the carrier board, or they can be from the Huawei device itself. I don’t recall from before (and it is a long thread), but have you tried this with an externally powered USB HUB?

One interesting part of this is that if USB did not truly function, then it would not be possible to query those devices, and certainly it wouldn’t be possible to ask a device if it is offline or not. If the device is offline, then it could be because of (A) a data error, or (B) a power error, or (C) the device itself failing (we can eliminate this latter failure because it works on the PC). I think we’d see different errors if this were the former (case “A”) data error. Odds are in favor of a power issue, although not guaranteed.

Later in the log a GSM modem is successfully created, which is the main part of this device. This produces both “/dev/USB0” and “/dev/USB1” (can you verify that “ls /dev/USB0 /dev/USB1” shows these files exist?).

My “almost” conclusion is that the modem exists and could work, but it needs something from either the ISO9660 “/dev/sr1” and/or the SCSI device “/dev/sda”. If this really is just a power issue, then it might “just start working” when “/dev/sr1” and “/dev/sda” successfully power up. If the power issue cannot be fixed with an external USB supply it becomes quite difficult to say if it is a quirk of the USB or something else.

138

I’m suspecting that the problem may be in my hub-usb… because when I remove and put only the usb, the messages from dmesg --follow are different… is there any way to check if it is working? Because if I disconnect the internet cable, I can’t access via ssh, without access via ssh and using only the TX1 input for the Modem-USB, I can’t connect a keyboard to type

result of dmesg using only TX1 input instead of usb hub:

[782832.541478] usb 1-4: new high-speed USB device number 43 using xhci-tegra
[782832.669283] usb 1-4: New USB device found, idVendor=12d1, idProduct=14fe
[782832.669302] usb 1-4: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[782832.669315] usb 1-4: Product: HUAWEI Mobile
[782832.669326] usb 1-4: Manufacturer: HUAWEI Technology
[782832.711727] usb-storage 1-4:1.0: USB Mass Storage device detected
[782832.711991] scsi host47: usb-storage 1-4:1.0
[782832.712329] usb-storage 1-4:1.1: USB Mass Storage device detected
[782832.716578] scsi host48: usb-storage 1-4:1.1
[782833.718292] scsi 48:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[782833.828949] scsi 47:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[782833.944386] sd 48:0:0:0: [sda] Attached SCSI removable disk
[782833.947552] sr 47:0:0:0: [sr1] scsi-1 drive
[782833.947935] sr 47:0:0:0: Attached scsi CD-ROM sr1
[782986.616301] r8152 2-1:1.0 eth0: carrier on
139

Yes, that is an improved “shorter” log. I am curious if direct connection to USB produces a different “lsblk -f” (only the differences matter)?

So far as networking goes it is likely that the NetworkManager software is thinking that when one network device is present it should use that, but then switches when another is present (one being a default). However, with the device not providing networking it implies switching just causes network failure. Once the device can be made to work it is possible to configure such that both devices work, but one has priority, and thus if not enabled networking would switch to the other device. Probably have to have it working before you can change that.

I recommend you purchase a USB3 HUB which has “external power”. This provides more power to external devices, and removes power drain from the Jetson itself (Jetsons are designed for efficiency in power, and that in itself can be a weakness when something outside tries to use its power).

140

log.log (650 Bytes)
I noticed that now instead of being sr0 it became sr1

I’m connecting via ssh, and leaving only the TX1 input for the usb device. My question is how can we test this, without having to remove the network cable, because removing the cable, I lose SSH access, being necessary to act with a keyboard, which would make me use the Hub-USB that was maybe causing power problems for HUAWEI

141

Some devices are automatically enumerated with same base name, followed by an increment of a number for each one they find. The “/dev/sr*” are read-only ISO9660 devices; the first one found is “/dev/sr0”; if a second is found, or it the first is removed and added quickly, then the next device is “/dev/sr1”, and so on. A CD/DVD ROM would usually be “/dev/sr0”, and your device would enumerate later and become “/dev/sr1”. If there is a disconnect/reconnect during boot, then it is conceivable your device is still the only ISO9660 device, and yet gets enumerated as “/dev/sr1” (while “/dev/sr0” would only give an error if accessed).

You would test by purchasing a new HUB which is “externally” powered and has its own power. This does two things:

  • External power specifies even more power is available.
  • External power removes power draw from the Jetson.