 Show Posts
|
|
Pages: [1] 2 »
|
SOMEBODY PLEASE write the correct script/code for miner reset when a GPU hangs, 'thread exit code 46 - or whichever".
It happens to me during the night and I lose hours of mining because of that,
I tried all suggestions from this topic, but nothing worked.
And send me your btc address, I'll give out a reward to successful solution.
So... about that script? EWBF?
Anybody?
It should be fairly simple to write a miner reset code when sols drop to zero,
I'm not a dev, but it's no nuclear science, right guys?
Put this in the .bat file: :loop miner --eexit 1 --server eu1-zcash.flypool.org --port 3333 --user t1QmwNgVc6VrhTuGgL9so7jeVz1BYcN3dPz --pass x goto loop --eexit 1 - exit when gpu cannot be restarted. Problem is that gpus are restarted and keep working with 0 sols, so program doesn't ever terminate with this command unless we manually reopen it. Check your USB cables. I had this very same problem, and I replaced the cables to my risers with known good cables. I've not had a problem since (knocking on wood). Thanks for the answer, but I have 5 different rigs, with 5 different risers and it happened on all of them at one time or another, so it is not cable related. My clock is really not that high, I'm getting around 440-450 per card (1070). +180 core, +400 memory, I've seen people going +250 core and +700 memory... It does happen rarely, but still it happens in the early morning hours usually, which is annoying. I tried with different versions of that code, will try again. I fought this problem for weeks. I finally took the machine out of the rack, and replaced all of the USB cables. So far so good - it's been running now for 72hrs without a problem. The longest I've ever had it run without that error. I found while I was diagnosing the problem that it was only two cards that would cause the errors. I used 'nvidia-smi -q | grep UUID' (I'm running on Ubuntu) to ID the cards, and those are the ones I switched the cables. YMMV |
|
|
|
SOMEBODY PLEASE write the correct script/code for miner reset when a GPU hangs, 'thread exit code 46 - or whichever".
It happens to me during the night and I lose hours of mining because of that,
I tried all suggestions from this topic, but nothing worked.
And send me your btc address, I'll give out a reward to successful solution.
So... about that script? EWBF?
Anybody?
It should be fairly simple to write a miner reset code when sols drop to zero,
I'm not a dev, but it's no nuclear science, right guys?
Put this in the .bat file: :loop miner --eexit 1 --server eu1-zcash.flypool.org --port 3333 --user t1QmwNgVc6VrhTuGgL9so7jeVz1BYcN3dPz --pass x goto loop --eexit 1 - exit when gpu cannot be restarted. Problem is that gpus are restarted and keep working with 0 sols, so program doesn't ever terminate with this command unless we manually reopen it. Check your USB cables. I had this very same problem, and I replaced the cables to my risers with known good cables. I've not had a problem since (knocking on wood). |
|
|
|
|
@EWBF_ a small feature request - print out the card's UUID on start-up when finding the card. That way we know for sure which card may be acting up more easily.
Thanks!
|
|
|
|
Ewbf_ any update on a new release with better API? Hope all is well on your end!
Hi, yes new release coming soon. What new api features do you want to see? More verbose error messages, i.e. Error 29 means nothing to me and I get it frequently. |
|
|
|
|
Anyone have an idea what code 29 means?
I've a rig that runs fine for a while, but then randomly every device throughs a code 29 and the miner keeps chugging along, but all devices are at 0 sols/s.
This is happening with 1080s that are not overclocked.
|
|
|
|
If I do this; wouldn't it also prevent a user from being able to reattach the usb to a windows pc to modify or copy their oneBash? I intentionally made the partition with oneBash a windows partition, to ensure that windows users could interact with it. I have no problem having an image that supports both usb and ssd; I thought it was best to direct users to use a USB key instead of an ssd in order to save users ~$30. I will ensure that I implement ssd support in the next version, as if you think it is important; others probably do as well. You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process. I will get to this eventually. Thanks for offer to build a playbook, I may take you up on that later. I have some ideas I want to implement which may make this unnecessary. I am currently only doing this in my freetime; soon I will go crypto fulltime (for the second time) and really get to work on this and other projects.  It would prevent them from being able to mount the Windows partition and edit directly. I'd suggest you consider making the onebash file available by itself for download. People can edit on Windows/Mac/etc, and then use scp to copy it to the mining rig. Setup would be - burn image to whatever. Once the machine starts - scp onebash, and go. BTW - I only used SSD's because I have a bunch of 30G ones laying around, and I'm impatient and like faster boot times. |
|
|
|
That is what I thought; just wanted to make sure I understood what you where suggesting. I didn't know I had to change ownership with chown; I have never been a *nix system administrator. I have some linux and unix experience (about 9 years); but most of it was very specialized, and generally limited to networking. I will add implementing your suggested changes and testing them out to the list of: testing Asus - PRIME Z270-A mobo improving amdOC beta lan management monitor / push / update app dynamically editing xorg.conf automatically modify / test expectless version of oneBash potentially if members want ( re-add ssd support )  There's no real reason SSD and USB support can't be the same image. The issue that makes the SSD special is the Windows partition. I'd recommend removing that and allow have the users edit the file once the mining machines starts. Then, the image supports both USB and small SSDs. You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process. |
|
|
|
@fullzero DM me - there's no reason to be using expect here. It looks like expect is used just to handle privilege escalation for commands. You can easily just make the script suid, or call out smaller scripts that need the extra privs. I'll try and update the script when I can - the coming week is a bit crazy though.
I know that expect is not meant to be used within bash, and there are much cleaner ways to handle privilege escalation. I want to avoid having oneBash call other scripts, keeping as much as possible within one bash script (oneBash). It would probably be easier to make oneBash suid; by this do you mean: sudo chmod 4750 '/media/m1/1263-A96E/oneBash' or sudo chmod u+s '/media/m1/1263-A96E/oneBash' ? I am always open to suggestions for improvements. I would also never claim to know everything about linux; which is good: because its fun to learn. [/quote] No criticism directed - you've done something VERY useful to the community. The fact you did so with little Unix experience is that more impressive! I'm just trying to help. Both of those commands do the same thing. Here's what you'd have to do: 1. sudo chown root /media/m1/1263-A96E/oneBash 2. sudo chmod u+s /media/m1/1263-A96E/oneBash 3. sudo chmod o+x /media/m1/1263-A96E/oneBash Now onebash is owned by root and executes with all of it's privs, and anyone on the system can execute the script. After doing that, you should be able to just delete the expect code that provides the password to elevate privs. The down side of this is that the miners now all run as root. To take care of that, chmod u+s to each mining program and make sure it is owned by the user m1 with chown m1 <miner_program>. Now, each of the miner programs should drop privs when they execute. This approach allows you to keep one big script - You should definitely confirm all of this. I'm in management now, and I'm not on the keyboard as much  |
|
|
|
For the benefit of others using a SSD, the windows partition is not automatically mounted. It is /dev/sda1 and it's type is MSDOS. You can mount it with the followng command: mount -t msdos /dev/sda1 /media/m1/1263-A96E To have it automount at boot time, you'll have to edit the /etc/fstab file. The easier option is just use dos2unix to remove the Windows' linefeeds from the file, and move it to a proper Unix partition. That's what I've done. @fullzero DM me - there's no reason to be using expect here. It looks like expect is used just to handle privilege escalation for commands. You can easily just make the script suid, or call out smaller scripts that need the extra privs. I'll try and update the script when I can - the coming week is a bit crazy though. |
|
|
|
So I was finally able to get nvOC going. A few hints for those that use Macs. 1. unzip will error out on the zip file. 2. tar will extract the file but it will be corrupt. I just unzipped on a PC, and burned there. As a side note, the images do work on 30GB SSD's as well. A couple of asks: please add openssh-server, and screen. The addition of both of those allows us old command line guys to still use it.  Finally - where is onebash on the file system? A find from '/' with wild cards couldn't find it. |
|
|
|
|
Following up my own post - some times three cards magically appear. But, mining always has one card at about 30 sols/s with three cards. Two cards there are no problems.
$ nvidia-smi
Wed May 24 16:44:53 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 381.09 Driver Version: 381.09 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 108... Off | 0000:01:00.0 On | N/A |
| 51% 73C P2 251W / 250W | 693MiB / 11171MiB | 99% Default |
+-------------------------------+----------------------+----------------------+
| 1 GeForce GTX 108... Off | 0000:03:00.0 Off | N/A |
| 0% 34C P2 68W / 250W | 674MiB / 11172MiB | 100% Default |
+-------------------------------+----------------------+----------------------+
| 2 GeForce GTX 108... Off | 0000:04:00.0 Off | N/A |
| 35% 64C P2 251W / 250W | 674MiB / 11172MiB | 99% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 1133 G /usr/bin/X 17MiB |
| 0 1328 C ./miner 663MiB |
| 1 1328 C ./miner 663MiB |
| 2 1328 C ./miner 663MiB |
+-----------------------------------------------------------------------------+
|
|
|
|
|
I've a H81-Pro BTC v2 with four 1080Ti cards in it running Ubuntu 16.04 and the latest NVIDIA drivers.
lspci shows all four boards:
$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
03:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
04:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
05:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
nvidia-smi only shows 2 boards:
$ nvidia-smi
Wed May 24 16:23:40 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 381.09 Driver Version: 381.09 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 108... Off | 0000:01:00.0 On | N/A |
| 0% 41C P8 11W / 250W | 20MiB / 11171MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 1 GeForce GTX 108... Off | 0000:04:00.0 Off | N/A |
| 0% 24C P8 8W / 250W | 1MiB / 11172MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 1135 G /usr/bin/X 17MiB |
+-----------------------------------------------------------------------------+
I've replaced the USB cable and riser as well as moved PCI slots, reset the CMOS etc etc.
Any ideas?
|
|
|
|
|
The zip image for the H81 appears corrupt. I can't unzip on a mac. It says the header is corrupted when I try to unzip - I downloaded twice.
Any chance you can post SHA256 hashes for the images?
|
|
|
|
Has anyone had luck getting the miner to run on GTX 1080 TI Founder's Edition?
This is my current configuration... Workers fail with no real error info...
Nvidia Driver: 381.22 (Ubuntu 16)
CUDA Version: 8.0.61
I'm using driver 378.13 on Ubuntu 16.04 server and headless with a 1080 Ti. It only uses as much memory as my 1080's so nearly half of the memory is unused. I suspect things could be massively improved on the card. I'm getting 650 sol/s on the card currently with stock settings. I have real issues with ewbf on Linux though. It will randomly crash and require a hard reset. It also takes a few hard resets to get all of the cards at full throttle. I'm slowly switching my NVIDIA boxes over to Windows. |
|
|
|
Anyone get the slowdown issue? I'm getting around 335-340 sol/s here with a palit gtx 1060 6gb (+90MHz core/780+MHz mem OC, running at 67-69C) but sometimes when I leave it for like 6+ hours it gets randomly slow down to 250~. restart my computer seems to solved it but pretty annoying tho when I have to monitor my PC like every hour.
Try using auto mouse clicker by murgee (Or any other automatic mouse clicker/mover) and set it to move your mouse every minute or so. It should hopefully keep your hashrate the same infinitely as long as the movement of the mouse is repeated. It worked for me and another guy. If not then you probably don't have the same issue that I had. I'm hoping @EWBF_ knows if the issue is with the miner or something windows related. Huh, pretty interesting issue on how and why this miner program don't like idling, lol. Maybe it's on windows side. Thanks man for the solution btw. You might be able to adjust the sleep settings as well. Tell the OS not to go to sleep etc.....might have the same effect. |
|
|
|
|
I've been using Linux with EWBF 0.3.3b, and it needs to be rebooted every 12+ hours or so. All the cards drop down to 0 Sol/s, and it takes a hard boot to clear things.
As a result, I've started to tinker with Win 10 Enterprise ver 1703 (latest). My motherboard is an Asrock H81 Pro v2 with 16GB of RAM. I've run 4+ AMD cards in this board with Linux. In Win10, I'm getting a 'code 43' when I add in a second card (geforce 1080 Ti).
I've turned off everything I can in the BIOS, and I've tried gen1 and auto for the PCI settings. I've also cleared CMOS. Nothing seems to allow me to use the second card.
I really don't want to continue using Linux (well I do but the care and feeding of a hard reboot at random times is annoying). Any ideas on how to get more cards accepted by the BIOS/OS?
|
|
|
|
Hello
I will like to comment, that , even when --pec is a good tool to give an idea of the efficiency, it is not exact at all.
for instance, a 1080 at minimum target power limit uses 100W, but eats 124 watts at the wall (with a gold rated PSU at 40% load)
so if you want real numbers, use a AC wattmeter, like the Kill-a-watt gadget, or better, because that is the real power you are paying for.
cheers
indkt.
Yes , but --pec is very good to compare cards. Maybe someone can paste --pec @gtx1080ti ? Here you go (stock settings) Temp: GPU0: 60C GPU0: 707 Sol/s Total speed: 707 Sol/s +-----+-------------+--------------+ | GPU | Power usage | Effecincy | +-----+-------------+--------------+ | 0 | 279W | 2.53 Sol/W | +-----+-------------+--------------+ Are you doing anything special to cool your card? I can't get mine under 81C with stock settings, and only 660 Sol/s with Linux. |
|
|
|
GPU will randomly halt, and then the rest of the gpu's seem to halt as well. A hard power cycle is needed to clear this as a reboot usually hangs.
Any clues - the log entry right before things die is shown below. There's nothing else in the log to indicate a problem prior.
ERROR: Looks like GPU3 are stopped. Restart attempt.
ERROR: Looks like GPU3 are stuck he not respond.
CUDA: Device: 4 Thread exited with code: 29
CUDA: Device: 2 Thread exited with code: 29
CUDA: Device: 1 Thread exited with code: 29
CUDA: Device: 0 Thread exited with code: 29
CUDA: Device: 5 Thread exited with code: 29
Temp: GPU0 75C GPU1 57C GPU2 59C GPU3 0C GPU4 55C GPU5 58C
GPU0: 655 Sol/s GPU1: 452 Sol/s GPU2: 494 Sol/s GPU3: 0 Sol/s GPU4: 500 Sol/s GPU5: 498 Sol/s
Total speed: 2599 Sol/s
Temp: GPU0 56C GPU1 46C GPU2 49C GPU3 0C GPU4 46C GPU5 48C
GPU0: 0 Sol/s GPU1: 0 Sol/s GPU2: 0 Sol/s GPU3: 0 Sol/s GPU4: 0 Sol/s GPU5: 0 Sol/s
Total speed: 0 Sol/s
Usually is a riser problem, or could be OC, p, 75C ?, insane temperature for GPU0 !! keep it below 70C if you want stability check GPU3 which says 0, that the driver that lost control of the GPU, i will start by replacing the riser of that card and lower your OC GPU0 is a 1080 Ti - they seem to run hot....lowest I've seen it has been 80C when running. |
|
|
|
|
GPU will randomly halt, and then the rest of the gpu's seem to halt as well. A hard power cycle is needed to clear this as a reboot usually hangs.
Any clues - the log entry right before things die is shown below. There's nothing else in the log to indicate a problem prior.
ERROR: Looks like GPU3 are stopped. Restart attempt.
ERROR: Looks like GPU3 are stuck he not respond.
CUDA: Device: 4 Thread exited with code: 29
CUDA: Device: 2 Thread exited with code: 29
CUDA: Device: 1 Thread exited with code: 29
CUDA: Device: 0 Thread exited with code: 29
CUDA: Device: 5 Thread exited with code: 29
Temp: GPU0 75C GPU1 57C GPU2 59C GPU3 0C GPU4 55C GPU5 58C
GPU0: 655 Sol/s GPU1: 452 Sol/s GPU2: 494 Sol/s GPU3: 0 Sol/s GPU4: 500 Sol/s GPU5: 498 Sol/s
Total speed: 2599 Sol/s
Temp: GPU0 56C GPU1 46C GPU2 49C GPU3 0C GPU4 46C GPU5 48C
GPU0: 0 Sol/s GPU1: 0 Sol/s GPU2: 0 Sol/s GPU3: 0 Sol/s GPU4: 0 Sol/s GPU5: 0 Sol/s
Total speed: 0 Sol/s
|
|
|
|
I've a new 1080 Ti to play around with and I've found a bug (mostly like in the NVIDIA Linux drivers) so I may be heading to Windows. Here's the kerenl bt
Mar 30 16:10:33 zcash3 kernel: [12308.114736] BUG: unable to handle kernel NULL pointer dereference at 0000000000000160
Mar 30 16:10:33 zcash3 kernel: [12308.114983] IP: [<ffffffffc18b0736>] _nv015951rm+0x1c6/0x2b0 [nvidia]
Mar 30 16:10:33 zcash3 kernel: [12308.115312] PGD 0
Mar 30 16:10:33 zcash3 kernel: [12308.115377] Oops: 0000 [#1] SMP
Mar 30 16:10:33 zcash3 kernel: [12308.115484] Modules linked in: nvidia_uvm(POE) snd_hda_codec_hdmi nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
kvm irqbypass snd_hda_codec_realtek serio_raw snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core mei_me snd_hwdep snd_pcm mei snd_timer snd lpc_ich soundcore shpchp tpm_infineon 8250_fintek mac_hid acpi_p
ad ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq lib
crc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd nouveau psmouse ahci mxm_wmi i2c_algo_bit libahci ttm drm_kms_he
lper syscopyarea sysfillrect sysimgblt fb_sys_fops alx drm mdio video wmi fjes
Mar 30 16:10:33 zcash3 kernel: [12308.118288] CPU: 0 PID: 1370 Comm: miner Tainted: P OE 4.4.0-71-generic #92-Ubuntu
Mar 30 16:10:33 zcash3 kernel: [12308.118553] Hardware name: MSI MS-7917/Z97 GAMING 5 (MS-7917), BIOS V1.13 02/16/2016
Mar 30 16:10:33 zcash3 kernel: [12308.118792] task: ffff88002b715400 ti: ffff8804a2ae0000 task.ti: ffff8804a2ae0000
Mar 30 16:10:33 zcash3 kernel: [12308.119023] RIP: 0010:[<ffffffffc18b0736>] [<ffffffffc18b0736>] _nv015951rm+0x1c6/0x2b0 [nvidia]
Mar 30 16:10:33 zcash3 kernel: [12308.124837] RSP: 0018:ffff8804a2ae39e0 EFLAGS: 00010246
Mar 30 16:10:33 zcash3 kernel: [12308.130505] RAX: 0000000000000000 RBX: ffff880482a12ea0 RCX: 00000001fe86cfff
Mar 30 16:10:33 zcash3 kernel: [12308.136322] RDX: 00000001fe86c000 RSI: 0000000000000000 RDI: ffff8804bb7d0008
Mar 30 16:10:33 zcash3 kernel: [12308.142085] RBP: ffff880482a12e68 R08: 0000000000000000 R09: 0000000000000001
Mar 30 16:10:33 zcash3 kernel: [12308.147813] R10: 0000000002020008 R11: ffffffffc1aaaf20 R12: ffff8804bb7d0008
Mar 30 16:10:33 zcash3 kernel: [12308.153497] R13: 0000000000000001 R14: 00000001fe86c000 R15: 0000000000001000
Mar 30 16:10:33 zcash3 kernel: [12308.159101] FS: 00007f7c45fff700(0000) GS:ffff8804cec00000(0000) knlGS:0000000000000000
Mar 30 16:10:33 zcash3 kernel: [12308.170096] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mar 30 16:10:33 zcash3 kernel: [12308.175759] CR2: 0000000000000160 CR3: 0000000001e0a000 CR4: 00000000001406f0
Mar 30 16:10:33 zcash3 kernel: [12308.181439] Stack:
Mar 30 16:10:33 zcash3 kernel: [12308.186928] 0000000000000000 00000000001fe86c ffff8804ba123008 ffff880482a12ff8
Mar 30 16:10:33 zcash3 kernel: [12308.197989] 0000000000000000 ffffffffc17fb890 ffff8804ba123008 00000000001fe86c
Mar 30 16:10:33 zcash3 kernel: [12308.209097] 0000000000000000 ffff880482a12ff8 ffff8804869a6608 ffffffffc1a9e5cd
Mar 30 16:10:33 zcash3 kernel: [12308.220213] Call Trace:
Mar 30 16:10:33 zcash3 kernel: [12308.225662] [<ffffffffc17fb890>] ? _nv010389rm+0xb0/0x270 [nvidia]
Mar 30 16:10:33 zcash3 kernel: [12308.231167] [<ffffffffc1a9e5cd>] ? _nv016944rm+0x6bd/0x700 [nvidia]
Mar 30 16:10:33 zcash3 kernel: [12308.236552] [<ffffffffc1a9eb90>] ? _nv016990rm+0x20/0xc0 [nvidia]
Mar 30 16:10:33 zcash3 kernel: [12308.241796] [<ffffffffc1b0e870>] ? rm_gpu_ops_stop_channel+0x120/0x140 [nvidia]
Mar 30 16:10:33 zcash3 kernel: [12308.252001] [<ffffffffc15554f1>] ? nvUvmInterfaceStopChannel+0x31/0x50 [nvidia]
Mar 30 16:10:33 zcash3 kernel: [12308.262244] [<ffffffffc07e4454>] ? uvm_user_channel_stop+0x34/0x40 [nvidia_uvm]
Mar 30 16:10:33 zcash3 kernel: [12308.272502] [<ffffffffc07b92ef>] ? uvm_va_space_stop_all_user_channels.part.7+0x6f/0xc0 [nvidia_uvm]
Mar 30 16:10:33 zcash3 kernel: [12308.282820] [<ffffffffc07ba6c3>] ? uvm_va_space_destroy+0x383/0x390 [nvidia_uvm]
Mar 30 16:10:33 zcash3 kernel: [12308.293238] [<ffffffffc07b06d1>] ? uvm_release+0x11/0x20 [nvidia_uvm]
Mar 30 16:10:33 zcash3 kernel: [12308.298613] [<ffffffff81210c44>] ? __fput+0xe4/0x220
Mar 30 16:10:33 zcash3 kernel: [12308.304003] [<ffffffff81210dbe>] ? ____fput+0xe/0x10
Mar 30 16:10:33 zcash3 kernel: [12308.309266] [<ffffffff8109f001>] ? task_work_run+0x81/0xa0
Mar 30 16:10:33 zcash3 kernel: [12308.314522] [<ffffffff81083fc1>] ? do_exit+0x2e1/0xb00
Mar 30 16:10:33 zcash3 kernel: [12308.319701] [<ffffffff812239a0>] ? poll_select_copy_remaining+0x140/0x140
Mar 30 16:10:33 zcash3 kernel: [12308.324856] [<ffffffff81084863>] ? do_group_exit+0x43/0xb0
Mar 30 16:10:33 zcash3 kernel: [12308.329957] [<ffffffff810909f2>] ? get_signal+0x292/0x600
Mar 30 16:10:33 zcash3 kernel: [12308.334992] [<ffffffff8102e567>] ? do_signal+0x37/0x6f0
Mar 30 16:10:33 zcash3 kernel: [12308.339929] [<ffffffff812239a0>] ? poll_select_copy_remaining+0x140/0x140
Mar 30 16:10:33 zcash3 kernel: [12308.344859] [<ffffffff812239a0>] ? poll_select_copy_remaining+0x140/0x140
Mar 30 16:10:33 zcash3 kernel: [12308.349596] [<ffffffff812239a0>] ? poll_select_copy_remaining+0x140/0x140
Mar 30 16:10:33 zcash3 kernel: [12308.354140] [<ffffffff8100320c>] ? exit_to_usermode_loop+0x8c/0xd0
Mar 30 16:10:33 zcash3 kernel: [12308.358581] [<ffffffff81003c6e>] ? syscall_return_slowpath+0x4e/0x60
Mar 30 16:10:33 zcash3 kernel: [12308.362931] [<ffffffff8183c7d0>] ? int_ret_from_sys_call+0x25/0x8f
Mar 30 16:10:33 zcash3 kernel: [12308.367182] Code: 0f 00 00 00 0f 84 d4 fe ff ff 48 8b 83 88 00 00 00 45 31 c0 48 85 c0 0f 85 c2 00 00 00 4c 89 f2 4b 8d 4c 3e ff 4c 89 c6 4c 89 e7 <41> ff 90 60 01 00 00 84 c0 8b 43
08 0f 94 c2 a9 00 00 00 01 0f
Mar 30 16:10:33 zcash3 kernel: [12308.380668] RIP [<ffffffffc18b0736>] _nv015951rm+0x1c6/0x2b0 [nvidia]
Mar 30 16:10:33 zcash3 kernel: [12308.385433] RSP <ffff8804a2ae39e0>
Mar 30 16:10:33 zcash3 kernel: [12308.389949] CR2: 0000000000000160
Mar 30 16:10:33 zcash3 kernel: [12308.400824] ---[ end trace 283780b61aeb276b ]---
This is definitely a driver issue with 378.13. Things would crash within a few hours. I reverted back to 375.39 and things have been stable for six hours. |
|
|
|
|
