- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

spi_async inside IRQ handler and spin_(un)lock_irq* doubt.
by Daniel. Nov. 11, 2015

Nov. 11, 2015

Hi everybody! I'm using an gpio expansion called MCP23s17 from Microchip as a digital input device. There are 6 input ports at my device. The MCP is configured to generate an interrupt at input state change (from 0 to 1, or 1 to 0, what ever), the interrupts are disabled on MCP until the INTCAP register is readed. This register holds a byte where each bit represent the input port state at interrupt time. So my code does like this: #1 An interrupt ocurred #2 I initialize a spi_message to get INTCAP and fires a spi_async_locked. #3 The SPI core do its stuff #4 The complete callback is called. It gets the INTCAP value and put it on a circular queue to be read after by the user application. So basicaly I enqueue INTCAP values to be consumed by user's application. So far not so good. I'm facing problems of NULL pointers at kernel after sometime when high throughput happens and/or when multiple inputs changes at same time. The spi_message used at #2 is always in the same memory area, allocated at probe time. What I'm think is happening is that a new interrupt is happening while step #3 is running, so spi_message_init() is called on a message about to be transferred, and when is transferred I got the NULL pointer handling error. So I put a spin_lockirqsave() at step #2 before messing up with the spi_message buffer and spin_unlock_irqrestore() at step #4. If spi_async_locked() fails I unlock it too. But this make a big doubt arises in my head. Since interrupts are disabled at the chip (this is farly common) until I read some register, should still I use spin_lock_irqsave()/restore() routines or I'm safe to keep with normal spin_lock() ones? What happens if an interrupt (from other hardware for example) happens while a spin lock is held? Here is the code: http://pastebin.com/JTubAHuz Thanks in advance, -- "Do or do not. There is no try" Yoda Master

1 0

How to read last oops message in Android kernel
by Umair Khan Nov. 11, 2015

Nov. 11, 2015

Hi, I'm working on the kernel of my xiaomi device. However, whenever I start it, it soft reboots to recovery. I'm guessing a kernel oops occur. I wanted to ask how to read kernel debug messages of the last run ? In my Nexus 5, I have /proc/last_kmsg which contains the messages from the last run. However, in my xiaomi kernel tree, that proc entry is removed. Responsible commit - https://github.com/omerjerk/android_kernel_xiaomi_ferrari/commit/15d7644620… It says that functionality has been moved to pstore. But I'm not able to get how to exactly read the debug messages of the last run. Thanks Umair

2 3

Informing kernel that a block device is offlined
by Alvin Abitria Nov. 11, 2015

Nov. 11, 2015

Hello, Good day. My inquiry is about block drivers. Suppose our device encounter problems and all error handling failed. The only remaining option I see for the driver to do is to offline it. The intention is for the system to be notified to avoid sending any future request to the device and be inaccessible so any wicked behavior, like system crash, are avoided. This should work whether the device is used standalone or with RAID. The question is how to do it cleanly. I've searched existing drivers in the kernel source (like sd, skd, etc), and all they do (as I see it) is to complete succeeding requests with -EIO (__blk_end_request_all(rq, -EIO)). So far this works with FIO, because once that happens and all fio requests are completed with -EIO, fio stops sending further requests. But if used with RAID and unrecoverable fault is triggered, just completing requests with error seems not to be working. RAID detects errors, but can't remove the erring device from its system. Sometimes kernel is still sending requests to the RAID'ed faulty device (which should stop). RAID becomes degraded (in a not-so-good way) and eventually crashes the system. So how does the block driver properly informs the upper layers that its device is faulty and must not be used again for that session? Best regards, Alvin

1 0

Re: Improvement of trails and tutorials to become a kernel developer / maintainer
by Albino B Neto Nov. 6, 2015

Nov. 6, 2015

2015-11-06 15:15 GMT-02:00 Patrick Plattes <patrick(a)erdbeere.net>: > ello, > > I'm interested since a very long time in kernel development, but I > never saw the right path to become familiar with parts of the kernel. > I read a bit of ipc code and ext* code, but since I often don't know > any possible next steps I moved back to something else in the user > space. > > I really like the tutorial on kernelnewbies.org FirstKernelPatch an I > had the idea to create this type of tutorial as a training for > specific kernel subsystems eg. ipc, file systems, usb drivers, ... > > A structure of such a tutorial could look like that: (eg scheduler) > > 1. Introduction / Goal > [5 sentences of the goal - what should be archived by this tutorial] > - understand scheduling in the linux kernel > - write your own scheduler > - ... > 2. Preparation > 2.1 Understand how to write a kernel patch: > http://kernelnewbies.org/FirstKernelPatch > 2.2 Understand the goal of Scheduling: https://en.wikipedia.org/wiki/Schedule > 3. User space view > 3.1 Read and understand: http://man7.org/linux/man-pages/man7/sched.7.html > 3.1.1 Questions > 3.2 Exercise: Write a program that does A > 3.3 Exercise: Write a program that does B > 3.4 Exercise: Write a program that does C > 4. Kernel > 4.1 Read and understand: http://man7.org/linux/man-pages/man7/sched.7.html > 4.1.1 Questions > 4.2 Read API description: http://... > 4.3 Exercise (understanding): Read and understand function xxxx_yyyy() > 4.4 Exercise (understanding: Change the implementation of xxxx_yyyy(), > so that ... > 4.5 Exercise (debugging): checkout version 123456 and fix the > following (old) bug > 4.6 Final Exercise (developing): Write your own scheduler with the > following algorithm... > > In my opinion that could help a lot of interested people to have a > guided tour though the kernel. It could really lower barriers, also in > terms of the fear of communication. > > I am NOT able to to produce it by myself, but I can help to structure > it, review it and also answer questions. I would also maintain them in > case of changes and test the tutorials on a regular basis to keep them > up to date. I also would improve the tutorial from a newbie point of > view ;) > > If there is someone out there that is also interested in doing it > please let me know. > > And if there is something like this out there please let me know, so I > can maybe support this project :) Add mailing kernelnewbies. Albino

1 0

How to mark suspicious code?
by Ivan Safonov Nov. 6, 2015

Nov. 6, 2015

Hi all! How can I mark suspicious code, if I can not fix it?

3 5

Regadring Linux Scatter Gather List
by babu subash Nov. 6, 2015

Nov. 6, 2015

Hi All, I have a basic query regarding the DMA. After the SG list is prepared and mapped using dma_map_sg(). we need to do DMA transfer. Here the list will give the bus addresses of source SG list. In my one of the earlier project in vxworks, I had a DMA registers which provided the src and dst address register and mode. where we use to fill both addresses, size and direction. But here how to specify the destination addresses. Please let me know. In one of the driver I saw this method: dmaflags = claim_dma_lock(); set_dma_mode(); /* Read / Write */ set_dma_addr(dma, dma_addr); set_dma_count(dma, size); enable_dma(dma); release_dma_lock(dmaflags); Here the dma_addr will be the address will be given that we get from the SG list mapped address list which becomes the src address for write on that channel. But to give the dest address where to write on to particular offset on data buffer?? Is the issue... Is there any other methods should we use? Regards, Subash

1 0

Get user stackpointer from task_struct
by Shirish Gajera Nov. 6, 2015

Nov. 6, 2015

Hi, I have kcore and I want to get userspace backtrace from kcore. I looked at some macro <https://www.kernel.org/doc/Documentation/kdump/gdbmacros.txt> but still this is just giving me kernel backtrace only. What I want is userspace backtrace. Good news is I have pointer to task_struct. task_struct->thread->sp (Kernel stack pointer) task_struct->thread->usersp (user stack pointer) but this is junk My question is how to get userspace backtrace (or stack pointer) from kcore or task_struct ? - Shirish

2 1

How to properly write tests for kernel functions
by Maxim Pugachev Nov. 5, 2015

Nov. 5, 2015

Hi all, I'm trying to understand is there any uniform way to write tests? For example, lib/ folder has a bunch of tests, but all of them use various technics: - pr_warn/pr_err (i.e. printk) or WARN for assertions - just tens of functions that check something, or unified macros - no naming convention for test cases So, I'm wondering, whether there is an example or guidelines that is worth to follow. Thanks!

2 4

[PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
by Gabriel L. Somlo Nov. 4, 2015

Nov. 4, 2015

From: "Gabriel Somlo" <somlo(a)cmu.edu> Allow access to QEMU firmware blobs, passed into the guest VM via the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name, size, and fw_cfg key), as well as the raw binary blob data may be accessed. The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was selected based on overall similarity to the type of information exposed under /sys/firmware/dmi/entries/... NEW (since v2): Using ACPI to detect the presence and details of the fw_cfg virtual hardware device. Device Tree has been suggested by Ard as a comment on v2 of this patch, but after some deliberation I decided to go with ACPI, since it's supported on both x86 and some (uefi-enabled) versions of aarch64. I really don't see how I'd reasonably use *both* DT (on ARM) *and* ACPI (on x86), and after all I'm mostly concerned with x86, but originally wanted to maximize portability (which is where the register probing in earlier versions came from). A patch set generating an ACPI device node for qemu's fw_cfg is currently under review on the qemu-devel list: http://lists.nongnu.org/archive/html/qemu-devel/2015-09/msg06946.html (sorry, gmane appears down at the moment...) In consequence: - Patch 1/4 is mostly the same as in v2; - Patch 2/4 switches device initialization from register probing to using ACPI; this is a separate patch only to illustrate the transition from probing to ACPI, and I'm assuming it will end up squashed on top of patch 1/4 in the final version. - Patches 3/4 and 4/4 add a "human-readable" directory hierarchy built from tokenizing fw_cfg blob names into '/'-separated components, with symlinks to each 'by_key' blob folder (same as in earlier versions). At Greg's suggestion I tried to build this folder hierarchy and leaf symlinks using udev rules, but so far I haven't been successful in figuring that out. If udev turns out to be applicable after all, these two patches can be dropped from this series. In other words, patches 1 and 2 give us the following "by_key" listing of blobs contained in the qemu fw_cfg device (example pulled from a PC qemu guest running Fedora 22), with the value of each "name" attribute shown on the right: $ tree /sys/firmware/qemu_fw_cfg/ /sys/firmware/qemu_fw_cfg/ |-- by_key | |-- 32 | | |-- key | | |-- name ("etc/boot-fail-wait") | | |-- raw | | `-- size | |-- 33 | | |-- key | | |-- name ("etc/smbios/smbios-tables") | | |-- raw | | `-- size | |-- 34 | | |-- key | | |-- name ("etc/smbios/smbios-anchor") | | |-- raw | | `-- size | |-- 35 | | |-- key | | |-- name ("etc/e820") | | |-- raw | | `-- size | |-- 36 | | |-- key | | |-- name ("genroms/kvmvapic.bin") | | |-- raw | | `-- size | |-- 37 | | |-- key | | |-- name ("etc/system-states") | | |-- raw | | `-- size | |-- 38 | | |-- key | | |-- name ("etc/acpi/tables") | | |-- raw | | `-- size | |-- 39 | | |-- key | | |-- name ("etc/table-loader") | | |-- raw | | `-- size | |-- 40 | | |-- key | | |-- name ("etc/tpm/log") | | |-- raw | | `-- size | |-- 41 | | |-- key | | |-- name ("etc/acpi/rsdp") | | |-- raw | | `-- size | `-- 42 | |-- key | |-- name ("bootorder") | |-- raw | `-- size | ... Additionally, patches 3 and 4 (mostly 4) give us the following "user friendly" directory hierarchy as a complement to the above, based on tokenizing each blob name into symlink-tipped (sub)directories: ... |-- by_name | |-- bootorder -> ../by_key/42 | |-- etc | | |-- acpi | | | |-- rsdp -> ../../../by_key/41 | | | `-- tables -> ../../../by_key/38 | | |-- boot-fail-wait -> ../../by_key/32 | | |-- e820 -> ../../by_key/35 | | |-- smbios | | | |-- smbios-anchor -> ../../../by_key/34 | | | `-- smbios-tables -> ../../../by_key/33 | | |-- system-states -> ../../by_key/37 | | |-- table-loader -> ../../by_key/39 | | `-- tpm | | `-- log -> ../../../by_key/40 | `-- genroms | `-- kvmvapic.bin -> ../../by_key/36 `-- rev The trick is to figure out how to replace patches 3 and 4 with a udev rule that would read the contents of each "name" attribute, and build the "by_name" hierarchy and symlinks in userspace. I tried: $ udevadm info -a -p /sys/firmware/qemu_fw_cfg/by_key/33 looking at device '/firmware/qemu_fw_cfg/by_key/33': KERNEL=="33" SUBSYSTEM=="" DRIVER=="" ATTR{key}=="33" ATTR{name}=="etc/smbios/smbios-tables" ATTR{size}=="388" looking at parent device '/firmware/qemu_fw_cfg/by_key': KERNELS=="by_key" SUBSYSTEMS=="" DRIVERS=="" looking at parent device '/firmware/qemu_fw_cfg': KERNELS=="qemu_fw_cfg" SUBSYSTEMS=="" DRIVERS=="" ATTRS{rev}=="1" Then I tried creating a file, /usr/lib/udev/rules.d/99-qemu-fw-cfg.rules containing the following line: KERNELS=="qemu_fw_cfg", ATTRS{rev}=="1", SYMLINK="%p/%s{name}" but NOTHING happens when I insert/remove qemu_fw_cfg.ko. I also tried: KERNELS=="qemu_fw_cfg", ATTRS{rev}=="1", PROGRAM="/foo %k" where "/foo" basically did "echo $* > /tmp/bar", but no /tmp/bar file ever showed up as a consequence of inserting/removing the qemu_fw_cfg.ko module. At this point, I need help figuring out whether udev is really what would get the second, user-friendly, "by_name" /sysfs directory tree created, and how I'd go about that... Thanks much, --Gabriel Gabriel Somlo (4): firmware: introduce sysfs driver for QEMU's fw_cfg device firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver kobject: export kset_find_obj() for module use firmware: create directory hierarchy for sysfs fw_cfg entries .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 213 ++++++++ drivers/firmware/Kconfig | 10 + drivers/firmware/Makefile | 1 + drivers/firmware/qemu_fw_cfg.c | 575 +++++++++++++++++++++ lib/kobject.c | 1 + 5 files changed, 800 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg create mode 100644 drivers/firmware/qemu_fw_cfg.c -- 2.4.3

8 16

Bluetooth doesn't work
by Kinka Huang Nov. 4, 2015

Nov. 4, 2015

Hi all, Thinkpad X1 2015, ubuntu 15.10, the bluetooth module seems not work well. Once connect, it prints the following kernel log: [ 196.730943] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.730946] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.730948] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.740970] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.740975] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.740976] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 201.764755] Bluetooth: hci0 SCO packet for unknown connection handle 257 [ 201.764768] Bluetooth: hci0 SCO packet for unknown connection handle 257 [ 201.764777] Bluetooth: hci0 SCO packet for unknown connection handle 257 and something I think related while kernel initing: [ 3.738275] usbcore: registered new interface driver btusb [ 3.754215] Bluetooth: hci0: read Intel version: 370810011003110e00 [ 3.755429] Adding 7999996k swap on /swap/swapfile. Priority:-1 extents:66 across:13275644k SSFS [ 3.757145] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq I think it is a good chance for me to diving into the linux kernel, so can anyone offer some hints that I could solve this problem. $ uname -ar Linux kinka-X1 4.3.0-rc7+ #50 SMP Wed Oct 28 22:49:01 CST 2015 x86_64 x86_64 x86_64 GNU/Linux Many thanks~ Kinka

1 0