I have this strange problem in an embedded system (linux) we build, so I don't have normal GUI trouble-shooting tools on Linux or Windows machines.
The problem is the NIC is no longer usable after cable removed. Even if I re-plug the cable, the lights on it never come back on again and nothing can be sent or received. ifconfig still works on the surface, but doesn't have real effect. Only a reboot will solve the problem. I guess the problem is in the ethernet driver.
My question is how the trouble-shoot it. Any clues/hints? Thanks.
====================
Thank you guys! The board is a gumstix and the PHY is SMSC911x. We are running on Linux 3.0.12. It turns out the smsc911x_soft_reset() of the NIC fails when driver calls smsc911x_open(). The symptom also includes we must run ifconfig multiple times (not consistent) to bring the NIC up and the system can detect it.
I did a search on "SMSC911x soft reset failed" and find this link. http://comments.gmane.org/gmane.linux.network/216467. I removed SMSC_PHY=y in the linux build config file and that fixed the problem. It seems the driver is not compatible. Can somebody explain this, or is there a better solution?
Related
So, my knowladge in embedded development is quite bad and now I am trying to receive some data from PC inside my MCu STM32F429IGT6 which is on WaveShare Core4X9I dev-board and send it back via USB Virtual COM Port.
I realized how to set up connection from MCu part and I even see connected device from Windows 10 Device Manager but... it appears as STM Device in DFU Mode
I have tryed already to install drivers from ST for such things but they are useless and official documentation says that they are not needed for Windows 10.
I have been following tutorials where guys just clicked several times inside Cube MX, generated code and VCP worked out of the box.
The question is what am I doing wrong? I don`t even know what information you might ask for thats why I created GitHub repo: https://github.com/dessy4oko/stm32f429-vcp-appears-as-dfu
And this is events from Device Manager of Windows 10 (translation from ru lang):
Device USB\VID_0483&PID_DF11\305233703237 is running. code 410
Device USB\VID_0483&PID_DF11\305233703237 is configured. code 400
Device USB\VID_0483&PID_DF11\305233703237 have not been moved due to partial or ambiguous matching. code 442
Device USB\VID_0483&PID_DF11\305233703237 requires further installation. code 430
Thank you for any information about my mistakes.
STM32 starts in DFU mode if BOOT-pins are pulled accordingly:
"System memory" means embedded bootloader, DFU in this case. You need "Main Flash" to run your app.
Check jumpers and switches on your board. Refer also to the AN2606 app note for complete information.
I picked up an AUPS-A10-R11 DC UPS, and am working with their API to build some monitoring software for my xen host. Their API runs over the USB connection on the device, which presents itself as /dev/ttyUSB# on the host.
I've got things working fine except for one thing that's puzzling me. When I first power on or reboot the host it's connected to, I can't communicate with the device. However, if I open up a screen connection to it:
screen /dev/ttyUSB0 9600
and then close it (ctrl+a, k) then it will work perfectly fine until the next time that you reboot the host.
Does anyone have any idea as to why I would have to connect to the device over screen first? I've pasted my code here: http://susepaste.org/0b8bb37f . When connecting on a fresh reboot, it stops at the "Read Nothing" section of the if...else clause. After connecting to the device with screen, it works fine.
Any thoughts??
Does anyone have any idea as to why I would have to connect to the device over screen first?
Such behavior is almost always related to incomplete termios initialization by your program.
The ideal program would configure a serial terminal for its purposes, and on exit restore the termios configuration back to the way it found it.
But most programs, including terminal emulation programs such as minicom and apparently screen, simply leave their termios configuration instead of restoring it.
Fortunately for you, this leftover termios configuration fills in the missing pieces that allows your program to access the serial terminal as expected.
Review of "your" code suggests that it was copied from the accepted answer of this question. Based on the number of up-votes, this code apparently works for a lot of people. However the author admits it was written before POSIX standards, and therefore the code should not be considered portable. In other words, your mileage may vary.
Apparently you overlooked the alternative answer which is POSIX compliant. A tested termios configuration for blocking non-canonical mode is in that program.
If you prefer to simplify with the use of the cfmakeraw() macro, then here's another code example.
I've been testing MTWWW for about a couple of days, and I've come to notice something.
I have to add the device to MTWW by going to a url on the device that looks like this,
protocol://hostname:+port/mobile
However, sometimes my device can't reach that address neither when I restart eclipse. When that happens I typically restart my computer and everything is fine and dandy again.
There was even one time that on that same screen that display the QRCode and URL to add a device, a notification appeared which showed something close to "RTW server could not start properly" or something like that.
This led me to believe that MTWW uses some other web server other that WL server to receive the recordings from the instrumented apps.
This also led me to believe that perhaps sometimes when the server tries to start the ports are already binded to some socket and it fails the initialization. Just speculation here.
However if there is a slight sense in what I written, is there a way to inspect the status of the RTW server, some dashboard perhaps?
Besides that, what should I do to fix when the RTW server didn't start properly? Rebooting the computer is pretty lame, there must be something more clever to do.
Oh, I've found this behavior on a mac osx box, on a windows one I haven't done so much testing.
Thanks in advance.
There is no dashboard for the server. But if yoy think that the issue come from the port, you can change it in the preferences. Please read http://www-01.ibm.com/support/docview.wss?uid=swg21678980
Hope its help
I set up CGMiner 3.8.1 (even the one before this version) on MACOS X 10.8.5
I have 11 Block Erupters but the CGMiner just see 10 and keep giving this error: SEM: Icarus USB timeout waiting for (blah blah).
I already changed usb hub, plugged the usbs direct into the computer but nothing seems to fix it.
BFGMiner sees and recognize all of them, I just really don't like it.
Do you guys know what I can do to fix CGMiner?
Thank you.
cgminer uses SysV semaphores and makes use of the UNDO mechanism. Most OSs have low settings of this value (kern.sysv.semume), usually 10 or less. Use 'sysctl' to adjust that value upwards. You may need to do this via /etc/sysctl.conf and reboot.
I've set up raspbian "wheezy" (more information here, and image file here) on my recently arrived raspberry-pi (model B, but with 256MB RAM). Since I plan to use it via SSH from other locations, I was looking for a way to lock the console on the actual machine.
Raspbian is the first unix based OS I am working with, so I'm not really familiar with it, but I think I am looking for something like "vlock".
I installed vlock like this:
apt-get install vlock
When I now log into my pi via SSH from my Windows PC vlock works just fine, but when I try using it on the machine itself it shows a strange behaviour.
If I enter a wrong password, I get the usual message:
vlock: Authentication failure
but immediately after that the commandline shows up as if I entered the right one. So basically everyone can just roll his or her head over my keyboard to unlock my pi.
Does anyone know if this is a known bug (or even intended)? Or are there any equivalents to vlock that I could try?
Thanks in advance.
PS: This is my first question on stackoverflow so I hope I provided enough information. If I didn't, feel free to comment/ask.