I follow this link
Install into a virtual environment
01 I create venv /home/evol/pyq
02 source /home/evol/pyq/bin/active
03 Download l64.zip to /home/evol/pyq/q
04 Copy license to /home/evol/pyq/q
05 The q folder is
06 Set activate file add code echo "export QLIC=/home/evol/pyq/bin" >> ${pyq}/bin/activate
07 source ${pyq}/bin/activate
08 pip install pyq
So i can`t install pyq
error
what`s problem ? how do i do ? thanks all
Related
Upgraded fedora33 lately and found my cephfs mounts won't work anymore. After hours of debugging and looking around, I realized a new kernel 5.11.X was installed. Before I had 5.10.X. Did reboot with 5.10 and everything was fine. To verify the kernel version is the problem I installed a recent ubuntu 21.04 with kernel 5.11.0: showed the same problem. Now I have fixed my kernel to boot to 5.10 and I can live with that, but there seems to be a serious problem with > 5.10 kernels.
I'm using octopus. Any ideas?
Adding ms_mode=legacy does not help.
When I try to mount I get lot's of kernel logs starting with:
Apr 26 09:22:15 ubuntu kernel: libceph: no match of type 2 in addrvec
Apr 26 09:22:15 ubuntu kernel: libceph: corrupt full osdmap (-2) epoch 64001 off 3154 (0000000073edcb82 of 00000000aaa67e88-00000000ea93de62)
Apr 26 09:22:15 ubuntu kernel: osdmap: 00000000: 08 07 72 20 00 00 09 01 9e 12 00 00 86 bb d6 c5 ..r ............
Apr 26 09:22:15 ubuntu kernel: osdmap: 00000010: ae 96 4c 78 8a 5e 50 62 3f 0a e5 24 01 fa 00 00 ..Lx.^Pb?..$....
Apr 26 09:22:15 ubuntu kernel: osdmap: 00000020: 54 f0 53 5d 3a fd ae 0e 3e ea 85 60 07 ab 94 2b T.S]:...>..`...+
Apr 26 09:22:15 ubuntu kernel: osdmap: 00000030: 06 00 00 00 02 00 00 00 00 00 00 00 1d 05 44 01 ..............D.
Apr 26 09:22:15 ubuntu kernel: osdmap: 00000040: 00 00 01 02 02 02 20 00 00 00 20 00 00 00 00 00 ...... ... .....
.....
Apr 26 09:22:15 ubuntu kernel: libceph: osdc handle_map corrupt msg
....
Magnus
I can confirm this. I'm booting my linux with 5.10.X and it works well but when I switch to the 5.11.X I have the corrupt message and cannot attach my rbd volumes.
Something is wrong with it. Can you open an issue to ceph and post here the issue, please?
I'm porting the lirc_serial kernel module to work on our embedded board. We only need to implement the IR transmitter function.
For only the transmitter, the custom driver need only control the RTS pin on /dev/ttyS0, from within the module.
On standard hardware, the driver loads:
00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
NEW APPROACH
I have not figured out how to deactivate the current driver for the serial port, so rather than create a new driver, how would you use the current 8250-dw driver to change the RTS pin on behalf of my kernel module? Something like this?
Using line disciplines per this article on the slip driver looked promising, Just take slip.c and remove the network side of the code. But it needs a user space program (slattach or dip) to open /dev/ttyS0 and activate the line discipline.
Is that possible (or a good idea) from within a kernel module?
In this similar question, How do I open/write/read a uart device from a kernel module?, Ian Abbott suggested backporting serdev to kernel 4.9.
That's getting a bit involved and we're already behind schedule. Is there an easier way?
ORIGINAL QUESTION
However, the embedded board (based on the BayTrail Atom E3845) has the serial port controller in memory mapped I/O:
80860F0A:00: ttyS0 at MMIO 0x90a0c000 (irq = 39, base_baud = 2764800) is a 16550A
80860F0A:01: ttyS1 at MMIO 0x90a0e000 (irq = 40, base_baud = 2764800) is a 16550A
I'm new to driver development. I guess 0x90a0c000 is the physical address of the controller?
To probe the module, I first remapped 0x90a0c000 to a virtual address using ioremap_nocache and then tried to reserve the memory using request_mem_region. That failed.
ioVirtBase = ioremap_nocache(iommap, 8);
TQTRACE("ecp_serial_probe: devm_ioremap for MMIO 0x%X returned 0x%X\n", (uint32_t)iommap, (uint32_t)ioVirtBase);
if (ioVirtBase != NULL)
{
tqDumpBuffer(ioVirtBase, 8);
}
tqRes = request_mem_region((uint32_t)ioVirtBase, 8, ECP_DRIVER_NAME);
TQTRACE("ecp_serial_probe: request_mem_region for 0x%X returned 0x%X\n", (uint32_t)ioVirtBase, (uint32_t)tqRes);
if (!tqRes)
{
TQTRACE("ecp_serial_probe: Cannot request memory at 0x%X\n", (uint32_t)iommap);
return -ENXIO;
}
Is this the correct order of the functions?
Also, it seems request_mem_region fails because the device is under control of 80860F0A ?? There is no such entry in lsmod but there is an entry in /sys/devices.
Do I need to unload that driver to control the USART? How?
# ls -l /sys/devices/platform/80860F0A\:00
lrwxrwxrwx 1 root root 0 Jul 8 23:30 driver -> ../../../bus/platform/drivers/dw-apb-uart
-rw-r--r-- 1 root root 4096 Jul 9 17:02 driver_override
lrwxrwxrwx 1 root root 0 Jul 9 17:14 firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/80860F0A:00
-r--r--r-- 1 root root 4096 Jul 9 17:02 modalias
drwxr-xr-x 2 root root 0 Jul 9 17:02 power
lrwxrwxrwx 1 root root 0 Jul 8 23:30 subsystem -> ../../../bus/platform
drwxr-xr-x 3 root root 0 Jul 8 23:30 tty
-rw-r--r-- 1 root root 4096 Jul 9 17:02 uevent
drwxr-xr-x 3 root root 0 Jul 8 23:30 VCOM0001:00
dmesg output below. Dumping the data at the remapped virtual address is not consistent. Sometimes all 0xFF, other times, 00 00 00 00 41 02 1C 48. I don't understand that either...
MARK Tue Jul 9 17:45:35 SGT 2019
ecp_serial: ecp_serial_exit_module()
Spectre V2 : System may be vulnerable to spectre v2
ecp_serial: loading module not compiled with retpoline compiler.
ecp_serial: ecp_serial_init_module()
ecp_serial: ecp_serial_init()
ecp_serial: ecp_serial_probe() iommap=0x90A0C000
ecp_serial: ecp_serial_probe: devm_ioremap for MMIO 0x90A0C000 returned 0xE3296000
ecp_serial: Dump address 0xE3296000:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0000 FF FF FF FF FF FF FF FF
ecp_serial: ecp_serial_probe: request_mem_region for 0xE3296000 returned 0x0
ecp_serial: ecp_serial_probe: Cannot request memory at 0x90A0C000
platform ecp_serial.0: lirc_dev: driver ecp_serial registered at minor = 0
MARK Tue Jul 9 17:46:08 SGT 2019
ecp_serial: ecp_serial_exit_module()
Spectre V2 : System may be vulnerable to spectre v2
ecp_serial: loading module not compiled with retpoline compiler.
ecp_serial: ecp_serial_init_module()
ecp_serial: ecp_serial_init()
ecp_serial: ecp_serial_probe() iommap=0x90A0C000
ecp_serial: ecp_serial_probe: devm_ioremap for MMIO 0x90A0C000 returned 0xE32A2000
ecp_serial: Dump address 0xE32A2000:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0000 00 00 00 00 41 02 1C 48
ecp_serial: ecp_serial_probe: request_mem_region for 0xE32A2000 returned 0x0
ecp_serial: ecp_serial_probe: Cannot request memory at 0x90A0C000
platform ecp_serial.0: lirc_dev: driver ecp_serial registered at minor = 0
What proc/iomem has to say
90a0c000-90a0cfff : 80860F0A:00
90a0e000-90a0efff : 80860F0A:01
So indeed, the memory is under control of another driver... But how to unload it if it is not listed in lsmod ?
# rmmod 80860F0A:00
ERROR: Module 80860F0A:00 does not exist in /proc/modules
# rmmod 80860F0A
ERROR: Module 80860F0A does not exist in /proc/modules
OS INFO
# uname -a
Linux ecp 4.4.127-1.el6.elrepo.i686 #1 SMP Sun Apr 8 09:44:43 EDT 2018 i686 i686 i386 GNU/Linux
# cat /etc/centos-release
CentOS release 6.6 (Final)
sorry if this is not the right forum for this question but I
can't find the answer anywhere. I'm working on a raspberry pi project
which requires the SPI module to be loaded. I can't get it to load.
Here's what I've done
sudo apt-get update
sudo apt-get upgrade
sudo rpi-update
Here's what my blacklist.conf file looks like
#blacklist spi and i2c by default (many users don't need them)
#blacklist spi-bcm2708
blacklist i2c-bcm2708
I've rebooted several times with no luck. When I run sudo uname -a I get
Linux raspberrypi 3.18.5+ #744 PREEMPT Fri Jan 30 18:19:07 GMT2015 armv6l GNU/Linux
See http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=97314
Fixed my i2c and one-wire interfaces.
This is required with the new kernal upgrade to 3.18.5 on Jan 21st.
You should have it enabled. You did not specify how you test if it works.
What I suggest
Check if you have it enabled using lsmod | grep spi_ or ls -al /dev/spi*
If it does not work in your program try sudo adduser pi spi (if you use the pi user)
a) Download http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/spi/spidev_test.c
b) compile it with gcc spidev_test.c -o spidev_test. If you get compilation error try downloading this file and compiling it: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/spi/spidev_test.c?id=95b1ed2ac7ffe3205afc6f5a20320fbdb984da92 (it is older version of this file)
c) shorten your MOSI and MISO pins on your Raspberry ( http://neophob.com/wp-content/uploads/2012/08/254px-GPIOs.png pins 9 and 10 on this schematics, but please double check what pins you should shorten on schematics for your raspberry)
d) run the compiled program sudo ./spidev_test -D /dev/spidev0.0
e) if it returns
FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D
it works and you might have some issue with your program or with connection to some other device.
This is driving me crazy. I have CentOS 5.5 installed running KDE desktop. I have an NEC 3550 DVDRW drive on /dev/hda. When I put in a DVD, I want it to automount it and provide an icon on the desktop, as well as under /media mount point. It will not automount. Automount is running. HALD is running. Drive is on /dev/hda. It is NOT listed in /etc/fstab. There is NOT a remove policy setup for hald-addon-storage for polling. I can read from the drive using dd. K3B burn utility can see the drive and read disk info. Running eject and eject -t ejects the drive ok.
I cannot mount from the command line. Says:
mount: block device /dev/hda is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/hda,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
dmesg says:
ide: failed opcode was: unknown
ATAPI device hda:
Error: Illegal request -- (Sense key=0x05)
Cannot read medium - incompatible format -- (asc=0x30, ascq=0x02)
The failed "Read Subchannel" packet command was:
"42 02 40 01 00 00 00 00 10 00 00 00 00 00 00 00 "
hfs: unable to parse mount options
attempt to access beyond end of device
hda: rw=0, want=68, limit=4
isofs_fill_super: bread failed, dev=hda, iso_blknum=16, block=16
To me, seems like some kind of media format issue, but I have no idea. Ideas?
no real solution, started working on its own.
I followed this guide to implementing build numbers in an XCode iPhone project (guide).
I tried it and I am getting the wrong build number when NSLogging. It's not updating correctly and is always one or two numbers behind the info.plist. I need it to be the same number. Anyone know why this is happening?
i.e "[[[NSBundle mainBundle] infoDictionary] objectForKey:#"CFBuildNumber"]" is not the same as the plist's CFBuildNumber.
The script is set to run first, before copy bundle resources and everything. This is the output and info.plist numbers I get:
Application Version: 1.0 Build No: 52 Build Date: Wed Nov 10 15:10:05 CET 2010
(info.plist is build number: 54 and date: Wed Nov 10 15:10:43 CET 2010)
Application Version: 1.0 Build No: 54 Build Date: Wed Nov 10 15:10:43 CET 2010
(info.plist is build number: 55 and date: Wed Nov 10 15:12:54 CET 2010)
Application Version: 1.0 Build No: 54 Build Date: Wed Nov 10 15:10:43 CET 2010
(info.plist is build number: 56 and date: Wed Nov 10 15:13:49 CET 2010)
Application Version: 1.0 Build No: 56 Build Date: Wed Nov 10 15:13:49 CET 2010
(info.plist is build number: 57 and date:Wed Nov 10 15:14:46 CET 2010)
It seems to follow this pattern throughout. So continuing it would be 56 (real 58), 58 (real 59), 58 (real 60), 60 (real 61), 60 real (62), 62 (real 63) etc. etc.
The script (that is set to run before everything else) is:
#!/bin/bash
# Auto Increment Version Script
buildPlist="Project-Info.plist"
CFBuildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBuildNumber" $buildPlist)
CFBuildNumber=$(($CFBuildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBuildNumber $CFBuildNumber" $buildPlist
CFBuildDate=$(date)
/usr/libexec/PlistBuddy -c "Set :CFBuildDate $CFBuildDate" $buildPlist
Because project's Info.plist processed prior to 'Run Script' phase. See 'Build results' window in XCode. To resolve this you should
1) Create new target with type "Run script only" and configure it to update version number
2) Create new target with type "Aggregate" and add to it "Version update" target and "you product" target.
So when you build "Aggregate" target, at first step - version will be updated, and at second step - your product.
I ended up using the already-copied plist file, ${TARGET_BUILD_DIR}/${INFOPLIST_PATH}, and placing the "copy bundle resources"-phase before the script runs instead. That way the number will always be synchronized.