Attempt to run the following command with root privilege on kernel 2.6.35 results in error:
% echo 0000:00:03.0 > /sys/bus/pci/drivers/foo/bind
-bash: echo: write error: No such device
UPDATE
The device does exist in /sys/bus/pci/devices/ the output of lspci is as follows:
% lspci -v -s 0000:00:03.0
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
Memory at f0000000 (32-bit, non-prefetchable) [size=128K]
I/O ports at d010 [size=8]
Capabilities: <access denied>
Kernel driver in use: e1000
I think I resolved the issue. It appears that the driver requires to unbind device at first.
It also appears that the shell processes redirection (echo .. > /sys/bus/..) with user permission, and 'sudo' handles only the command, i.e. 'echo' but not the whole command line that follows it, therefore it has to be executed this way:
% sudo sh -c "echo 0000:00:03.0 > /sys/bus/pci/drivers/foo/unbind"
% sudo sh -c "echo 0000:00:03.0 > /sys/bus/pci/drivers/foo_new/bind"
Related
I'm currently working on a Linux machine and I want to know if there is a command that tells you the number of hard drive slots the actual machine has regardless of whether there are hard drives installed or not. I know reading the machine's manual provides that information but is there any way to get this information by command line?
I've tried lshw and dmidecode commands but they do not provide information on slots. This specific machine has 6 slots for hard drives to be installed with only 3 currently occupied. It does not have hardware raid either so I cannot use megacli.
Any help would be appreciated.
What about this command:
smartctl --scan
Output:
/dev/sda -d scsi # /dev/sda, SCSI device
/dev/sdb -d scsi # /dev/sdb, SCSI device
/dev/sdc -d scsi # /dev/sdc, SCSI device
/dev/sdd -d scsi # /dev/sdd, SCSI device
/dev/sde -d scsi # /dev/sde, SCSI device
/dev/sdf -d scsi # /dev/sdf, SCSI device
/dev/bus/0 -d megaraid,8 # /dev/bus/0 [megaraid_disk_08], SCSI device
/dev/bus/0 -d megaraid,9 # /dev/bus/0 [megaraid_disk_09], SCSI device
/dev/bus/0 -d megaraid,10 # /dev/bus/0 [megaraid_disk_10], SCSI device
/dev/bus/0 -d megaraid,11 # /dev/bus/0 [megaraid_disk_11], SCSI device
/dev/bus/0 -d megaraid,12 # /dev/bus/0 [megaraid_disk_12], SCSI device
/dev/bus/0 -d megaraid,13 # /dev/bus/0 [megaraid_disk_13], SCSI device
lsblk should list all block devices. If you want only physical disks you can use lsblk -d.
Example:
lsblk -o name,serial
Output:
NAME SERIAL
sda S2U5J1VZ500792
├─sda1
└─sda9
sdb W3APDFP8
├─sdb1
└─sdb9
Can it be done by lspci or lsscsi command. It can tell you the PCI or SCSI slots available and used.
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 am trying to enable monitoring mode for a USB wifi dongle with the RTL8188CUS chipset on a raspberry pi model b+ (or any raspberry pi for that matter).
$ lsusb
Bus 001 Device 005: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
$ sudo iwconfig wlan0 mode monitor
Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Invalid argument.
According to github/raspberrypi/linux/issues/369, you need to enable the rtlwifi/rtl8192cu kernel module that is included with the kernel distribution but not compiled. This requires minor modifications to some files as diff'ed below in 'STEP 2'.
The USB issue mentioned in that thread has been resolved as of 4.1.6+, so the rtlwifi driver should work.
Steps to recreate on a fresh raspberry pi (model B+)...
STEP 0: Update existing modules and kernel to latest
$ sudo apt-get update
$ sudo rpi-update
$ uname -a
Linux raspberrypi 4.1.7+ #815 PREEMPT Thu Sep 17 17:59:24 BST 2015 armv6l GNU/Linux
STEP 1: Get the raspbian kernel source and add missing dependencies
$ git clone --depth=1 https://github.com/raspberrypi/linux
$ sudo apt-get install bc lshw
STEP 2: Enable the rtlwifi (kernel) drivers for RTL8188CUS (RTL8192)
edit linux/drivers/net/wireless/Kconfig
-#source "drivers/net/wireless/rtlwifi/Kconfig"
-source "drivers/net/wireless/rtl8192cu/Kconfig"
+source "drivers/net/wireless/rtlwifi/Kconfig"
+#source "drivers/net/wireless/rtl8192cu/Kconfig"
(Wheezy) edit linux/drivers/net/wireless/Makefile
-#obj-$(CONFIG_RTLWIFI) += rtlwifi/
+obj-$(CONFIG_RTLWIFI) += rtlwifi/
(Jessie) edit linux/drivers/net/wireless/realtek/Makefile
-#obj-$(CONFIG_RTLWIFI) += rtlwifi/
+obj-$(CONFIG_RTLWIFI) += rtlwifi/
STEP 3: Compile and install kernel (took many hours)
Summarized from kernel building documentation .
$ cd linux
$ KERNEL=kernel
$ make bcmrpi_defconfig
$ make zImage modules dtbs
$ sudo make modules_install
$ sudo cp arch/arm/boot/dts/*.dtb /boot/
$ sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
$ sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
$ sudo scripts/mkknlimg arch/arm/boot/zImage /boot/$KERNEL.img
STEP 4: Reboot
$ sudo reboot
STEP 5: Check that the rtlwifi/rtl8192cu module is loaded
$ lsmod | fgrep rtl8192cu
rtl8192cu 100806 0
rtl_usb 14781 1 rtl8192cu
rtl8192c_common 72091 1 rtl8192cu
rtlwifi 101122 3 rtl_usb,rtl8192c_common,rtl8192cu
mac80211 623281 3 rtl_usb,rtlwifi,rtl8192cu
$
$ lshw
*-network:0
description: Ethernet interface
physical id: 1
bus info: usb#1:1.3
logical name: wlan0
serial: 00:0b:81:94:e9:a3
capabilities: ethernet physical
configuration: broadcast=yes driver=rtl8192cu driverversion=4.1.7+ firmware=N/A link=no multicast=yes
STEP 6: Try to activate monitoring mode
$ sudo iwconfig wlan0 mode monitor
Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Operation not supported.
What did i miss?
Issue 369 seems to indicate that it can work with the rtlwifi driver?
Turns out the steps to recompile and load the rtlwifi module are correct. The problem is iwconfig not working to enable/determine monitoring mode in this situation.
Instead, I used iw as outlined by Steven Gordon - Capturing WiFi in Monitor mode with iw and it worked.
To summarize:
STEP 6b: List the physical network interfaces available
$ iw dev
STEP 7: Determine if the physical interface supports monitoring mode
$ iw phy phy0 info
... lots of stuff ...
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
... lots more stuff ...
STEP 8: Add a monitoring interface to that physical card
You need to explicitly add a 'monitoring' interface for the hardware you have.
$ sudo iw phy phy0 interface add mon0 type monitor
STEP 8: Start monitoring
In my case, I'm using tshark to facilitate monitoring, displaying a few useful fields rather than a lot of noise.
$ sudo apt-get install tshark
$ sudo tshark -i mon0 -f 'broadcast' -T fields -e frame.time_epoch -e wlan.sa -e radiotap.dbm_antsignal -e wlan.fc.type -e wlan.fc.subtype
Done.
For anyone still interested, the rtl8192cu is now compiled into the raspberry kernel by default. It can be activated by commenting out the blacklist in /etc/modprobe.d/blacklist-rtl8192cu.conf. Executing sudo iwconfig wlan0 mode monitor after a reboot will activate monitoring mode without any further problems.
I want to be able to do so from both Windows and from Linux. I know that there are ways by getting sysinfo and using thumb rules related to hardware identifiers.
I want to know if there is a more fundamental method, like looking at a memory address / issuing an interrupt etc.
BTW I am trying to do this on Intel hardware and the virtualization software I use are Vmware Workstation and Windows HyperV.
Here is one more useful command:
$ lscpu | grep -E 'Hypervisor vendor|Virtualization type'
Hypervisor vendor: KVM
Virtualization type: full
Example output of other commands:
$ sudo virt-what
kvm
$ dmesg | grep -i virtual
[ 0.000000] Booting paravirtualized kernel on KVM
[ 0.029160] CPU0: Intel QEMU Virtual CPU version 1.0 stepping 03
$ sudo dmidecode | egrep -i 'manufacturer|product|vendor|domU'
Vendor: Bochs
Manufacturer: Bochs
Product Name: Bochs
Manufacturer: Bochs
Manufacturer: Bochs
Manufacturer: Bochs
Manufacturer: Bochs
Manufacturer: Bochs
Manufacturer: Bochs
Manufacturer: Bochs
Manufacturer: Bochs
Manufacturer: Bochs
At least one of these should work to detect if you are running under VMware (or some other common virtual environment) on Linux:
Check for virtual devices detected by kernel when system boots.
dmesg | grep -i virtual
Another way to detect virtualized hardware devices, if dmesg doesn't say anything useful.
dmidecode | egrep -i 'manufacturer|product|vendor|domU'
You can also check for virtual disks:
cat /proc/ide/hd*/model
Virtuozzo can usually be detected by looking for /proc/vz or /dev/vzfs.
Most software check the hypervisor CPUID leaf -
Leaf 0x40000000, Hypervisor CPUID information
EAX: The maximum input value for hypervisor CPUID info (0x40000010).
EBX, ECX, EDX: Hypervisor vendor ID signature. E.g. "KVMKVMKVM"
Leaf 0x40000010, Timing information.
EAX: (Virtual) TSC frequency in kHz.
EBX: (Virtual) Bus (local apic timer) frequency in kHz.
ECX, EDX: RESERVED
Ofcourse, you are still relying on the hypervisor to give you this information. It may very well decide to not report 0x40000000 at all, in turn leading the guest to believe that it's actually running on real hardware
Basically I need to verify that a USB Drive is connected to a certain USB Port. I have the following:
USB Drives are labeled virtually:
White, Green, Red
I have 3 USB Ports that are also labeled physically:
White, Green, Red
Using BLKID I can receive information from the drives such as
BLKID Example
/dec/sdb1: SEC_TYPE="msdos" LABEL="WHTIE" UUID="78FE-870D" TYPE="vfat"
Therefore I know a lot about the drive itself by only knowing the label. Now I using LSPCI I can get the information about the USB port as I know the ID's of each bridge. For example:
LSPCI Example
0a.00.0 USB Controller: some info 4d88
So that last part 4d88 is the PCI ID.
So I know the PCI ID's of each port and need to match them up to the USB Drive itself such as:
4d88 = WHITE
4dC0 = GREEN
4d84 = RED
I don't know how to match / check that relationship. Any help will be appreciated.
ANSWER: Thanks for all the help.
#!/bin/bash
#variables
error="ERROR : Incorrect Command use 'usb_pci.sh'"
pci="USB PCI Check Successful"
errorstatus_white_pci="ERROR : USB PCI FAILED : WHITE Drive"
errorstatus_green_pci="ERROR : USB PCI FAILED : GREEN Drive"
errorstatus_red_pci="ERROR : USB PCI FAILED : RED Drive"
pci_check_white=4dc9
pci_check_green=4d81
pci_check_red=4dc5
#Takes USB label and gets /sys/block/sd?
echo "checking path for USB Label"
path_white=$(blkid | grep WHITE | cut -d : -f 1 | sed 's|[0-9]*$||; s|^/dev/|/sys/block/|')
echo "white: "$path_white
path_green=$(blkid | grep GREEN | cut -d : -f 1 | sed 's|[0-9]*$||; s|^/dev/|/sys/block/|')
echo "green: "$path_green
path_red=$(blkid | grep RED | cut -d : -f 1 | sed 's|[0-9]*$||; s|^/dev/|/sys/block/|')
echo "red: "$path_red
#Takes /sys/block/sd? and gets PCI Path xx:xx.x
echo "checking path to PCI path"
pci_path_white=$(ls -l ${path_white} | xargs | cut -d / -f 8 | cut -b 6-13)
echo "white: "$pci_path_white
pci_path_green=$(ls -l ${path_green} | xargs | cut -d / -f 8 | cut -b 6-13)
echo "green: "$pci_path_green
pci_path_red=$(ls -l ${path_red} | xargs | cut -d / -f 8 | cut -b 6-13)
echo "red: "$pci_path_red
#Takes xx:xx.x and gets the PCI Device ID xxxx
echo "checking PCI path to PCI Device ID"
pci_device_id_white=$(lspci -s ${pci_path_white} | tail -c -5)
echo "white: "$pci_device_id_white
pci_device_id_green=$(lspci -s ${pci_path_green} | tail -c -5)
echo "green: "$pci_device_id_green
pci_device_id_red=$(lspci -s ${pci_path_red} | tail -c -5)
echo "red: "$pci_device_id_red
#check if pci_device_id_xxxx = pci_check_xxxx
echo "checking PCI Device ID equals what it should"
if [ $pci_device_id_white = $pci_check_white ] ; then
echo "WHITE USB PCI Check Successful"
else
echo $errorstatus_white_pci
exit 1
fi
if [ $pci_device_id_green = $pci_check_green ] ; then
echo "GREEN USB PCI Check Successful"
else
echo $errorstatus_green_pci
exit 1
fi
if [ $pci_device_id_red = $pci_check_red ] ; then
echo "RED USB PCI Check Successful"
else
echo $errorstatus_red_pci
exit 1
fi
echo $pci
exit 0
Edit:
As requested dumps of lspci, lsusb, blkid.
lspci
00:00.0 Host bridge: Intel Corporation Unknown device 0104 (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Unknown device 0126 (rev 09)
00:16.0 Communication controller: Intel Corporation Unknown device 1c3a (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB Controller: Intel Corporation Unknown device 1c2d (rev 04)
00:1b.0 Audio device: Intel Corporation Unknown device 1c20 (rev 04)
00:1c.0 PCI bridge: Intel Corporation Unknown device 1c10 (rev b4)
00:1c.2 PCI bridge: Intel Corporation Unknown device 1c14 (rev b4)
00:1c.3 PCI bridge: Intel Corporation Unknown device 1c16 (rev b4)
00:1c.5 PCI bridge: Intel Corporation Unknown device 1c1a (rev b4)
00:1d.0 USB Controller: Intel Corporation Unknown device 1c26 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Unknown device 1c4f (rev 04)
00:1f.2 RAID bus controller: Intel Corporation Mobile 82801 SATA RAID Controller (rev 04)
00:1f.3 SMBus: Intel Corporation Unknown device 1c22 (rev 04)
08:00.0 PCI bridge: Integrated Device Technology, Inc. PES4T4 PCI Express Switch (rev 0e)
09:02.0 PCI bridge: Integrated Device Technology, Inc. PES4T4 PCI Express Switch (rev 0e)
09:03.0 PCI bridge: Integrated Device Technology, Inc. PES4T4 PCI Express Switch (rev 0e)
09:04.0 PCI bridge: Integrated Device Technology, Inc. PES4T4 PCI Express Switch (rev 0e)
0a:00.0 USB Controller: Unknown device 4d88
0a:00.1 USB Controller: Unknown device 4dc9
0a:00.2 System peripheral: Unknown device 4dca
0a:00.3 Communication controller: Unknown device 4d8b
0b:00.0 USB Controller: Unknown device 4dc0
0b:00.1 USB Controller: Unknown device 4d81
0b:00.2 System peripheral: Unknown device 4d8e
0b:00.3 Serial controller: Unknown device 4dcf
0c:00.0 USB Controller: Unknown device 4d84
0c:00.1 USB Controller: Unknown device 4dc5
0c:00.2 System peripheral: Unknown device 4dc6
0c:00.3 Communication controller: Unknown device 4d87
0d:00.0 SD Host controller: O2 Micro, Inc. Unknown device 8221 (rev 05)
0d:00.1 Mass storage controller: O2 Micro, Inc. Unknown device 8231 (rev 03)
lsusb
Bus 004 Device 001: ID 0000:0000
Bus 006 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 001 Device 002: ID 8087:0024
Bus 001 Device 001: ID 0000:0000
Bus 007 Device 001: ID 0000:0000
Bus 008 Device 001: ID 0000:0000
Bus 003 Device 003: ID 0718:063d Imation Corp.
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 002: ID 8087:0024
Bus 002 Device 004: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications Processor
Bus 002 Device 001: ID 0000:0000
Bus 002 Device 003: ID 413c:3012 Dell Computer Corp. Optical Wheel Mouse
blkid
/dev/mapper/VolGroup00-LogVol01: TYPE="swap" UUID="6b361baf-08ae-4f2c-933b-5028c15b6fb5"
/dev/mapper/VolGroup00-LogVol00: UUID="d15840ac-0073-483d-b630-7d2a497eaac9" TYPE="ext3"
/dev/sda1: LABEL="/boot" UUID="39331b93-a08d-45b5-b1ea-fcc6586be7bd" TYPE="ext3"
/dev/VolGroup00/LogVol00: UUID="d15840ac-0073-483d-b630-7d2a497eaac9" TYPE="ext3"
/dev/VolGroup00/LogVol01: TYPE="swap" UUID="6b361baf-08ae-4f2c-933b-5028c15b6fb5"
/dev/sdb1: SEC_TYPE="msdos" LABEL="WHITE" UUID="78FE-870D" TYPE="vfat"
/dev/sdc1: SEC_TYPE="msdos" LABEL="GREEN" UUID="61FE-B32E" TYPE="vfat"
/dev/sdd1: SEC_TYPE="msdos" LABEL="RED" UUID="E5DB-4A1A" TYPE="vfat"
This is how I would do it on my system:
Step 1: Find the device node:
# blkid | grep MyDisk
/dev/sdj1: LABEL="MyDisk-0" UUID="4876-5945" TYPE="vfat"
The device node is /dev/sdj1.
Step 2: /sys is your friend:
# ll /sys/block/sdj
lrwxrwxrwx 1 root root 0 Feb 3 00:40 /sys/block/sdj -> ../devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/host15/target15:0:0/15:0:0:0/block/sdj/
The symbolic link target above contains a lot of useful information, including the path from your flash drive back to the PCI bridge via the SCSI and USB subsystems.
Step 3: From the link target above isolate the PCI bus ID (00:1a.7 in this case) and check with lspci:
# lspci | grep 00:1a.7
00:1a.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
If in doubt, inspect the lspci output visually...
EDIT:
Here is an extremely crude and extremely fragile way to automate the process above:
blkid |
grep Label |
cut -d : -f 1 |
sed 's|[0-9]*$||; s|^/dev/|/sys/block/|' |
xargs readlink |
cut -d / -f 4 |
xargs -n 1 lspci -s
NOTE: This works on my system, but it is by no means safe (or recommended):
It will break if a kernel update changes the layout of the /sys filesystem.
It can break if you have a different device layout, although you should be able to adjust for that.