[VU+ Duo] usb stick missing from list of storage devices

[Midnight]

For some reason my box is not creating debug logs.

Oh, well hope they get to the bottom of this.

 

[Rob van der Does]

For some reason my box is not creating debug logs.

If you are on ViX 2.3-204 debug logs can be found in hdd/logs (or usb/logs or whatever your device is), or in home/root/logs if no device is attached.
I presume you activated debug logs? After doing so, a GUI-restart is needed.
You should also be able to see the logs when in LogManager, and send them from there.

 

[judge]

My Solo is also loosing it's USB mount after a few hours.
My DUO doesn't, both running latest VIX with all updates applied.
I'll swap the sticks in both & see if it still happens on the solo.

 

[Rimmel]

Using the vix media player seems to put the usb stick to sleep as well.

 

[Rimmel]

More data:

I added an hourly cron job in the vix menu "touch /media/usb/keepalive.log" and now the mount does NOT disapear overnight (standby), however the contents of the usb stick still vanishes until reboot.

I was hoping to set the cron for 15 minutes to see if that makes a difference; but the vix cron menu doesnt seem to support it, I'll have a look at adding one manually using the terminal later.

thanks
CT

 

[andyblac]

More data:

I added an hourly cron job in the vix menu "touch /media/usb/keepalive.log" and now the mount does NOT disapear overnight (standby), however the contents of the usb stick still vanishes until reboot.

I was hoping to set the cron for 15 minutes to see if that makes a difference; but the vix cron menu doesnt seem to support it, I'll have a look at adding one manually using the terminal later.

thanks
CT

vix cron just edit the cron job file thats all. if your usb keeps losing connect that is the issue cron won't help

 

[Rimmel]

vix cron just edit the cron job file thats all. if your usb keeps losing connect that is the issue cron won't help

But the cron is set to change the file access time of a file resident on the usb stick at hourly intervals (touch command). My theory was that using the cron to issue this command may keep the usb alive. So yes the cron doesn't affect the usb subsystem, but the commands used in cron can. The regular touch command is obviously having so effect on the usb mounts as now it doesn't actually disapear.

thanks
CT

 

[skater]

I was waiting to see if this issue was more widespread, but it seems a small amount of users are experiencing this fault.
My USB stick is also still dissapearing from mounts, so no access to picons and EPG. Seems to be a new kernel issue, as the mount was always accessable from the old VIX 2.3 and all previous versions
The machine is not rebooting, so no crash logs and it looses the mount after going into standby. A restart restores the mount, but I do not want to continually reboot the box.
I have tried reflashing VIX 2.3 153 fault still occurred so then VIX 2.3 204, no CAMS only rootpwd changer and emXX DVB driver loaded, all settings manually restored. Still loosing mounts. Reflashed bootloader and then VIX 2.3 204, still issues.
Do you require debug logs?, as I would just need to restart every morning, after the unit has been in stanby overnight, and the mounts lost.
I understand it is very fustrating to have to fix a fault you cannot replicate, but I am willing to help where possible.
My hardware is from the second batch, supplied by AL**T in Kilburn.

 

[Rimmel]

More data:
I manually set a cron job (crontab) to touch the keepalive.log file every 15 minutes on the usb and the stick didn't disapear overnight (in standby)!!! The picons on the usb stick are still working.

Interesting
CT

 

[Rimmel]

More data:
I manually set a cron job (crontab) to touch the keepalive.log file every 15 minutes on the usb and the stick didn't disapear overnight (in standby)!!! The picons on the usb stick are still working.

Interesting
CT

