I would like to know who wakes the kthread daemon up, when a read from the SD card is done using vfs_read.
According to the code flow the kthreadd will wake up the mmcqd (mmc_queue_thread) which will process the read/write requests to the SD driver.
The issue I am facing here is although the vfs_read to the SD card is called by the USB Mass Storage driver, the read does not proceed to the mmc_queue_thread. This leads to old contents of the SD card being shown on PC.
Here is the kernel stack after vfs_read generated from sdhci_send_command().
------------[ cut here ]------------
WARNING: at /vobs/iandroid/src/kernel/drivers/mmc/host/mx_sdhci.c:495 sdhci_send_command+0x120/0x758()
Modules linked in: g_mot_android mxc91341_oh_udc sipcttydrv aplogger coredump bploader sipcdrv mu_drv
[] (dump_stack+0x0/0x14) from [] (warn_slowpath+0x68/0x84)
[<c009cd3c>] (warn_slowpath+0x0/0x84) from [<c0249000>] (sdhci_send_command+0x120/0x758)
r3:00000033 r2:00000000
r7:c6605f04 r6:c6605f5c r5:c65305c0 r4:c0409510
[<c0248ee0>] (sdhci_send_command+0x0/0x758) from [<c0249a98>] (sdhci_request+0x188/0x1bc)
[<c0249910>] (sdhci_request+0x0/0x1bc) from [<c0240834>] (mmc_wait_for_req+0x110/0x128)
r8:c656f870 r7:c6605dc8 r6:00000000 r5:c6530400 r4:c6605ef0
[<c0240724>] (mmc_wait_for_req+0x0/0x128) from [<c02479f8>] (mmc_blk_issue_rq+0x1f4/0x7b0)
r7:c642ae00 r6:00000000 r5:c64daeac r4:c64daea0
[<c0247804>] (mmc_blk_issue_rq+0x0/0x7b0) from [<c0248464>] (mmc_queue_thread+0x134/0x154)
[<c0248330>] (mmc_queue_thread+0x0/0x154) from [<c00b2e88>] (kthread+0x54/0x80)
r8:00000000 r7:00000000 r6:00000000 r5:c0248330 r4:fffffffc
[<c00b2e34>] (kthread+0x0/0x80) from [<c009f3a8>] (do_exit+0x0/0x738)
r5:00000000 r4:00000000
---[ end trace 24b57c573e7a44e3 ]---
Related
I am aiming on GPU-mining Ethereum on a Windows 10 PC with 2 Radeon RX590.
geth version is
1.9.9-stable-01744997
cmd call to start geth:
geth --rpc --syncmode "fast" --cache 4096 --etherbase [ADR] --datadir "[MyDataDir]" --mine --minerthreads 0
Blockchain is up to date and everything seems fine on the geth side.
Used Miner is
Claymore's Dual GPU Miner - v15.0
cmd to start miner:
EthDcrMiner64.exe -epool http://127.0.0.1:8545 -mode 1 -tt 75
Now the miner starts and seems to start mining. GPU's show they are doing massive work.
Once the miner is initiated it only permanently outputs something like this (plus every once in a while some GPU info):
ETH: 12/21/19-15:46:33 - New job from 127.0.0.1:8545
ETH - Total Speed: 21.345 Mh/s, Total Shares: 0, Rejected: 0, Time: 45:52
ETH: GPU0 10.665 Mh/s, GPU1 10.680 Mh/s
So this looks good.
In the geth console meanwhile I get this output:
INFO [12-21|15:46:35.446] Imported new chain segment blocks=1 txs=74 mgas=9.921 elapsed=159.999ms mgasps=62.007 number=9141165 hash=05972d…032349 dirty=1019.58MiB
INFO [12-21|15:46:35.459] Commit new mining work number=9141166 sealhash=35129c…59de27 uncles=0 txs=0 gas=0 fees=0 elapsed=999.3µs
INFO [12-21|15:46:35.720] Commit new mining work number=9141166 sealhash=3788e2…df83fc uncles=0 txs=39 gas=9922304 fees=0.0347883012 elapsed=261.998ms
WARN [12-21|15:46:36.032] Served eth_submitHashrate conn=127.0.0.1:54083 reqid=6 t=0s err="the method eth_submitHashrate does not exist/is not available"
INFO [12-21|15:46:38.548] Commit new mining work number=9141166 sealhash=7451f4…69a431 uncles=0 txs=72 gas=9911680 fees=0.04369322037 elapsed=89.942ms
WARN [12-21|15:46:41.120] Served eth_submitHashrate conn=127.0.0.1:54083 reqid=6 t=0s err="the method eth_submitHashrate does not exist/is not available"
There is this warning/error message:
err="the method eth_submitHashrate does not exist/is not available"
But also it states "Commit new mining work".
I am quite unsure now.
Do I mine or do I only waste electric power as the work is never commited?
You have not connected to any mining pools, only to your own geth node, meaning that you are mining alone and competing against the whole world. When mining solo, you have no shares. You either mine a whole block or get nothing. It is extremely hard to mine all alone, thus it is advised to join a mining pool. Claymore-Dual-Miner (CDM) has a list of available mining pool alternatives.
Also, when mining solo with CDM, you can miss mined messages because in this mode, it uses HTTP protocol instead of the Stratum pool protocol. You can manually check your balance on etherscan at any time, though.
Use PhoenixMiner 5e with -rate 2 command. It will stop showing this error.
I am trying to establish a bluetooth serial communication link between a Raspberry Pi Zero W, running Raspbian Jessie [03-07-2017], and an Arduino (UNO).
I am currently able to write data to the Arduino using bluetoothctl.
The application requires that we are able to write data to a particular BLE Slave. There are multiple [HM-10] Slaves to switch between, the Slave needs to be chosen during the program execution.
There is no BAUD rate preference. Currently, we are using 9600 universally.
Functions have been created that automatically connect and then write data to an "attribute", this shows up as data on the Serial Monitor of the Arduino.
Python Code - using BlueZ 5.44 (manually installed):
import subprocess
from subprocess import Popen, PIPE
# Replaces the ':' with '_' to allow the MacAddress to be in the form
# of a "Path" when "selecting an attribute"
def changeMacAddr(word):
return ''.join(c if c != ':' else '_' for c in word)
# Connects to a given MacAddress and then selects the attribute to write to
def connBT(BTsubProcess, stringMacAddr):
BTsubProcess.stdin.write(bytes("".join("connect "+stringMacAddr +"\n"), "utf-8"))
BTsubProcess.stdin.flush()
time.sleep(2)
stringFormat = changeMacAddr(stringMacAddr)
BTsubProcess.stdin.write(bytes("".join("select-attribute /org/bluez/hci0/dev_"
+ stringFormat +
"/service0010/char0011" + "\n"), "utf-8"))
BTsubProcess.stdin.flush()
# Can only be run once connBT has run - writes the data in a list [must have numbers 0 - 255 ]
def writeBT(BTsubProcess, listOfData):
stringList = [str('{0} ').format(elem) for elem in listOfData]
BTsubProcess.stdin.write(bytes("".join("write " + "".join(stringList) + "\n"), "utf-8"))
BTsubProcess.stdin.flush()
# Disconnects
def clostBT(BTsubProcess):
BTsubProcess.communicate(bytes("disconnect\n", "utf-8"))
# To use the functions a subprocess "instance" of bluetoothctl must be made
blt = subprocess.Popen(["bluetoothctl"], stdin=subprocess.PIPE, shell=True)
# blt with then be passed into the function for BTsubProcess
# Note: the MacAddresses of the Bluetooth modules were pre-connected and trusted manually via bluetoothctl
This method works fine for small sets of data, but my requirements require me to stream data to the Arduino very quickly.
The current set up is:
Sensor data (accelerometer, EEG) via USB serial is received by the Pi
The Pi processes the data
Commands are then sent to the Arduino via the in built bluetooth of the Pi Zero W
However, while using this method the bluetooth data transmission would delay (temporarily freeze) when the sensor data changed.
The data transmission was flawless when using two pre-paired HM-10 modules, the Pi's GPIO serial port was configured using PySerial.
The following methods have also been tried:
Using WiringPi to set-up a bluetooth serial port on the /dev/ttyAMA0
using Python sockets and rfcomm
When attempting to use both of these methods. The Python code compiles, however, once the Serial Port is opened the data is seemingly not written and does not show up on the Arduino's Serial Monitor.
This then cripples the previous functions. Even when using bluetoothctl manually, the module cannot be unpaired/disconnected. Writing to the appropriate attribute does not work either.
A restart is required to regain normal function.
Is this approach correct?
Is there a better way to send data over BLE?
UPDATE: 05/07/2017
I am no longer working on this project. But troubleshooting has led me to believe that a "race condition" in the code may have led to the program not functioning as intended.
This was verified during the testing phase where a more barebones code was created that functioned very well.
I'm using a mellanox Infiniband card MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] with mlnx-ofed-kernel-3.1 on a linux kernel version 3.13.0.
When the card is connected to another one and configured (ibstat said both cards are active in the infiniband link layer), I experimented that every 9 seconds the card send 8 interrupts consisting of 4 pairs of event type MLX4_EVENT_TYPE_COMP and MLX4_EVENT_TYPE_CMD.
I also noticed that If I modify the function mlx4_interrupt code (which is the interrupt handler in the mlnx-ofed-kernel-3.1) to avoid it to handle those two interrupts events, the completion queues are immedialty destroy which directly cause further data transfers on the infiniband card to fail.
My question is what are the purpose of those interrupt events and MLX4_EVENT_TYPE_COMP and MLX4_EVENT_TYPE_CMD and why are they mandatory to keep queue pair available ?
Here are the codes called by each of those interrupt event in drivers/net/ethernet/mellanox/mlx4/eq.c
MLX4_EVENT_TYPE_COMP :
cqn = be32_to_cpu(eqe->event.comp.cqn) & 0xffffff;
mlx4_cq_completion(dev, cqn);
MLX4_EVENT_TYPE_CMD :
mlx4_cmd_event(dev, be16_to_cpu(eqe->event.cmd.token), eqe->event.cmd.status, be64_to_cpu(eqe->event.cmd.out_param));
I have some experience of StdPeriph libraries usage for programming stm32. But now I tried STM32Cube HAL with STM32CubeMX code generator. I generated a project with this options:
Middleware: FreeRTOS and FatFS via SDIO
Compiler is GCC
stm32f103ret6 MCU
I imported generated code to Eclipse environment. I made a binary and flashed it with "st-flash write ..." as usual. My test program successfuly wrote to USART1 "Hello" in cycle - this is no problem. But then, when I tried to flash another code, it failed with "unknown chip id". If I manually connect NRST to GND, st-flash gives:
...Flash: 0 bytes (0 KiB) in pages of 2048 bytes
Full output:
2015-06-14T16:07:29 INFO src/stlink-common.c: Loading device parameters....
2015-06-14T16:07:29 INFO src/stlink-common.c: Device connected is: F1 High-density device, id 0x10036414
2015-06-14T16:07:29 INFO src/stlink-common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0 bytes (0 KiB) in pages of 2048 bytes
I tried to use ST-Link Utility from Windows, but it cannot connect to this MCU to change option bytes (connection to another devices with stm32 works well).
I tried to flash through USART1, but it failed.
Source code I flashed, of course, does not contain any read/write protection enabling. I tried 2 another MCU, but this error was reproduced.
How can I unbrick by MCUs and flash anything?
I found a root cause!
This is a HAL initialization function, generated by STM32CubeMX:
void HAL_MspInit(void)
{
/* USER CODE BEGIN MspInit 0 */
/* USER CODE END MspInit 0 */
__HAL_RCC_AFIO_CLK_ENABLE();
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
/* System interrupt init*/
/* SysTick_IRQn interrupt configuration */
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
/**DISABLE: JTAG-DP Disabled and SW-DP Disabled
*/
__HAL_AFIO_REMAP_SWJ_DISABLE();
/* USER CODE BEGIN MspInit 1 */
/* USER CODE END MspInit 1 */
}
I didn't notice this simple lines!
/**DISABLE: JTAG-DP Disabled and SW-DP Disabled
*/
__HAL_AFIO_REMAP_SWJ_DISABLE();
This macros totally disables SWD and JTAG programming, look at stm321xx_hal_gpio_ex.h:
#define __HAL_AFIO_REMAP_SWJ_DISABLE() MODIFY_REG(AFIO->MAPR, AFIO_MAPR_SWJ_CFG, AFIO_MAPR_SWJ_CFG_DISABLE)
I didn't found any checkbox in CubeMX to disable/enable SWD/JTAG, so this is the only behavior of code generator! Pay attention to this point when using STM32CubeMX!
If you set the pin assignments for the JTAG/SWD pins correctly (e.g. SYS_JTDI, SYS_JTDO-TRACESWO, etc.) on the pinout tab of STM32CubeMX, the generated code will not disable JTAG/SWD.
It's (BURIED) under Pinout | SYS | Debug of STM32CubeMX...set to Serial Wire or whatever.
I have a instance (F1-Micro) and a root persistent disk (10GB) on Google Cloud, Compute Engine service. When I start an instance and attach a disk in READ_WRITE the instance starts normally, executes my startup script and I can access through SSH. However, when I change the disk mode parameter to READ_ONLY the instance apparently starts normally and I can't do SSH giving me a timeout connection. Also, my startup script does not start. I suspect that or I need to attach more one root persistent disk with READ_WRITE permission or I need to setup some configuration in my disk. Someone could give me insight about what are happening? Below I give some data and logs:
Body Request:
instance = {
'name': instance_name,
'machineType': machine_type_url,
'disks': [{
'index' : 0,
'autoDelete': 'false',
'boot': 'true',
'type': 'PERSISTENT',
'mode' : 'READ_ONLY', # READ_ONLY, READ_WRITE
'deviceName' : root_disk_name,
'source' : source_root_disk
}],
'networkInterfaces': [{
'accessConfigs': [{
'type': 'ONE_TO_ONE_NAT',
'name': 'External NAT'
}],
'network': network_url
}],
'serviceAccounts': [{
'email': service_email,
'scopes': scopes
}]
}
Log of started instance on GC-CE:
Changing serial settings was 0/0 now 3/0
Start bios (version 1.7.2-20131007_152402-google)
No Xen hypervisor found.
Unable to unlock ram - bridge not found
Ram Size=0x26600000 (0x0000000000000000 high)
Relocating low data from 0x000e10a0 to 0x000ef780 (size 2161)
Relocating init from 0x000e1911 to 0x265d07a0 (size 63291)
CPU Mhz=2601
=== PCI bus & bridge init ===
PCI: pci_bios_init_bus_rec bus = 0x0
=== PCI device probing ===
Found 4 PCI devices (max PCI bus is 00)
=== PCI new allocation pass #1 ===
PCI: check devices
=== PCI new allocation pass #2 ===
PCI: map device bdf=00:03.0 bar 0, addr 0000c000, size 00000040 [io]
PCI: map device bdf=00:04.0 bar 0, addr 0000c040, size 00000040 [io]
PCI: map device bdf=00:04.0 bar 1, addr febff000, size 00001000 [mem]
PCI: init bdf=00:01.0 id=8086:7110
PIIX3/PIIX4 init: elcr=00 0c
PCI: init bdf=00:01.3 id=8086:7113
Using pmtimer, ioport 0xb008, freq 3579 kHz
PCI: init bdf=00:03.0 id=1af4:1004
PCI: init bdf=00:04.0 id=1af4:1000
Found 1 cpu(s) max supported 1 cpu(s)
MP table addr=0x000fdaf0 MPC table addr=0x000fdb00 size=240
SMBIOS ptr=0x000fdad0 table=0x000fd9c0 size=269
Memory hotplug not enabled. [MHPE=0xffffffff]
ACPI DSDT=0x265fe1f0
ACPI tables: RSDP=0x000fd990 RSDT=0x265fe1c0
Scan for VGA option rom
WARNING - Timeout at i8042_flush:68!
All threads complete.
Found 0 lpt ports
Found 0 serial ports
found virtio-scsi at 0:3
Searching bootorder for: /pci#i0cf8/*#3/*#0/*#0,0
Searching bootorder for: /pci#i0cf8/*#3/*#0/*#1,0
virtio-scsi vendor='Google' product='PersistentDisk' rev='1' type=0 removable=0
virtio-scsi blksize=512 sectors=20971520
Searching bootorder for: /pci#i0cf8/*#3/*#0/*#2,0
...
Searching bootorder for: /pci#i0cf8/*#3/*#0/*#255,0
Scan for option roms
Searching bootorder for: HALT
drive 0x000fd950: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=20971520
Space available for UMB: 000c0000-000eb800
Returned 122880 bytes of ZoneHigh
e820 map has 6 items:
0: 0000000000000000 - 000000000009fc00 = 1 RAM
1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
3: 0000000000100000 - 00000000265fe000 = 1 RAM
4: 00000000265fe000 - 0000000026600000 = 2 RESERVED
5: 00000000fffbc000 - 0000000100000000 = 2 RESERVED
Unable to lock ram - bridge not found
Changing serial settings was 3/2 now 3/0
enter handle_19:
NULL
Booting from Hard Disk...
Booting from 0000:7c00
[ 1.386940] i8042: No controller found
Loading, please wait...
INIT: version 2.88 booting
[[36minfo[39;49m] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevd[?25l[?1c7[1G[[32m ok [39;49m8[?25h[?0c.
[....] Synthesizing the initial hotplug events...[?25l[?1c7[1G[[32m ok [39;49m8[?25h[?0cdone.
[....] Waiting for /dev to be fully populated...[ 8.524814] piix4_smbus 0000:00:01.3: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr
[?25l[?1c7[1G[[32m ok [39;49m8[?25h[?0cdone.
[....] Activating swap...[?25l[?1c7[1G[[32m ok [39;49m8[?25h[?0cdone.
[....] Checking root file system...fsck from util-linux 2.20.1
fsck.ext4: Operation not permitted while trying to open /dev/sda1
You must have r/w access to the filesystem or be root
fsck died with exit status 8
[?25l[?1c7[1G[[31mFAIL[39;49m8[?25h[?0c[31mfailed (code 8).[39;49m
[....] An automatic file system check (fsck) of the root filesystem failed. A manual fsck must be performed, then the system restarted. The fsck should be performed in maintenance mode with the root filesystem mounted in read-only mode. ...[?25l[?1c7[1G[[31mFAIL[39;49m8[? 25h[?0c [31mfailed![39;49m
[....] The root filesystem is currently mounted in read-only mode. A maintenance shell will now be started. After performing system maintenance, press CONTROL-D to terminate the maintenance shell and restart the system. ...[?25l[?1c7[1G[[33mwarn[39;49m8[?25h[?0c [33m(warning).[39;49m
sulogin: root account is locked, starting shell
root#localhost:~#
Thanks!
You're correct in assuming that the boot disk for a GCE instance needs to appear in read-write mode. The documentation for root persistent disks says:
To start an instance with an existing root persistent disk in gcutil,
provide the boot parameter when you attach the disk. When you create a
root persistent disk using a Google-provided image, you must attach it
to your instance in read-write mode. If you try to attach it in
read-only mode, your instance may be created successfully, but it
won't boot up correctly.