• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: Debian Squeeze: Mounting USB Drive on reboot fails  (Read 4390 times)
odoll
Full Member
***

Karma: 0
Posts: 148


View Profile
« on: November 21, 2010, 02:39:00 AM »

Hi, already had look here http://plugcomputer.org/plugforum/index.php?topic=1083.0, but as this is too old I dare to open a new thread.

I recently switched from Ubuntu 9.04 to Debian Squeeze with my SheevaPlugs (booting from a 1GB SD).
Attached to the plug is also a 2TB Hitachi USB HDD, which contains my data, e.g. shared via cfis/samba.

Debian's working quite well, however when rebooting the plug, the attached USB drive usually doesn't get mounted. That's new to me as it worked fine using Ubuntu.

This is the entry in /etc/fstab:

#/dev/sda1 /mnt/sda1 ext3 rw,usrquota 0 0
UUID=<USB's ID> /mnt/sda1 ext3 rw,usrquota 0 0


Mounting it on the CLI "mount /dev/sda1 /mnt/sda1 works.

Strangly if I power cycle the plug the drive gets mounted.

Any idea what this might be. Haven't tried it yet, but may an "usbstart" during the u-boot initialization improve the situation?
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 440


View Profile WWW
« Reply #1 on: November 21, 2010, 11:40:22 AM »

Do you have a rootdelay setting in your bootargs?
This lets the USB devices start and and settle on the USB bus before the kernel (and udev) start looking for them
Logged

odoll
Full Member
***

Karma: 0
Posts: 148


View Profile
« Reply #2 on: November 23, 2010, 05:09:31 AM »

Hi birdman,

On the weekend I amended the bootcmd_mmc u-boot environment variable given her http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html with an "usb start"

setenv bootcmd_mmc 'mmcinit; ext2load mmc 0:1 0x00800000 /uImage; ext2load mmc 0:1 0x01100000 /uInitrd; usb start'

but it does not mitigate the situation:

Last login: Sun Nov 21 16:51:42 2010
root@Share:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p2          746848    607824    101088  86% /
tmpfs                   257788         0    257788   0% /lib/init/rw
udev                    254952        76    254876   1% /dev
tmpfs                   257788         0    257788   0% /dev/shm
/dev/mmcblk0p1          124743     22009     96078  19% /boot
root@Share:~# mount -a
root@Share:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p2          746848    607860    101052  86% /
tmpfs                   257788         0    257788   0% /lib/init/rw
udev                    254952        76    254876   1% /dev
tmpfs                   257788         0    257788   0% /dev/shm
/dev/mmcblk0p1          124743     22009     96078  19% /boot
/dev/sda1            1922858352 1424940752 478382444  75% /mnt/sda1

But of course your hint was worthwhile a new try (in the meantime I also saw some of your post where you ran into a similar situation :-)

Thus I modified the u-boot variables as follows:

setenv bootargs_console 'console=ttyS0,115200 rootdelay=5'
setenv bootargs_mmc 'mmcinit; ext2load mmc 0:1 0x01100000 /uInitrd; ext2load mmc 0:1 0x00800000 /uImage'
setenv bootcmd_mmc 'setenv bootargs $(bootargs_console); run bootargs_mmc; bootm 0x00800000 0x01100000'
setenv bootcmd 'run bootcmd_mmc; run bootcmd_nand; run bootcmd_sd'


And indeed, looks better, now :-)

BTW: as my plug's in the basement I always have to pick it up and bring it to my PC to have access to the u-boot environment.
So I though being lazy and considered the use of the sheeva-uboot-tools (https://code.google.com/p/sheeva-uboot-tools/), dl them and compiled my own version.

However, though the sheeva-ubootenv-print worked OK, sheeva-ubootenv-save seem to have screwed the config, as another print claimed about CRC? errors and the plug didn't came after reboot. When I picked it up I could access u-boot, but it just had default settings. Luckily I had a backup at hand and could restore my previous settings, so got it working again (though there was another small intermezzo with the kernel complaining about an unknown Manufacturer ID, but I can't recall exactly how did overcome this ;-)
« Last Edit: November 23, 2010, 05:12:40 AM by odoll » Logged

birdman
Sr. Member
****

Karma: 4
Posts: 440


