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.
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.
since yesterday my true-crypt partition do not automount on startup with my OS every time (sometimes it works, sometimes it doesn't).
Yes they are set as system favorites and the checkbox mount on startup is set.
Yes they have the same password, typed with the same (EN INTL) layout.
Yes it worked somehow before a few times.
Thanks for the help.
edit:
OS: Windows 8
Update
It seems only not to work from cold starts.
warm starts seem to work
I have this problem on my Windows 8 laptop. I tracked the problem to the new shutdown process with Windows 8. It won't do a full shutdown/startup when you do, only some sort of hybrid shutdown (https://superuser.com/questions/496241/are-there-downsides-to-windows-8-hybrid-shutdown)
I found that if I use the normal Charm -> Settings -> Power -> Shutdown, it would fail to load the encrypted partition when I got to the desktop.
However, if you use the command line "shutdown.exe /s /t 0" to shutdown, it will reliably load the next time you start up.
I was forced to fix it this way because my Dropbox was on the encrypted partition, and Dropbox would complain that it couldn't find the folder anymore (same with Google Drive and SkyDrive, only worse).
This might fix that problem, but I haven't tried it yet (http://www.askvg.com/fix-windows-8-restart-and-shutdown-problems-by-disabling-hybrid-shutdown-feature/)
Win 8.x seams to offer special shutdown option for a fast restart. This leads also to another special file on the boot driver (besider hypee and page). Therefore the "cold restart" is not a real cold start it's something like hypernation "light".
In the power options you may try to disable the option "turn fast startup (recommended)" selection.
There is an alternative to disabling hybrid boot/shutdown. You can also get it to work consistently if you go to TrueCrypt, Favorites, Organize System Favorite Volumes and then tick the option to Allow only administrators to view and dismount system favorite volumes.
Source.
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?
This is been making my programming really frustrating lately.
I´m in Argentina right now connecting to a U.S. server via SSH. Understandably, the pings are a bit higher here (around 200ms on average) so when I SSH into the server there is a slightly noticeable lag between each keystroke. This is fine and easy enough to work with.
What isn´t easy to work with is that about every 5 minutes or so, SSH will completely hang and take about 3-5 minutes to return back a prompt. I know the server is not bogged down because I can easily open several new connections while I´m waiting for one to return (in fact this is the only way I´ve been able to work). And when SSH finally comes back I can see it has actually been working away in the background (large file downloads was a good way to test this) but it just hasn´t been updating my screen.
Does anyone have an idea what might be causing this?
Few other facts: the server is Ubuntu and I'm connecting with Mac OS X. I have keepalive turned on in the SSH settings. It is most likely to hang when I hold down a key (for example a left or right arrow to scroll) which sends a lot of keys quickly. In fact I can reliably reproduce the hang by logging in and holding down any key like "a" - it never makes it past a full line of "a"'s before hanging. This just started when I connected internationally for the first time so I´m assuming it has something to do with that (latency?) but can´t say for sure.
Odd. I can't help you with your problem but I have a tip to make it less annoying: Use screen(1). This will keep your shell on the other end alive and you can continue whatever you were doing after reconnecting.
If you only need to run a command on the other side, I suggest to pass the command as an option to ssh (it will connect, run the command, display the result and disconnect).
I think it was some problem with the ISP down here in argentina. When I switched to another wireless network with another ISP it started working. They are probably playing some port throttling games or who knows what.
Try adjusting your TCP window size.
I'm used to ssh over high latency links - 600ms. It is slow but I rarely had any problems. To start with - open another terminal window, ping your server and watch the connection. Tell us what you see.
Try sshing in with a few verbose flags (ssh -vv[vv] somehost) and seeing if there's anything indicative printed around the time it hangs.
Well, I am now connected to a different wireless network and the problem seems to have disappeared. I can't say for sure what exactly was causing it (and I don't have login access to the wireless router) but this seems to suggest it was something on the router, and not the server or client computer.
Both the old router and the new router were Linksys WRT54G's so I'm not sure what the problem was. Hope it helps someone!
I was having a similar problem with 'cat' and even 'ls -l' causing ssh to hang (on Ubuntu). Adjusting MTU size to 1400 fixed it for me.