This seems to be working on 2 boxes (ET9000's). USB doesn't lose mount and picons working in the morning.

regards
CT
I will post info if someone else wants to try it.

 

[Rimmel]

Update - 2 days now and both the mounts are still there!!!

So it seems using crontab to touch a file on the usb stick IS keeping it alive.

regards
CT

 

[Zartmy]

Having the same problem,
mount

rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,sync,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime,size=64k,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/sda1 on /media/hdd type ext4 (rw,relatime,barrier=1,data=ordered)
/dev/sdb1 on /media/usb type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
tmpfs on /var/volatile type tmpfs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
root@vuduo:/lib/modules#

dmesg - kernel messages

FAT-fs (sdb1): Directory bread(block 3882) failed
FAT-fs (sdb1): Directory bread(block 3883) failed
FAT-fs (sdb1): Directory bread(block 3884) failed
FAT-fs (sdb1): Directory bread(block 3885) failed
FAT-fs (sdb1): Directory bread(block 3886) failed
FAT-fs (sdb1): Directory bread(block 3887) failed
FAT-fs (sdb1): Directory bread(block 3888) failed
FAT-fs (sdb1): Directory bread(block 3889) failed

fdisk -l /dev/sdb

root@vuduo:/lib/modules# fdisk -l /dev/sdb
root@vuduo:/lib/modules#

So kernel cant read from usb device anymore, though it still see the device on the bus
lsusb

Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 2040:5200 Hauppauge
Bus 001 Device 002: ID 0781:5406 SanDisk Corp. Cruzer Micro 1/2/4GB Flash Drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Tried to unbind the device from the usb-storage and reattaching it again no success

root@vuduo:/sys/bus# find /sys/bus/usb/drivers/usb-storage/
/sys/bus/usb/drivers/usb-storage/
/sys/bus/usb/drivers/usb-storage/module
/sys/bus/usb/drivers/usb-storage/uevent
/sys/bus/usb/drivers/usb-storage/unbind
/sys/bus/usb/drivers/usb-storage/bind
/sys/bus/usb/drivers/usb-storage/new_id
/sys/bus/usb/drivers/usb-storage/remove_id
/sys/bus/usb/drivers/usb-storage/1-1:1.0
root@vuduo:/sys/bus# echo -n "1-1:1.0" > /sys/bus/usb/drivers/usb-storage/unbind
root@vuduo:/sys/bus# dmesg | tail
scsi: killing requests for dead queue
root@vuduo:/sys/bus# echo -n "1-1:1.0" > /sys/bus/usb/drivers/usb-storage/bind
root@vuduo:/sys/bus# dmesg | tail
scsi3 : usb-storage 1-1:1.0
scsi 3:0:0:0: Direct-Access SanDisk Cruzer 7.01 PQ: 0 ANSI: 0 CCS
sd 3:0:0:0: Attached scsi generic sg1 type 0
scsi: killing requests for dead queue
sd 3:0:0:0: [sdb] Attached SCSI removable disk
root@vuduo:/sys/bus# fdisk -l /dev/sdb
root@vuduo:/sys/bus#

Must be a kernel bug ?!?

 

[Sicilian]

I use ext3 or 4 on all my USB sticks and had zero issues.

 

[Zartmy]

I use ext3 or 4 on all my USB sticks and had zero issues.

Do you "manually" mount them in /etc/fstab ?

 

[Sicilian]

No, initialize connected to receiver, then set in mount manager.

 

[Rob van der Does]

On the PLi forum there are some identical reports. Only a very few users are effected by this problem, and it is impossible to reproduce this by people who's boxes are not affected.
PLi is investigating this.

 

[Zartmy]

On the PLi forum there are some identical reports. Only a very few users are effected by this problem, and it is impossible to reproduce this by people who's boxes are not affected.
PLi is investigating this.

I have reformated my USB stick to ext4 and have been running a variant of Cameltoe cronjob to see if it survives longer.

Kernel screams the following after a while

[AUD]: setting mute : 0
sd 2:0:0:0: [sdb] 15695871 512-byte logical blocks: (8.03 GB/7.48 GiB)
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through
usb 1-1: reset high speed USB device number 2 using ehci-brcm
sd 2:0:0:0: [sdb] 15695871 512-byte logical blocks: (8.03 GB/7.48 GiB)
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] Device not ready
sd 2:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
sd 2:0:0:0: [sdb] Sense Key : 0x2 [current]
sd 2:0:0:0: [sdb] ASC=0x3a ASCQ=0x0
sd 2:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 00 00 19 00 00 00 08 00
end_request: I/O error, dev sdb, sector 6400
sd 2:0:0:0: [sdb] Device not ready
sd 2:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
sd 2:0:0:0: [sdb] Sense Key : 0x2 [current]
sd 2:0:0:0: [sdb] ASC=0x3a ASCQ=0x0
sd 2:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 00 00 19 08 00 00 08 00
end_request: I/O error, dev sdb, sector 6408
sd 2:0:0:0: [sdb] Device not ready
sd 2:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
sd 2:0:0:0: [sdb] Sense Key : 0x2 [current]
sd 2:0:0:0: [sdb] ASC=0x3a ASCQ=0x0
sd 2:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 00 00 19 10 00 00 60 00
end_request: I/O error, dev sdb, sector 6416
sd 2:0:0:0: [sdb] Device not ready
sd 2:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
sd 2:0:0:0: [sdb] Sense Key : 0x2 [current]
sd 2:0:0:0: [sdb] ASC=0x3a ASCQ=0x0
sd 2:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 00 00 19 18 00 00 58 00
end_request: I/O error, dev sdb, sector 6424
usb 1-1: reset high speed USB device number 2 using ehci-brcm
EXT4-fs error (device sdb1): __ext4_get_inode_loc:3305: inode #730: block 557: comm touch: unable to read itable block
EXT4-fs error (device sdb1) in ext4_reserve_inode_write:4123: IO failure
sd 2:0:0:0: [sdb] 15695871 512-byte logical blocks: (8.03 GB/7.48 GiB)
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through

Hoping the openpli folks fixes this.

 

[Rimmel]

My two et9000's have been running fine since I added the cronjob (set it now at every 10 minutes). 3 days now. I have one on fat32 and one on ext4. Once thing to note is that they are both 4gb sticks. I am wondering if the size can affect anything (different drivers?)

thanks
CT

 

[Rimmel]

On the PLi forum there are some identical reports. Only a very few users are effected by this problem, and it is impossible to reproduce this by people who's boxes are not affected.
PLi is investigating this.

Have you got a link to the pli forum please?

 

[Rob van der Does]

Have you got a link to the pli forum please?

http://openpli.org/forums/topic/22449-grove-bug-met-usb-nog-steeds-aanwezig/