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

Zartmy · Feb 25, 2012

Cameltoe said:
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

Size shouldnt matter, they all use usb-masstorage driver. Could you post the output from lsusb ? Se if we are using the same vendor on USB memory.

stuattravs · Feb 25, 2012

Just to add, the same thing has been happening to me on blackhole 1.7.2, not a massive issue just needs pulled out and put back in and re-mounted.
could be a official driver issue?

Zartmy · Feb 25, 2012

stuattravs said:
Just to add, the same thing has been happening to me on blackhole 1.7.2, not a massive issue just needs pulled out and put back in and re-mounted.
could be a official driver issue?

What's your output from lsusb ?

judge · Feb 25, 2012

funny, this happened to me on my solo a couple of times, never happened on my duo.
I swapped both sticks around (so the solo stick is now in the duo & vice versa) & It's never happened since.
Both run latest VIX with all online updates.

SOLO

Code:

root@vusolo:~# 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 002: ID 0951:1642 Kingston Technology
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

DUO

Code:

root@vuduo:~# 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:7080 Hauppauge
Bus 001 Device 002: ID 0781:5566 SanDisk Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

However, had my 2nd 10 second recording issue tonight, only 10 seconds of a show set to record actually recorded (not to above USBs, to internal HD), seen this issue posted on some other threads so will look there.

all a bit random really.

Zartmy · Feb 25, 2012

judge said:
Code:

root@vuduo:~# 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:7080 Hauppauge Bus 001 Device 002: ID 0781:5566 SanDisk Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

However, had my 2nd 10 second recording issue tonight, only 10 seconds of a show set to record actually recorded (not to above USBs, to internal HD), seen this issue posted on some other threads so will look there.

all a bit random really.

I see we share two things here, we both have a Hauppauge DVB-T stick and Sandisk USB memory. But your Duo works flawless with latest VIX 2.3 image?

My DUO lsusb

Code:

root@vuduo:/media/hdd# 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

judge · Feb 25, 2012

Zartmy said:
I see we share two things here, we both have a Hauppauge DVB-T stick and Sandisk USB memory. But your Duo works flawless with latest VIX 2.3 image?

I wouldn't say flawless, the odd random reboot when zapping fast through Irish channels on the USB tuner, but other than that is usually rock solid.
Recording on the USB now & watching sat, never an issue with that.

Sicilian · Feb 26, 2012

stuattravs said:
Just to add, the same thing has been happening to me on blackhole 1.7.2, not a massive issue just needs pulled out and put back in and re-mounted.
could be a official driver issue?

Thanks for reporting this, at least we know it not just an issue on VIX, but got to say never had a single issue with USB sticks un-mounting themselves. I always initialise them in the receiver.

Anyone losing USB mounts could you post the file system being used.

Midnight · Feb 26, 2012

Sicilian said:
Anyone losing USB mounts could you post the file system being used.

ET5000
Device /dev/sda1
Mount /media/usb
type ext4 r/w

Sicilian · Feb 26, 2012

Midnight said:
ET5000
Device /dev/sda1
Mount /media/usb
type ext4 r/w

Would you mind formating again (you will loose data) Menu > Setup > System > Harddisk > Initialise. Once done, check in mount manager and reboot. Then report back.

Larry-G · Feb 26, 2012

I had this happen to me on the Uno and the Duo both using 4GB cruzor blade sticks.

At the time they were formatted as FAT32 via a laptop then mounted to their respective receivers. I have since ditched these sticks and gone back to using my older 16GB duracel capless sticks again formatted as FAT32 via a Laptop and there working without issues.

Although saying that i am still using one of those Cruzor blade sticks on my Ultimo formatted as EXT4 via the receiver and so far it is fine ( been about 3 weeks now ).

Sicilian · Feb 26, 2012

I've been using Cruzier blades 2GB, 4GB & 16Gb all fine, always been EXT4.

Larry-G · Feb 26, 2012

yeah i did at the time put my issues down to a dodgy batch of sticks as they were all from the same triple pack, as i said i went back to my older duracell sticks without any issues. not had any problems since with any of them.

Zartmy · Feb 26, 2012

Sicilian said:
Anyone losing USB mounts could you post the file system being used.

Vu+ DUO
Device /dev/sdb1
Mount /media/usb
type ext4 (same problem with vfat)

Sicilian · Feb 26, 2012

Zartmy said:
Vu+ DUO
Device /dev/sdb1
Mount /media/usb
type ext4 (same problem with vfat)

Would you mind formatting again (you will loose data) Menu > Setup > System > Harddisk > Initialise. Once done, check in mount manager and reboot. Then report back.

Zartmy · Feb 26, 2012

Ok i cracked it down to the real problem. I attached a computer to the serial console and noticed that just before my USB drive stopped working the following occured

Code:

It's now  Sun Feb 26 21:36:26 2012
next real activation is Tue Feb 28 20:59:40 2012
[timer.py] next activation:  Sun Feb 26 21:38:06 2012  (in 99997 ms)
It's now  Sun Feb 26 21:36:26 2012
[timer.py] next activation:  Sun Feb 26 21:38:06 2012  (in 99995 ms)
[ePopen] command: ('sdparm', 'sdparm', '--flexible', '--readonly', '--command=stop', '/dev/sdb')
child has terminated
pipes closed
poll: unhandled POLLERR/HUP/NVAL for fd 60(16)
[EPGC] 94824 bytes for cache used
^[[AIt's now  Sun Feb 26 21:38:06 2012
next real activation is Tue Feb 28 20:59:40 2012
[timer.py] next activation:  Sun Feb 26 21:39:46 2012  (in 99997 ms)
It's now  Sun Feb 26 21:38:06 2012

After that fdisk -l /dev/sdb returns nothing which isnt that strange because something just told the SCSI bus to stop disk /dev/sdb. After this the filesystem gets broken - stopping the disk with a mounted filesystem != clever. Testing that theory we make the same call but with start as command instead, voila fdisk -l /dev/sdb now returns the expected partion layout. It seems the code that calls sdparm with command=stop is in enigma2 Components/Harddisk.py . Reading the code it seems like a try to put the disk to sleep while nothing is using it.

Code:

zartmy@hexapod:~/SRC/enigma2-git/usr/lib/enigma2/python/Components$ git blame -L 450,+10 Harddisk.py
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 450)                        print "hdd IDLE!"
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 451) 
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 452)                print "[IDLE]", idle_time, self.max_idle_time, self.is_sleeping
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 453)                if idle_time >= self.max_idle_time and not self.is_sleeping:
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 454)                        self.setSleep()
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 455) 
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 456)        def setSleep(self):
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 457)                if self.bus() == "External":
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 458)                        Console().ePopen(("sdparm", "sdparm", "--command=stop", self.disk_path))
^bbf4965 (Andreas Monzner 2011-11-10 19:49:27 +0100 459)                else:

My workaround for now is chmod 000 /usr/bin/sdparm - hoping that solves it for now...

Sicilian · Feb 26, 2012

@ Zartmy, do you have and other mounted devices? i.e. internal HDD? Network mount?

Zartmy · Feb 26, 2012

Sicilian said:
@ Zartmy, do you have and other mounted devices? i.e. internal HDD? Network mount?

Yes, i have an internal SATA harddrive mount under /media/hdd - but that ones goes to standby nicely and wakes up when it should. The code uses hdparm to put that one in standby it seems (atleast it is hdparm that gets called in the log).

Sicilian · Feb 27, 2012

Zartmy said:
Yes, i have an internal SATA harddrive mount under /media/hdd - but that ones goes to standby nicely and wakes up when it should. The code uses hdparm to put that one in standby it seems (atleast it is hdparm that gets called in the log).

This device falling asleep, can you confirm, is it a USB HDD or USB stick?

Zartmy · Feb 27, 2012

Sicilian said:
This device falling asleep, can you confirm, is it a USB HDD or USB stick?

The device falling into permanent sleep /dev/sdb1 mounted on /media/usb is a Sandisk U2 Micro 8 GB USB flash stick
Bus 001 Device 002: ID 0781:5406 SanDisk Corp. Cruzer Micro 1/2/4GB Flash Drive

Internal drive on SATA bus is SAMSUNG HD204UI appearing as /dev/sda1, mounted on /media/hdd, that one goes in standby nicely and start on further accesses.

I use /media/usb for epg data and picons
/media/hdd for recordings

Rimmel · Feb 27, 2012

Zartmy said:
Reading the code it seems like a try to put the disk to sleep while nothing is using it.

AHA! so that confirms why the crontab "touch" every 10 minutes works for me.

Nice work
CT

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

Zartmy

Guest

stuattravs

Guest

Zartmy

Guest

ViX Beta Tester

Zartmy

Guest

ViX Beta Tester

The Boss

Forum Supporter

The Boss

V.I.P ,

The Boss

V.I.P ,

Zartmy

Guest

The Boss

Zartmy

Guest

The Boss

Zartmy

Guest

The Boss

Zartmy

Guest

Rimmel

Guest

OpenViX Feeds Status