This shows you the differences between the selected revision and the current version of the page.
| mobilemesh:issues 2009/11/03 12:01 | mobilemesh:issues 2009/11/12 16:59 current | ||
|---|---|---|---|
| Line 2: | Line 2: | ||
| This pages captures issues with the boxes and their solutions, as they are discovered. | This pages captures issues with the boxes and their solutions, as they are discovered. | ||
| + | |||
| + | === GPS Gets Wierd Time (March 1990) === | ||
| + | |||
| + | If you cycle the power on the box when the GPS is out of range. And then once the box is back up and running, move the gps into range. | ||
| + | The time it reports is weird. | ||
| + | |||
| + | On the other hand, simply moving the gps out of range and then back into range causes no trouble. When it reenters range it begins printing reasonable values again. | ||
| + | |||
| + | === GPSD Starts Automatically During Boot === | ||
| + | |||
| + | **Desc:** Even if you configure ''gpsd'' to not start at boot (using ''dpkg-configure'' as recommended in documentation), it still starts during the boot process. | ||
| + | |||
| + | **Fix:** The culprit is the ''gpsd'' hotplug rules, which are called when the GPS is detected on the USB during boot. Because we do not need gpsd to hotplug (i.e., we always start it ourselves) the easiest fix is to disable the hotplug as follows: | ||
| + | |||
| + | mv /lib/udev/gpsd.hotplug /lib/udev/gpsd.hotplug.DISABLED | ||
| + | |||
| + | Removing ''.DISABLED'' will renable the hotplug behavior. | ||
| + | |||
| === Boot Crashes when Mounting Root fs === | === Boot Crashes when Mounting Root fs === | ||
| Line 38: | Line 56: | ||
| wifi0: Atheros 5212: mem=0xe0040000, irq=9 | wifi0: Atheros 5212: mem=0xe0040000, irq=9 | ||
| - | A manual Ctl+C is required to continue to load. | + | A manual Ctl+C is required to continue to load, or you have to wait up to 5 minutes for it to timeout on its own. |
| + | |||
| + | **Fix:** The problem concerns ''udev'' setting up the USB device in the ''dev'' device in the case where a GPS is plugged into the USB port on boot. A closer examination revealed that there is a place in the ''/etc/init.d/udev'' script that calls ''udevsettle'' to wait for all the devices to be correctly linked to their userspace aliases in ''/dev''. It is here the boot is hanging. A somewhat hacky solution that seems to work is to add the ''--timeout'' flag to the udevsettle and give it a more reasonable value, such as 5. (It takes an argument in seconds). | ||
| + | |||
| + | Specifically, in ''/etc/udev/udev'' change this code: | ||
| - | **Note:** The hang is not permanent. After a minute or two, the boot continues. The the wifi0 stuff just happens to be the last activity of the following command: | + | log_action_begin_msg "Waiting for /dev to be fully populated..." |
| + | if udevsettle; then | ||
| - | Waiting for /dev to be fully populated... | + | To this code: |
| + | log_action_begin_msg "Waiting for /dev to be fully populated (timeout added)..." | ||
| + | if udevsettle --timeout=5; then | ||
| - | **Note:** The problem seems to be whether or not the gps device is plugged in. The populating of ''/dev'' must be waiting for some information from the gps which can take awhile. | + | The USB GPS still seems to work fine after this timeout, so whatever event was hanging was probably buggy. |