USB OTG port does not appear to be working.

[urjaman]

Shouldnt stuff from /etc/modutils/* that generates /etc/modules.conf be used always when you just modprobe (so the suspend script wouldnt need to remember to give options)?

Eg. options g_whatever dev_addr=... or something like that to a file in /etc/modutils and update-modules and it should be persistent.

- this would of course make /etc/default/usb-gadget options not really 100% functional so maybe that should be removed and something (even a commented line) added to like /etc/modutils/usb-gadget or something. Not sure, just saying an idea out loud.

 

[Neelix]

I've been looking into that over the last couple of days. When I discovered how that is supposed to work I thought I'd found a solution...

It's entirely possible I was doing something wrong because I've never seen an example of how to do it properly, but when (after a careful reading of the man-pages) I tried adding a configuration file for g_cdc to /etc/modutils and ran update-modules the modules.conf file was unchanged. (containing only a comment that it is automatically generated by update-modules based on the contents of /etc/modutils and should not be edited directly)

Having failed to get that to work I reverted to my previous method.

The options specified in /etc/default/usb-gadget actually take precedence over modules.conf, as they are passed to modprobe on the command line (and command line arguments take precedence over the config file)

In any case, I have also created a proof of concept script for a way to save and restore the module arguments. It should be possible to use this method in both op_power.sh and op_storage.sh

Spoiler

#!/bin/bash

SaveModuleArgs() {
# generate list of parameters for selected module
local ArgList=""
for Arg in $(ls /sys/module/$1/parameters/ 2>/dev/null); do
ArgList="$ArgList""$Arg=$(cat /sys/module/$1/parameters/$Arg) "
done
# save list of arguments (if any) to cache file
if [ ! "x$ArgList" == "x" ]; then
echo -e "$ArgList" > $ArgsCache/$1
fi
}

#setup cache folder (used to simplify saving of arg lists for multiple modules)
ArgsCache="/tmp/ac$(date +%s)"
mkdir -p $ArgsCache

#example module
Mod="g_cdc"

#save module arguments and unload module
SaveModuleArgs $Mod
sudo rmmod $Mod

echo "$Mod unloaded"
sleep 2

# load module with saved arguments
sudo modprobe -v $Mod $(cat $ArgsCache/$Mod)

#cleanup cache folder
rm -r $ArgsCache

I'd appreciate any feedback.

- Neelix

 

[Neelix]

Also I would add that unplugging the USB cable with USB networking active still crashes the unit most of the time... The times it didn't crash during my initial testing when I first installed the kernel upgrade seem to have been an aberration in this regard.

- Neelix

 

[notaz]

I don't like using /sys/module/$1/parameters and you have to save all default parameters needlessly, which might have unintended side affects when you pass them on reload, instead of passing nothing.

Awhen you later supply them lso I would add that unplugging the USB cable with USB networking active still crashes the unit most of the time... The times it didn't crash during my initial testing when I first installed the kernel upgrade seem to have been an aberration in this regard.

I use USB networking all the time, and it doesn't crash for me at all. Are you doing heavy traffic when unplugging or something?

 

[Neelix]

I don't like using /sys/module/$1/parameters and you have to save all default parameters needlessly, which might have unintended side affects when you pass them on reload, instead of passing nothing.

Well I'm open to other ideas. That was the simplest method I could find which didn't involve installing additional applications. Do you have any other suggestions for how to obtain the parameters a module was called with? (or how to distinguish a specified value from a default value)
It also occurred to me that since we do have applications that load gadget drivers with specific parameters, it makes sense to restore those applications to their prior state if the end user does happen to trigger a suspend while they are active.

Also I would add that unplugging the USB cable with USB networking active still crashes the unit most of the time... The times it didn't crash during my initial testing when I first installed the kernel upgrade seem to have been an aberration in this regard.

I use USB networking all the time, and it doesn't crash for me at all. Are you doing heavy traffic when unplugging or something?

Actually I'm usually pretty careful about terminating any active sessions before pulling the plug.

Last time it happened I had specifically waited until the netbook reported no active connections to the pandora's IP before pulling the plug. (I checked it with netstat -a)

- Neelix

 

[Neelix]

I have a suspicion as to what's causing my crashes but further testing is required... It doesn't seem to be happening if I disconnect the USB cable from the netbook first, which suggests to me that its not an issue with the software at all.

- Neelix

 

[Neelix]

And now I'm back to square one... using a completely different USB cable now, and it still crashes on disconnect, no matter which end of the cable I disconnect first.

 

[notaz]

Dunno, just unplugged the cable with ping flood going to pandora like 5 times, no problems whatsoever. Tried both g_cdc and g_ether. What are you running on host PC?

 

[Neelix]

Ubuntu 10.04 LTS

Linux nb-fezzik 2.6.32-45-generic #104-Ubuntu SMP Tue Feb 19 21:21:41 UTC 2013 i686 GNU/Linux
There doesn't need to be any traffic established beyond the original dhcp traffic...

huh... I just ran

sudo rmmod g_cdc
...before disconnecting. This time it didn't crash but the keyboard no longer works... (the dpad and gaming buttons do but not the keyboard itself)
... BT keyboard still connects though and I was able to capture a dmesg.

- Neelix

 

[notaz]

Thanks for that log, I can see what's going on now.

 

[Neelix]

You're welcome Looking at that log, I only have a vague grasp of what most of it means, but it seems to me that g_cdc was only exacerbating another issue, not the cause of the issue itself, would that be correct?

- Neelix

 

[notaz]

Yeah it was a bug I've left as it doesn't trigger on DM3730, it has different interconnect stuff that allows accessing registers with interface clocks off, while on OMAP3 you can't and get a data abort.

I've uploaded new kernel onto the feeds, would be nice if you could do "upgrade pandora OS" and test that.

 

[Neelix]

Yeah it was a bug I've left as it doesn't trigger on DM3730, it has different interconnect stuff that allows accessing registers with interface clocks off, while on OMAP3 you can't and get a data abort.

I've uploaded new kernel onto the feeds, would be nice if you could do "upgrade pandora OS" and test that.

I'd love to but the upgrade tool seems to be failing to upgrade the kernel...

Spoiler

Downloading http://openpandora.org/feeds/unstable/all/Packages.gz.
Inflating http://openpandora.org/feeds/unstable/all/Packages.gz.
Updated list of available packages in /var/lib/opkg/pandora-all.
Downloading http://openpandora.org/feeds/unstable/armv7a/Packages.gz.
Inflating http://openpandora.org/feeds/unstable/armv7a/Packages.gz.
Updated list of available packages in /var/lib/opkg/pandora-armv7a.
Downloading http://openpandora.org/feeds/unstable/omap3-pandora/Packages.gz.
Inflating http://openpandora.org/feeds/unstable/omap3-pandora/Packages.gz.
Updated list of available packages in /var/lib/opkg/pandora-omap3-pandora.
Upgrading omap3-pandora-kernel2 on root from 3.2-pandora-r1.5 to 3.2-pandora-r4.5...
Downloading http://openpandora.org/feeds/unstable/omap3-pandora/omap3-pandora-kernel2_3.2-pandora-r4.5_omap3-pandora.ipk.
Upgrading pandora-scripts on root from 1.0-r131.5 to 1.0-r135.5...
Downloading http://openpandora.org/feeds/unstable/omap3-pandora/pandora-scripts_1.0-r135.5_omap3-pandora.ipk.
Collected errors:
* opkg_download: Failed to download http://openpandora.org/feeds/unstable/omap3-pandora/omap3-pandora-kernel2_3.2-pandora-r4.5_omap3-pandora.ipk, wget returned 1.
* opkg_install_pkg: Failed to download omap3-pandora-kernel2. Perhaps you need to run 'opkg update'?
* opkg_download: Failed to download http://openpandora.org/feeds/unstable/omap3-pandora/pandora-scripts_1.0-r135.5_omap3-pandora.ipk, wget returned 1.
* opkg_install_pkg: Failed to download pandora-scripts. Perhaps you need to run 'opkg update'?

- Neelix

 

[notaz]

Hmh, package index did not update last time, strange..

Try it again now.

 

[Neelix]

upgrade works now... successfully updated kernel and rebooted.

... Pandora still crashing on USB networking disconnect though

... Keyboard no longer failing if I unload g_cdc first nothing useful on dmsg either though.

- Neelix

 

[notaz]

Doesn't reproduce on CC unit either, no matter what. Have you tried removing battery for 5 minutes?

 

[Binky]

(slightly off-topic)

How many components (not including the in-SOC NAND memory) are there in the pandora that can remember settings after the battery has been removed?

 

[notaz]

There is a capacitor connected to power chip intended to keep time between battery swap (lasts for something like a minute, that's why you need 5 minutes to reset the power chip).

As for longer storage, I can't think of anything, unless you consider nub microcontrollers and perhaps wifi EEPROM that can be reprogrammed with external hardware.

 

[Neelix]

Doesn't reproduce on CC unit either, no matter what. Have you tried removing battery for 5 minutes?

I have now... looks promising actually. Have connected and disconnected several times without it crashing. good call. Thanks.

- Neelix

 

[notaz]

I've updated the kernel with persistent_ram driver, which can keep kernel log as long as you don't power off (hardware reset with pandora+power_switch should be fine). The log of previous session can be found in /proc/last_kmsg , so I need that log after a reboot done after a hang.