While sampling memory loads and stores via Perf, I'm attempting to capture the physical address of the memory location accessed. However, I'm finding that many accesses to kernel space (as determined by their associated virtual addresses) have an associated physical address that is null (i.e., 0x0).
Why are these physical addresses null? Is null reported because the physical address could not be determined? If null is the valid physical address, what does a physical address of null mean?
An easy way to observe this is to run the following:
sudo perf record -e mem_uops_retired.all_loads:p --count 1000 --data --phys-data timeout 2 yes
sudo perf report -i perf.data -D | grep -A2 PERF_RECORD_SAMPLE | grep phys_addr | sort | uniq -c | sort -n
I'm seeing the following:
...
2765 .. phys_addr: 0x100e849b8
3204 .. phys_addr: 0x10c553478
3588 .. phys_addr: 0x10c553480
4148 .. phys_addr: 0x10c5534a8
135328 .. phys_addr: 0x0
I'm running on Ubuntu v20.04.1 with Intel Xeon CPU D-1540.
Looking at the notes associated with the patch introducing physical address sampling:
For kernel direct mapping addresses, the patch uses virt_to_phys to
convert the virtual addresses from DLA to physical address.
For user virtual addresses, __get_user_pages_fast is used to walk the
pages tables for user physical address.
This does not work for vmalloc addresses. Right now these are not
resolved, but code to do that could be added.
Checking the Linux source, the physical address of a vmalloc address still cannot be determined (at the time of this posting). Instead, the physical address returned is null (i.e., 0).
Related
I have a VM instance on Oracle Cloud (Ubuntu 22.04) set up with ZeroTier to act as a web server for some services that should work with my local Synology NAS.
For some of those services I also need to mount three SMB shares from my NAS with the ZeroTier tunnel, but I can't make it work.
I used mount and mount.cifs plenty of times with automounting too, this time it acts very strange:
running the mount command seems to succeed from the console, but /var/log/syslog reads
CIFS: VFS: \\XXX.XXX.XXX.XXX has not responded in 180 seconds.
Reconnecting...
if trying to access one of the shares (ls or lsof or cd or any other command), it succeeds for only one of the shares (always the same one), but only for the first time any command is given:
$ ls /temp
folder1 folder2 folder3
any other following command just "hangs" as if they system is working on something, but it stays like that indefinitely most of the times:
$ ls /temp
█
Just a few times it spits out this error
lsof: WARNING: can't stat() cifs file system /temp
Output information may be incomplete.
ls 1475 ubuntu 3r DIR 0,44 0 123207681 /temp
findmnt reads:
└─/temp //XXX.XXX.XXX.XXX/Downloads cifs rw,relatime,vers=2.0,cache=strict, username=[redacted],uid=1005,noforceuid,gid=0,noforcegid,addr=XXX.XXX.XXX.XXX,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1
for the remaining two "mounted" shares, none of them seems to respond to any command, not even the very first command, and they just hang like the one share that, at least, lets me browse for one time;
umount and umount -l take at least 2-3 minutes to successfully unmount the shares.
Same behavior when using smbclient and also with NFS shares from the same NAS.
What I have already tried:
update kernel and all packages;
remove, purge and reinstall cifs-utils, smbclient and so on...
tried mounting the same shares in another client / node within the ZeroTier network and it works just fine; also browsing from Windows and Android file manager apps with and without ZeroTier works flawlessly;
tried all SMB versions including SMBv3 and SMBv1 (CIFS);
tried different browsing or mounting methods / commands including mount, mount.cifs, autofs, smbclient;
tried to debug what happens behind the console, but didn't found anything that seems related to this in logs, htop or anything else. During the "hanging" sessions there is no spike in CPU, RAM or Network usage in either the Oracle VM or Synology NAS;
checked, reset and reconfigured all permissions on my NAS for shares, folders and files recursively and reconfigured users groups permissions.
What I haven't tried yet (I'll try as soon as possible):
reproduce this on another Oracle VM configured the same as the faulty one and another with a different base image (maybe Oracle Linux?);
It seems to me that the mount.cifs process doesn't really succeeds in mounting the share correctly, as it doesn't show as such anywhere. It also seems an issue not related to folder/file permissions, but rather something related to networking?
A note on something that may or may not be related to this: ZeroTier on my Synology NAS does not seems to work with IPv4 only - it remains OFFLINE. The node goes ONLINE only when IPv6 is enabled, but I must say that this is the only node in my ZT network that shows a IPv6 as public IP in the ZT web GUI - the other nodes show IPv4 public addresses.
If anyone has any clue on this, I'll be happy to support and reproduce any advice. Thank you!
I'm using YailScale, but I presume it will work the same.
You need to add the port 445 to /etc/iptables/rules.v4 just under the SSH setup like below:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 445 -j ACCEPT (like this)
Then you need to edit the interfaces in /etc/samba/smb.conf to:
interfaces = lo tailscale0 100.0.0.0/24
Obviously, my interface is tailscale0, but yours will be different. Use ip link show to find yours. You may also need to change your IP range to suit ZeroTeirs, such as 100.0.0.0/24, which is what tailscale uses.
Then reboot!
I couldn't get it working without doing this.
I am new in DICOM and DCMTK. I was trying to retrieve dcm files from a public test server (http://www.dicomserver.co.uk) with movescu command. But it's not working. I was able run findscu successfully but that's only to get data. Here's what I have tried:
findscu -v -P --call COMMON --patient --key 0008,0052=PATIENT --key 0010,0020="PAT004" www.dicomserver.co.uk 104
It works but same thing doesn't work for movescu like this:
movescu -v -P --call COMMON +P 104 --patient --key 0008,0052=PATIENT --key 0010,0020="PAT004" www.dicomserver.co.uk 104
The output:
I: Requesting Association
I: Association Accepted (Max Send PDV: 65524)
I: Sending Move Request (MsgID 1)
I: Request Identifiers:
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [PATIENT] # 8, 1 QueryRetrieveLevel
I: (0010,0020) LO [PAT004] # 6, 1 PatientID
I:
W: Move response with error status (Failed: UnableToProcess)
I: Received Final Move Response (Failed: UnableToProcess)
I: Releasing Association
I am not running any local DICOM server or anything else. What is the right way to achieve this?
According to the DICOM standard (PS3.4), you have to specify the unique key of the PATIENT level for the C-MOVE request. Patient's Name (0010,0010) shouldn't be "*" (which is "Wild Card Matching" for the query phase) but Patient ID (0010,0020) should have the real value, i.e. one of those Patient IDs that you have queried using "findscu".
By the way, did you also start a Storage SCP on your system to listen on port 104? See online documentation of http://dicomserver.co.uk/. If not, you could start "movescu" with the additional command line option "+P 104" (because this tool has a one build in).
In case someone still has trouble with this issue:
each query has to include StudyInstanceUID + SeriesInstanceUID + PatientID
Because the retrieval process makes the PACS create an SCP session towards what's running movescu it needs to know how to approach it. AE is the name (of the machine) being sent and default is MOVESCU (can be changed with aec/aet flags flags, but PACS hosts file must have that ip-to-name mapping)
By default this protocol runs on port 104, which is restricted. you can either change this with +P flag to a port higher than 1024 (have not tried to verify PACS recieves this port number) or just run movescu with sudo/root
I don't know what is the default store directory, but this can be defined with -od flag.
working example:
sudo /usr/bin/movescu -v -od /path/to/dir PACS_IP 104 -k StudyInstanceUID=1.2.3.4.5 -k SeriesInstanceUID=1.2.3.4.5 -k PatientID=12345 +P 104
I can get the switch status by using oid : .1.3.6.1.2.1.2.2.1.8
This displays all the ports with status up or down.
However, I want an oid to check the particular port, e.g. to check whether the 5th port is up or down.
Also, I want an oid to get the MAC Address & IP which is connected to a port, e.g. the MAC Address & IP of a PC which is connected to port 5.
The data about ports is stored in a MIB table. The table OID is .1.3.6.1.2.1.2.2.1, which means, that to get a specific piece of data you must query:
.1.3.6.1.2.1.2.2.1.X.Y
where X is the item index, and Y is the port index. For example the oid for the description of port 10101 is .1.3.6.1.2.1.2.2.1.2.10101:
$ snmpget -mall -v1 -c public <switch_ip> .1.3.6.1.2.1.2.2.1.2.10101
IF-MIB::ifDescr.10101 = STRING: GigabitEthernet0/1
To get all the data in the ports table you can query it like this:
$ snmpwalk -mall -v1 -c public <switch_ip> .1.3.6.1.2.1.2.2.1
To get MAC addresses on a specific port you can query the FDB in BRIDGE-MIB:
$ snmpwalk -mall -v1 -c public <switch_ip> .1.3.6.1.2.1.17.4.3.1.2
Since switching on 2960 is mostly a layer 2 operation, there is no way to get the corresponding IP addresses, unless you set it up as router.
I need to know how to connect to a beaglebone (or beagleboard) with SSH when I plug it into a new network with an ethernet cable like this:
$ ssh root#beaglebone.local
So far I've only been able to access it like this, if I know the IP address:
$ ssh root#<ip_address>
But I don't always know the IP address of the board on new networks so I'm hoping to access it with with a name like: beaglebone.local.
Right now when I try to do this I get this error:
"ssh: Could not resolve hostname beaglebone.local: nodename nor servname provided, or not known"
I checked the hostname and hosts files, and added "127.0.0.1 beaglebone" to the hosts on the beaglebone, but not sure what else I can do?
# cat /etc/hostname
beaglebone
# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
127.0.0.1 beaglebone
I had a similar issue running my beaglebone on Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.04.22.img.xz. In this distribution, "beaglebone.local" should appear on the network after the system boots.
About 50% of the time after reboot, "beaglebone.local" would not appear on the network (although the bone would be available by IP address). When this happened, "systemctl status avahi-daemon.service" showed that the avahi-daemon failed with "exit code 255". Interestingly, a subsequent "systemctl start avaihi-daemon.service" would always be successful and "beaglebone.local" would appear on the network.
Also "journalctl | grep avahi" returned a single message stating something like "Daemon already runnin gon PID NNN".
So, I "fixed" the problem by adding the line "ExecStartPre=/bin/rm -f /var/run/avahi-daemon/pid" to the [Service] section of /lib/systemd/system/avahi-daemon.service. With this addition, "beaglebone.local" now appears on the network 100% of reboots.
I say "fixed" (i.e., in quotes) because I have not been able to track down the root cause that is leaving around the stray avahi pid file(s) and thus don't have a true fix.
-- Frank
For 'beaglebone.local' to work, your host machine must recognize Zeroconf. The BeagleBone uses Avahi to tell other systems on the LAN that it is there and serving up applications and that it should be called a 'beaglebone'. If there are more than one, the second one is generally called 'beaglebone-2.local'.
I hate answering my own questions. The following hack will work until a better way emerges:
This shell script (where xxx.xxx.xxx is the first three numbers in your computer's IP) will find your beaglebone or beagleboard (that is plugged-into ethernet on a new network with DHCP) by looping through all the ip address on the subnet and attempting to login to each as root. If it finds one then try your password. If it doesn't work just hit enter until the loop starts again. If it doesn't find the board then something else is probably wrong.
for ip in $(seq 1 254); do ssh root#xxx.xxx.xxx.$ip -o ConnectTimeout=5; [ $? -eq 0 ] && echo "xxx.xxx.xxx.$ip UP" || : ; done
UPDATE 1
Today I plugged-in the beaglebone and saw Bonjour recognize that it joined the network. So I tried it and it worked. No idea why it decided to all of the sudden but it did. Strange, but true.
I had this issue quite often with Mac OS X 10.7. But unlike Frank Halasz "systemctl status avahi-daemon.service" shown no failure. And in fact the problem was on the Mac side. Restarting Bonjour with the following commands fixed the issue.
$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
$ sudo launchctl load -F /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
I am facing a strange problem on my Ubuntu Karmic system.
When I call getaddrinfo() with AI_PASSIVE and AF_UNSPEC, for an empty host and the UDP 12000 port to get a bindable address, I only get back one IPv4 result (0.0.0.0:12000 for instance).
If I change my call and specify AF_INET6 instead of AF_UNSPEC, then getaddrinfo() returns "Name or service not known".
Shouldn't I get [::]:12000 as a result ?
The same thing happens if I set the host to ::1.
When I call getaddrinfo() without AI_PASSIVE (to get a "connectable" address) for the host "localhost" and the UDP 12000 port, I first get [::1]:12000 then 127.0.0.1:12000.
So apparently, my system is IPv6 ready (I can ping to both IPv4 and IPv6 addresses, as well as DNS resolution). But how is it that I can't get an IPv6 address to bind to with getaddrinfo() ?
Do you guys have any idea about what could be wrong ?
My OS is Ubuntu Karmic, fresh install without any networking tweaking.
Thank you.
P.S: If you have no idea but still want to help me, you can get this sample program or type:
wget http://people.apache.org/~jorton/gai.c
And give me the result of:
$ ./gai -ap null 12000
My result is:
$ ./gai -ap null 12000
getaddrinfo(NULL, "12000", {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG|AI_PASSIVE}) = 0:
family= 2, proto= 6 inet4: addr=0.0.0.0, port=12000
There you can see that I only have one IPv4 result.
This happens on new systems that use eglibc: debian-glibc.
Apparently, there is a bug that requires you to set at least one valid IPv6 address to one of your network interfaces (the loopback doesn't count).
After I did this:
$ sudo ip -6 addr add 2001:660:4701:1001::1 dev eth0
I have:
$ ./gai -ap null 12000
getaddrinfo(NULL, "12000", {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG|AI_PASSIVE}) = 0:
family= 2, proto= 6 inet4: addr=0.0.0.0, port=12000
family=10, proto= 6 inet6: addr=::, port=12000, flowinfo=0
I hope this can help someone.