Re: user space device drivers
Prabhu nath wrote: But if the device has to generate an interrupt on the reception of the data then it is best for the driver code to be in the kernel space waiting for the data, rather than in the user space because there is no efficient mechanism till now for the control to be transferred to the waiting user space code on the reception of the interrupt. What are the curently available mechanisms for an interrupt to propagate into user space? Is there one that affects the scheduler? - Gergely ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
how to debug oom killer errors
Hi, How to decode the stats thrown by the oom killer ? Is there any good in depth documentation out there for this ? Node 0 DMA per-cpu: cpu 0 hot: high 0, batch 1 used:0 cpu 0 cold: high 0, batch 1 used:0 Node 0 DMA32 per-cpu: cpu 0 hot: high 186, batch 31 used:25 cpu 0 cold: high 62, batch 15 used:49 Node 0 Normal per-cpu: empty Node 0 HighMem per-cpu: empty Free pages:3532kB (0kB HighMem) Active:4471 inactive:4099 dirty:1 writeback:0 unstable:0 free:883 slab:14568 mapped-file:542 mapped-anon:8049 pagetables:1033 Node 0 DMA free:368kB min:44kB low:52kB high:64kB active:0kB inactive:0kB present:9700kB pages_scanned:0 all_unreclaimable? yes lowmem_reserve[]: 0 632 632 632 Node 0 DMA32 free:3164kB min:3192kB low:3988kB high:4788kB active:17884kB inactive:16396kB present:647348kB pages_scanned:920345 all_unreclaims lowmem_reserve[]: 0 0 0 0 Node 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 30*4kB 7*8kB 2*16kB 1*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 368kB Node 0 DMA32: 81*4kB 53*8kB 65*16kB 23*32kB 0*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 3164kB Node 0 Normal: empty Node 0 HighMem: empty 8602 pagecache pages Swap cache: add 21037, delete 12988, find 320/473, race 0+1 Free swap = 940120kB Total swap = 1020116kB Out of memory: Killed process 2024, UID 51, (sendmail). Regards. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: how do i read a block
Hi, On Mon, May 13, 2013 at 9:52 PM, Matthias Brugger matthias@gmail.com wrote: El 13/05/2013 10:07, shampavman shampavman...@gmail.com va escriure: Hi all, Supposing i create a file of size 10K, it will occupy 2 blocks (4K each). Now if i want to read only 1 block from it how can i do it? read(fd, buf, 4096) ; would this mean i would read the first block and all its contents? One way to do this is use the FIBMAP ioctl to the get the block numbers of a file and then seek the disk /dev/sdX directly and use the read() to get data block. Regards. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: user space device drivers
One that I know is through proc interface where the interrupt info is lodged in a file in /proc and the user code keeps polling on this file. Exact use of this is to be looked for. On Tue, May 14, 2013 at 3:24 PM, Gergely Buday gbu...@gmail.com wrote: Prabhu nath wrote: But if the device has to generate an interrupt on the reception of the data then it is best for the driver code to be in the kernel space waiting for the data, rather than in the user space because there is no efficient mechanism till now for the control to be transferred to the waiting user space code on the reception of the interrupt. What are the curently available mechanisms for an interrupt to propagate into user space? Is there one that affects the scheduler? - Gergely -- Regards, Prabhunath G Linux Trainer Bangalore ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
PCIe MSI smp_affinity for ARM architecture
Hello, I have an ARM platform board. I need to change the smp_affinity of PCIe MSI interrupt. The drivers/pci/msi.c file does not any function for changing the smp_affinity. Any pointers as to how to change the affinity would be very helpful. Regards, Amit. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
PCIe MSI smp_affinity for ARM architecture
Hello, I have an ARM platform board. I need to change the smp_affinity of PCIe MSI interrupt. The drivers/pci/msi.c file does not any function for changing the smp_affinity. Any pointers as to how to change the affinity would be very helpful. Regards, Amit.___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: bio size is always 4096
Hi Neha On 5/13/13, neha naik nehanai...@gmail.com wrote: Hi, I was under the impression that when the bio comes to a block device driver its size is variable. But, after writing a block device driver i realized that such is not the case and it always is 4096. Your Filesystem block size is usually page size so from file system point of view your bios would be that of block size that the filesystem understands. Try having a file system block size other than PAGE_SIZE (must be multiple of 512 and =PAGE_SIZE) though. Does this mean that by default if i don't use any merge function the bio will always have size 4096(meaning it will have only 1 page). I guess it's not about that if you don't use a merge function. Bios would be given by file system to your driver depending on the block size of the file system. Now there would most probably be a mismatch of granularity of file system block size and your device's block size. If every thing is default and File System block size == PAGE_SIZE and by default the block size for your device is taken to be 512 (kernel always works in 512 bytes for block device). This means 4096/512 = 8 sectors per bio. Actually if you see this, set_min_blocksize This would make it clear that the block size of the file system would be larger of the block size of block size of your device and the block size of your file system. I guess while formatting the mkfs would also try to match it like that or it may be fixed. You can change the block size of your device by doing blk_queue_logical_block_size before you make you add your disk. Again, if you do this your request handling function must be able to translate everything to/from 512 bytes since for kernel everything is in 512 size sectors. So you can check a) By changing the block size of file system first. b) By changing the block size of device. c) Do both By changing i mean don't use PAGE_SIZE for file system and don't use 512 bytes for device's block size. Regards, Neha ---P.K.S -- Pranay Srivastava ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: user space device drivers
On May 13, 2013, at 9:52 PM, Gergely Buday gbu...@gmail.com wrote: Hi there, I learned, e.g. from here that user space device drivers are indeed possible: http://www.makelinux.net/ldd3/chp-2-sect-9 Are there serious user space drivers in Linux? Could you name a few? Or, is this just for hacking a driver for your home-made hardware? - Gergely ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Some are suggested in the ldd3 link, for example SANE (scsi scanner devices). http://www.sane-project.org/source.html You can find sources there. - Pietro ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: user space device drivers
On Mon, May 13, 2013 at 9:52 PM, Gergely Buday gbu...@gmail.com wrote: Hi there, I learned, e.g. from here that user space device drivers are indeed possible: http://www.makelinux.net/ldd3/chp-2-sect-9 Are there serious user space drivers in Linux? Could you name a few? UIO has lots of serious users. One prominent VFIO user is qemu/kvm. -- Thanks, //richard ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Wake on Lan and pci_enable_wake()
Hello, As far as I know, Wake On Lan is disabled by default in Linux. Now I try this on p2p1: ethtool -i p2p1 ... driver: r8169 ... ethtool p2p1 .. Wake-on: g ... this means, according to the man, that Wake on Lan is enabled for MagicPacket packets on p2p1 Now I looked in the code of the driver and I cannot see anywhere a call to pci_enable_wake(); see drivers/net/ethernet/realtek/r8169.c So any ideas how come that the Wake on Lan is enabled for this driver after boot ? rgs, Andy ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: user space device drivers
On Tue, May 14, 2013 at 11:54 AM, Gergely Buday gbu...@gmail.com wrote: Prabhu nath wrote: But if the device has to generate an interrupt on the reception of the data then it is best for the driver code to be in the kernel space waiting for the data, rather than in the user space because there is no efficient mechanism till now for the control to be transferred to the waiting user space code on the reception of the interrupt. What are the curently available mechanisms for an interrupt to propagate into user space? See VFIO and UIO. Even the gpio sysfs interface allows you to catch interrupts. Is there one that affects the scheduler? ??? -- Thanks, //richard ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: user space device drivers
I think the webpage itself will talk what are the drivers that are preferred in the user space. In principle, following are the broad constituents of any device driver. 1. code operating on device registers / device memory / device FIFO (through device registers) 2. code operating on some data in the system memory. The main reason why drivers are preferred in the kernel space is accessibility of device registers/memory i.e. the device registers/memory can be mapped to the kernel virtual address space (the vmalloc region). With the help of *mmap()* system call and with the help of * remap_pfn_range()* kernel function the device registers/memory can be mapped to the user virtual address space and thus we can make the driver code in the user space access the device registers/memory. Also the user code can allocate memory in the system memory and access it. But the main point of debate/concern is how the data is sent or received to/from the device. Sending data to the device will happen at the trigger of the application. Thus when ever an application intends to send data to the device, the device driver code can write to the device memory or device FIFO (through device registers) mapped to the virtual address space (either user virtual address or kernel virtual address). This can be done both by the code at the user space as well at the kernel space easily. Receiving data from the device has two mechanisms. * Device can be polled for data or * Driver code can wait for the data from the device ( normally happens through interrupt mechanism) If the device is polled for data then it can happen either from the user space or kernel space. But if the device has to generate an interrupt on the reception of the data then it is best for the driver code to be in the kernel space waiting for the data, rather than in the user space because there is no *efficient *mechanism till now for the control to be transferred to the waiting user space code on the reception of the interrupt. Thus to conclude, drivers are preferred to be placed in the kernel space for the devices whose data have to be received through interrupt mechanism. Hence we see drivers' for most of the output devices (E.g. display device ) are preferred to be in the user space and for most of the input devices (E.g. mouse, keyboard) and network devices (E.g. Ethernet card) are preferred to be in the kernel space. -- Regards, Prabhunath G Linux Trainer Bangalore On Tue, May 14, 2013 at 1:22 AM, Gergely Buday gbu...@gmail.com wrote: Hi there, I learned, e.g. from here that user space device drivers are indeed possible: http://www.makelinux.net/ldd3/chp-2-sect-9 Are there serious user space drivers in Linux? Could you name a few? Or, is this just for hacking a driver for your home-made hardware? - Gergely ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: user space device drivers
Are there serious user space drivers in Linux? Could you name a few? Printer drivers, scanner drivers, file system drivers etc. How can I find them? Are they in the kernel source tree? - Gergely ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86
Hi Sergio, On Tue, May 14, 2013 at 12:41 AM, Sergio Andrés Gómez del Real sergio.g.delr...@gmail.com wrote: I've got some questions regarding this linear to physical address mapping on x86 architecture; I'm not sure I've grassped the whole thing. Before asking, I'd like to be sure I understand some basic things about this: 1. Addresses within the kernel are linked to start at 0xC000 so, that the kernel issues linear addresses starting at gigabyte 3 is really accomplished at link time through a linker directive. 2. User applications are linked to addresses somewhere at 0x-0xBFFF. 3. There is a data structure (struct page), immediately following the kernel image in physical memory. It describes all page frames available. 4. The kernel creates its own page-relative structures. It maps linear addresses starting at 0xC000 linearly starting at physical address 0x. So, accessing this linear space is equivalent to accessing Physical address may not be always 0x_. It can be mapped any where. physical memory, because the map is linear and the conversion between linear to physical address is always a constant (0xC000)· 5. The last part of the kernel's linear address space is reserved for temporarily mapping high memory (is this strictly true?). If all of this is true, here are my questions: 1. The problem of accessing high memory is EXCLUSIVE to the kernel, right? It doesn't affect user-space applications, because it's linear address, 0x-0xBFFF, can be mapped anywhere in physical memory, by just writing the high-memory address to the appropiate page tables. Is this right? 2. When user applications allocates memory, the kernel must allocate virtual memory and physical memory, right? For example, the kernel would first allocate some linear address from the processes' address space, and then find some suitable page frames where to map this linear address. It would just write to the appropiate page tables; specifically, the page frames can come from low memory or high memory, i.e the high memory problem does not affect user-space physical memory allocations. Is this entirely correct? 3. Is physical memory allocated to user-space generally satisfied from high memory? Yes. High mem is the first priority. thanks, Arun 4. When does the kernel allocate pages from high memory to itself? Thanks in advance to anyone who replies. On 5/13/13, Prabhu nath gprabhun...@gmail.com wrote: Is this is a question that popped up to your mind arbitrarily or do you have a specific system at hand which triggered you to ponder over the design of the kernel ? I felt the answer to this question is not straight forward but is multi faceted and to be discussed in a specific context. On Sat, May 11, 2013 at 9:02 AM, Paul Davies C pauldavi...@gmail.comwrote: In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is permanently mapped to the kernel address space.This leaves a 128MB free space in the Kernel address space and according to my understanding, the ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the system actually had a 4GB physical memory you will be mapping(not smultaneously) the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that was the case Kernel would have to frequently access HIHGMEM which implicates a frequent change in temporaty mapping and that in my view is a penalty. So what was the reason why ZONE_NORMAL fixed at 896MB and not something really lower? -- *Regards,* *Paul Davies C* vivafoss.blogspot.com -- Regards, Prabhunath G Linux Trainer Bangalore ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: user space device drivers
On Tue, May 14, 2013 at 10:18 AM, Gergely Buday gbu...@gmail.com wrote: Are there serious user space drivers in Linux? Could you name a few? Printer drivers, scanner drivers, file system drivers etc. How can I find them? Are they in the kernel source tree? They are everywhere except the kernel source. -- Thanks, //richard ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86
It is an arbitrary question that popped in my mind. However, I came to know that the constraints I stated in the previous mail is only restricted to x86 only.Now besides my first questions , I have one more question, Why x86 only? On Tue, May 14, 2013 at 2:34 AM, Sergio Andrés Gómez del Real sergio.g.delr...@gmail.com wrote: Sure, I forgot what you said; precisely the mechanism allows to use lots of linear space without necessarily allocating physical memory (demand paging and the like). What about the rest of what I said? Is it correct or is there something wrong about it? Thanks. On 5/13/13, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: On Mon, 13 May 2013 14:11:22 -0500, Sergio Andr said: 2. When user applications allocates memory, the kernel must allocate virtual memory and physical memory, right? Wrong. If userspace allocates (say) 15M of memory, the kernel has every right to overcommit and not actually allocate either physical memory or backing page space for all 15M. It instead maps it as a non-existent virtual address, and if/when the application actually touches the page, it generates a page fault, and *then* the kernel does the allocating of physical memory and maybe swap space. -- *Regards,* *Paul Davies C* vivafoss.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: user space device drivers
Are there serious user space drivers in Linux? Could you name a few? Printer drivers, scanner drivers, file system drivers etc. Hope this helps, Sannu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86
On Tue, 14 May 2013 11:15:35 +0530, Paul Davies C said: It is an arbitrary question that popped in my mind. However, I came to know that the constraints I stated in the previous mail is only restricted to x86 only.Now besides my first questions , I have one more question, Why x86 only? It's architecture dependent. X86 has a lot of legacy crap that most other archs never had to deal with (for instance, I/O controllers that could only do DMA under the 16M line because they only supported 24 address lines). Most other archs have either been design stable (for example alpha), or they did it mostly right the first time. X86 is the only major arch that's really grown from 16 bit to 32 to 64, accumulating cruft all the way. pgpyVbbxKQv0L.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86
Well, I came up with the same question: Why 896MB (almost all the linear space) is permanently mapped linearly to physical memory? The alternative would be to map just the amount that accounts to the kernel image and the uninitialized data, and then dinamically map the rest. I'd guess that the tradeoff is better performance in most cases, at the cost of flexibility in the mappings, because little space is left to map potentially enormous amounts of physical memory. El 14/05/2013, a las 0:45, Paul Davies C pauldavi...@gmail.com escribió: It is an arbitrary question that popped in my mind. However, I came to know that the constraints I stated in the previous mail is only restricted to x86 only.Now besides my first questions , I have one more question, Why x86 only? On Tue, May 14, 2013 at 2:34 AM, Sergio Andrés Gómez del Real sergio.g.delr...@gmail.com wrote: Sure, I forgot what you said; precisely the mechanism allows to use lots of linear space without necessarily allocating physical memory (demand paging and the like). What about the rest of what I said? Is it correct or is there something wrong about it? Thanks. On 5/13/13, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: On Mon, 13 May 2013 14:11:22 -0500, Sergio Andr said: 2. When user applications allocates memory, the kernel must allocate virtual memory and physical memory, right? Wrong. If userspace allocates (say) 15M of memory, the kernel has every right to overcommit and not actually allocate either physical memory or backing page space for all 15M. It instead maps it as a non-existent virtual address, and if/when the application actually touches the page, it generates a page fault, and *then* the kernel does the allocating of physical memory and maybe swap space. -- Regards, Paul Davies C vivafoss.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: how do i read a block
On 05/14/2013 11:59 AM, Prashant Shah wrote: Hi, On Mon, May 13, 2013 at 9:52 PM, Matthias Brugger matthias@gmail.com wrote: El 13/05/2013 10:07, shampavman shampavman...@gmail.com va escriure: Hi all, Supposing i create a file of size 10K, it will occupy 2 blocks (4K each). Now if i want to read only 1 block from it how can i do it? read(fd, buf, 4096) ; would this mean i would read the first block and all its contents? One way to do this is use the FIBMAP ioctl to the get the block numbers of a file and then seek the disk /dev/sdX directly and use the read() to get data block. But why does a simple read not turn out 1 block for me? Eg, i know my block size if 4k and my file (according to du) reports that it's using 8k of space. So when i read the file via the read() and ask it to give me the 'first 4k' bytes, would that not return 1 block ? thanks Regards. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: how do i read a block
On Tue, 14 May 2013 12:05:32 +0530, shampavman said: But why does a simple read not turn out 1 block for me? So explain to us why you think a read of 4096 bytes is reading something other than 1 4K block? pgpSyX0_YYYeT.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
