search for: xhejtman

Hello, is there any reason why even permissive devices cannot write some areas in the PCI config space? The PCI_COMMAND is handled in special way so that the device is enabled/disabled properly, am I right? Why is PCI_INTERRUPT_LINE read from dev->irq and not from the config space? Why the PCI address bars are handled in very different way? And it seems that writing these bars is never

Patch allowing drivers in DomU to restore address bars if needed. Signed-off-by: xhejtman@ics.muni.cz -- Lukáš Hejtmánek _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hello, I'm using sama 3.0.24 on linux machine that serves a share for a windows client. When editing a file on samba, using MS Word I can see there are severals (probably) backup files. ls looks like this: Dotaznik1.doc ~$taznik1.doc ~WRD0000.tmp ~WRD0001.tmp ~WRD0002.tmp ~WRD0003.tmp ~WRD0004.tmp These files do not disappear after I quit the Word. This does not happen if I edit

Hello, I'm facing a bug with winbind. If I request groups for particular domain user, winbind cache gets corrupted. My winbind version is 4.1.12-23.el7_1 (Centos 7.1, x86_64). 1) this is correct UID to SID mapping: wbinfo -U 100152 S-1-5-21-3451901064-902568176-4053310204-180212 2) I request groups info for a user: id -G -n 209459 [reply with 33 groups] 3) I request UID to SID mapping

On Tue, Jun 16, 2015 at 09:12:24AM -0700, Jeremy Allison wrote: > Not that I know of. Can you run winbindd under valgrind ? > Should help debug this. this is the only waring regardless read/write that valgrind reports: ==16475== Syscall param writev(vector[...]) points to uninitialised byte(s) ==16475== at 0xBB32337: writev (in /usr/lib64/libc-2.17.so) ==16475== by 0xA4AC8E4:

Hello, I'm using the Samba server 3.0.33 that exports volume from a GPFS. The GPFS strongly dislikes unlinking files that are locked (resulting in permission denied) using fcntl F_SETLEASE. It seems that the Samba *sometimes* tries to unlink a file that is oplocked. Why? Is this a bug? Why it does not happen always but only sometimes? I have strace logs showing: Wrong case: 8711

Hello, I''m trying to get working infiniband device in Xen. I have Xen v3 with 2.6.18 kernel. I export PCI device from Dom0 into DomU. I''ve enabled permisive device in Dom0. However, inserting infiniband module results in the following messages (with little more verbosity which I have added): pcifront pci-0: Installing PCI frontend pcifront pci-0: Creating PCI Frontend Bus

Hello, I''m trying to get to work InfiniBand card in DomU via exporting PCI device. How does the export works internally? I guess that pci frontend forwards stuff like pci_read_config_dword and pci_write_config_dword to pci backend that actually does it. Am I right? So if the driver of InfiniBand writes some config values to PCI config space and these values are not applied actually,

Hello, so the current domain configuration: <cpu mode='host-passthrough'><topology sockets='8' cores='4' threads='1'/><numa><cell cpus='0-3' memory='62000000' /><cell cpus='4-7' memory='62000000' /><cell cpus='8-11' memory='62000000' /><cell cpus='12-15'

Hello, ok, I found that cpu pinning was wrong, so I corrected it to be 1:1. The issue with iozone remains the same. The spec is running, however, it runs slower than 1-NUMA case. The corrected XML looks like follows: <cpu mode='host-passthrough'><topology sockets='8' cores='4' threads='1'/><numa><cell cpus='0-3'

Hello again, when the iozone writes slow. This is how slabtop looks like: 62476752 62476728 0% 0.10K 1601968 39 6407872K buffer_head 1000678 999168 0% 0.56K 142954 7 571816K radix_tree_node 132184 125911 0% 0.03K 1066 124 4264K kmalloc-32 118496 118224 0% 0.12K 3703 32 14812K kmalloc-node 73206 56467 0% 0.19K 3486 21

Hello, I have cluster with AMD EPYC 7351 cpu. Two CPUs per node. I have performance 8-NUMA configuration: This is from hypervizor: [root@hde10 ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 64 On-line CPU(s) list: 0-63 Thread(s) per core: 2 Core(s) per socket: 16 Socket(s): 2 NUMA