I am trying short.c in examples of Linux Device Driver 3
My PC has Parallel Port and after the Ubuntu boots up, I can see these:
cat /proc/ioports
0378-037a : parport0
037b-037f : parport0
outp 0x378 1
(outp is another example in LDD3 which write data to ports)
the LED on the port is ON.
Then I run these commands to remove modules
rmmod lp
rmmod parport_pc
cat /proc/ioports
(There is no module on 0378-037f any more.)
I run this again but the LED is not ON this time.
outp 0x378 1
Then I install short.ko and request_region() succeeds.
cat /proc/ioports
0378-037f : short
cat /proc/devices
249 short
outp 0x378 1
the LED is not ON this time either.
I tried these too, but same result (LED is not ON)
mknod /dev/short0 c 249 0
echo -n "a" > /dev/short0
"a" is 0x61 so that the last bit is 1.
Why can I not write data out though I have got the I/O region?
Thanks for your answer.
Finally, I found the solution.
Make sure the “parport” module is not loaded or compiled into your kernel. It is not enough to simply unload the parport module, as it leaves the ports in an inconsistent state. You must reboot the machine and keep the parport and all related modules/code from loading in the first place.
One way to do this is to edit the /etc/modprobe.d/blacklist.conf file and add the following lines:
blacklist ppdev
blacklist lp
blacklist parport_pc
blacklist parport
It seems that partport has modify the mode of parallel port.
And if cups is installed, you should modify /etc/modules-load.d/cups-filters.conf:
#lp
#ppdev
#parport_pc
Related
In config I have used
dtoverlay=pi3-miniuart-bt
I still want to use the bluetooth connection
How do I set bluetooth to use ttyS0 instead of ttyAMA0
A doc stated
It is also necessary to edit /lib/systemd/system/hciuart.service and replace ttyAMA0 with ttyS0
But there is no such thing as ttyAMA0 in the hciuart.service
If you have properly changed /boot/config.txt file and later rebooted your RPi, your Bluetooth should automatically be using ttyS0. You can check that by running
ls -l /dev
and looking for a line saying
serial1 -> ttyS0
If serial1 does not appear to be mapped to ttyS0, then I recommend checking if this line
dtoverlay=pi3-miniuart-bt
is a right choice for your Raspberry Pi Zero. It has proved to work well for RPi 3&4, but you need to look it up if it is right also for the Zero.
I've been trying to get GPIO-Poweroff to switch off the board PSU using GPIO but no matter what I try, it never seems to work. If I manually toggle the GPIO pin, the device immediately shuts down. If I take stock Raspbian-Lite and add the following line to config.txt it works. But U-Boot seems to be ignoring it. I am using Raspbian Lite 2017-07-5 with the latest mainline U-Boot: git://git.denx.de/u-boot.git compiled with rpi_defconfig.
dtoverlay=gpio-poweroff,gpiopin=6,active_low=1
With U-Boot the Raspberry Pi boots and works normally, it even shuts down but it never toggles GPIO6. This leaves the PSU running and the only way to fix it is by holding down the power button for at least 5 seconds. I know that dt-blob.bin is loaded and applied as the board has a camera which only works with the correct dt-blob.bin.
At thus point I am out of ideas. I have tried:
Updating the Linux kernel using rpi-update
Decompiling both gpio-poweroff.dtbo and dt-blob.bin. Changing 0x1a to 0x06 and 0x0 to 0x1 inside gpio -poweroff.dtbo, concatenating them together and it doesn't work.
Manually doing the above and intertwining the decompiled code.
Using fdt addr, and fdt apply inside boot.scr to apply it manually, this didn't work because fdt_overlay_apply FDT_ERR_NOSPACE and I couldn't seem to get past this.
Cloning linux and trying to make dtsb, target doesn't exist.
Cloning linux/arch/arm/boot/dts, writing a MakeFile and compiling them with my changes results in a U-Boot loading, Raspbian loading but gpio-poweroff not working.
Other attempts which are barely worth mentioning.
Nothing I try seems to work, and I'm not sure where to go forward.
For reference, here are some of the files in use:
boot.cmd:
#Setting default bootargs
setenv original_bootargs console=ttyS0 console=tty1 rootfstype=ext4 fsck.repair=yes hdmi.audio=0 disp.screen0_output_mode=1920x1080p60:1280x720p60:800x600p60:EDID rootwait panic=10 # console MUST be ttyS0 or it WILL NOT BOOT!
# Identify if we are using partition 2 or 3
if fatload mmc 0:1 ${loadaddr} swap; then echo "Using Partition 3"; setenv partition 3; else echo "Using Partition 2"; setenv partition 2; fi
# Check for recovery
if fatload mmc 0:1 ${loadaddr} recovery; then echo "Using Recovery Partition"; setenv partition 4; fi
#if gpio input 32 || fatload mmc 0:1 ${loadaddr} recovery; then echo "Using Recovery Partition"; setenv partition 4; fi
# Create an empty file to detect boot failures
fatwrite mmc 0:1 ${kernel_addr_r} recovery 0
# Set bootargs
setenv bootargs "${original_bootargs} root=/dev/mmcblk0p${partition}"
# Load the existing Linux kernel into RAM
echo Loading partition ${partition}
ext4load mmc 0:${partition} ${kernel_addr_r} kernel.img
# Boot the kernel we have just loaded
bootz ${kernel_addr_r} - ${fdt_addr}
Not sure why, but it boots with red and blue swapped, and at a low resolution. Compiled with mkimage -A arm -O linux -T script -C none -a 0x00000000 -e 0x00000000 -n "Boot Script" -d boot.cmd boot.scr
config.txt:
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
#dtparam=audio=on
gpu_mem=128
start_x=1
dtoverlay=gpio-poweroff,gpiopin=6,active_low=1
dtdebug=1
So, I've somewhat fixed it by compiling my own bcm27***.dtb files with the following concatenated after their original content:
/ {
compatible = "brcm,bcm2709";
power_ctrl: power_ctrl {
compatible = "gpio-poweroff";
gpios = <&gpio 6 1>;
};
};
However, this has completely broken GPIO and i2c. So this isn't a complete solution. My next step is to restore the original files, and try adding this to the end of dt-blob.bin
I did it, here is the answer:
# Manually apply overlay
setenv fdt_length 50000
setexpr kernel_addr_r ${fdt_addr} + ${fdt_length}
fdt addr ${fdt_addr} # Load the existing tree
fdt boardsetup # Device specific setup
fdt move ${fdt_addr} ${fdt_addr} ${fdt_length} # Resize the loaded fdt to ${fdt_length}
fatload mmc 0:1 ${kernel_addr_r} overlays/gpio-poweroff.dtbo
fdt apply ${kernel_addr_r} # Apply the overlay
Editing default device trees and dt-blob.bin ended being a fruitless endeavour. What you need to do is apply the overlay yourself, manually, inside uboot.src.
The first step is to find the source code of the desired overlay, and change the default value to you desired value, you cannot use overlay arguments inside U-Boot.
Before applying overlays you need to increase the size of the loaded device tree using fdt move, then you can load and apply from fat. If you wanted to apply more overlays you simply need to add additional lines such as:
fatload mmc 0:1 ${kernel_addr_r} overlays/rpi-tv.dtbo
fdt apply ${kernel_addr_r} # Apply the overlay
Be careful your device tree doesn't run out of space!
Good day,
I am currently working on a project where PCIe SSDs are constantly being swapped out and tested through benchmark programs such as VDBench and Iometer. The problem I face right now, which is only on the Linux side (got it working fine on windows), is that if the drives were not on at initial boot-up, they never appear under GParted or Disks. Here's what I have done:
Cold boot, PCIe Add-in-card SSD is off. It is then powered on through a pass through card that is logically controlled to make sure power and shorts are not an issue.
I turn the device on, then run:
sudo sh -c "echo 1 > /sys/bus/pci/rescan"
Performing a
lspci -tv
The device shows with no issues in the tree. When I check under Disks however, it is not there.
I have tried a bunch of different commands with none of them seeming to help me. I have tried
partprobe
Which did not do anything. and:
sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:82:00.0/remove"
Followed up another rescan:
sudo sh -c "echo 1 > /sys/bus/pci/rescan"
As well as:
sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:82:00.0/enable"
Still nothing. Also ran:
dmesg
Which shows, amongst other things:
[ 68.128778] pci 0000:82:00.0: [8086:0953] type 00 class 0x010802
[ 68.128797] pci 0000:82:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[ 68.128820] pci 0000:82:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[ 68.133398] pci 0000:84:00.0: [1c58:0003] type 00 class 0x010802
..............................
[ 68.141751] nvme 0000:82:00.0: enabling device (0100 -> 0102)
..............................
I do see a lot of fails in dmesg for other addresses, such as:
[ 1264.718446] pcieport 0000:03:04.0: BAR 14: no space for [mem size 0x00400000]
[ 1264.718448] pcieport 0000:03:04.0: BAR 14: failed to assign [mem size 0x00400000]
[ 1264.718451] pcieport 0000:03:04.0: BAR 13: no space for [io size 0x1000]
[ 1264.718453] pcieport 0000:03:04.0: BAR 13: failed to assign [io size 0x1000]
Although I have a feeling that those are unrelated to what I am doing, although I'd be happy for someone to prove me wrong.
So, after all of these attempts, does anyone know if there is a way (or if it is even possible) to scan for this PCIe Add-in NVMe SSD and be able to use it without rebooting? I also took a look at some of the threads for other HDDs that reference a rescan for sata based drives, but this is NOT that, so referencing that won't help either.
Thanks in advance.
I ran into the same issue benchmarking nvme PCIE passthrough with QEMU / Proxmox.
First take note of the driver in use:
lspci -nnk -s '0000:82:00.0'
It should say
Kernel driver in use: vfio-pci
Now unbind the driver, then reprobe:
echo '0000:82:00.0' > /sys/bus/pci/drivers/vfio-pci/unbind
echo '0000:82:00.0' > /sys/bus/pci/drivers_probe
Check the driver again with:
lspci -nnk -s '0000:82:00.0'
Kernel driver in use: nvme
lsblk should now show the drive. Found the procedure here
I tried doing that to save time which is used by rebooting. The PCI device driver at that time was dodgy at best about successfully rescanning and getting all its ducks in a row. The device was an FPGA presenting a proprietary interface device for a device driver I was developing. That was with kernel 2.6.30-something tried around March 2014. My (substandard, but acceptable) solution was to reboot the system.
I'm trying to figure out what process is holding the other end of a unix domain socket. In some strace output I've identified a given file descriptor which is involved in the problem I'm currently debugging, and I'd like to know which process is on the other end of that. As there are multiple connections to that socket, simply going by path name won't work.
lsof provides me with the following information:
dbus-daem 4175 mvg 10u unix 0xffff8803e256d9c0 0t0 12828 #/tmp/dbus-LyGToFzlcG
So I know some address (“kernel address”?), I know some socket number, and I know the path. I can find that same information in other places:
$ netstat -n | grep 12828
unix 3 [ ] STREAM CONNECTED 12828 #/tmp/dbus-LyGToFzlcG
$ grep -E '12828|ffff8803e256d9c0' /proc/net/unix
ffff8803e256d9c0: 00000003 00000000 00000000 0001 03 12828 #/tmp/dbus-LyGToFzlcG
$ ls -l /proc/*/fd/* 2>/dev/null | grep 12828
lrwx------ 1 mvg users 64 10. Aug 09:08 /proc/4175/fd/10 -> socket:[12828]
However, none of this tells me what the other end of my socket connection is. How can I tell which process is holding the other end?
Similar questions have been asked on Server Fault and Unix & Linux. The accepted answer is that this information is not reliably available to the user space on Linux.
A common suggestion is to look at adjacent socket numbers, but ls -l /proc/*/fd/* 2>/dev/null | grep 1282[79] gave no results here. Perhaps adjacent lines in the output from netstat can be used. It seems like there was a pattern of connections with and without an associated socket name. But I'd like some kind of certainty, not just guesswork.
One answer suggests a tool which appears to be able to address this by digging through kernel structures. Using that option requires debug information for the kernel, as generated by the CONFIG_DEBUG_INFO option and provided as a separate package by some distributions. Based on that answer, using the address provided by lsof, the following solution worked for me:
# gdb /usr/src/linux/vmlinux /proc/kcore
(gdb) p ((struct unix_sock*)0xffff8803e256d9c0)->peer
This will print the address of the other end of the connection. Grepping lsof -U for that number will provide details like the process id and the file descriptor number.
If debug information is not available, it might be possible to access the required information by knowing the offset of the peer member into the unix_sock structure. In my case, on Linux 3.5.0 for x86_64, the following code can be used to compute the same address without relying on debugging symbols:
(gdb) p ((void**)0xffff8803e256d9c0)[0x52]
I won't make any guarantees about how portable that solution is.
Update: It's been possible to to do this using actual interfaces for a while now. Starting with Linux 3.3, the UNIX_DIAG feature provides a netlink-based API for this information, and lsof 4.89 and later support it. See https://unix.stackexchange.com/a/190606/1820 for more information.
I am running kernel 2.6.33.7.
Previously, I was running v2.6.18.x. On 2.6.18, the flush processes were named pdflush.
After upgrading to 2.6.33.7, the flush processes have a format of "flush-:".
For example, currently I see flush process "flush-8:32" popping up in top.
In doing a google search to try to determine an answer to this question, I saw examples of "flush-8:38", "flush-8:64" and "flush-253:0" just to name a few.
I understand what the flush process itself does, my question is what is the significance of the numbers on the end of the process name? What do they represent?
Thanks
Device numbers used to identify block devices. A kernel thread may be spawned to handle a particular device.
(On one of my systems, block devices are currently numbered as shown below. They may change from boot to boot or hotplug to hotplug.)
$ grep ^ /sys/class/block/*/dev
/sys/class/block/dm-0/dev:254:0
/sys/class/block/dm-1/dev:254:1
/sys/class/block/dm-2/dev:254:2
/sys/class/block/dm-3/dev:254:3
/sys/class/block/dm-4/dev:254:4
/sys/class/block/dm-5/dev:254:5
/sys/class/block/dm-6/dev:254:6
/sys/class/block/dm-7/dev:254:7
/sys/class/block/dm-8/dev:254:8
/sys/class/block/dm-9/dev:254:9
/sys/class/block/loop0/dev:7:0
/sys/class/block/loop1/dev:7:1
/sys/class/block/loop2/dev:7:2
/sys/class/block/loop3/dev:7:3
/sys/class/block/loop4/dev:7:4
/sys/class/block/loop5/dev:7:5
/sys/class/block/loop6/dev:7:6
/sys/class/block/loop7/dev:7:7
/sys/class/block/md0/dev:9:0
/sys/class/block/md1/dev:9:1
/sys/class/block/sda/dev:8:0
/sys/class/block/sda1/dev:8:1
/sys/class/block/sda2/dev:8:2
/sys/class/block/sdb/dev:8:16
/sys/class/block/sdb1/dev:8:17
/sys/class/block/sdb2/dev:8:18
/sys/class/block/sdc/dev:8:32
/sys/class/block/sdc1/dev:8:33
/sys/class/block/sdc2/dev:8:34
/sys/class/block/sdd/dev:8:48
/sys/class/block/sdd1/dev:8:49
/sys/class/block/sdd2/dev:8:50
/sys/class/block/sde/dev:8:64
/sys/class/block/sdf/dev:8:80
/sys/class/block/sdg/dev:8:96
/sys/class/block/sdh/dev:8:112
/sys/class/block/sdi/dev:8:128
/sys/class/block/sr0/dev:11:0
/sys/class/block/sr1/dev:11:1
/sys/class/block/sr2/dev:11:2
You should also be able to figure this out by searching for those numbers in /proc/self/mountinfo, eg:
$ grep 8:32 /proc/self/mountinfo
25 22 8:32 / /var rw,relatime - ext4 /dev/mapper/sysvg-var rw,barrier=1,data=ordered
This has the side benefit of working with nfs as well:
$ grep 0:73 /proc/self/mountinfo
108 42 0:73 /foo /mnt/foo rw,relatime - nfs host.domain.com:/volume/path rw, ...
Note, the data I included here is fabricated, but the mechanism works just fine.