Hi David (Woodhouse) I'm working a problem reported against the e100 driver that is related to the STD & request_firmware(), and I'm hoping you might be able to help. The problem is well described by the reporter in: https://sourceforge.net/tracker/?func=detail&aid=2876241&group_id=42302&atid=447449
I include here an extract form that report. -----Start of extract from e1000 SF tracker ----------- I use IntelPro/100 as second lan card in my fairly old machine. Since kernel 2.6.29 I'm having problem suspending and resuming (using native kernel hibernation) if the card is enabled. If the interface is brought down and module removed, hibernation is successful. At first, the hibernation suspending takes forever, however it seems that there are indeed some timeouts that run out, and it seems to be able to move to next stage. E.g. at some point sysrq doesn't work, but after few minutes it does. However suspending never finishes and never powers down. Sometimes the hibernation code manages to write image to the swap, so at restart kernel tries to resume the session, and hangs forever. To this report I attach the log from boot and single suspend using "pm_test=devices" debug mechanism. This test passes successfully, however new attempt to do "pm_test=devices" hangs the system. The system also hangs if I do `rmmod e100` after one "pm_test=devices". I have loaded the e100 module with the option debug=10, so I hope it have all needed debug info. While checking the logs I noticed that firmware loading is failing. It seems that udev is called and it tries to run firmware.sh script that is supposed to feed the firmware images. I have changed the script to display more info, in case script is given wrong data: err /sys$DEVPATH/loading $FIRMWARE err `ls /sys/class/firmware` err `ls /sys/devices/pci0000:00/0000:00:09.0/` err `ls -R /sys/devices/pci0000:00/0000:00:09.0/firmware/` After a number of tries I got to the conclusion that the the resuming module tries to load the firmware, however the userland process hangs at it (probably because all userland is still frozen). The module timeouts and fails at firmware loading. Then later when the userland is enabled the firmware.sh script is run but the directory/file it have to work are already removed. -----End of extract from e1000 SF tracker ----------- The e100 Si does require that the firmware is (re)loaded after a suspend/resume cycle. Do you agree with Ivan that the issue with failing to reload is probably because user space is still "frozen" at the time that e100 invokes request_firmware() ? And if so, how do you think we should proceed ? Thanks Dave ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