View Profile WWW
« Reply #3 on: November 23, 2010, 07:04:55 PM »

rootdelay=5
....
And indeed, looks better, now :-)
5 may be a little tight. I think 6 was suggested, but I used 10, as I'd rather wait a few more seconds but be sure.

"usb start" activates the USB bus in u-Boot.  rootdelay tells the kernel to wait <n> seconds before scanning the bus after activating it (which it needs to do itself anyway)
Logged

odoll
Full Member
***

Karma: 0
Posts: 148


View Profile
« Reply #4 on: November 28, 2010, 01:56:57 AM »

As a delay of 5 worked for me so far (former Ubuntu), I just kept it the same for the Debian boot for now, (though still configured as an option in u-boot, but more or less obsolete, now.)

setenv bootargs_sd 'console=ttyS0,115200 root=/dev/mmcblk0p2 rootdelay=5 mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw ip=a.b.c.253:a.b.c.1:a.b.c.1:255.255.255.0:Sheeva:eth0:none'
setenv bootcmd_sd 'setenv bootargs $(bootargs_sd); mmcinit; ext2load mmc 0 0x8000000 /uImage; bootm 0x8000000'
setenv bootcmd 'run bootcmd_mmc; run bootcmd_nand; run bootcmd_sd'


However I had another issue lately, thou I don't know if it's related to the delay value (as far as I can recall I at least never had these kind of issues on the plug running with Ubuntu).

I found the throughput to be very bad lately (log-on/off with the Windows Roaming Profiles was really a pain). I first suspected my network causing these problems, but in the end I found the I/O to the USB-HDD too small and I guess it was just mounted via USB1.1 (when I ran "dmesg | grep usb" I think think I saw a message telling me something like the USB-HDD could do better and I should use an highspeed USB-Hub?).

So I rebooted this morning and the issue seems to be gone for now.

Code:
root@Share:/mnt/sda1/public# dmesg | grep usb
[   23.203358] usbcore: registered new interface driver usbfs
[   23.231907] usbcore: registered new interface driver hub
[   23.238583] usbcore: registered new device driver usb
[   23.363372] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   23.370204] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   23.377478] usb usb1: Product: Marvell Orion EHCI
[   23.382217] usb usb1: Manufacturer: Linux 2.6.32-5-kirkwood ehci_hcd
[   23.388598] usb usb1: SerialNumber: orion-ehci.0
[   23.401912] usb usb1: configuration #1 chosen from 1 choice
[   24.141134] usb 1-1: new high speed USB device using orion-ehci and address 2
[   24.292046] usb 1-1: New USB device found, idVendor=4971, idProduct=ce23
[   24.298785] usb 1-1: New USB device strings: Mfr=10, Product=11, SerialNumber=3
[   24.306139] usb 1-1: Product: SimpleDrive III by Hitachi
[   24.311487] usb 1-1: Manufacturer: HitachiGST
[   24.315866] usb 1-1: SerialNumber: <S/N removed>
[   24.321739] usb 1-1: configuration #1 chosen from 1 choice
[   24.447088] usbcore: registered new interface driver usb-storage
[   24.453723] usb-storage: device found at 2
[   24.453732] usb-storage: waiting for device to settle before scanning
[   29.451371] usb-storage: device scan complete
root@Share:/mnt/sda1/public# sync; time sh -c "dd if=/dev/zero of=./test bs=1000k count=1000; sync"
1000+0 records in
1000+0 records out
1024000000 bytes (1.0 GB) copied, 37.9303 s, [color=green]27.0 MB/s[/color]

real    0m53.800s
user    0m0.050s
sys     0m11.730s
root@Share:/mnt/sda1/public# sync; time sh -c "dd if=./test of=/dev/null; sync"

2000000+0 records in
2000000+0 records out
1024000000 bytes (1.0 GB) copied, 37.3098 s, [color=green]27.4 MB/s[/color]

real    0m37.450s
user    0m2.070s
sys     0m8.410s

However it leave me with two questions:

i) which tool / command shall I use to monitor the "link state" of my USB connection?
ii) may I use the newer kernels compiled and hosted by ctxbiker on my Squeeze install or is this a bad idea?
« Last Edit: November 28, 2010, 01:58:44 AM by odoll » Logged

Pages: [1]
Print
Jump to: