View Full Version : [VU+ Duo] usb stick missing from list of storage devices
I have my picons on a usb stick in the top usb slot and it has been working well for 3 months but now it works for only a short time and then the usb stick is missing from the list of storage devices and the vix mount manager cannot fin it i have changed the usb stick and it still umounted after sometime of viewing a channel I am using vis 2.3 kernel 3.1.1 and all was ok until i changed to this version can i put the picons somewhere else until there is a fix for the usb slot
edogg
Hi there,
I think I might have something similar happening here.. I have my EPG set to download every morning onto the USB stick at 6:30AM. I use OpenTV and the box is able to download this fine most mornings without booting up the Duo.
However, on some occasions the Duo must not be able to see the USB stick and the box then boots up. On these occasions the epg.dat is created on the HDD. If I then reboot the Duo the USB is then visible again and I can manually download the EPG.
This has only happened 2-3 times since the update to Vix 2.3 (3.1.1) so not that big of deal for me..
yes I also had my epg on the same stick and also backups and it was after the 2.3 update I tried to create a backup and it reported that there was not enough space even after deleting all the other backups and then the picons failed to appear and that is when i checked the mount manager and file browser and neither could see the usb stick
the usb stick was disconnected again today causing the vu+duo to freeze and need rebooting the usb stick was then in mount list but after 2 hours it disconnected again this never happened with any other vix version only since 2.3 190 kernel 3.1.1 has the usb port been having faults like this disconnection
I am having the same problem. I have an exFAT formatted 2GB USB drive that I store picon & epg data on. It has always worked perfectly, but after upgrading to kernel 3.1.1, (full flash and manual reconfiguration, so no settings to clash etc), I keep loosing my usb mount after going into standby. A full reset restores the mount, but after standby, it fails again. The mount appears in Mount manager, but if I look to setup the mount, only the HDD is available, and then the USB mount is lost and won't appear till a reset is performed.
The usb drive is mounted in the rear top slot, with a DVB-T2 tuner plugged in below.
Any ideas??
Same happening on ET5000 and ET9000 boxes.
Can anyone shed any light on this as it seems to be a fundamental fault.
thanks
CT
Same happening on ET5000 and ET9000 boxes.
Can anyone shed any light on this as it seems to be a fundamental fault.
thanks
CT
If it was a fundamental fault than a lot more users would be experiencing it. Without logs there is little headway that can be made in getting to the bottom of your issue.
To keep things in perspective, I have three boxes running VIX and have 5 USB on them and not one has been "lost"
Any one having problems what are they formatted to and mounted as?
Perhaps many users dont realise they are becoming unmounted???
All my et9000's are initialised using vix 2.3 and they are auto mounted to:
Device /dev/sdb1
Mount /media/usb
type ext4 r/w
ET5000's
Device /dev/sda1
Mount /media/usb
type ext4 r/w
and they definitely lose the mount after emerging from standby.
thanks
Update: left the box on for 3 hours and the stick was unmounted when I got back! So it's not even the standby that causes it.
Very strange.
thanks
CT
I'm having the same difficulties on my ET5000
ET5000
Device /dev/sda1
Mount /media/usb
type ext4 r/w
Yeah my UNO has been doing the same thing got epg and picons On flash for now
Same here.
-USB was going to R/O frequently, now it got unmounted and mounting fails :/
Same here.
-USB was going to R/O frequently, now it got unmounted and mounting fails :/
I got a USB DVD unit mounted - it unmounted itself and wont mount again.
There's definitely something not quite right somewhere in the usb subsystem.
Without logs there is little headway that can be made in getting to the bottom of your issue.
What logs do you want exactly? There are no crash logs because the box isn't crashing. Please advise so we can get logs to you.
thanks
CT
Doesn't look as if this is going to get much attention?
Doesn't look as if this is going to get much attention?
Dont worry they will get to it. They are very good.
CT
What logs do you want exactly? There are no crash logs because the box isn't crashing. Please advise so we can get logs to you.
thanks
CT
menu> setup> system> logs> settings.
make sure enable debug log is set to yes and keep the default size as is. when you encounter a problem reboot the box and send the log that corresponds with the date and time of the reboot.
Doesn't look as if this is going to get much attention?
we listen to and pay attention to every bug report, submit your logs to us so we can investigate.
Rob van der Does
07-02-12, 08:28
Doesn't look as if this is going to get much attention?
Why does it look like so? Because we don't supply the solution within 2 hours?
Rest assured that every report made is being looked into. If we would have to answer every single one of them, we need to hire a secretary :D
Why does it look like so? Because we don't supply the solution within 2 hours?
Rest assured that every report made is being looked into. If we would have to answer every single one of them, we need to hire a secretary :D
Also its doesn't help that none of the Beta team is actually able to replicate this issue.
OK USB mount disapeared during normal operation so I restarted the box and here is the log.
thanks CT
For some reason my box is not creating debug logs.
Oh, well hope they get to the bottom of this.
Rob van der Does
08-02-12, 07:42
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.
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.
Using the vix media player seems to put the usb stick to sleep as well.
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
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
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
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.
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
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.
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
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=002 2,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 ?!?
I use ext3 or 4 on all my USB sticks and had zero issues.
I use ext3 or 4 on all my USB sticks and had zero issues.
Do you "manually" mount them in /etc/fstab ?
No, initialize connected to receiver, then set in mount manager.
Rob van der Does
25-02-12, 06:20
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.
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.
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
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
25-02-12, 14:07
Have you got a link to the pli forum please?
http://openpli.org/forums/topic/22449-grove-bug-met-usb-nog-steeds-aanwezig/
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
25-02-12, 21:21
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?
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 ?
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
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
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.
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
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
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.
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.
Anyone losing USB mounts could you post the file system being used.
ET5000
Device /dev/sda1
Mount /media/usb
type ext4 r/w
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.
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 ).
I've been using Cruzier blades 2GB, 4GB & 16Gb all fine, always been EXT4.
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.
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)
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.
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
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.
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...
@ Zartmy, do you have and other mounted devices? i.e. internal HDD? Network mount?
@ 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).
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?
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
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
I wonder what the timeout is for the code to be called? e.g how long before it is decided that the usb stick is not being used.
Rob van der Does
27-02-12, 14:06
As it is not a normal behaviour for an USB-stick to 'fall asleep', I think that that will be due to the firmware/hardware of the chipset in the pen. And hence also the duration of the period it manages to stay awake.
As it is not a normal behaviour for an USB-stick to 'fall asleep', I think that that will be due to the firmware/hardware of the chipset in the pen. And hence also the duration of the period it manages to stay awake.
Good point - however that raises the question of why it never happened with ViX 2.1? As I am using exactly the same sticks (a lot of other report this as well).
regards
CT
Good point - however that raises the question of why it never happened with ViX 2.1? As I am using exactly the same sticks (a lot of other report this as well).
I think the code was rather recently introduced in engima2 (i might be wrong).
I think the code was rather recently introduced in engima2 (i might be wrong).
Exactly so the firmware of the usb sticks shouldn't be of consideration.
Exactly so the firmware of the usb sticks shouldn't be of consideration.
Well, of course that mathers to. Otherwise all would share the same problem. For example the following usb stick
256 MB Kingston Technology DataTraveler II+ Pen Drive just ignores the command and does nothing.
Guinness.cobra
27-02-12, 19:31
My two pence - my new duo had problems of vanishing picons. I had settings to put the hdd to sleep in 5 min. What I did was put the hdd to sleep in 20 min and had a cron job setup every 15 min to the USB. I have a 500gb hdd and a 4gb USB wih the picons and epg. The hdd never had the problem, only the USB. Sinc making the above changes, I have not lost picons neither has my USB slept.
I am not a programmer so not sure if this logic of mine makes any cutting sense, but something for the developers to consider if they think it is worthwhile.
Rob van der Does
27-02-12, 20:14
I think the code was rather recently introduced in engima2 (i might be wrong).
Which code do you mean?
Well, of course that mathers to. Otherwise all would share the same problem. For example the following usb stick
256 MB Kingston Technology DataTraveler II+ Pen Drive just ignores the command and does nothing.
My point was... why add the command in the first place?
My point was... why add the command in the first place?
To spin down external usb harddrives while they are not in use. Thats the intention, though rather pointless to try to do it to usb flash sticks. But i guess there isnt an easy way to see if it is indeed a flashstick or a external harddrive.
Which code do you mean?
Enigma2 Harddisk.py
# the HDD idle poll daemon.
# as some harddrives have a buggy standby timer, we are doing this by hand here.
# first, we disable the hardware timer. then, we check every now and then if
# any access has been made to the disc. If there has been no access over a specifed time,
# we set the hdd into standby.
def readStats(self):
try:
l = open("/sys/block/%s/stat" % self.device).read()
except IOError:
return -1,-1
data = l.split(None,5)
return (int(data[0]), int(data[4]))
def startIdle(self):
self.last_access = time.time()
self.last_stat = 0
self.is_sleeping = False
from enigma import eTimer
# disable HDD standby timer
if self.bus() == "External":
Console().ePopen(("sdparm", "sdparm", "--set=SCT=0", self.disk_path))
else:
Console().ePopen(("hdparm", "hdparm", "-S0", self.disk_path))
self.timer = eTimer()
self.timer.callback.append(self.runIdle)
self.idle_running = True
self.setIdleTime(self.max_idle_time) # kick the idle polling loop
def runIdle(self):
if not self.max_idle_time:
return
t = time.time()
idle_time = t - self.last_access
stats = self.readStats()
l = sum(stats)
if l != self.last_stat and l >= 0: # access
self.last_stat = l
self.last_access = t
idle_time = 0
self.is_sleeping = False
if idle_time >= self.max_idle_time and not self.is_sleeping:
self.setSleep()
self.is_sleeping = True
def setSleep(self):
if self.bus() == "External":
Console().ePopen(("sdparm", "sdparm", "--flexible", "--readonly", "--command=stop", self.disk_path))
else:
Console().ePopen(("hdparm", "hdparm", "-y", self.disk_path))
def setIdleTime(self, idle):
self.max_idle_time = idle
if self.idle_running:
if not idle:
self.timer.stop()
else:
else:
self.timer.start(idle * 100, False) # poll 10 times per period.
def isSleeping(self):
return self.is_sleeping
Hi Guys,
Sorry to throw a spanner in the works, but I have solved the problem on my machine and am all the happier for it.
I had the following mount:
Vu+ DUO
Device /dev/sdb1
Mount /media/usb
type ext4
I was using a 4GB Cruzer Blade, which has always worked fine on the previous kernel, but after reading pheonix's comments about a possible faulty batch, I plugged in an old unbranded 2GB stick, given free on a training course, and copied all my picons etc to it. I left it formatted FAT32, and after 2 days, the mount is still fine and all files are accessable.
The cruzer blade was initialized in the STB and converted to EXT4, but still lost the mount. It was formatted at 4GB, but only 3GB showed up on the mount, not sure if that was relevant.
As Zartmy pointed out, maybe the Cruzer Blade has more sophisticated firmware and is being put into power save by the new kernel, or maybe there is just a bad batch around.
Hopefully this will give some hope to those in the same situation.
The obvious temporary answer is the add a user setting to allow the external standby (sdparm) to be turned off if the user is having problems. Basically allowing the sdparm command not to be issued. Long term we need to know why this is happening when it didn't in ViX 2.1 and/or why the kernal is losing the mount and not being able to restore them.
Quite honestly I'd prefer to be able to disable sleep mode for usb sticks.
Rob van der Does
21-03-12, 20:09
There is indeed a kernel bug in kernel 3.x, resulting in setting all USB-storage devices to standby. Not all devices are affected by this: on many the firmware prevents this.
An easy work-around is to set HDD-idle time to 'never'.
as i started this thread i thought i should say how it was cured I followed this http://www.world-of-satellite.com/showthread.php?16650-Problems-with-ViX-2-3-crashes-and-using-USB-memory-read-this-first and have had no problems since
edogg
Rob van der Does
29-03-12, 06:40
Next update will have a fix for this.
Next update will have a fix for this.
Excellent!!
thanks
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.