From jinzhao at wingtech.com Tue Sep 1 05:24:10 2015 From: jinzhao at wingtech.com (jinzhao at wingtech.com) Date: Tue, 1 Sep 2015 17:24:10 +0800 Subject: read emmc partition References: Message-ID: <2015090117240925741910@wingtech.com> Dear All: Is there any interface which can be read the emmc partition? as "emmc_partition_rw("proinfo", cmd, PARAM_SEEK, tmp_buf, size)" Thanks! jinzhao at wingtech.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150901/f43d8a81/attachment.html From ronag89 at gmail.com Tue Sep 1 14:34:41 2015 From: ronag89 at gmail.com (Robert Nagy) Date: Tue, 1 Sep 2015 20:34:41 +0200 Subject: MADV_ZERO Message-ID: I have recently switched over to Linux after encountering an issue that seems unsolvable in Windows with the hope of finding a solution in Linux. Basically what I need to achieve is IPC persisted to a huge file. I?m doing this currently by memory-mapping a huge backing file and always sequentially writing to the file in a circular fashion 24/7. However, this has some major throughput issues since overwriting pages will always cause a page-faults, even if entire pages are overwritten, which totally trashes disk performance. Basically I would need a flag for madvice (e.g. MADV_ZERO) with similar functionality to FALLOC_FL_ZERO_RANGE so that I would get much faster zero fill page faults instead. The closest I?ve come is to use MADV_REMOVE before overwriting the range, however, that is a suboptimal as it will from my understanding fragment the backing file and potentially degrade performance over time. What I?d like to be able to do is something like: int mm_fast_write(void* dst, void* src, size_t length) { if (dst & ~PAGE_MASK) return -EINVAL; if (src & ~PAGE_MASK) return -EINVAL; if (length & ~PAGE_MASK) return -EINVAL; madvice(ptr, len, MADV_ZERO); memcpy(ptr, src, len); madvice(ptr, len, MADV_DONTNEED); // Might not do anything without msync? return 0; } Is it possible to implement or emulate something like MADV_ZERO in user mode? Or should I look into modifying the kernel? I believe it could be implemented based on madvice_remove by simply replacing the FALLOC_FL_PUNCH_HOLE flag with FALLOC_FL_ZERO_RANGE? From jhmccaskill at fastertechnology.com Wed Sep 2 16:51:57 2015 From: jhmccaskill at fastertechnology.com (John McCaskill) Date: Wed, 2 Sep 2015 15:51:57 -0500 Subject: What is the proper Linux suspend / resume kernel reentry point when the processor is powered down and back up Message-ID: <10ade01d0e5c1$382c4aa0$a884dfe0$@com> I am working on expanding the suspend and resume capability for Linux running on a Xilinx Zynq Soc that has dual ARM A9s using the Xilinx 2014.4 PetaLinux distribution that uses the 3.17 kernel. The distribution currently supports suspend and resume without removing power to the processors. I am working on expanding the support to include removing power to the processors while the DDR memory is in self refresh mode, then performing a warm boot and having the first stage boot loader (FSBL) hand control back to the Linux kernel in the correct spot to continue with the resume process. I am looking for what routine to have the first stage boot loader call. I think it might be cpu_resume in arch/arm/kernel/sleep.S, but I am not sure and would like to verify that it is the correct routine to be calling. I am jumping to this from the FSBL after a suspend and warm boot, and single stepping through the code in a debugger. It gets to the end of this routine, but the debugger looses connection near the end of that routine shortly after this instruction is executed: ARM( ldmia r0!, {r1, sp, pc} ) In an effort to see if this is the correct entry point, I have modified pm.c in arch/arm/mach-zynq.c to call soft_restart(virt_to_phys(cpu_resume)) just after the resume has happened in the case where the processors are not powered off, but are woken back up with an interrupt. The soft_restart routine turns off the MMUs and clears the caches, and I am using it to get the processors into a similar state as to what they would be in if they had been power cycled. The cpu_resume routine expects to be called with cache and MMU off. This test mostly works, and gets much further than calling cpu_resume from the FSBL. It gets out of assembly code, and back into C, and is printing messages. The cpu_resume routine expects to be called with cache and MMU off. I have read the Documentation/power/devices.txt file, and anything else I could find. I have already done a version of this that uses the no OS flow to put the DDR into self refresh and power cycle the processors, and tested it on hardware. That flow does not use virtual memory. I have looked for other code that does this, but since the code performing the warm boot is device firmware and not kenel code I have not found an example yet. Is cpu_resume the correct renentry point for resuming after a suspend? Can anyone point me to an example I can look at? Thank you in advance, John McCaskill From victorascroft at gmail.com Thu Sep 3 07:54:45 2015 From: victorascroft at gmail.com (victorascroft at gmail.com) Date: Thu, 3 Sep 2015 17:24:45 +0530 Subject: What is the proper Linux suspend / resume kernel reentry point when the processor is powered down and back up In-Reply-To: <10ade01d0e5c1$382c4aa0$a884dfe0$@com> References: <10ade01d0e5c1$382c4aa0$a884dfe0$@com> Message-ID: <20150903115445.GA4983@Sanchayan-Arch.toradex.int> On 15-09-02 15:51:57, John McCaskill wrote: > I am working on expanding the suspend and resume capability for Linux > running on a Xilinx Zynq Soc that has dual ARM A9s using the Xilinx 2014.4 > PetaLinux distribution that uses the 3.17 kernel. > > The distribution currently supports suspend and resume without removing > power to the processors. I am working on expanding the support to include > removing power to the processors while the DDR memory is in self refresh > mode, then performing a warm boot and having the first stage boot loader > (FSBL) hand control back to the Linux kernel in the correct spot to continue > with the resume process. > > I am looking for what routine to have the first stage boot loader call. I > think it might be cpu_resume in arch/arm/kernel/sleep.S, but I am not sure > and would like to verify that it is the correct routine to be calling. > > I am jumping to this from the FSBL after a suspend and warm boot, and single > stepping through the code in a debugger. It gets to the end of this routine, > but the debugger looses connection near the end of that routine shortly > after this instruction is executed: ARM( ldmia r0!, {r1, sp, pc} > ) > > In an effort to see if this is the correct entry point, I have modified pm.c > in arch/arm/mach-zynq.c to call soft_restart(virt_to_phys(cpu_resume)) just > after the resume has happened in the case where the processors are not > powered off, but are woken back up with an interrupt. The soft_restart > routine turns off the MMUs and clears the caches, and I am using it to get > the processors into a similar state as to what they would be in if they had > been power cycled. The cpu_resume routine expects to be called with cache > and MMU off. This test mostly works, and gets much further than calling > cpu_resume from the FSBL. It gets out of assembly code, and back into C, and > is printing messages. The cpu_resume routine expects to be called with cache > and MMU off. > > I have read the Documentation/power/devices.txt file, and anything else I > could find. > > I have already done a version of this that uses the no OS flow to put the > DDR into self refresh and power cycle the processors, and tested it on > hardware. That flow does not use virtual memory. > > I have looked for other code that does this, but since the code performing > the warm boot is device firmware and not kenel code I have not found an > example yet. > > Is cpu_resume the correct renentry point for resuming after a suspend? > > Can anyone point me to an example I can look at? Some of the suspend resume stuff is very specific to SoC's. For example, look at arch/arm/mach-imx/pm-imx6.c. What and how exactly to do it depends on the SoC in question. For example, which all power domains to take care of, which clocks to bring up how and when and such. Also look at suspend- imx6.S . If you want to trace the functions called in suspend resume process, enable "Power Management Debug support" under "Power management options" when you run menuconfig. After enabling them, you also to need to have "initcall_debug" in bootargs. This should then print out a nice list of all functions called when suspend resume happens. - Sanchayan. From clement.vuchener at gmail.com Sun Sep 6 13:48:06 2015 From: clement.vuchener at gmail.com (=?iso-8859-1?Q?Cl=E9ment?= Vuchener) Date: Sun, 6 Sep 2015 19:48:06 +0200 Subject: How to properly unregister LED class devices? Message-ID: <20150906174806.GA16230@untxi.home> Hello, I am trying to write a driver that uses LED class devices using works for setting the LED brightness but I am not sure of how to unregister the devices. I have been using code like this: led_classdev_unregister(&drvdata->backlight.cdev); cancel_work_sync(&drvdata->backlight.work); trying with both flush_work or cancel_work_sync as I have seen it in other drivers. Using flush_work, the kernel oops in my work function when I unplug the device. cancel_work_sync seems to fix that, but I am not sure it will work every time. I would like to understand what happens and if I am doing something wrong, to be sure it will not break in some different setup. Another problem I have with this unregistering is that the LED brightness is set to zero when unregistering when the hardware is supposed to remember the last settings. Thus the LED state is reset when detaching and reattaching the driver. Below is the full code from my driver, if you need it: /* * HID driver for Corsair devices * * Supported devices: * - Vengeance K90 Keyboard * * Copyright (c) 2015 Clement Vuchener */ /* * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free * Software Foundation; either version 2 of the License, or (at your option) * any later version. */ #include #include #include #include #include "hid-ids.h" struct k90_led { struct led_classdev cdev; int brightness; struct work_struct work; }; struct k90_drvdata { int current_profile; int macro_mode; int meta_locked; struct k90_led backlight; struct k90_led record_led; }; #define K90_GKEY_COUNT 18 static int k90_usage_to_gkey(unsigned int usage) { /* G1 (0xd0) to G16 (0xdf) */ if (usage >= 0xd0 && usage <= 0xdf) return usage - 0xd0 + 1; /* G17 (0xe8) to G18 (0xe9) */ if (usage >= 0xe8 && usage <= 0xe9) return usage - 0xe8 + 17; return 0; } static unsigned short k90_gkey_map[K90_GKEY_COUNT] = { BTN_TRIGGER_HAPPY1, BTN_TRIGGER_HAPPY2, BTN_TRIGGER_HAPPY3, BTN_TRIGGER_HAPPY4, BTN_TRIGGER_HAPPY5, BTN_TRIGGER_HAPPY6, BTN_TRIGGER_HAPPY7, BTN_TRIGGER_HAPPY8, BTN_TRIGGER_HAPPY9, BTN_TRIGGER_HAPPY10, BTN_TRIGGER_HAPPY11, BTN_TRIGGER_HAPPY12, BTN_TRIGGER_HAPPY13, BTN_TRIGGER_HAPPY14, BTN_TRIGGER_HAPPY15, BTN_TRIGGER_HAPPY16, BTN_TRIGGER_HAPPY17, BTN_TRIGGER_HAPPY18, }; module_param_array_named(gkey_codes, k90_gkey_map, ushort, NULL, S_IRUGO); #define K90_USAGE_SPECIAL_MIN 0xf0 #define K90_USAGE_SPECIAL_MAX 0xff #define K90_USAGE_MACRO_RECORD_START 0xf6 #define K90_USAGE_MACRO_RECORD_STOP 0xf7 #define K90_USAGE_PROFILE 0xf1 #define K90_USAGE_M1 0xf1 #define K90_USAGE_M2 0xf2 #define K90_USAGE_M3 0xf3 #define K90_USAGE_PROFILE_MAX 0xf3 #define K90_USAGE_META_OFF 0xf4 #define K90_USAGE_META_ON 0xf5 #define K90_USAGE_LIGHT 0xfa #define K90_USAGE_LIGHT_OFF 0xfa #define K90_USAGE_LIGHT_DIM 0xfb #define K90_USAGE_LIGHT_MEDIUM 0xfc #define K90_USAGE_LIGHT_BRIGHT 0xfd #define K90_USAGE_LIGHT_MAX 0xfd /* USB control protocol */ #define K90_REQUEST_BRIGHTNESS 49 #define K90_REQUEST_MACRO_MODE 2 #define K90_REQUEST_STATUS 4 #define K90_REQUEST_GET_MODE 5 #define K90_REQUEST_PROFILE 20 #define K90_MACRO_MODE_SW 0x0030 #define K90_MACRO_MODE_HW 0x0001 #define K90_MACRO_LED_ON 0x0020 #define K90_MACRO_LED_OFF 0x0040 /* * LED class devices */ #define K90_BACKLIGHT_LED_SUFFIX ":blue:backlight" #define K90_RECORD_LED_SUFFIX ":red:record" static enum led_brightness k90_brightness_get(struct led_classdev *led_cdev) { struct k90_led *led = container_of(led_cdev, struct k90_led, cdev); return led->brightness; } static void k90_brightness_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct k90_led *led = container_of(led_cdev, struct k90_led, cdev); led->brightness = brightness; schedule_work(&led->work); } static void k90_backlight_work(struct work_struct *work) { int ret; struct k90_led *led = container_of(work, struct k90_led, work); struct device *dev = led->cdev.dev->parent; struct usb_interface *usbif = to_usb_interface(dev->parent); struct usb_device *usbdev = interface_to_usbdev(usbif); ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), K90_REQUEST_BRIGHTNESS, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, led->brightness, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); if (ret != 0) dev_warn(dev, "Failed to set backlight brightness (error: %d).\n", ret); } static void k90_record_led_work(struct work_struct *work) { int ret; struct k90_led *led = container_of(work, struct k90_led, work); struct device *dev = led->cdev.dev->parent; struct usb_interface *usbif = to_usb_interface(dev->parent); struct usb_device *usbdev = interface_to_usbdev(usbif); int value; if (led->brightness > 0) value = K90_MACRO_LED_ON; else value = K90_MACRO_LED_OFF; ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), K90_REQUEST_MACRO_MODE, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, value, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); if (ret != 0) dev_warn(dev, "Failed to set record LED state (error: %d).\n", ret); } /* * Keyboard attributes */ static ssize_t k90_show_macro_mode(struct device *dev, struct device_attribute *attr, char *buf) { struct k90_drvdata *drvdata = dev_get_drvdata(dev); return snprintf(buf, PAGE_SIZE, "%s\n", (drvdata->macro_mode ? "HW" : "SW")); } static ssize_t k90_store_macro_mode(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { int ret; struct usb_interface *usbif = to_usb_interface(dev->parent); struct usb_device *usbdev = interface_to_usbdev(usbif); struct k90_drvdata *drvdata = dev_get_drvdata(dev); __u16 value; if (strncmp(buf, "SW", 2) == 0) value = K90_MACRO_MODE_SW; else if (strncmp(buf, "HW", 2) == 0) value = K90_MACRO_MODE_HW; else return -EINVAL; ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), K90_REQUEST_MACRO_MODE, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, value, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); if (ret != 0) return ret; drvdata->macro_mode = (value == K90_MACRO_MODE_HW); return count; } static ssize_t k90_show_current_profile(struct device *dev, struct device_attribute *attr, char *buf) { struct k90_drvdata *drvdata = dev_get_drvdata(dev); return snprintf(buf, PAGE_SIZE, "%d\n", drvdata->current_profile); } static ssize_t k90_store_current_profile(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { int ret; struct usb_interface *usbif = to_usb_interface(dev->parent); struct usb_device *usbdev = interface_to_usbdev(usbif); struct k90_drvdata *drvdata = dev_get_drvdata(dev); int profile; if (kstrtoint(buf, 10, &profile)) return -EINVAL; if (profile < 1 || profile > 3) return -EINVAL; ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), K90_REQUEST_PROFILE, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, profile, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); if (ret != 0) return ret; drvdata->current_profile = profile; return count; } static DEVICE_ATTR(macro_mode, 0644, k90_show_macro_mode, k90_store_macro_mode); static DEVICE_ATTR(current_profile, 0644, k90_show_current_profile, k90_store_current_profile); static struct attribute *k90_attrs[] = { &dev_attr_macro_mode.attr, &dev_attr_current_profile.attr, NULL }; static const struct attribute_group k90_attr_group = { .attrs = k90_attrs, }; /* * Driver functions */ static int k90_init_special_functions(struct hid_device *dev) { int ret; struct usb_interface *usbif = to_usb_interface(dev->dev.parent); struct usb_device *usbdev = interface_to_usbdev(usbif); char data[8]; struct k90_drvdata *drvdata = kzalloc(sizeof(struct k90_drvdata), GFP_KERNEL); size_t name_sz; char *name; struct k90_led *led; if (!drvdata) { ret = -ENOMEM; goto fail_drvdata; } hid_set_drvdata(dev, drvdata); /* Get current status */ ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), K90_REQUEST_STATUS, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0, 0, data, 8, USB_CTRL_SET_TIMEOUT); if (ret < 0) { hid_warn(dev, "Failed to get K90 initial state (error %d).\n", ret); drvdata->backlight.brightness = 0; drvdata->current_profile = 1; } else { drvdata->backlight.brightness = data[4]; drvdata->current_profile = data[7]; } /* Get current mode */ ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), K90_REQUEST_GET_MODE, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0, 0, data, 2, USB_CTRL_SET_TIMEOUT); if (ret < 0) hid_warn(dev, "Failed to get K90 initial mode (error %d).\n", ret); else { switch (data[0]) { case K90_MACRO_MODE_HW: drvdata->macro_mode = 1; break; case K90_MACRO_MODE_SW: drvdata->macro_mode = 0; break; default: hid_warn(dev, "K90 in unknown mode: %02x.\n", data[0]); } } /* Init LED device for backlight */ name_sz = strlen(dev_name(&dev->dev)) + sizeof(K90_BACKLIGHT_LED_SUFFIX); name = devm_kzalloc(&dev->dev, name_sz, GFP_KERNEL); if (!name) { ret = -ENOMEM; goto fail_backlight; } snprintf(name, name_sz, "%s" K90_BACKLIGHT_LED_SUFFIX, dev_name(&dev->dev)); led = &drvdata->backlight; led->cdev.name = name; led->cdev.max_brightness = 3; led->cdev.brightness_set = k90_brightness_set; led->cdev.brightness_get = k90_brightness_get; INIT_WORK(&led->work, k90_backlight_work); ret = led_classdev_register(&dev->dev, &led->cdev); if (ret != 0) goto fail_backlight; /* Init LED device for record LED */ name_sz = strlen(dev_name(&dev->dev)) + sizeof(K90_RECORD_LED_SUFFIX); name = devm_kzalloc(&dev->dev, name_sz, GFP_KERNEL); if (!name) { ret = -ENOMEM; goto fail_record_led; } snprintf(name, name_sz, "%s" K90_RECORD_LED_SUFFIX, dev_name(&dev->dev)); led = &drvdata->record_led; led->cdev.name = name; led->cdev.max_brightness = 1; led->cdev.brightness_set = k90_brightness_set; led->cdev.brightness_get = k90_brightness_get; INIT_WORK(&led->work, k90_record_led_work); ret = led_classdev_register(&dev->dev, &led->cdev); if (ret != 0) goto fail_record_led; /* Init attributes */ ret = sysfs_create_group(&dev->dev.kobj, &k90_attr_group); if (ret != 0) goto fail_sysfs; return 0; fail_sysfs: led_classdev_unregister(&drvdata->record_led.cdev); cancel_work_sync(&drvdata->record_led.work); fail_record_led: led_classdev_unregister(&drvdata->backlight.cdev); cancel_work_sync(&drvdata->backlight.work); fail_backlight: kfree(drvdata); fail_drvdata: hid_set_drvdata(dev, NULL); return ret; } static void k90_cleanup_special_functions(struct hid_device *dev) { struct k90_drvdata *drvdata = hid_get_drvdata(dev); if (drvdata) { sysfs_remove_group(&dev->dev.kobj, &k90_attr_group); led_classdev_unregister(&drvdata->record_led.cdev); led_classdev_unregister(&drvdata->backlight.cdev); cancel_work_sync(&drvdata->record_led.work); cancel_work_sync(&drvdata->backlight.work); kfree(drvdata); } } static int k90_probe(struct hid_device *dev, const struct hid_device_id *id) { int ret; struct usb_interface *usbif = to_usb_interface(dev->dev.parent); ret = hid_parse(dev); if (ret != 0) { hid_err(dev, "parse failed\n"); return ret; } ret = hid_hw_start(dev, HID_CONNECT_DEFAULT); if (ret != 0) { hid_err(dev, "hw start failed\n"); return ret; } if (usbif->cur_altsetting->desc.bInterfaceNumber == 0) { ret = k90_init_special_functions(dev); if (ret != 0) hid_warn(dev, "Failed to initialize K90 special functions.\n"); } else hid_set_drvdata(dev, NULL); return 0; } static void k90_remove(struct hid_device *dev) { struct usb_interface *usbif = to_usb_interface(dev->dev.parent); if (usbif->cur_altsetting->desc.bInterfaceNumber == 0) k90_cleanup_special_functions(dev); hid_hw_stop(dev); } static int k90_event(struct hid_device *dev, struct hid_field *field, struct hid_usage *usage, __s32 value) { struct k90_drvdata *drvdata = hid_get_drvdata(dev); if (!drvdata) return 0; switch (usage->hid & HID_USAGE) { case K90_USAGE_MACRO_RECORD_START: drvdata->record_led.brightness = 1; break; case K90_USAGE_MACRO_RECORD_STOP: drvdata->record_led.brightness = 0; break; case K90_USAGE_M1: case K90_USAGE_M2: case K90_USAGE_M3: drvdata->current_profile = (usage->hid & HID_USAGE) - K90_USAGE_PROFILE + 1; break; case K90_USAGE_META_OFF: drvdata->meta_locked = 0; break; case K90_USAGE_META_ON: drvdata->meta_locked = 1; break; case K90_USAGE_LIGHT_OFF: case K90_USAGE_LIGHT_DIM: case K90_USAGE_LIGHT_MEDIUM: case K90_USAGE_LIGHT_BRIGHT: drvdata->backlight.brightness = (usage->hid & HID_USAGE) - K90_USAGE_LIGHT; break; default: break; } return 0; } static int k90_input_mapping(struct hid_device *dev, struct hid_input *input, struct hid_field *field, struct hid_usage *usage, unsigned long **bit, int *max) { int gkey; gkey = k90_usage_to_gkey(usage->hid & HID_USAGE); if (gkey != 0) { hid_map_usage_clear(input, usage, bit, max, EV_KEY, k90_gkey_map[gkey - 1]); return 1; } if ((usage->hid & HID_USAGE) >= K90_USAGE_SPECIAL_MIN && (usage->hid & HID_USAGE) <= K90_USAGE_SPECIAL_MAX) return -1; return 0; } static const struct hid_device_id k90_devices[] = { { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90) }, {} }; MODULE_DEVICE_TABLE(hid, k90_devices); static struct hid_driver k90_driver = { .name = "k90", .id_table = k90_devices, .probe = k90_probe, .event = k90_event, .remove = k90_remove, .input_mapping = k90_input_mapping, }; static int __init k90_init(void) { return hid_register_driver(&k90_driver); } static void k90_exit(void) { hid_unregister_driver(&k90_driver); } module_init(k90_init); module_exit(k90_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Clement Vuchener"); MODULE_DESCRIPTION("HID driver for Corsair Vengeance K90 Keyboard"); From pria.mn9 at gmail.com Mon Sep 7 02:40:56 2015 From: pria.mn9 at gmail.com (Pria Mn) Date: Mon, 7 Sep 2015 12:10:56 +0530 Subject: How to get the dentry value - no path_lookup Message-ID: Hi, I happened to come across the below discussion. http://lists.kernelnewbies.org/pipermail/kernelnewbies/2012-August/005914.html I am having a similar issue. I am using Rhel7-3.10.0-123 kernel. I tried all the options that are mentioned above and none of the api's including kern_path() return valid dentry value. My requirement is to fetch directory name from filepath. Can anybody suggest a work-around for this ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150907/5333066b/attachment.html From pranjas at gmail.com Mon Sep 7 02:38:17 2015 From: pranjas at gmail.com (Pranay Srivastava) Date: Mon, 7 Sep 2015 12:08:17 +0530 Subject: How to properly unregister LED class devices? In-Reply-To: <20150906174806.GA16230@untxi.home> References: <20150906174806.GA16230@untxi.home> Message-ID: On Sun, Sep 6, 2015 at 11:18 PM, Cl?ment Vuchener wrote: > Hello, > > I am trying to write a driver that uses LED class devices using works for setting the LED brightness but I am not sure of how to unregister the devices. > > I have been using code like this: > led_classdev_unregister(&drvdata->backlight.cdev); > cancel_work_sync(&drvdata->backlight.work); > trying with both flush_work or cancel_work_sync as I have seen it in other drivers. > > Using flush_work, the kernel oops in my work function when I unplug the device. cancel_work_sync seems to fix that, but I am not sure it will work every time. I would like to understand what happens and if I am doing something wrong, to be sure it will not break in some different setup. Can you post the backtrace? > > Another problem I have with this unregistering is that the LED brightness is set to zero when unregistering when the hardware is supposed to remember the last settings. Thus the LED state is reset when detaching and reattaching the driver. > > Below is the full code from my driver, if you need it: > > /* > * HID driver for Corsair devices > * > * Supported devices: > * - Vengeance K90 Keyboard > * > * Copyright (c) 2015 Clement Vuchener > */ > > /* > * This program is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License as published by the Free > * Software Foundation; either version 2 of the License, or (at your option) > * any later version. > */ > > #include > #include > #include > #include > > #include "hid-ids.h" > > struct k90_led { > struct led_classdev cdev; > int brightness; > struct work_struct work; > }; > > struct k90_drvdata { > int current_profile; > int macro_mode; > int meta_locked; > struct k90_led backlight; > struct k90_led record_led; > }; > > #define K90_GKEY_COUNT 18 > > static int k90_usage_to_gkey(unsigned int usage) > { > /* G1 (0xd0) to G16 (0xdf) */ > if (usage >= 0xd0 && usage <= 0xdf) > return usage - 0xd0 + 1; > /* G17 (0xe8) to G18 (0xe9) */ > if (usage >= 0xe8 && usage <= 0xe9) > return usage - 0xe8 + 17; > return 0; > } > > static unsigned short k90_gkey_map[K90_GKEY_COUNT] = { > BTN_TRIGGER_HAPPY1, > BTN_TRIGGER_HAPPY2, > BTN_TRIGGER_HAPPY3, > BTN_TRIGGER_HAPPY4, > BTN_TRIGGER_HAPPY5, > BTN_TRIGGER_HAPPY6, > BTN_TRIGGER_HAPPY7, > BTN_TRIGGER_HAPPY8, > BTN_TRIGGER_HAPPY9, > BTN_TRIGGER_HAPPY10, > BTN_TRIGGER_HAPPY11, > BTN_TRIGGER_HAPPY12, > BTN_TRIGGER_HAPPY13, > BTN_TRIGGER_HAPPY14, > BTN_TRIGGER_HAPPY15, > BTN_TRIGGER_HAPPY16, > BTN_TRIGGER_HAPPY17, > BTN_TRIGGER_HAPPY18, > }; > > module_param_array_named(gkey_codes, k90_gkey_map, ushort, NULL, S_IRUGO); > > #define K90_USAGE_SPECIAL_MIN 0xf0 > #define K90_USAGE_SPECIAL_MAX 0xff > > #define K90_USAGE_MACRO_RECORD_START 0xf6 > #define K90_USAGE_MACRO_RECORD_STOP 0xf7 > > #define K90_USAGE_PROFILE 0xf1 > #define K90_USAGE_M1 0xf1 > #define K90_USAGE_M2 0xf2 > #define K90_USAGE_M3 0xf3 > #define K90_USAGE_PROFILE_MAX 0xf3 > > #define K90_USAGE_META_OFF 0xf4 > #define K90_USAGE_META_ON 0xf5 > > #define K90_USAGE_LIGHT 0xfa > #define K90_USAGE_LIGHT_OFF 0xfa > #define K90_USAGE_LIGHT_DIM 0xfb > #define K90_USAGE_LIGHT_MEDIUM 0xfc > #define K90_USAGE_LIGHT_BRIGHT 0xfd > #define K90_USAGE_LIGHT_MAX 0xfd > > /* USB control protocol */ > > #define K90_REQUEST_BRIGHTNESS 49 > #define K90_REQUEST_MACRO_MODE 2 > #define K90_REQUEST_STATUS 4 > #define K90_REQUEST_GET_MODE 5 > #define K90_REQUEST_PROFILE 20 > > #define K90_MACRO_MODE_SW 0x0030 > #define K90_MACRO_MODE_HW 0x0001 > > #define K90_MACRO_LED_ON 0x0020 > #define K90_MACRO_LED_OFF 0x0040 > > /* > * LED class devices > */ > > #define K90_BACKLIGHT_LED_SUFFIX ":blue:backlight" > #define K90_RECORD_LED_SUFFIX ":red:record" > > static enum led_brightness k90_brightness_get(struct led_classdev *led_cdev) > { > struct k90_led *led = container_of(led_cdev, struct k90_led, cdev); > > return led->brightness; > } > > static void k90_brightness_set(struct led_classdev *led_cdev, > enum led_brightness brightness) > { > struct k90_led *led = container_of(led_cdev, struct k90_led, cdev); > > led->brightness = brightness; > schedule_work(&led->work); > } > > static void k90_backlight_work(struct work_struct *work) > { > int ret; > struct k90_led *led = container_of(work, struct k90_led, work); > struct device *dev = led->cdev.dev->parent; > struct usb_interface *usbif = to_usb_interface(dev->parent); > struct usb_device *usbdev = interface_to_usbdev(usbif); > > ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), > K90_REQUEST_BRIGHTNESS, > USB_DIR_OUT | USB_TYPE_VENDOR | > USB_RECIP_DEVICE, led->brightness, 0, > NULL, 0, USB_CTRL_SET_TIMEOUT); > if (ret != 0) > dev_warn(dev, "Failed to set backlight brightness (error: %d).\n", > ret); > } > > static void k90_record_led_work(struct work_struct *work) > { > int ret; > struct k90_led *led = container_of(work, struct k90_led, work); > struct device *dev = led->cdev.dev->parent; > struct usb_interface *usbif = to_usb_interface(dev->parent); > struct usb_device *usbdev = interface_to_usbdev(usbif); > int value; > > if (led->brightness > 0) > value = K90_MACRO_LED_ON; > else > value = K90_MACRO_LED_OFF; > > ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), > K90_REQUEST_MACRO_MODE, > USB_DIR_OUT | USB_TYPE_VENDOR | > USB_RECIP_DEVICE, value, 0, NULL, 0, > USB_CTRL_SET_TIMEOUT); > if (ret != 0) > dev_warn(dev, "Failed to set record LED state (error: %d).\n", > ret); > } > > /* > * Keyboard attributes > */ > > static ssize_t k90_show_macro_mode(struct device *dev, > struct device_attribute *attr, char *buf) > { > struct k90_drvdata *drvdata = dev_get_drvdata(dev); > > return snprintf(buf, PAGE_SIZE, "%s\n", > (drvdata->macro_mode ? "HW" : "SW")); > } > > static ssize_t k90_store_macro_mode(struct device *dev, > struct device_attribute *attr, > const char *buf, size_t count) > { > int ret; > struct usb_interface *usbif = to_usb_interface(dev->parent); > struct usb_device *usbdev = interface_to_usbdev(usbif); > struct k90_drvdata *drvdata = dev_get_drvdata(dev); > __u16 value; > > if (strncmp(buf, "SW", 2) == 0) > value = K90_MACRO_MODE_SW; > else if (strncmp(buf, "HW", 2) == 0) > value = K90_MACRO_MODE_HW; > else > return -EINVAL; > > ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), > K90_REQUEST_MACRO_MODE, > USB_DIR_OUT | USB_TYPE_VENDOR | > USB_RECIP_DEVICE, value, 0, NULL, 0, > USB_CTRL_SET_TIMEOUT); > if (ret != 0) > return ret; > > drvdata->macro_mode = (value == K90_MACRO_MODE_HW); > > return count; > } > > static ssize_t k90_show_current_profile(struct device *dev, > struct device_attribute *attr, > char *buf) > { > struct k90_drvdata *drvdata = dev_get_drvdata(dev); > > return snprintf(buf, PAGE_SIZE, "%d\n", drvdata->current_profile); > } > > static ssize_t k90_store_current_profile(struct device *dev, > struct device_attribute *attr, > const char *buf, size_t count) > { > int ret; > struct usb_interface *usbif = to_usb_interface(dev->parent); > struct usb_device *usbdev = interface_to_usbdev(usbif); > struct k90_drvdata *drvdata = dev_get_drvdata(dev); > int profile; > > if (kstrtoint(buf, 10, &profile)) > return -EINVAL; > if (profile < 1 || profile > 3) > return -EINVAL; > > ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), > K90_REQUEST_PROFILE, > USB_DIR_OUT | USB_TYPE_VENDOR | > USB_RECIP_DEVICE, profile, 0, NULL, 0, > USB_CTRL_SET_TIMEOUT); > if (ret != 0) > return ret; > > drvdata->current_profile = profile; > > return count; > } > > static DEVICE_ATTR(macro_mode, 0644, k90_show_macro_mode, k90_store_macro_mode); > static DEVICE_ATTR(current_profile, 0644, k90_show_current_profile, > k90_store_current_profile); > > static struct attribute *k90_attrs[] = { > &dev_attr_macro_mode.attr, > &dev_attr_current_profile.attr, > NULL > }; > > static const struct attribute_group k90_attr_group = { > .attrs = k90_attrs, > }; > > /* > * Driver functions > */ > > static int k90_init_special_functions(struct hid_device *dev) > { > int ret; > struct usb_interface *usbif = to_usb_interface(dev->dev.parent); > struct usb_device *usbdev = interface_to_usbdev(usbif); > char data[8]; > struct k90_drvdata *drvdata = > kzalloc(sizeof(struct k90_drvdata), GFP_KERNEL); > size_t name_sz; > char *name; > struct k90_led *led; > > if (!drvdata) { > ret = -ENOMEM; > goto fail_drvdata; > } > hid_set_drvdata(dev, drvdata); > > /* Get current status */ > ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), > K90_REQUEST_STATUS, > USB_DIR_IN | USB_TYPE_VENDOR | > USB_RECIP_DEVICE, 0, 0, data, 8, > USB_CTRL_SET_TIMEOUT); > if (ret < 0) { > hid_warn(dev, "Failed to get K90 initial state (error %d).\n", > ret); > drvdata->backlight.brightness = 0; > drvdata->current_profile = 1; > } else { > drvdata->backlight.brightness = data[4]; > drvdata->current_profile = data[7]; > } > /* Get current mode */ > ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), > K90_REQUEST_GET_MODE, > USB_DIR_IN | USB_TYPE_VENDOR | > USB_RECIP_DEVICE, 0, 0, data, 2, > USB_CTRL_SET_TIMEOUT); > if (ret < 0) > hid_warn(dev, "Failed to get K90 initial mode (error %d).\n", > ret); > else { > switch (data[0]) { > case K90_MACRO_MODE_HW: > drvdata->macro_mode = 1; > break; > case K90_MACRO_MODE_SW: > drvdata->macro_mode = 0; > break; > default: > hid_warn(dev, "K90 in unknown mode: %02x.\n", > data[0]); > } > } > > /* Init LED device for backlight */ > name_sz = > strlen(dev_name(&dev->dev)) + sizeof(K90_BACKLIGHT_LED_SUFFIX); > name = devm_kzalloc(&dev->dev, name_sz, GFP_KERNEL); > if (!name) { > ret = -ENOMEM; > goto fail_backlight; > } > snprintf(name, name_sz, "%s" K90_BACKLIGHT_LED_SUFFIX, > dev_name(&dev->dev)); > led = &drvdata->backlight; > led->cdev.name = name; > led->cdev.max_brightness = 3; > led->cdev.brightness_set = k90_brightness_set; > led->cdev.brightness_get = k90_brightness_get; > INIT_WORK(&led->work, k90_backlight_work); > ret = led_classdev_register(&dev->dev, &led->cdev); > if (ret != 0) > goto fail_backlight; > > /* Init LED device for record LED */ > name_sz = strlen(dev_name(&dev->dev)) + sizeof(K90_RECORD_LED_SUFFIX); > name = devm_kzalloc(&dev->dev, name_sz, GFP_KERNEL); > if (!name) { > ret = -ENOMEM; > goto fail_record_led; > } > snprintf(name, name_sz, "%s" K90_RECORD_LED_SUFFIX, > dev_name(&dev->dev)); > led = &drvdata->record_led; > led->cdev.name = name; > led->cdev.max_brightness = 1; > led->cdev.brightness_set = k90_brightness_set; > led->cdev.brightness_get = k90_brightness_get; > INIT_WORK(&led->work, k90_record_led_work); > ret = led_classdev_register(&dev->dev, &led->cdev); > if (ret != 0) > goto fail_record_led; > > /* Init attributes */ > ret = sysfs_create_group(&dev->dev.kobj, &k90_attr_group); > if (ret != 0) > goto fail_sysfs; > > return 0; > > fail_sysfs: > led_classdev_unregister(&drvdata->record_led.cdev); > cancel_work_sync(&drvdata->record_led.work); > fail_record_led: > led_classdev_unregister(&drvdata->backlight.cdev); > cancel_work_sync(&drvdata->backlight.work); > fail_backlight: > kfree(drvdata); > fail_drvdata: > hid_set_drvdata(dev, NULL); > return ret; > } > > static void k90_cleanup_special_functions(struct hid_device *dev) > { > struct k90_drvdata *drvdata = hid_get_drvdata(dev); > > if (drvdata) { > sysfs_remove_group(&dev->dev.kobj, &k90_attr_group); > led_classdev_unregister(&drvdata->record_led.cdev); > led_classdev_unregister(&drvdata->backlight.cdev); flush_work/cancel_work before doing unregistering? > cancel_work_sync(&drvdata->record_led.work); > cancel_work_sync(&drvdata->backlight.work); > kfree(drvdata); > } > } > > static int k90_probe(struct hid_device *dev, const struct hid_device_id *id) > { > int ret; > struct usb_interface *usbif = to_usb_interface(dev->dev.parent); > > ret = hid_parse(dev); > if (ret != 0) { > hid_err(dev, "parse failed\n"); > return ret; > } > ret = hid_hw_start(dev, HID_CONNECT_DEFAULT); > if (ret != 0) { > hid_err(dev, "hw start failed\n"); > return ret; > } > > if (usbif->cur_altsetting->desc.bInterfaceNumber == 0) { > ret = k90_init_special_functions(dev); > if (ret != 0) > hid_warn(dev, "Failed to initialize K90 special functions.\n"); > } else > hid_set_drvdata(dev, NULL); > > return 0; > } > > static void k90_remove(struct hid_device *dev) > { > struct usb_interface *usbif = to_usb_interface(dev->dev.parent); > > if (usbif->cur_altsetting->desc.bInterfaceNumber == 0) > k90_cleanup_special_functions(dev); > > hid_hw_stop(dev); > } > > static int k90_event(struct hid_device *dev, struct hid_field *field, > struct hid_usage *usage, __s32 value) > { > struct k90_drvdata *drvdata = hid_get_drvdata(dev); > > if (!drvdata) > return 0; > > switch (usage->hid & HID_USAGE) { > case K90_USAGE_MACRO_RECORD_START: > drvdata->record_led.brightness = 1; > break; > case K90_USAGE_MACRO_RECORD_STOP: > drvdata->record_led.brightness = 0; > break; > case K90_USAGE_M1: > case K90_USAGE_M2: > case K90_USAGE_M3: > drvdata->current_profile = > (usage->hid & HID_USAGE) - K90_USAGE_PROFILE + 1; > break; > case K90_USAGE_META_OFF: > drvdata->meta_locked = 0; > break; > case K90_USAGE_META_ON: > drvdata->meta_locked = 1; > break; > case K90_USAGE_LIGHT_OFF: > case K90_USAGE_LIGHT_DIM: > case K90_USAGE_LIGHT_MEDIUM: > case K90_USAGE_LIGHT_BRIGHT: > drvdata->backlight.brightness = (usage->hid & HID_USAGE) - > K90_USAGE_LIGHT; > break; > default: > break; > } > > return 0; > } > > static int k90_input_mapping(struct hid_device *dev, struct hid_input *input, > struct hid_field *field, struct hid_usage *usage, > unsigned long **bit, int *max) > { > int gkey; > > gkey = k90_usage_to_gkey(usage->hid & HID_USAGE); > if (gkey != 0) { > hid_map_usage_clear(input, usage, bit, max, EV_KEY, > k90_gkey_map[gkey - 1]); > return 1; > } > if ((usage->hid & HID_USAGE) >= K90_USAGE_SPECIAL_MIN && > (usage->hid & HID_USAGE) <= K90_USAGE_SPECIAL_MAX) > return -1; > > return 0; > } > > static const struct hid_device_id k90_devices[] = { > { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90) }, > {} > }; > > MODULE_DEVICE_TABLE(hid, k90_devices); > > static struct hid_driver k90_driver = { > .name = "k90", > .id_table = k90_devices, > .probe = k90_probe, > .event = k90_event, > .remove = k90_remove, > .input_mapping = k90_input_mapping, > }; > > static int __init k90_init(void) > { > return hid_register_driver(&k90_driver); > } > > static void k90_exit(void) > { > hid_unregister_driver(&k90_driver); > } > > module_init(k90_init); > module_exit(k90_exit); > > MODULE_LICENSE("GPL"); > MODULE_AUTHOR("Clement Vuchener"); > MODULE_DESCRIPTION("HID driver for Corsair Vengeance K90 Keyboard"); > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- ---P.K.S From rohan.puri15 at gmail.com Mon Sep 7 03:15:50 2015 From: rohan.puri15 at gmail.com (Rohan Puri) Date: Mon, 7 Sep 2015 12:45:50 +0530 Subject: How to get the dentry value - no path_lookup In-Reply-To: References: Message-ID: On Mon, Sep 7, 2015 at 12:10 PM, Pria Mn wrote: > Hi, > > > > I happened to come across the below discussion. > > > > http://lists.kernelnewbies.org/pipermail/kernelnewbies/2012-August/005914.html > > > I am having a similar issue. > > I am using Rhel7-3.10.0-123 > > kernel. I tried all the options that are mentioned above and none of the > api's > > including kern_path() > > return valid dentry value. My requirement is to fetch directory name from > filepath. > > > > Can anybody suggest a work-around for this ? > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > Hi Pria, This is in regards with which kernel version? also what are you trying to do, please be more detailed. Enjoy life, Rohan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150907/cf285ddb/attachment.html From pria.mn9 at gmail.com Mon Sep 7 03:41:15 2015 From: pria.mn9 at gmail.com (Pria Mn) Date: Mon, 7 Sep 2015 13:11:15 +0530 Subject: How to get the dentry value - no path_lookup In-Reply-To: References: Message-ID: Hi Rohan, I am using 3.10.0-123.el7.x86_64 kernel (RHEL-7). I am trying to obtain 'dentry' value from file path information. For this: earlier I had written the code as below : #if(LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)) err= kern_path_parent(tmp,nd); #else err= path_lookup(tmp, 0, nd); #endif Now that "nameidata" structure is not exposed with kernel version >= 3.6.0 I used kern_path_create() which is returning invalid dentry value. dentry =kern_path_create(AT_FDCWD, tmp, path, 1); So, I tried using : user_path_at() , kern_path() which are not helping me. How to fetch 'dentry' data from file name ? On Mon, Sep 7, 2015 at 12:45 PM, Rohan Puri wrote: > > > On Mon, Sep 7, 2015 at 12:10 PM, Pria Mn wrote: > >> Hi, >> >> >> >> I happened to come across the below discussion. >> >> >> >> http://lists.kernelnewbies.org/pipermail/kernelnewbies/2012-August/005914.html >> >> >> I am having a similar issue. >> >> I am using Rhel7-3.10.0-123 >> >> kernel. I tried all the options that are mentioned above and none of the >> api's >> >> including kern_path() >> >> return valid dentry value. My requirement is to fetch directory name from >> filepath. >> >> >> >> Can anybody suggest a work-around for this ? >> >> >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > Hi Pria, > > This is in regards with which kernel version? also what are you trying to > do, please be more detailed. > > > Enjoy life, > Rohan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150907/2a53ecee/attachment.html From rohan.puri15 at gmail.com Mon Sep 7 03:55:08 2015 From: rohan.puri15 at gmail.com (Rohan Puri) Date: Mon, 7 Sep 2015 13:25:08 +0530 Subject: How to get the dentry value - no path_lookup In-Reply-To: References: Message-ID: On Mon, Sep 7, 2015 at 1:11 PM, Pria Mn wrote: > Hi Rohan, > > I am using 3.10.0-123.el7.x86_64 kernel (RHEL-7). I am trying to obtain > 'dentry' value from file path information. For this: earlier I had written > the code as below : > > #if(LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)) > > err= kern_path_parent(tmp,nd); > > #else > > err= path_lookup(tmp, 0, nd); > > #endif > Now that "nameidata" structure is not exposed with kernel version >= 3.6.0 > I used kern_path_create() which is returning invalid dentry value. > > dentry =kern_path_create(AT_FDCWD, tmp, path, 1); > > So, I tried using : user_path_at() , kern_path() which are not helping me. > > How to fetch 'dentry' data from file name ? > > On Mon, Sep 7, 2015 at 12:45 PM, Rohan Puri > wrote: > >> >> >> On Mon, Sep 7, 2015 at 12:10 PM, Pria Mn wrote: >> >>> Hi, >>> >>> >>> >>> I happened to come across the below discussion. >>> >>> >>> >>> http://lists.kernelnewbies.org/pipermail/kernelnewbies/2012-August/005914.html >>> >>> >>> I am having a similar issue. >>> >>> I am using Rhel7-3.10.0-123 >>> >>> kernel. I tried all the options that are mentioned above and none of the >>> api's >>> >>> including kern_path() >>> >>> return valid dentry value. My requirement is to fetch directory name >>> from filepath. >>> >>> >>> >>> Can anybody suggest a work-around for this ? >>> >>> >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies at kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >>> >> Hi Pria, >> >> This is in regards with which kernel version? also what are you trying to >> do, please be more detailed. >> >> >> Enjoy life, >> Rohan >> > > Hi Pria, Yes, just checked nameidata is moved to fs/internal.h file, I think you can make use of kern_path () here. NOTE: Also please post reply at the bottom. Enjoy life, Rohan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150907/dc968223/attachment.html From clement.vuchener at gmail.com Mon Sep 7 05:05:56 2015 From: clement.vuchener at gmail.com (=?iso-8859-1?Q?Cl=E9ment?= Vuchener) Date: Mon, 7 Sep 2015 11:05:56 +0200 Subject: How to properly unregister LED class devices? In-Reply-To: References: <20150906174806.GA16230@untxi.home> Message-ID: <20150907090556.GA2549@untxi.home> On Mon, Sep 07, 2015 at 12:08:17PM +0530, Pranay Srivastava wrote: > On Sun, Sep 6, 2015 at 11:18 PM, Cl?ment Vuchener > wrote: > > Hello, > > > > I am trying to write a driver that uses LED class devices using works for setting the LED brightness but I am not sure of how to unregister the devices. > > > > I have been using code like this: > > led_classdev_unregister(&drvdata->backlight.cdev); > > cancel_work_sync(&drvdata->backlight.work); > > trying with both flush_work or cancel_work_sync as I have seen it in other drivers. > > > > Using flush_work, the kernel oops in my work function when I unplug the device. cancel_work_sync seems to fix that, but I am not sure it will work every time. I would like to understand what happens and if I am doing something wrong, to be sure it will not break in some different setup. > > Can you post the backtrace? > I could not get it with my patched kernel (I must be missing some config option) so I used the code as a module on my fedora 22 (4.1.6) kernel. general protection fault: 0000 [#1] SMP Modules linked in: hid_corsair_k90(OE) bnep bluetooth nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_g snd_hda_codec_hdmi coretemp arc4 kvm_intel snd_hda_codec_realtek iwldvm kvm snd_hda_codec_generic mac80211 snd_hda_intel snd_hda_controller snd_hda_co CPU: 2 PID: 491 Comm: kworker/2:3 Tainted: G OE 4.1.6-200.fc22.x86_64 #1 Hardware name: CLEVO CO. W350ET/W350ET, BIOS 1.02.21PM v3 07/01/2013 Workqueue: events k90_record_led_work [hid_corsair_k90] task: ffff880223bd4f00 ti: ffff8800c92a0000 task.ti: ffff8800c92a0000 RIP: 0010:[] [] __dev_printk+0x26/0x90 RSP: 0018:ffff8800c92a3d48 EFLAGS: 00010202 RAX: 657079740000009d RBX: ffff8801fcee7800 RCX: 000000000001a2e1 RDX: ffff8800c92a3d58 RSI: ffff8801fcee7800 RDI: ffffffff81a2673f RBP: ffff8800c92a3d48 R08: 0000001400730102 R09: ffff8800c92a3d58 R10: ffffffff81578c4b R11: 0000000000000000 R12: ffff88022f317000 R13: ffff88022f31b900 R14: 0000000000000080 R15: ffff8801fcc7d320 FS: 0000000000000000(0000) GS:ffff88022f300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000002eee850 CR3: 0000000002c0b000 CR4: 00000000001406e0 Stack: ffff8800c92a3db8 ffffffff814e8bd2 ffffffffa09701f8 ffff8800c92a3d68 ffff880100000010 ffff8800c92a3dc8 ffff8800c92a3d88 000000002440e468 0000000000000000 ffff8801fcee7800 00000000ffffffed 000000000001a2e1 Call Trace: [] dev_warn+0x62/0x80 [] k90_record_led_work+0x8c/0xa0 [hid_corsair_k90] [] ? __schedule+0x241/0x720 [] process_one_work+0x1bb/0x410 [] worker_thread+0x1bc/0x480 [] ? process_one_work+0x410/0x410 [] ? process_one_work+0x410/0x410 [] kthread+0xd8/0xf0 [] ? kthread_worker_fn+0x180/0x180 [] ret_from_fork+0x42/0x70 [] ? kthread_worker_fn+0x180/0x180 Code: 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 49 89 d1 48 89 e5 74 60 4c 8b 46 50 4d 85 c0 74 26 48 8b 86 90 00 00 00 48 85 c0 74 2a <48> 8b 08 0f be RIP [] __dev_printk+0x26/0x90 > > > > Another problem I have with this unregistering is that the LED brightness is set to zero when unregistering when the hardware is supposed to remember the last settings. Thus the LED state is reset when detaching and reattaching the driver. > > > > Below is the full code from my driver, if you need it: > > > > /* > > * HID driver for Corsair devices > > * > > * Supported devices: > > * - Vengeance K90 Keyboard > > * > > * Copyright (c) 2015 Clement Vuchener > > */ > > > > /* > > * This program is free software; you can redistribute it and/or modify it > > * under the terms of the GNU General Public License as published by the Free > > * Software Foundation; either version 2 of the License, or (at your option) > > * any later version. > > */ > > > > #include > > #include > > #include > > #include > > > > #include "hid-ids.h" > > > > struct k90_led { > > struct led_classdev cdev; > > int brightness; > > struct work_struct work; > > }; > > > > struct k90_drvdata { > > int current_profile; > > int macro_mode; > > int meta_locked; > > struct k90_led backlight; > > struct k90_led record_led; > > }; > > > > #define K90_GKEY_COUNT 18 > > > > static int k90_usage_to_gkey(unsigned int usage) > > { > > /* G1 (0xd0) to G16 (0xdf) */ > > if (usage >= 0xd0 && usage <= 0xdf) > > return usage - 0xd0 + 1; > > /* G17 (0xe8) to G18 (0xe9) */ > > if (usage >= 0xe8 && usage <= 0xe9) > > return usage - 0xe8 + 17; > > return 0; > > } > > > > static unsigned short k90_gkey_map[K90_GKEY_COUNT] = { > > BTN_TRIGGER_HAPPY1, > > BTN_TRIGGER_HAPPY2, > > BTN_TRIGGER_HAPPY3, > > BTN_TRIGGER_HAPPY4, > > BTN_TRIGGER_HAPPY5, > > BTN_TRIGGER_HAPPY6, > > BTN_TRIGGER_HAPPY7, > > BTN_TRIGGER_HAPPY8, > > BTN_TRIGGER_HAPPY9, > > BTN_TRIGGER_HAPPY10, > > BTN_TRIGGER_HAPPY11, > > BTN_TRIGGER_HAPPY12, > > BTN_TRIGGER_HAPPY13, > > BTN_TRIGGER_HAPPY14, > > BTN_TRIGGER_HAPPY15, > > BTN_TRIGGER_HAPPY16, > > BTN_TRIGGER_HAPPY17, > > BTN_TRIGGER_HAPPY18, > > }; > > > > module_param_array_named(gkey_codes, k90_gkey_map, ushort, NULL, S_IRUGO); > > > > #define K90_USAGE_SPECIAL_MIN 0xf0 > > #define K90_USAGE_SPECIAL_MAX 0xff > > > > #define K90_USAGE_MACRO_RECORD_START 0xf6 > > #define K90_USAGE_MACRO_RECORD_STOP 0xf7 > > > > #define K90_USAGE_PROFILE 0xf1 > > #define K90_USAGE_M1 0xf1 > > #define K90_USAGE_M2 0xf2 > > #define K90_USAGE_M3 0xf3 > > #define K90_USAGE_PROFILE_MAX 0xf3 > > > > #define K90_USAGE_META_OFF 0xf4 > > #define K90_USAGE_META_ON 0xf5 > > > > #define K90_USAGE_LIGHT 0xfa > > #define K90_USAGE_LIGHT_OFF 0xfa > > #define K90_USAGE_LIGHT_DIM 0xfb > > #define K90_USAGE_LIGHT_MEDIUM 0xfc > > #define K90_USAGE_LIGHT_BRIGHT 0xfd > > #define K90_USAGE_LIGHT_MAX 0xfd > > > > /* USB control protocol */ > > > > #define K90_REQUEST_BRIGHTNESS 49 > > #define K90_REQUEST_MACRO_MODE 2 > > #define K90_REQUEST_STATUS 4 > > #define K90_REQUEST_GET_MODE 5 > > #define K90_REQUEST_PROFILE 20 > > > > #define K90_MACRO_MODE_SW 0x0030 > > #define K90_MACRO_MODE_HW 0x0001 > > > > #define K90_MACRO_LED_ON 0x0020 > > #define K90_MACRO_LED_OFF 0x0040 > > > > /* > > * LED class devices > > */ > > > > #define K90_BACKLIGHT_LED_SUFFIX ":blue:backlight" > > #define K90_RECORD_LED_SUFFIX ":red:record" > > > > static enum led_brightness k90_brightness_get(struct led_classdev *led_cdev) > > { > > struct k90_led *led = container_of(led_cdev, struct k90_led, cdev); > > > > return led->brightness; > > } > > > > static void k90_brightness_set(struct led_classdev *led_cdev, > > enum led_brightness brightness) > > { > > struct k90_led *led = container_of(led_cdev, struct k90_led, cdev); > > > > led->brightness = brightness; > > schedule_work(&led->work); > > } > > > > static void k90_backlight_work(struct work_struct *work) > > { > > int ret; > > struct k90_led *led = container_of(work, struct k90_led, work); > > struct device *dev = led->cdev.dev->parent; > > struct usb_interface *usbif = to_usb_interface(dev->parent); > > struct usb_device *usbdev = interface_to_usbdev(usbif); > > > > ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), > > K90_REQUEST_BRIGHTNESS, > > USB_DIR_OUT | USB_TYPE_VENDOR | > > USB_RECIP_DEVICE, led->brightness, 0, > > NULL, 0, USB_CTRL_SET_TIMEOUT); > > if (ret != 0) > > dev_warn(dev, "Failed to set backlight brightness (error: %d).\n", > > ret); > > } > > > > static void k90_record_led_work(struct work_struct *work) > > { > > int ret; > > struct k90_led *led = container_of(work, struct k90_led, work); > > struct device *dev = led->cdev.dev->parent; > > struct usb_interface *usbif = to_usb_interface(dev->parent); > > struct usb_device *usbdev = interface_to_usbdev(usbif); > > int value; > > > > if (led->brightness > 0) > > value = K90_MACRO_LED_ON; > > else > > value = K90_MACRO_LED_OFF; > > > > ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), > > K90_REQUEST_MACRO_MODE, > > USB_DIR_OUT | USB_TYPE_VENDOR | > > USB_RECIP_DEVICE, value, 0, NULL, 0, > > USB_CTRL_SET_TIMEOUT); > > if (ret != 0) > > dev_warn(dev, "Failed to set record LED state (error: %d).\n", > > ret); > > } > > > > /* > > * Keyboard attributes > > */ > > > > static ssize_t k90_show_macro_mode(struct device *dev, > > struct device_attribute *attr, char *buf) > > { > > struct k90_drvdata *drvdata = dev_get_drvdata(dev); > > > > return snprintf(buf, PAGE_SIZE, "%s\n", > > (drvdata->macro_mode ? "HW" : "SW")); > > } > > > > static ssize_t k90_store_macro_mode(struct device *dev, > > struct device_attribute *attr, > > const char *buf, size_t count) > > { > > int ret; > > struct usb_interface *usbif = to_usb_interface(dev->parent); > > struct usb_device *usbdev = interface_to_usbdev(usbif); > > struct k90_drvdata *drvdata = dev_get_drvdata(dev); > > __u16 value; > > > > if (strncmp(buf, "SW", 2) == 0) > > value = K90_MACRO_MODE_SW; > > else if (strncmp(buf, "HW", 2) == 0) > > value = K90_MACRO_MODE_HW; > > else > > return -EINVAL; > > > > ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), > > K90_REQUEST_MACRO_MODE, > > USB_DIR_OUT | USB_TYPE_VENDOR | > > USB_RECIP_DEVICE, value, 0, NULL, 0, > > USB_CTRL_SET_TIMEOUT); > > if (ret != 0) > > return ret; > > > > drvdata->macro_mode = (value == K90_MACRO_MODE_HW); > > > > return count; > > } > > > > static ssize_t k90_show_current_profile(struct device *dev, > > struct device_attribute *attr, > > char *buf) > > { > > struct k90_drvdata *drvdata = dev_get_drvdata(dev); > > > > return snprintf(buf, PAGE_SIZE, "%d\n", drvdata->current_profile); > > } > > > > static ssize_t k90_store_current_profile(struct device *dev, > > struct device_attribute *attr, > > const char *buf, size_t count) > > { > > int ret; > > struct usb_interface *usbif = to_usb_interface(dev->parent); > > struct usb_device *usbdev = interface_to_usbdev(usbif); > > struct k90_drvdata *drvdata = dev_get_drvdata(dev); > > int profile; > > > > if (kstrtoint(buf, 10, &profile)) > > return -EINVAL; > > if (profile < 1 || profile > 3) > > return -EINVAL; > > > > ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), > > K90_REQUEST_PROFILE, > > USB_DIR_OUT | USB_TYPE_VENDOR | > > USB_RECIP_DEVICE, profile, 0, NULL, 0, > > USB_CTRL_SET_TIMEOUT); > > if (ret != 0) > > return ret; > > > > drvdata->current_profile = profile; > > > > return count; > > } > > > > static DEVICE_ATTR(macro_mode, 0644, k90_show_macro_mode, k90_store_macro_mode); > > static DEVICE_ATTR(current_profile, 0644, k90_show_current_profile, > > k90_store_current_profile); > > > > static struct attribute *k90_attrs[] = { > > &dev_attr_macro_mode.attr, > > &dev_attr_current_profile.attr, > > NULL > > }; > > > > static const struct attribute_group k90_attr_group = { > > .attrs = k90_attrs, > > }; > > > > /* > > * Driver functions > > */ > > > > static int k90_init_special_functions(struct hid_device *dev) > > { > > int ret; > > struct usb_interface *usbif = to_usb_interface(dev->dev.parent); > > struct usb_device *usbdev = interface_to_usbdev(usbif); > > char data[8]; > > struct k90_drvdata *drvdata = > > kzalloc(sizeof(struct k90_drvdata), GFP_KERNEL); > > size_t name_sz; > > char *name; > > struct k90_led *led; > > > > if (!drvdata) { > > ret = -ENOMEM; > > goto fail_drvdata; > > } > > hid_set_drvdata(dev, drvdata); > > > > /* Get current status */ > > ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), > > K90_REQUEST_STATUS, > > USB_DIR_IN | USB_TYPE_VENDOR | > > USB_RECIP_DEVICE, 0, 0, data, 8, > > USB_CTRL_SET_TIMEOUT); > > if (ret < 0) { > > hid_warn(dev, "Failed to get K90 initial state (error %d).\n", > > ret); > > drvdata->backlight.brightness = 0; > > drvdata->current_profile = 1; > > } else { > > drvdata->backlight.brightness = data[4]; > > drvdata->current_profile = data[7]; > > } > > /* Get current mode */ > > ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), > > K90_REQUEST_GET_MODE, > > USB_DIR_IN | USB_TYPE_VENDOR | > > USB_RECIP_DEVICE, 0, 0, data, 2, > > USB_CTRL_SET_TIMEOUT); > > if (ret < 0) > > hid_warn(dev, "Failed to get K90 initial mode (error %d).\n", > > ret); > > else { > > switch (data[0]) { > > case K90_MACRO_MODE_HW: > > drvdata->macro_mode = 1; > > break; > > case K90_MACRO_MODE_SW: > > drvdata->macro_mode = 0; > > break; > > default: > > hid_warn(dev, "K90 in unknown mode: %02x.\n", > > data[0]); > > } > > } > > > > /* Init LED device for backlight */ > > name_sz = > > strlen(dev_name(&dev->dev)) + sizeof(K90_BACKLIGHT_LED_SUFFIX); > > name = devm_kzalloc(&dev->dev, name_sz, GFP_KERNEL); > > if (!name) { > > ret = -ENOMEM; > > goto fail_backlight; > > } > > snprintf(name, name_sz, "%s" K90_BACKLIGHT_LED_SUFFIX, > > dev_name(&dev->dev)); > > led = &drvdata->backlight; > > led->cdev.name = name; > > led->cdev.max_brightness = 3; > > led->cdev.brightness_set = k90_brightness_set; > > led->cdev.brightness_get = k90_brightness_get; > > INIT_WORK(&led->work, k90_backlight_work); > > ret = led_classdev_register(&dev->dev, &led->cdev); > > if (ret != 0) > > goto fail_backlight; > > > > /* Init LED device for record LED */ > > name_sz = strlen(dev_name(&dev->dev)) + sizeof(K90_RECORD_LED_SUFFIX); > > name = devm_kzalloc(&dev->dev, name_sz, GFP_KERNEL); > > if (!name) { > > ret = -ENOMEM; > > goto fail_record_led; > > } > > snprintf(name, name_sz, "%s" K90_RECORD_LED_SUFFIX, > > dev_name(&dev->dev)); > > led = &drvdata->record_led; > > led->cdev.name = name; > > led->cdev.max_brightness = 1; > > led->cdev.brightness_set = k90_brightness_set; > > led->cdev.brightness_get = k90_brightness_get; > > INIT_WORK(&led->work, k90_record_led_work); > > ret = led_classdev_register(&dev->dev, &led->cdev); > > if (ret != 0) > > goto fail_record_led; > > > > /* Init attributes */ > > ret = sysfs_create_group(&dev->dev.kobj, &k90_attr_group); > > if (ret != 0) > > goto fail_sysfs; > > > > return 0; > > > > fail_sysfs: > > led_classdev_unregister(&drvdata->record_led.cdev); > > cancel_work_sync(&drvdata->record_led.work); > > fail_record_led: > > led_classdev_unregister(&drvdata->backlight.cdev); > > cancel_work_sync(&drvdata->backlight.work); > > fail_backlight: > > kfree(drvdata); > > fail_drvdata: > > hid_set_drvdata(dev, NULL); > > return ret; > > } > > > > static void k90_cleanup_special_functions(struct hid_device *dev) > > { > > struct k90_drvdata *drvdata = hid_get_drvdata(dev); > > > > if (drvdata) { > > sysfs_remove_group(&dev->dev.kobj, &k90_attr_group); > > led_classdev_unregister(&drvdata->record_led.cdev); > > led_classdev_unregister(&drvdata->backlight.cdev); > > flush_work/cancel_work before doing unregistering? > If led_classdev_unregister generates work (setting the brightness to zero), there will still be work in the workqueue after the cleanup. I don't understand why the work should be flushed/cancelled while the led device is still active. > > cancel_work_sync(&drvdata->record_led.work); > > cancel_work_sync(&drvdata->backlight.work); > > kfree(drvdata); > > } > > } > > > > static int k90_probe(struct hid_device *dev, const struct hid_device_id *id) > > { > > int ret; > > struct usb_interface *usbif = to_usb_interface(dev->dev.parent); > > > > ret = hid_parse(dev); > > if (ret != 0) { > > hid_err(dev, "parse failed\n"); > > return ret; > > } > > ret = hid_hw_start(dev, HID_CONNECT_DEFAULT); > > if (ret != 0) { > > hid_err(dev, "hw start failed\n"); > > return ret; > > } > > > > if (usbif->cur_altsetting->desc.bInterfaceNumber == 0) { > > ret = k90_init_special_functions(dev); > > if (ret != 0) > > hid_warn(dev, "Failed to initialize K90 special functions.\n"); > > } else > > hid_set_drvdata(dev, NULL); > > > > return 0; > > } > > > > static void k90_remove(struct hid_device *dev) > > { > > struct usb_interface *usbif = to_usb_interface(dev->dev.parent); > > > > if (usbif->cur_altsetting->desc.bInterfaceNumber == 0) > > k90_cleanup_special_functions(dev); > > > > hid_hw_stop(dev); > > } > > > > static int k90_event(struct hid_device *dev, struct hid_field *field, > > struct hid_usage *usage, __s32 value) > > { > > struct k90_drvdata *drvdata = hid_get_drvdata(dev); > > > > if (!drvdata) > > return 0; > > > > switch (usage->hid & HID_USAGE) { > > case K90_USAGE_MACRO_RECORD_START: > > drvdata->record_led.brightness = 1; > > break; > > case K90_USAGE_MACRO_RECORD_STOP: > > drvdata->record_led.brightness = 0; > > break; > > case K90_USAGE_M1: > > case K90_USAGE_M2: > > case K90_USAGE_M3: > > drvdata->current_profile = > > (usage->hid & HID_USAGE) - K90_USAGE_PROFILE + 1; > > break; > > case K90_USAGE_META_OFF: > > drvdata->meta_locked = 0; > > break; > > case K90_USAGE_META_ON: > > drvdata->meta_locked = 1; > > break; > > case K90_USAGE_LIGHT_OFF: > > case K90_USAGE_LIGHT_DIM: > > case K90_USAGE_LIGHT_MEDIUM: > > case K90_USAGE_LIGHT_BRIGHT: > > drvdata->backlight.brightness = (usage->hid & HID_USAGE) - > > K90_USAGE_LIGHT; > > break; > > default: > > break; > > } > > > > return 0; > > } > > > > static int k90_input_mapping(struct hid_device *dev, struct hid_input *input, > > struct hid_field *field, struct hid_usage *usage, > > unsigned long **bit, int *max) > > { > > int gkey; > > > > gkey = k90_usage_to_gkey(usage->hid & HID_USAGE); > > if (gkey != 0) { > > hid_map_usage_clear(input, usage, bit, max, EV_KEY, > > k90_gkey_map[gkey - 1]); > > return 1; > > } > > if ((usage->hid & HID_USAGE) >= K90_USAGE_SPECIAL_MIN && > > (usage->hid & HID_USAGE) <= K90_USAGE_SPECIAL_MAX) > > return -1; > > > > return 0; > > } > > > > static const struct hid_device_id k90_devices[] = { > > { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90) }, > > {} > > }; > > > > MODULE_DEVICE_TABLE(hid, k90_devices); > > > > static struct hid_driver k90_driver = { > > .name = "k90", > > .id_table = k90_devices, > > .probe = k90_probe, > > .event = k90_event, > > .remove = k90_remove, > > .input_mapping = k90_input_mapping, > > }; > > > > static int __init k90_init(void) > > { > > return hid_register_driver(&k90_driver); > > } > > > > static void k90_exit(void) > > { > > hid_unregister_driver(&k90_driver); > > } > > > > module_init(k90_init); > > module_exit(k90_exit); > > > > MODULE_LICENSE("GPL"); > > MODULE_AUTHOR("Clement Vuchener"); > > MODULE_DESCRIPTION("HID driver for Corsair Vengeance K90 Keyboard"); > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies at kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > -- > ---P.K.S From pranjas at gmail.com Mon Sep 7 07:47:09 2015 From: pranjas at gmail.com (Pranay Srivastava) Date: Mon, 7 Sep 2015 17:17:09 +0530 Subject: How to properly unregister LED class devices? In-Reply-To: <55ED74C3.2090409@samsung.com> References: <20150906174806.GA16230@untxi.home> <20150907090556.GA2549@untxi.home> <55ED74C3.2090409@samsung.com> Message-ID: On Mon, Sep 7, 2015 at 4:58 PM, Jacek Anaszewski wrote: > Hi Cl?ment, > > > On 09/07/2015 11:05 AM, Cl?ment Vuchener wrote: >> >> On Mon, Sep 07, 2015 at 12:08:17PM +0530, Pranay Srivastava wrote: >>> >>> On Sun, Sep 6, 2015 at 11:18 PM, Cl?ment Vuchener >>> wrote: >>>> >>>> Hello, >>>> >>>> I am trying to write a driver that uses LED class devices using works >>>> for setting the LED brightness but I am not sure of how to unregister the >>>> devices. >>>> >>>> I have been using code like this: >>>> led_classdev_unregister(&drvdata->backlight.cdev); >>>> cancel_work_sync(&drvdata->backlight.work); >>>> trying with both flush_work or cancel_work_sync as I have seen it in >>>> other drivers. >>>> >>>> Using flush_work, the kernel oops in my work function when I unplug the >>>> device. cancel_work_sync seems to fix that, but I am not sure it will work >>>> every time. I would like to understand what happens and if I am doing >>>> something wrong, to be sure it will not break in some different setup. >>> >>> >>> Can you post the backtrace? >>> >> >> I could not get it with my patched kernel (I must be missing some config >> option) so I used the code as a module on my fedora 22 (4.1.6) kernel. >> >> general protection fault: 0000 [#1] SMP >> Modules linked in: hid_corsair_k90(OE) bnep bluetooth nf_nat_h323 >> nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp >> nf_conntrack_proto_g >> snd_hda_codec_hdmi coretemp arc4 kvm_intel snd_hda_codec_realtek iwldvm >> kvm snd_hda_codec_generic mac80211 snd_hda_intel snd_hda_controller >> snd_hda_co >> CPU: 2 PID: 491 Comm: kworker/2:3 Tainted: G OE >> 4.1.6-200.fc22.x86_64 #1 >> Hardware name: CLEVO CO. W350ET/W350ET, BIOS >> 1.02.21PM v3 07/01/2013 >> Workqueue: events k90_record_led_work [hid_corsair_k90] >> task: ffff880223bd4f00 ti: ffff8800c92a0000 task.ti: ffff8800c92a0000 >> RIP: 0010:[] [] >> __dev_printk+0x26/0x90 >> RSP: 0018:ffff8800c92a3d48 EFLAGS: 00010202 >> RAX: 657079740000009d RBX: ffff8801fcee7800 RCX: 000000000001a2e1 >> RDX: ffff8800c92a3d58 RSI: ffff8801fcee7800 RDI: ffffffff81a2673f >> RBP: ffff8800c92a3d48 R08: 0000001400730102 R09: ffff8800c92a3d58 >> R10: ffffffff81578c4b R11: 0000000000000000 R12: ffff88022f317000 >> R13: ffff88022f31b900 R14: 0000000000000080 R15: ffff8801fcc7d320 >> FS: 0000000000000000(0000) GS:ffff88022f300000(0000) >> knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 0000000002eee850 CR3: 0000000002c0b000 CR4: 00000000001406e0 >> Stack: >> ffff8800c92a3db8 ffffffff814e8bd2 ffffffffa09701f8 ffff8800c92a3d68 >> ffff880100000010 ffff8800c92a3dc8 ffff8800c92a3d88 000000002440e468 >> 0000000000000000 ffff8801fcee7800 00000000ffffffed 000000000001a2e1 >> Call Trace: >> [] dev_warn+0x62/0x80 >> [] k90_record_led_work+0x8c/0xa0 [hid_corsair_k90] >> [] ? __schedule+0x241/0x720 >> [] process_one_work+0x1bb/0x410 >> [] worker_thread+0x1bc/0x480 >> [] ? process_one_work+0x410/0x410 >> [] ? process_one_work+0x410/0x410 >> [] kthread+0xd8/0xf0 >> [] ? kthread_worker_fn+0x180/0x180 >> [] ret_from_fork+0x42/0x70 >> [] ? kthread_worker_fn+0x180/0x180 >> Code: 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 49 89 d1 48 89 e5 74 60 4c >> 8b 46 50 4d 85 c0 74 26 48 8b 86 90 00 00 00 48 85 c0 74 2a <48> 8b 08 0f be >> RIP [] __dev_printk+0x26/0x90 > > > As your backtrace shows, the problem originates from dev_warn call from > k90_record_led_work. dev_warn takes dev in its first argument, which > is already released at the time when it is called as a result of the > call to flush_work. In order to work this around you could set some > flag on remove to indicate that LED class device has been released > and return from k90_record_led_work immediately. You can also try doing get_device to have > 1 ref count so it won't go away. But I still feel you shouldn't have to if you re-order your work_fn and unregister calls. That is flush/cancel work before unregistering and then at the end remove sysfs group. > The same applies to your question regarding retaining the LED state > on remove. Hope this helps. > > Is the backtrace always the same? It could likely happen also earlier, > during dereference of dev in the following line: > > > struct device *dev = led->cdev.dev->parent; > > -- > Best Regards, > Jacek Anaszewski -- ---P.K.S From clement.vuchener at gmail.com Mon Sep 7 08:23:55 2015 From: clement.vuchener at gmail.com (=?iso-8859-1?Q?Cl=E9ment?= Vuchener) Date: Mon, 7 Sep 2015 14:23:55 +0200 Subject: How to properly unregister LED class devices? In-Reply-To: References: <20150906174806.GA16230@untxi.home> <20150907090556.GA2549@untxi.home> <55ED74C3.2090409@samsung.com> Message-ID: <20150907122355.GA5254@untxi.home> On Mon, Sep 07, 2015 at 05:17:09PM +0530, Pranay Srivastava wrote: > On Mon, Sep 7, 2015 at 4:58 PM, Jacek Anaszewski > wrote: > > Hi Cl?ment, > > > > > > On 09/07/2015 11:05 AM, Cl?ment Vuchener wrote: > >> > >> On Mon, Sep 07, 2015 at 12:08:17PM +0530, Pranay Srivastava wrote: > >>> > >>> On Sun, Sep 6, 2015 at 11:18 PM, Cl?ment Vuchener > >>> wrote: > >>>> > >>>> Hello, > >>>> > >>>> I am trying to write a driver that uses LED class devices using works > >>>> for setting the LED brightness but I am not sure of how to unregister the > >>>> devices. > >>>> > >>>> I have been using code like this: > >>>> led_classdev_unregister(&drvdata->backlight.cdev); > >>>> cancel_work_sync(&drvdata->backlight.work); > >>>> trying with both flush_work or cancel_work_sync as I have seen it in > >>>> other drivers. > >>>> > >>>> Using flush_work, the kernel oops in my work function when I unplug the > >>>> device. cancel_work_sync seems to fix that, but I am not sure it will work > >>>> every time. I would like to understand what happens and if I am doing > >>>> something wrong, to be sure it will not break in some different setup. > >>> > >>> > >>> Can you post the backtrace? > >>> > >> > >> I could not get it with my patched kernel (I must be missing some config > >> option) so I used the code as a module on my fedora 22 (4.1.6) kernel. > >> > >> general protection fault: 0000 [#1] SMP > >> Modules linked in: hid_corsair_k90(OE) bnep bluetooth nf_nat_h323 > >> nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp > >> nf_conntrack_proto_g > >> snd_hda_codec_hdmi coretemp arc4 kvm_intel snd_hda_codec_realtek iwldvm > >> kvm snd_hda_codec_generic mac80211 snd_hda_intel snd_hda_controller > >> snd_hda_co > >> CPU: 2 PID: 491 Comm: kworker/2:3 Tainted: G OE > >> 4.1.6-200.fc22.x86_64 #1 > >> Hardware name: CLEVO CO. W350ET/W350ET, BIOS > >> 1.02.21PM v3 07/01/2013 > >> Workqueue: events k90_record_led_work [hid_corsair_k90] > >> task: ffff880223bd4f00 ti: ffff8800c92a0000 task.ti: ffff8800c92a0000 > >> RIP: 0010:[] [] > >> __dev_printk+0x26/0x90 > >> RSP: 0018:ffff8800c92a3d48 EFLAGS: 00010202 > >> RAX: 657079740000009d RBX: ffff8801fcee7800 RCX: 000000000001a2e1 > >> RDX: ffff8800c92a3d58 RSI: ffff8801fcee7800 RDI: ffffffff81a2673f > >> RBP: ffff8800c92a3d48 R08: 0000001400730102 R09: ffff8800c92a3d58 > >> R10: ffffffff81578c4b R11: 0000000000000000 R12: ffff88022f317000 > >> R13: ffff88022f31b900 R14: 0000000000000080 R15: ffff8801fcc7d320 > >> FS: 0000000000000000(0000) GS:ffff88022f300000(0000) > >> knlGS:0000000000000000 > >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > >> CR2: 0000000002eee850 CR3: 0000000002c0b000 CR4: 00000000001406e0 > >> Stack: > >> ffff8800c92a3db8 ffffffff814e8bd2 ffffffffa09701f8 ffff8800c92a3d68 > >> ffff880100000010 ffff8800c92a3dc8 ffff8800c92a3d88 000000002440e468 > >> 0000000000000000 ffff8801fcee7800 00000000ffffffed 000000000001a2e1 > >> Call Trace: > >> [] dev_warn+0x62/0x80 > >> [] k90_record_led_work+0x8c/0xa0 [hid_corsair_k90] > >> [] ? __schedule+0x241/0x720 > >> [] process_one_work+0x1bb/0x410 > >> [] worker_thread+0x1bc/0x480 > >> [] ? process_one_work+0x410/0x410 > >> [] ? process_one_work+0x410/0x410 > >> [] kthread+0xd8/0xf0 > >> [] ? kthread_worker_fn+0x180/0x180 > >> [] ret_from_fork+0x42/0x70 > >> [] ? kthread_worker_fn+0x180/0x180 > >> Code: 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 49 89 d1 48 89 e5 74 60 4c > >> 8b 46 50 4d 85 c0 74 26 48 8b 86 90 00 00 00 48 85 c0 74 2a <48> 8b 08 0f be > >> RIP [] __dev_printk+0x26/0x90 > > > > > > As your backtrace shows, the problem originates from dev_warn call from > > k90_record_led_work. dev_warn takes dev in its first argument, which > > is already released at the time when it is called as a result of the > > call to flush_work. In order to work this around you could set some > > flag on remove to indicate that LED class device has been released > > and return from k90_record_led_work immediately. > > You can also try doing get_device to have > 1 ref count so it won't go > away. But I still feel you shouldn't have to if you re-order your > work_fn and unregister calls. That is flush/cancel work before > unregistering and then at the end remove sysfs group. No, I tested it, reordering flush and unregister still crash the driver when the device is unplugged. Anyway, Jacek's solution looks nice as it should solve both my problems. Thank you. > > > The same applies to your question regarding retaining the LED state > > on remove. Hope this helps. > > > > Is the backtrace always the same? It could likely happen also earlier, > > during dereference of dev in the following line: > > > > > > struct device *dev = led->cdev.dev->parent; > > > > -- > > Best Regards, > > Jacek Anaszewski > > > > -- > ---P.K.S From pranjas at gmail.com Mon Sep 7 10:10:51 2015 From: pranjas at gmail.com (Pranay Srivastava) Date: Mon, 7 Sep 2015 19:40:51 +0530 Subject: How to properly unregister LED class devices? In-Reply-To: <20150907122355.GA5254@untxi.home> References: <20150906174806.GA16230@untxi.home> <20150907090556.GA2549@untxi.home> <55ED74C3.2090409@samsung.com> <20150907122355.GA5254@untxi.home> Message-ID: On Mon, Sep 7, 2015 at 5:53 PM, Cl?ment Vuchener wrote: > On Mon, Sep 07, 2015 at 05:17:09PM +0530, Pranay Srivastava wrote: >> On Mon, Sep 7, 2015 at 4:58 PM, Jacek Anaszewski >> wrote: >> > Hi Cl?ment, >> > >> > >> > On 09/07/2015 11:05 AM, Cl?ment Vuchener wrote: >> >> >> >> On Mon, Sep 07, 2015 at 12:08:17PM +0530, Pranay Srivastava wrote: >> >>> >> >>> On Sun, Sep 6, 2015 at 11:18 PM, Cl?ment Vuchener >> >>> wrote: >> >>>> >> >>>> Hello, >> >>>> >> >>>> I am trying to write a driver that uses LED class devices using works >> >>>> for setting the LED brightness but I am not sure of how to unregister the >> >>>> devices. >> >>>> >> >>>> I have been using code like this: >> >>>> led_classdev_unregister(&drvdata->backlight.cdev); >> >>>> cancel_work_sync(&drvdata->backlight.work); >> >>>> trying with both flush_work or cancel_work_sync as I have seen it in >> >>>> other drivers. >> >>>> >> >>>> Using flush_work, the kernel oops in my work function when I unplug the >> >>>> device. cancel_work_sync seems to fix that, but I am not sure it will work >> >>>> every time. I would like to understand what happens and if I am doing >> >>>> something wrong, to be sure it will not break in some different setup. >> >>> >> >>> >> >>> Can you post the backtrace? >> >>> >> >> >> >> I could not get it with my patched kernel (I must be missing some config >> >> option) so I used the code as a module on my fedora 22 (4.1.6) kernel. >> >> >> >> general protection fault: 0000 [#1] SMP >> >> Modules linked in: hid_corsair_k90(OE) bnep bluetooth nf_nat_h323 >> >> nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp >> >> nf_conntrack_proto_g >> >> snd_hda_codec_hdmi coretemp arc4 kvm_intel snd_hda_codec_realtek iwldvm >> >> kvm snd_hda_codec_generic mac80211 snd_hda_intel snd_hda_controller >> >> snd_hda_co >> >> CPU: 2 PID: 491 Comm: kworker/2:3 Tainted: G OE >> >> 4.1.6-200.fc22.x86_64 #1 >> >> Hardware name: CLEVO CO. W350ET/W350ET, BIOS >> >> 1.02.21PM v3 07/01/2013 >> >> Workqueue: events k90_record_led_work [hid_corsair_k90] >> >> task: ffff880223bd4f00 ti: ffff8800c92a0000 task.ti: ffff8800c92a0000 >> >> RIP: 0010:[] [] >> >> __dev_printk+0x26/0x90 >> >> RSP: 0018:ffff8800c92a3d48 EFLAGS: 00010202 >> >> RAX: 657079740000009d RBX: ffff8801fcee7800 RCX: 000000000001a2e1 >> >> RDX: ffff8800c92a3d58 RSI: ffff8801fcee7800 RDI: ffffffff81a2673f >> >> RBP: ffff8800c92a3d48 R08: 0000001400730102 R09: ffff8800c92a3d58 >> >> R10: ffffffff81578c4b R11: 0000000000000000 R12: ffff88022f317000 >> >> R13: ffff88022f31b900 R14: 0000000000000080 R15: ffff8801fcc7d320 >> >> FS: 0000000000000000(0000) GS:ffff88022f300000(0000) >> >> knlGS:0000000000000000 >> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> >> CR2: 0000000002eee850 CR3: 0000000002c0b000 CR4: 00000000001406e0 >> >> Stack: >> >> ffff8800c92a3db8 ffffffff814e8bd2 ffffffffa09701f8 ffff8800c92a3d68 >> >> ffff880100000010 ffff8800c92a3dc8 ffff8800c92a3d88 000000002440e468 >> >> 0000000000000000 ffff8801fcee7800 00000000ffffffed 000000000001a2e1 >> >> Call Trace: >> >> [] dev_warn+0x62/0x80 >> >> [] k90_record_led_work+0x8c/0xa0 [hid_corsair_k90] >> >> [] ? __schedule+0x241/0x720 >> >> [] process_one_work+0x1bb/0x410 >> >> [] worker_thread+0x1bc/0x480 >> >> [] ? process_one_work+0x410/0x410 >> >> [] ? process_one_work+0x410/0x410 >> >> [] kthread+0xd8/0xf0 >> >> [] ? kthread_worker_fn+0x180/0x180 >> >> [] ret_from_fork+0x42/0x70 >> >> [] ? kthread_worker_fn+0x180/0x180 >> >> Code: 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 49 89 d1 48 89 e5 74 60 4c >> >> 8b 46 50 4d 85 c0 74 26 48 8b 86 90 00 00 00 48 85 c0 74 2a <48> 8b 08 0f be >> >> RIP [] __dev_printk+0x26/0x90 >> > >> > >> > As your backtrace shows, the problem originates from dev_warn call from >> > k90_record_led_work. dev_warn takes dev in its first argument, which >> > is already released at the time when it is called as a result of the >> > call to flush_work. In order to work this around you could set some >> > flag on remove to indicate that LED class device has been released >> > and return from k90_record_led_work immediately. >> >> You can also try doing get_device to have > 1 ref count so it won't go >> away. But I still feel you shouldn't have to if you re-order your >> work_fn and unregister calls. That is flush/cancel work before >> unregistering and then at the end remove sysfs group. > No, I tested it, reordering flush and unregister still crash the > driver when the device is unplugged. > > Anyway, Jacek's solution looks nice as it should solve both my problems. Thank > you. Hmm... I'm just wondering why it goes away while still at work. I don't have hardware so probably won't be able to test it out. :( >> >> > The same applies to your question regarding retaining the LED state >> > on remove. Hope this helps. >> > >> > Is the backtrace always the same? It could likely happen also earlier, >> > during dereference of dev in the following line: >> > >> > >> > struct device *dev = led->cdev.dev->parent; >> > >> > -- >> > Best Regards, >> > Jacek Anaszewski >> >> >> >> -- >> ---P.K.S -- ---P.K.S From alx741 at riseup.net Mon Sep 7 12:35:41 2015 From: alx741 at riseup.net (alx741 at riseup.net) Date: Mon, 07 Sep 2015 11:35:41 -0500 Subject: USB error codes and usbmon Message-ID: <19c681abff15a82fa769e3ebbe191a52@riseup.net> Kernel newbies community, I'm writing a simple usb device implementation using PIC microcontroller and using USBMON to debug, i've properly receive the very first GET_DESCRIPTOR request and try to send the device descriptor to the host and it seems not to be working, but the USBMON and dmesg confuses me and don't know if the device isn't sending the descriptor or if it's corrupted or if the descriptor is ok but the device don't accept the address (not programmed yet in the device). The USBMON output for the device (address 0) is: ffff8801c3272480 1145843 S Ci:3:000:0 s 80 06 0100 0000 0040 64 < ffff8801c3272480 2203609 C Ci:3:000:0 -32 0 ffff8801c3272480 2203652 S Ci:3:000:0 s 80 06 0100 0000 0040 64 < ffff8801c3272480 2203728 C Ci:3:000:0 -71 0 ffff8801c3272480 2203827 S Ci:3:000:0 s 80 06 0100 0000 0040 64 < ffff8801c3272480 2203952 C Ci:3:000:0 -71 0 The host request the device descriptor and asks for 64 bytes, from the device i (try to) send the descriptor but don't know what the "-32" and "-71" errors means, descriptor not received? descriptor bad constructed? neither? the DMESG output is: [ 3497.029992] usb 3-1.3: new full-speed USB device number 7 using xhci_hcd [ 3498.154446] usb 3-1.3: device descriptor read/64, error -71 [ 3498.324591] usb 3-1.3: device descriptor read/64, error -71 [ 3498.494831] usb 3-1.3: new full-speed USB device number 8 using xhci_hcd [ 3498.561500] usb 3-1.3: device descriptor read/64, error -71 [ 3498.731740] usb 3-1.3: device descriptor read/64, error -71 [ 3498.901870] usb 3-1.3: new full-speed USB device number 9 using xhci_hcd [ 3498.902080] usb 3-1.3: Device not responding to setup address. [ 3499.105555] usb 3-1.3: Device not responding to setup address. [ 3499.308882] usb 3-1.3: device not accepting address 9, error -71 [ 3499.375759] usb 3-1.3: new full-speed USB device number 10 using xhci_hcd [ 3499.375892] usb 3-1.3: Device not responding to setup address. [ 3499.579423] usb 3-1.3: Device not responding to setup address. [ 3499.782770] usb 3-1.3: device not accepting address 10, error -71 [ 3499.783035] usb 3-1-port3: unable to enumerate USB device Here the "-71" error is used for both device descriptor read error and device not accepting address. Is there a way to see what the host receives even if the data that is sent pretending to be the device descriptor is corrupted (for debugging)? and how can i know for sure what those errors tell me so i can start looking for the errors in my device code? Any pointers are much appreciated. Greetings from Ecuador. From Valdis.Kletnieks at vt.edu Mon Sep 7 13:55:35 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 07 Sep 2015 13:55:35 -0400 Subject: How to get the dentry value - no path_lookup In-Reply-To: References: Message-ID: <94683.1441648535@turing-police.cc.vt.edu> On Mon, 07 Sep 2015 12:10:56 +0530, Pria Mn said: > return valid dentry value. My requirement is to fetch directory name from > filepath. First off, unless this is a class assignment, your *requirement* isn't to fetch a directory name. Fetching the directory name is a *solution* you're thinking of using for a problem you're trying to solve. So take a step back, and explain what you're trying to do, and why you thought getting the directory name from filepath was a solution - it's quite likely that you should be using some other API and approach entirely. (I'd estimate that 75% of the "I can't get this API to work" questions on the Linux kernel are because the person should be using a different API....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150907/b273d32a/attachment.bin From rohan.puri15 at gmail.com Mon Sep 7 14:33:33 2015 From: rohan.puri15 at gmail.com (Rohan Puri) Date: Tue, 8 Sep 2015 00:03:33 +0530 Subject: How to get the dentry value - no path_lookup In-Reply-To: <94683.1441648535@turing-police.cc.vt.edu> References: <94683.1441648535@turing-police.cc.vt.edu> Message-ID: On 7 Sep 2015 23:25, wrote: > > On Mon, 07 Sep 2015 12:10:56 +0530, Pria Mn said: > > > return valid dentry value. My requirement is to fetch directory name from > > filepath. > > First off, unless this is a class assignment, your *requirement* isn't > to fetch a directory name. > > Fetching the directory name is a *solution* you're thinking of using for > a problem you're trying to solve. > > So take a step back, and explain what you're trying to do, and why you thought > getting the directory name from filepath was a solution - it's quite > likely that you should be using some other API and approach entirely. > > (I'd estimate that 75% of the "I can't get this API to work" questions > on the Linux kernel are because the person should be using a different API....) > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > Yes Valdis is absolutely right about being clear as to what you want to do and why you would be doing that. Also for what does the api do you need to understand the code and browse using tools(cscope ctags maybe others) to check for other APIs doing the same and you would definitely find one for your need. The way I would suggest is don't rush through, enjoy the process and not the result. Enjoy life, Rohan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150908/03eed909/attachment.html From mudongliangabcd at gmail.com Tue Sep 8 09:34:44 2015 From: mudongliangabcd at gmail.com (=?UTF-8?B?5oWV5Yas5Lqu?=) Date: Tue, 8 Sep 2015 21:34:44 +0800 Subject: linux aslr entropy bits Message-ID: Rs: number of bits randomized in the stack area, Rm: number of bits randomized in the mmap() area, Rx: number of bits randomized in the main executable area What's those three parameters? And how to calculate the aslr entropy bits? - mudongliang From danielhilst at gmail.com Tue Sep 8 13:19:28 2015 From: danielhilst at gmail.com (Daniel.) Date: Tue, 8 Sep 2015 14:19:28 -0300 Subject: SPI operations on interrupt context!? Message-ID: Hi all, I'm dealing with a SPI driver and I have a doubt. I need to read and write data to spi (registers and values) inside interrupt handler. I want to know if this pattern is safe or if I'll face problems with it. This code is being added to gpio-mcp23s08.c driver to handle IRQ and save INTCAP at interruption time. INTCAP register keeps the input port status at interruption time. I want to capture this as fast as possible and put it at a circular queue. I write this code inspired by spi_sync function, but using spinlocks so it doesn't sleeps. But, these spin_(un)lock calls seems a bad ideia to me. Any better idea or guidelines? Here is the code. https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L440 The functions are mcp23s17_read_irqsafe and mcp23s17_read_irqsafe_complete PS: The code is a little messed up (because I've been trying to optimize this INTCAP capturing by many means) Cheers - dhs -- *"Do or do not. There is no try"* *Yoda Master* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150908/c798eb33/attachment.html From anish198519851985 at gmail.com Tue Sep 8 15:30:01 2015 From: anish198519851985 at gmail.com (anish singh) Date: Tue, 8 Sep 2015 12:30:01 -0700 Subject: SPI operations on interrupt context!? In-Reply-To: References: Message-ID: On Tue, Sep 8, 2015 at 10:19 AM, Daniel. wrote: > Hi all, > > I'm dealing with a SPI driver and I have a doubt. I need to read and write > data to spi (registers and values) inside interrupt handler. I want to know > if this pattern is safe or if I'll face problems with it. > AFAIK the spi calls sleep, so it is not safe. > > This code is being added to gpio-mcp23s08.c driver to handle IRQ and save > INTCAP at interruption time. INTCAP register keeps the input port status at > interruption time. I want to capture this as fast as possible and put it at > a circular queue. I write this code inspired by spi_sync function, but > using spinlocks so it doesn't sleeps. But, these spin_(un)lock calls seems > a bad ideia to me. Any better idea or guidelines? > > Here is the code. > https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L440 > > The functions are mcp23s17_read_irqsafe and mcp23s17_read_irqsafe_complete > > PS: The code is a little messed up (because I've been trying to optimize > this INTCAP capturing by many means) > > What exactly you are trying to optimize you have not mentioned. I looked at the driver code you pointed out in your mail and looks like they are using threaded irq and I am sure that you understand that threaded irq can perform sleeping operations as it is basically a kthread. http://lxr.free-electrons.com/source/drivers/gpio/gpio-mcp23s08.c#L494 so you can easily use spinlock here. It is not interrupt context. Generally if you are trying to optimize something in linux kernel you should be very clear about your goal. Cheers > - dhs > > -- > *"Do or do not. There is no try"* > *Yoda Master* > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150908/0d571a92/attachment.html From danielhilst at gmail.com Tue Sep 8 17:23:31 2015 From: danielhilst at gmail.com (Daniel.) Date: Tue, 8 Sep 2015 18:23:31 -0300 Subject: SPI operations on interrupt context!? In-Reply-To: References: Message-ID: Even spi_async sleeps? I thought that spi_async wouldn't sleep :/ I have a board with an MCP23S17 gpio expander that is used as an digital input. I need to notify my application every time that any input status changes. The MCP triggers an interrupt every time that an input changes, but, the application may not be able to poll the MCP at the same rate that the input changes, so I used a circular queue at MCP driver. I need to add input changes (readed from INTCAP) as soon as they came, to be free to get new input changes as soon as possible. I'm looking for 1ms resolution here, so, summarizing, I want to be able to enqueue input changes at each 1ms. The MCP works like this. 1 - Input changes (set IRQ flags) 2 - Raise IRQ 3 - IRS reads INTCAP (this clears IRQ flags) Okay, ... I was enqueing on the threaded IRQ, but was losing events. The "losing events" here means that I got two interrupts in a row, with same INTCAP values, so I got input changes notification (IRS called) with no input changes. I think that a new interrupt is being raised before I read INTCAP so it got masked. The big question is: How to read INTCAP as fast as possible? This is why I tried spi_async in interrupt context. (mcp_hard_irq), but I'm still losing events at 1ms resolution. So, explaning the mess I did in the code :), first of all I've updated the code, is still in the same link: https://gist.github.com/gkos/4cce494e90518077084a I've decided to use a producing/consuming aproach, since application will never be abble to poll input status at same rate that it changes I need to enqueue it. To do this I've created a new function inside this module. mcp_getlast() should take the last element in queue, or wait for next event if is empty, is my consumer, here it is: https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L182 The procucer is the mcp23s17_produce_complete handler, it should enqueue INTCAP and return. This is it! https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L346 I've enabled tracing on my kernel (3.10.53 running on an i.MX6 quad). At the trace file I got this lines: spi32766-72 [000] d... 2589.220910: mcp23s17_produce_complete: mcp23s08: produced ffffff01 spi32766-72 [000] d... 2589.222973: mcp23s17_produce_complete: mcp23s08: produced ffffff00 spi32766-72 [000] d... 2589.223235: mcp23s17_produce_complete: mcp23s08: produced ffffff01 spi32766-72 [000] d... 2589.226119: mcp23s17_produce_complete: mcp23s08: produced ffffff00 spi32766-72 [000] d... 2589.227631: mcp23s17_produce_complete: mcp23s08: produced ffffff00 spi32766-72 [000] d... 2589.227898: mcp23s17_produce_complete: mcp23s08: produced ffffff01 There is possible see that INTCAP repeated (..ff00). This my problem! Well, thanks anybody that readed that long, any ideia would be helpful Best regards, 2015-09-08 16:30 GMT-03:00 anish singh : > > > On Tue, Sep 8, 2015 at 10:19 AM, Daniel. wrote: >> >> Hi all, >> >> I'm dealing with a SPI driver and I have a doubt. I need to read and write >> data to spi (registers and values) inside interrupt handler. I want to know >> if this pattern is safe or if I'll face problems with it. > > > AFAIK the spi calls sleep, so it is not safe. >> >> >> This code is being added to gpio-mcp23s08.c driver to handle IRQ and save >> INTCAP at interruption time. INTCAP register keeps the input port status at >> interruption time. I want to capture this as fast as possible and put it at >> a circular queue. I write this code inspired by spi_sync function, but using >> spinlocks so it doesn't sleeps. But, these spin_(un)lock calls seems a bad >> ideia to me. Any better idea or guidelines? >> >> Here is the code. >> >> https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L440 >> >> The functions are mcp23s17_read_irqsafe and mcp23s17_read_irqsafe_complete >> >> PS: The code is a little messed up (because I've been trying to optimize >> this INTCAP capturing by many means) >> > What exactly you are trying to optimize you have not mentioned. I looked at > the driver code > you pointed out in your mail and looks like they are using threaded irq and > I am sure that you > understand that threaded irq can perform sleeping operations as it is > basically a kthread. > > http://lxr.free-electrons.com/source/drivers/gpio/gpio-mcp23s08.c#L494 so > you can easily use > spinlock here. It is not interrupt context. > > Generally if you are trying to optimize something in linux kernel you should > be very clear about your goal. > >> Cheers >> - dhs >> >> -- >> "Do or do not. There is no try" >> Yoda Master >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > -- "Do or do not. There is no try" Yoda Master From yacdaniel at gmail.com Tue Sep 8 22:08:57 2015 From: yacdaniel at gmail.com (=?UTF-8?Q?Yacdaniel_Hurtado_Garc=C3=ADa?=) Date: Tue, 8 Sep 2015 20:08:57 -0600 Subject: Eudyptula task 2 Message-ID: Hi, i am doing task 2 of eudyptula, i cloned the repository, build, install and boot the kernel, when i send my response to little i attach the uname -a output and the .config but he answers this: Linus's tree is newer than this, or you forgot to set the requested configuration option :( atm i get this kernel version: 4.2.0-rc8 i dont know if i am doing something wrong.Thanks From ruben at mrbrklyn.com Tue Sep 8 22:18:32 2015 From: ruben at mrbrklyn.com (Ruben Safir) Date: Tue, 08 Sep 2015 22:18:32 -0400 Subject: Eudyptula task 2 In-Reply-To: References: Message-ID: <55EF96F8.8080407@mrbrklyn.com> On 09/08/2015 10:08 PM, Yacdaniel Hurtado Garc?a wrote: > Hi, i am doing task 2 of eudyptula, i cloned the repository, build, > install and boot the kernel, when i send my response to little i > attach the uname -a output and the .config but he answers this: > Linus's tree is newer than this, or you forgot to set the requested > configuration option :( > atm i get this kernel version: 4.2.0-rc8 i dont know if i am doing > something wrong.Thanks > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > that topic is not allowed on the list ;) From Valdis.Kletnieks at vt.edu Tue Sep 8 22:25:59 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Sep 2015 22:25:59 -0400 Subject: Eudyptula task 2 In-Reply-To: References: Message-ID: <58907.1441765559@turing-police.cc.vt.edu> On Tue, 08 Sep 2015 20:08:57 -0600, Yacdaniel Hurtado GarcC-a said: > atm i get this kernel version: 4.2.0-rc8 i dont know if i am doing > something wrong.Thanks You may or may not be doing something wrong. But you're probably no longer doing the Eudyptula challenge. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150908/52a6859f/attachment.bin From yacdaniel at gmail.com Tue Sep 8 22:26:08 2015 From: yacdaniel at gmail.com (=?UTF-8?Q?Yacdaniel_Hurtado_Garc=C3=ADa?=) Date: Tue, 8 Sep 2015 20:26:08 -0600 Subject: Eudyptula task 2 In-Reply-To: <55EF96F8.8080407@mrbrklyn.com> References: <55EF96F8.8080407@mrbrklyn.com> Message-ID: OK. ty :) 2015-09-08 20:18 GMT-06:00 Ruben Safir : > On 09/08/2015 10:08 PM, Yacdaniel Hurtado Garc?a wrote: >> Hi, i am doing task 2 of eudyptula, i cloned the repository, build, >> install and boot the kernel, when i send my response to little i >> attach the uname -a output and the .config but he answers this: >> Linus's tree is newer than this, or you forgot to set the requested >> configuration option :( >> atm i get this kernel version: 4.2.0-rc8 i dont know if i am doing >> something wrong.Thanks >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > > > that topic is not allowed on the list ;) > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies From chetannanda at gmail.com Wed Sep 9 05:09:50 2015 From: chetannanda at gmail.com (Chetan Nanda) Date: Wed, 9 Sep 2015 14:39:50 +0530 Subject: Videobuf2's vb2_dqbuf return (-EINVAL) error on streamoff Message-ID: Hi, I am working on a V4L2 based video decoder driver, At user side there are two contexts. One is queuing/dequeuing buffers from driver (in a separate thread) and other is the main context, from where I am calling streamon, streamoff. When I call a streamoff from main context and thread is blocking on dqbuf, This cause the blocking thread to unblock from dqbuf with an error (EINVAL). Seems this error coming from videobuf2-core, as streamoff will unblock the waiting thread, and this thread will go and check (in function __vb2_wait_for_done_vb) for q->streaming and will return error as q->streaming will be set to false on streamoff. Is it the right behavior of vb2_dqbuf to return error when streamoff is called? Or is it a right way to have this kind of mechanism i.e.on userside one thread is queue/dequeue buffers while another is doing streamoff. Thanks for your help and idea. Thanks, Chetan Nanda -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150909/08022b29/attachment.html From danielhilst at gmail.com Wed Sep 9 14:30:55 2015 From: danielhilst at gmail.com (Daniel.) Date: Wed, 9 Sep 2015 15:30:55 -0300 Subject: SPI operations on interrupt context!? In-Reply-To: References: Message-ID: I've checked the iomux configuration, there was some pins miss configured. Anyway I'm still losing IRQs. But now I have some hints from kernel. Now I see that I'm hitting this line: https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L380 which traces to: spi32766-72 [000] .... 1728.245798: mcp23s17_produce_complete: mcp23s08: Error on SPI transfer, -115 >From errno.h 115 means "operation in progress": http://lxr.free-electrons.com/source/include/uapi/asm-generic/errno.h?v=3.10#L88 So I need to take a look from ecspi (imx6 spi controller) code/clock/rates etc. Cheers, - dhs 2015-09-08 18:23 GMT-03:00 Daniel. : > Even spi_async sleeps? I thought that spi_async wouldn't sleep :/ > > I have a board with an MCP23S17 gpio expander that is used as an > digital input. I need to notify my application every time that any > input status changes. The MCP triggers an interrupt every time that an > input changes, but, the application may not be able to poll the MCP at > the same rate that the input changes, so I used a circular queue at > MCP driver. I need to add input changes (readed from INTCAP) as soon > as they came, to be free to get new input changes as soon as possible. > I'm looking for 1ms resolution here, so, summarizing, I want to be > able to enqueue input changes at each 1ms. > > The MCP works like this. > > 1 - Input changes (set IRQ flags) > 2 - Raise IRQ > 3 - IRS reads INTCAP (this clears IRQ flags) > > Okay, ... I was enqueing on the threaded IRQ, but was losing events. > The "losing events" here means that I got two interrupts in a row, > with same INTCAP values, so I got input changes notification (IRS > called) with no input changes. I think that a new interrupt is being > raised before I read INTCAP so it got masked. The big question is: How > to read INTCAP as fast as possible? > > This is why I tried spi_async in interrupt context. (mcp_hard_irq), > but I'm still losing events at 1ms resolution. > > So, explaning the mess I did in the code :), first of all I've updated > the code, is still in the same link: > https://gist.github.com/gkos/4cce494e90518077084a > > I've decided to use a producing/consuming aproach, since application > will never be abble to poll input status at same rate that it changes > I need to enqueue it. To do this I've created a new function inside > this module. mcp_getlast() should take the last element in queue, or > wait for next event if is empty, is my consumer, here it is: > https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L182 > > The procucer is the mcp23s17_produce_complete handler, it should > enqueue INTCAP and return. This is it! > https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L346 > > I've enabled tracing on my kernel (3.10.53 running on an i.MX6 quad). > At the trace file I got this lines: > spi32766-72 [000] d... 2589.220910: > mcp23s17_produce_complete: mcp23s08: produced ffffff01 > spi32766-72 [000] d... 2589.222973: > mcp23s17_produce_complete: mcp23s08: produced ffffff00 > spi32766-72 [000] d... 2589.223235: > mcp23s17_produce_complete: mcp23s08: produced ffffff01 > spi32766-72 [000] d... 2589.226119: > mcp23s17_produce_complete: mcp23s08: produced ffffff00 > spi32766-72 [000] d... 2589.227631: > mcp23s17_produce_complete: mcp23s08: produced ffffff00 > spi32766-72 [000] d... 2589.227898: > mcp23s17_produce_complete: mcp23s08: produced ffffff01 > > There is possible see that INTCAP repeated (..ff00). This my problem! > > Well, thanks anybody that readed that long, any ideia would be helpful > > Best regards, > > > 2015-09-08 16:30 GMT-03:00 anish singh : >> >> >> On Tue, Sep 8, 2015 at 10:19 AM, Daniel. wrote: >>> >>> Hi all, >>> >>> I'm dealing with a SPI driver and I have a doubt. I need to read and write >>> data to spi (registers and values) inside interrupt handler. I want to know >>> if this pattern is safe or if I'll face problems with it. >> >> >> AFAIK the spi calls sleep, so it is not safe. >>> >>> >>> This code is being added to gpio-mcp23s08.c driver to handle IRQ and save >>> INTCAP at interruption time. INTCAP register keeps the input port status at >>> interruption time. I want to capture this as fast as possible and put it at >>> a circular queue. I write this code inspired by spi_sync function, but using >>> spinlocks so it doesn't sleeps. But, these spin_(un)lock calls seems a bad >>> ideia to me. Any better idea or guidelines? >>> >>> Here is the code. >>> >>> https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L440 >>> >>> The functions are mcp23s17_read_irqsafe and mcp23s17_read_irqsafe_complete >>> >>> PS: The code is a little messed up (because I've been trying to optimize >>> this INTCAP capturing by many means) >>> >> What exactly you are trying to optimize you have not mentioned. I looked at >> the driver code >> you pointed out in your mail and looks like they are using threaded irq and >> I am sure that you >> understand that threaded irq can perform sleeping operations as it is >> basically a kthread. >> >> http://lxr.free-electrons.com/source/drivers/gpio/gpio-mcp23s08.c#L494 so >> you can easily use >> spinlock here. It is not interrupt context. >> >> Generally if you are trying to optimize something in linux kernel you should >> be very clear about your goal. >> >>> Cheers >>> - dhs >>> >>> -- >>> "Do or do not. There is no try" >>> Yoda Master >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies at kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> > > > > -- > "Do or do not. There is no try" > Yoda Master -- "Do or do not. There is no try" Yoda Master From danielhilst at gmail.com Wed Sep 9 16:19:36 2015 From: danielhilst at gmail.com (Daniel.) Date: Wed, 9 Sep 2015 17:19:36 -0300 Subject: SPI operations on interrupt context!? In-Reply-To: References: Message-ID: I also found that we having problems with MCP supply, so this is it! Thanks anish for your reply! Cheers, - dhs 2015-09-09 15:30 GMT-03:00 Daniel. : > I've checked the iomux configuration, there was some pins miss > configured. Anyway I'm still losing IRQs. But now I have some hints > from kernel. Now I see that I'm hitting this line: > https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L380 > which traces to: > > > spi32766-72 [000] .... 1728.245798: mcp23s17_produce_complete: > mcp23s08: Error on SPI transfer, -115 > > From errno.h 115 means "operation in progress": > > http://lxr.free-electrons.com/source/include/uapi/asm-generic/errno.h?v=3.10#L88 > > So I need to take a look from ecspi (imx6 spi controller) code/clock/rates > etc. > > Cheers, > - dhs > > 2015-09-08 18:23 GMT-03:00 Daniel. : > > Even spi_async sleeps? I thought that spi_async wouldn't sleep :/ > > > > I have a board with an MCP23S17 gpio expander that is used as an > > digital input. I need to notify my application every time that any > > input status changes. The MCP triggers an interrupt every time that an > > input changes, but, the application may not be able to poll the MCP at > > the same rate that the input changes, so I used a circular queue at > > MCP driver. I need to add input changes (readed from INTCAP) as soon > > as they came, to be free to get new input changes as soon as possible. > > I'm looking for 1ms resolution here, so, summarizing, I want to be > > able to enqueue input changes at each 1ms. > > > > The MCP works like this. > > > > 1 - Input changes (set IRQ flags) > > 2 - Raise IRQ > > 3 - IRS reads INTCAP (this clears IRQ flags) > > > > Okay, ... I was enqueing on the threaded IRQ, but was losing events. > > The "losing events" here means that I got two interrupts in a row, > > with same INTCAP values, so I got input changes notification (IRS > > called) with no input changes. I think that a new interrupt is being > > raised before I read INTCAP so it got masked. The big question is: How > > to read INTCAP as fast as possible? > > > > This is why I tried spi_async in interrupt context. (mcp_hard_irq), > > but I'm still losing events at 1ms resolution. > > > > So, explaning the mess I did in the code :), first of all I've updated > > the code, is still in the same link: > > https://gist.github.com/gkos/4cce494e90518077084a > > > > I've decided to use a producing/consuming aproach, since application > > will never be abble to poll input status at same rate that it changes > > I need to enqueue it. To do this I've created a new function inside > > this module. mcp_getlast() should take the last element in queue, or > > wait for next event if is empty, is my consumer, here it is: > > > https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L182 > > > > The procucer is the mcp23s17_produce_complete handler, it should > > enqueue INTCAP and return. This is it! > > > https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L346 > > > > I've enabled tracing on my kernel (3.10.53 running on an i.MX6 quad). > > At the trace file I got this lines: > > spi32766-72 [000] d... 2589.220910: > > mcp23s17_produce_complete: mcp23s08: produced ffffff01 > > spi32766-72 [000] d... 2589.222973: > > mcp23s17_produce_complete: mcp23s08: produced ffffff00 > > spi32766-72 [000] d... 2589.223235: > > mcp23s17_produce_complete: mcp23s08: produced ffffff01 > > spi32766-72 [000] d... 2589.226119: > > mcp23s17_produce_complete: mcp23s08: produced ffffff00 > > spi32766-72 [000] d... 2589.227631: > > mcp23s17_produce_complete: mcp23s08: produced ffffff00 > > spi32766-72 [000] d... 2589.227898: > > mcp23s17_produce_complete: mcp23s08: produced ffffff01 > > > > There is possible see that INTCAP repeated (..ff00). This my problem! > > > > Well, thanks anybody that readed that long, any ideia would be helpful > > > > Best regards, > > > > > > 2015-09-08 16:30 GMT-03:00 anish singh : > >> > >> > >> On Tue, Sep 8, 2015 at 10:19 AM, Daniel. wrote: > >>> > >>> Hi all, > >>> > >>> I'm dealing with a SPI driver and I have a doubt. I need to read and > write > >>> data to spi (registers and values) inside interrupt handler. I want to > know > >>> if this pattern is safe or if I'll face problems with it. > >> > >> > >> AFAIK the spi calls sleep, so it is not safe. > >>> > >>> > >>> This code is being added to gpio-mcp23s08.c driver to handle IRQ and > save > >>> INTCAP at interruption time. INTCAP register keeps the input port > status at > >>> interruption time. I want to capture this as fast as possible and put > it at > >>> a circular queue. I write this code inspired by spi_sync function, but > using > >>> spinlocks so it doesn't sleeps. But, these spin_(un)lock calls seems a > bad > >>> ideia to me. Any better idea or guidelines? > >>> > >>> Here is the code. > >>> > >>> > https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L440 > >>> > >>> The functions are mcp23s17_read_irqsafe and > mcp23s17_read_irqsafe_complete > >>> > >>> PS: The code is a little messed up (because I've been trying to > optimize > >>> this INTCAP capturing by many means) > >>> > >> What exactly you are trying to optimize you have not mentioned. I > looked at > >> the driver code > >> you pointed out in your mail and looks like they are using threaded irq > and > >> I am sure that you > >> understand that threaded irq can perform sleeping operations as it is > >> basically a kthread. > >> > >> http://lxr.free-electrons.com/source/drivers/gpio/gpio-mcp23s08.c#L494 > so > >> you can easily use > >> spinlock here. It is not interrupt context. > >> > >> Generally if you are trying to optimize something in linux kernel you > should > >> be very clear about your goal. > >> > >>> Cheers > >>> - dhs > >>> > >>> -- > >>> "Do or do not. There is no try" > >>> Yoda Master > >>> > >>> _______________________________________________ > >>> Kernelnewbies mailing list > >>> Kernelnewbies at kernelnewbies.org > >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >>> > >> > > > > > > > > -- > > "Do or do not. There is no try" > > Yoda Master > > > > -- > "Do or do not. There is no try" > Yoda Master > -- *"Do or do not. There is no try"* *Yoda Master* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150909/499af4c3/attachment.html From wkevils at gmail.com Thu Sep 10 00:52:49 2015 From: wkevils at gmail.com (Kevin Wilson) Date: Thu, 10 Sep 2015 07:52:49 +0300 Subject: Preceding a method call with (void) Message-ID: Hi all, I intend to send a patch to the kernel, and my question is about preceding a method with (void). In several OpenSource UserSpace projects, I encountered usage of preceding a method invocation with (void). For example: (void) myFunc(param1); I did not encounter such cases in the kernel code that I read, thus far. On the other hand, I did not saw in the kernel coding style doc anything which prohibits such usage. If I remember, using (void) before the method name is a way to tell explicitly that this method does not return any value, but I am not sure as for the exact reasons it is used (in userspace). My question is: Will sending a patch to the kernel with code with (void) preceding method calls make sense ? or should I avoid it in the first place (again, I did not saw such a pattern in the kernel) Regards, Kevin From greg at kroah.com Thu Sep 10 01:00:50 2015 From: greg at kroah.com (Greg KH) Date: Wed, 9 Sep 2015 22:00:50 -0700 Subject: Preceding a method call with (void) In-Reply-To: References: Message-ID: <20150910050050.GA29808@kroah.com> On Thu, Sep 10, 2015 at 07:52:49AM +0300, Kevin Wilson wrote: > Hi all, > > I intend to send a patch to the kernel, and my question is about > preceding a method with (void). Don't :) > My question is: > Will sending a patch to the kernel with code with (void) preceding > method calls make sense ? Nope. > or should I avoid it in the first place (again, I did not saw such a > pattern in the kernel) Avoid it please. Just curious, what code do you want to change to add a (void) to? thanks, greg k-h From Valdis.Kletnieks at vt.edu Thu Sep 10 02:39:20 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Sep 2015 02:39:20 -0400 Subject: Preceding a method call with (void) In-Reply-To: References: Message-ID: <25475.1441867160@turing-police.cc.vt.edu> On Thu, 10 Sep 2015 07:52:49 +0300, Kevin Wilson said: > (void) myFunc(param1); > > I did not encounter such cases in the kernel code that I read, thus far. > > On the other hand, I did not saw in the kernel coding style doc > anything which prohibits such usage. > > If I remember, using (void) before the method name is a way to tell > explicitly that this method does not return any value, > but I am not sure as for the exact reasons it is used (in userspace). Well, if the function actually returns nothing, in kernel code we usually declare it as: void myFunc( int param1) { /* yadda yadda yadda *. } Given that, what reason is there for casting the return value with (void)? (And if the function is actually 'int myFunc ( int param1) {...}', why are you calling it and then ignoring the return value? That's a clue that you're abusing the API...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150910/fcebd1a8/attachment.bin From rocklee_104 at outlook.com Thu Sep 10 03:09:42 2015 From: rocklee_104 at outlook.com (Rock Lee) Date: Thu, 10 Sep 2015 15:09:42 +0800 Subject: Use a variable before it's declaration Message-ID: Hi, all: Here is a snippet of linux-v3.4 which drives me crazy. Because init_task hasn't been declared yet when init_thread_union is initializing. Why is there no compiling error? Any hint would be helpful. union thread_union init_thread_union __init_task_data = { INIT_THREAD_INFO(init_task) }; /* * Initial task structure. * * All other task structs will be allocated on slabs in fork.c */ struct task_struct init_task = INIT_TASK(init_task); -- Rock Lee From Valdis.Kletnieks at vt.edu Thu Sep 10 03:55:25 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Sep 2015 03:55:25 -0400 Subject: Use a variable before it's declaration In-Reply-To: References: Message-ID: <30823.1441871725@turing-police.cc.vt.edu> On Thu, 10 Sep 2015 15:09:42 +0800, Rock Lee said: > union thread_union init_thread_union __init_task_data = > > { INIT_THREAD_INFO(init_task) }; 'gcc -E' to see what this expands to. All may not be as it seems. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150910/bc10f249/attachment.bin From bjorn at mork.no Thu Sep 10 04:00:07 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 10 Sep 2015 10:00:07 +0200 Subject: Use a variable before it's declaration In-Reply-To: (Rock Lee's message of "Thu, 10 Sep 2015 15:09:42 +0800") References: Message-ID: <87zj0uk8l4.fsf@nemi.mork.no> Rock Lee writes: > Hi, all: > Here is a snippet of linux-v3.4 which drives me crazy. > Because init_task hasn't been declared yet when init_thread_union is > initializing. Why is there no compiling error? Any hint would be helpful. > > union thread_union init_thread_union __init_task_data = > > { INIT_THREAD_INFO(init_task) }; > > > > /* > > * Initial task structure. > > * > > * All other task structs will be allocated on slabs in fork.c > > */ > > struct task_struct init_task = INIT_TASK(init_task); Because init_task is declared "extern" in linux/sched.h Bj?rn From rocklee_104 at outlook.com Thu Sep 10 04:27:53 2015 From: rocklee_104 at outlook.com (Rock Lee) Date: Thu, 10 Sep 2015 16:27:53 +0800 Subject: Use a variable before it's declaration In-Reply-To: <87zj0uk8l4.fsf@nemi.mork.no> References: <87zj0uk8l4.fsf@nemi.mork.no> Message-ID: > Rock Lee writes: > >> Hi, all: >> Here is a snippet of linux-v3.4 which drives me crazy. >> Because init_task hasn't been declared yet when init_thread_union is >> initializing. Why is there no compiling error? Any hint would be helpful. >> >> union thread_union init_thread_union __init_task_data = >> >> { INIT_THREAD_INFO(init_task) }; >> >> >> >> /* >> >> * Initial task structure. >> >> * >> >> * All other task structs will be allocated on slabs in fork.c >> >> */ >> >> struct task_struct init_task = INIT_TASK(init_task); > > > Because init_task is declared "extern" in linux/sched.h > > > Bj?rn I do something like that: extern int b; int a = b + 10; int b = 20; int main(void) { return 0; } No doubt, compiling error. -- Rock Lee From bjorn at mork.no Thu Sep 10 04:43:15 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 10 Sep 2015 10:43:15 +0200 Subject: Use a variable before it's declaration In-Reply-To: (Rock Lee's message of "Thu, 10 Sep 2015 16:27:53 +0800") References: <87zj0uk8l4.fsf@nemi.mork.no> Message-ID: <87r3m6k6l8.fsf@nemi.mork.no> Rock Lee writes: >> Rock Lee writes: >> >>> Hi, all: >>> Here is a snippet of linux-v3.4 which drives me crazy. >>> Because init_task hasn't been declared yet when init_thread_union is >>> initializing. Why is there no compiling error? Any hint would be helpful. >>> >>> union thread_union init_thread_union __init_task_data = >>> >>> { INIT_THREAD_INFO(init_task) }; >>> >>> >>> >>> /* >>> >>> * Initial task structure. >>> >>> * >>> >>> * All other task structs will be allocated on slabs in fork.c >>> >>> */ >>> >>> struct task_struct init_task = INIT_TASK(init_task); >> >> >> Because init_task is declared "extern" in linux/sched.h >> >> >> Bj?rn > > I do something like that: > > extern int b; > int a = b + 10; > int b = 20; > > int main(void) > { > return 0; > } > > No doubt, compiling error. Sure. That's a completely different issue. But this works: extern int b; int *a = &b; int b = 20; int main(void) { return 0; } and that's what the code you refer do does. Bj?rn From rocklee_104 at outlook.com Thu Sep 10 04:44:23 2015 From: rocklee_104 at outlook.com (Rock Lee) Date: Thu, 10 Sep 2015 16:44:23 +0800 Subject: Use a variable before it's declaration In-Reply-To: <30823.1441871725@turing-police.cc.vt.edu> References: <30823.1441871725@turing-police.cc.vt.edu> Message-ID: On 2015/9/10 15:55, Valdis.Kletnieks at vt.edu wrote: > On Thu, 10 Sep 2015 15:09:42 +0800, Rock Lee said: > >> union thread_union init_thread_union __init_task_data = >> >> { INIT_THREAD_INFO(init_task) }; > > 'gcc -E' to see what this expands to. All may not be as it seems. :) > Thanks, I used "make arch/arm/kernel/init_task.i" instead to see what that code expands to. It's exactly what confused me still. init_thread_union uses init_task before init_task's initialization. union thread_union init_thread_union __attribute__((__section__(".data..init_task"))) = { { .task = &init_task, .exec_domain = &default_exec_domain, .flags = 0, .preempt_count = (1 + 0x40000000), .addr_limit = 0x00000000, .cpu_domain = ((3) << (2*(1))) | ((3) << (2*(0))) | ((1) << (2*(2))), .restart_block = { .fn = do_no_restart_syscall, }, } }; struct task_struct init_task = { .state = 0, .stack = &(init_thread_union.thread_info), .usage = { (2) }, .flags = 0x00200000, .prio = (100 + 40)-20, .static_prio = (100 + 40)-20, .normal_prio = (100 + 40)-20, .policy = 0, .cpus_allowed = (cpumask_t) { { [(((1) + (8 * sizeof(long)) - 1) / (8 * sizeof(long)))-1] = ( ((1) % 32) ? (1UL<<((1) % 32))-1 : ~0UL ) } }, .mm = ((void *)0), .active_mm = &init_mm, .se = { .group_node = { &(init_task.se.group_node), &(init_task.se.group_node) }, }, .rt = { .run_list = { &(init_task.rt.run_list), &(init_task.rt.run_list) }, .time_slice = (100 * 100 / 1000), .nr_cpus_allowed = 1, }, .tasks = { &(init_task.tasks), &(init_task.tasks) }, .ptraced = { &(init_task.ptraced), &(init_task.ptraced) }, .ptrace_entry = { &(init_task.ptrace_entry), &(init_task.ptrace_entry) }, .real_parent = &init_task, .parent = &init_task, .children = { &(init_task.children), &(init_task.children) }, .sibling = { &(init_task.sibling), &(init_task.sibling) }, .group_leader = &init_task, .real_cred = (typeof(*&init_cred) *)(&init_cred), .cred = (typeof(*&init_cred) *)(&init_cred), .comm = "swapper", .thread = { }, .fs = &init_fs, .files = &init_files, .signal = &init_signals, .sighand = &init_sighand, .nsproxy = &init_nsproxy, .pending = { .list = { &(init_task.pending.list), &(init_task.pending.list) }, .signal = {{0}}}, .blocked = {{0}}, .alloc_lock = (spinlock_t ) { { .rlock = { .raw_lock = { 1 }, .magic = 0xdead4ead, .owner_cpu = -1, .owner = ((void *)-1L), } } }, .journal_info = ((void *)0), .cpu_timers = { { &(init_task.cpu_timers[0]), &(init_task.cpu_timers[0]) }, { &(init_task.cpu_timers[1]), &(init_task.cpu_timers[1]) }, { &(init_task.cpu_timers[2]), &(init_task.cpu_timers[2]) }, }, .pi_lock = (raw_spinlock_t) { .raw_lock = { 1 }, .magic = 0xdead4ead, .owner_cpu = -1, .owner = ((void *)-1L), }, .timer_slack_ns = 50000, .pids = { [PIDTYPE_PID] = { .node = { .next = ((void *)0), .pprev = ((void *)0), }, .pid = &init_struct_pid, }, [PIDTYPE_PGID] = { .node = { .next = ((void *)0), .pprev = ((void *)0), }, .pid = &init_struct_pid, }, [PIDTYPE_SID] = { .node = { .next = ((void *)0), .pprev = ((void *)0), }, .pid = &init_struct_pid, }, }, .thread_group = { &(init_task.thread_group), &(init_task.thread_group) }, }; -- Rock Lee From rocklee_104 at outlook.com Thu Sep 10 04:58:51 2015 From: rocklee_104 at outlook.com (Rock Lee) Date: Thu, 10 Sep 2015 16:58:51 +0800 Subject: Use a variable before it's declaration In-Reply-To: <87r3m6k6l8.fsf@nemi.mork.no> References: <87zj0uk8l4.fsf@nemi.mork.no> <87r3m6k6l8.fsf@nemi.mork.no> Message-ID: > Sure. That's a completely different issue. But this works: > > extern int b; > int *a = &b; > int b = 20; > > int main(void) > { > return 0; > } > > and that's what the code you refer do does. Yes, that make sense, thanks very much :-) -- Rock Lee From laitianli2015 at outlook.com Thu Sep 10 05:41:51 2015 From: laitianli2015 at outlook.com (tianlilai) Date: Thu, 10 Sep 2015 17:41:51 +0800 Subject: Set the ACPI=on on the cmdline, and the OS can not boot. Message-ID: Hi,Everyone,I have a problem as follow: When I set the ACPI=on on the cmdline,and the OS can not boot(If set ACPI=off, The system is OK). The attachmemt file is the booting log. Would help me slove this ploblem? Thanks very much. Note:kernel version v2.6.18,and the arch is x86_64. Regards laitianli -------------- next part -------------- Bootdata ok (command line is ro root=LABEL=/ rhgb console=ttyS0,115200 console=tty1 apic=debug acpi=on) Linux version 2.6.18-std (laitianli at XCompiler) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)) #13 SMP Thu Sep 10 16:35:59 CST 2015 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009d400 (usable) BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved) BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000bf7a0000 (usable) BIOS-e820: 00000000bf7a0000 - 00000000bf7bd000 (ACPI data) BIOS-e820: 00000000bf7bd000 - 00000000bf7be000 (ACPI NVS) BIOS-e820: 00000000bf7be000 - 00000000bf7ff000 (reserved) BIOS-e820: 00000000bf800000 - 00000000c0000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000140000000 (usable) DMI present. No NUMA configuration found Faking a node at 0000000000000000-0000000140000000 Bootmem setup node 0 0000000000000000-0000000140000000 ACPI: PM-Timer IO Port: 0x1008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 7:14 APIC version 21 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) Processor #2 7:14 APIC version 21 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) Processor #4 7:14 APIC version 21 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled) Processor #6 7:14 APIC version 21 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Setting APIC routing to physical flat ACPI: HPET id: 0x8086a701 base: 0xfed00000 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at c2000000 (gap: c0000000:20000000) SMP: Allowing 4 CPUs, 0 hotplug CPUs Built 1 zonelists. Total pages: 1028401 Kernel command line: ro root=LABEL=/ rhgb console=ttyS0,115200 console=tty1 apic=debug acpi=on Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer. time.c: Detected 2394.071 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing software IO TLB between 0x62c0000 - 0xa2c0000 Memory: 4032088k/5242880k available (2276k kernel code, 153244k reserved, 1193k data, 200k init) Calibrating delay using timer specific routine.. 4791.75 BogoMIPS (lpj=2395878) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 256 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 MCE: warning: using only 9 banks CPU0: Thermal monitoring enabled (TM1) SMP alternatives: switching to UP code ACPI: Core revision 20060707 tbxface-0107 [01] load_tables : ACPI Tables successfully acquired Parsing all Control Methods: Table [DSDT](id 0007) - 513 Objects with 52 Devices 118 Methods 37 Regions Parsing all Control Methods: Table [SSDT](id 0004) - 68 Objects with 0 Devices 48 Methods 0 Regions Parsing all Control Methods: Table [SSDT](id 0005) - 8 Objects with 0 Devices 1 Methods 2 Regions ACPI Namespace successfully loaded at root ffffffff815aa740 evxfevnt-0089 [02] enable : Transition to ACPI mode successful enabled ExtINT on CPU#0 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 Using local APIC timer interrupts. result 8312740 Detected 8.312 MHz APIC timer. SMP alternatives: switching to SMP code Booting processor 1/4 APIC 0x2 Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 4787.98 BogoMIPS (lpj=2393991) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 MCE: warning: using only 9 banks CPU1: Thermal monitoring enabled (TM1) Intel(R) Xeon(R) CPU X3430 @ 2.40GHz stepping 05 SMP alternatives: switching to SMP code Booting processor 2/4 APIC 0x4 Initializing CPU#2 masked ExtINT on CPU#2 Calibrating delay using timer specific routine.. 4787.70 BogoMIPS (lpj=2393851) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 2 MCE: warning: using only 9 banks CPU2: Thermal monitoring enabled (TM1) Intel(R) Xeon(R) CPU X3430 @ 2.40GHz stepping 05 SMP alternatives: switching to SMP code Booting processor 3/4 APIC 0x6 Initializing CPU#3 masked ExtINT on CPU#3 Calibrating delay using timer specific routine.. 4787.97 BogoMIPS (lpj=2393987) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 3 MCE: warning: using only 9 banks CPU3: Thermal monitoring enabled (TM1) Intel(R) Xeon(R) CPU X3430 @ 2.40GHz stepping 05 Brought up 4 CPUs testing NMI watchdog ... OK. migration_cost=19 checking if image is initramfs... it is Freeing initrd memory: 2487k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using MMCONFIG at e0000000 evgpeblk-0951 [04] ev_create_gpe_block : GPE 00 to 3F [_GPE] 8 regs on int 0x9 evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 4 Wake, Enabled 0 Runtime GPEs in this block Completing Region/Field/Buffer/Package initialization:........................................................................... Initialized 39/39 Regions 0/0 Fields 31/31 Buffers 5/17 Packages (598 nodes) Initializing Device/Processor/Thermal objects by executing _INI methods:. Executed 1 _INI methods requiring 0 _STA executions (examined 70 objects) ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs<7>Losing some ticks... checking if CPU frequency changed. 4 5 6 7 10 11 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 4 5 6 7 10 11 14 15) *9 Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 11 devices usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report testing the IO APIC....................... Using vector-based indexing .................................... done. hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 0, 0, 0, 0, 0, 0 hpet0: 8 64-bit timers, 14318180 Hz PCI-GART: No AMD northbridge found. PCI: Bridge: 0000:00:03.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.7 IO window: 2000-2fff MEM window: dc100000-dc1fffff PREFETCH window: disabled. PCI: Ignore bogus resource 6 [0:0] of 0000:11:03.0 PCI: Bridge: 0000:00:1e.0 IO window: 3000-3fff MEM window: dc000000-dc0fffff PREFETCH window: d8000000-dbffffff GSI 16 sharing vector 0xA9 and IRQ 16 ACPI: PCI Interrupt 0000:00:03.0[A] -> GSI 16 (level, low) -> IRQ 169 GSI 17 sharing vector 0xB1 and IRQ 17 ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 177 GSI 18 sharing vector 0xB9 and IRQ 18 ACPI: PCI Interrupt 0000:00:1c.7[D] -> GSI 19 (level, low) -> IRQ 185 NET: Registered protocol family 2 IP route cache hash table entries: 131072 (order: 8, 1048576 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered Simple Boot Flag at 0x36 set to 0x80 Total HugeTLB memory allocated, 0 Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) assign_interrupt_mode Found MSI capability assign_interrupt_mode Found MSI capability assign_interrupt_mode Found MSI capability pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: CPU1 (power states: C1[C1] C2[C2]) ACPI: CPU2 (power states: C1[C1] C2[C2]) ACPI: CPU3 (power states: C1[C1] C2[C2]) ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0x4 ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0x5 ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0x6 ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0x7 ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0x8 ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0x9 ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0xa ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0xb ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0xc ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0xd ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0xe ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0xf Real Time Clock Driver v1.12ac ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFF0 [20060707] Non-volatile memory driver v1.2 Linux agpgart interface v0.101 (c) Dave Jones Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled [SERIAL_Log]=[serial8250_init:2644]=NR_IRQS=239 [SERIAL_Log]=[serial8250_init:2648]=1 [SERIAL_Log]=[serial8250_init:2655]=2 [SERIAL_Log]=[serial8250_init:2659]=2.1 From Valdis.Kletnieks at vt.edu Thu Sep 10 09:48:19 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Sep 2015 09:48:19 -0400 Subject: Set the ACPI=on on the cmdline, and the OS can not boot. In-Reply-To: References: Message-ID: <56056.1441892899@turing-police.cc.vt.edu> On Thu, 10 Sep 2015 17:41:51 +0800, tianlilai said: > When I set the ACPI=on on the cmdline,and the OS can not boot(If set > ACPI=off, The system is OK). The attachmemt file is the booting log. Would > help me slove this ploblem? Thanks very much. > Note:kernel version v2.6.18,and the arch is x86_64. That's an ancient kernel - 9 years ago. So you're missing the last 9 years of ACPI fixes. Also, problems like this are usually caused by the BIOS having buggy ACPI tables that don't match the actual hardware - and if you're still on 2.6.18, your BIOS is probably equally out of date. And you would need to be a *lot* more specific about the hardware than "x86_64" - for instance,"Dell Latitude E6530 laptop with BIOS A16". Unfortunately for you, I doubt anybody is going to want to give much more assistance than this for free until you're running a kernel from the last 2-3 years and the most recent BIOS the manufacturer has released. (I can think of a number of people that will do this for contract work, but be prepared to pay US$50/hour and up...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150910/76213eba/attachment.bin From zertsekel at gmail.com Thu Sep 10 13:49:06 2015 From: zertsekel at gmail.com (Kosta Zertsekel) Date: Thu, 10 Sep 2015 20:49:06 +0300 Subject: When to use threaded interrupts? Message-ID: Hi guys, I hope I'm on right mailing list. :-) I think I get the pro of using threaded interrupts - to decrease the maximum interrupt latency on RT workloads and/or RT machines (servers, embedded, etc.). Also, I see that in 4.2 there are only ~76 drivers that use threaded interrupt: ``` $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l 76 ``` ?So, I'd like to ask: - Why not **all** of the drivers use the threaded interrupts? - What are the cons of the threaded interrupts?? Thanks, --- KostaZ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150910/11ea411f/attachment.html From roszenrami at gmail.com Thu Sep 10 16:09:41 2015 From: roszenrami at gmail.com (Rami Rosen) Date: Thu, 10 Sep 2015 23:09:41 +0300 Subject: When to use threaded interrupts? In-Reply-To: References: Message-ID: Kosta, Just a wild assumption: maybe the cost of incurring context switches ? (comparing to tasklets) Best Regards, Rami Rosen http://ramirose.wix.com/ramirosen On 10 September 2015 at 20:49, Kosta Zertsekel wrote: > Hi guys, > > I hope I'm on right mailing list. :-) > I think I get the pro of using threaded interrupts - to decrease the maximum > interrupt latency on RT workloads and/or RT machines (servers, embedded, > etc.). > > Also, I see that in 4.2 there are only ~76 drivers that use threaded > interrupt: > ``` > $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l > 76 > ``` > > So, I'd like to ask: > - Why not **all** of the drivers use the threaded interrupts? > - What are the cons of the threaded interrupts? > > Thanks, > --- KostaZ > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > From sabelaraga at gmail.com Fri Sep 11 10:07:17 2015 From: sabelaraga at gmail.com (Sabela Ramos Garea) Date: Fri, 11 Sep 2015 16:07:17 +0200 Subject: Userspace pages in UC mode Message-ID: Dear all, For research purposes I need some userspace memory pages to be in uncacheable mode. I am using two different Intel architectures (Sandy Bridge and Haswell) and two different kernels (2.6.32-358 and 3.19.0-28). The non-temporal stores from Intel assembly are not a valid solution so I am programming a kernel module that gets a set of pages from user space reserved with posix_memalign (get_user_pages) and then sets them as uncacheable (I have tried set_pages_uc and set_pages_array_uc). When I use one page, the access times are not very coherent and with more than one page the module crashes (in both architectures and both kernels). I wonder if I am using the correct approach or if I have to use kernel space pages in order to work with uncacheable memory. Or if I have to remap the memory. Just in case it makes it clearer, I am attaching the relevant lines of a kernel module function that should set the pages as uncacheable. (This function is the .write of a misc device; count is treated as the number of pages). Best and Thanks, Sabela. struct page *pages; //defined outside in order to be able to set them to WB in the release function. int numpages; static ssize_t setup_memory(struct file *filp, const char __user *buf, size_t count, loff_t * ppos) { int res; struct vm_area_struct *vmas; numpages = count/4096; down_read(¤t->mm->mmap_sem); res = get_user_pages(current, current->mm, (unsigned long) buf, numpages, /* Number of pages */ 0, /* Do want to write into it */ 1, /* do force */ &pages, &vmas); up_read(¤t->mm->mmap_sem); numpages=res; if (res > 0) { set_pages_uc(pages, numpages); /* Uncached */ printk("Write: %d pages set as uncacheable\n",numpages); } else{ pr_err("Couldn't get pages to set them as UC :(\n"); return -EAGAIN; } } From sabelaraga at gmail.com Fri Sep 11 10:59:10 2015 From: sabelaraga at gmail.com (Sabela Ramos Garea) Date: Fri, 11 Sep 2015 16:59:10 +0200 Subject: Userspace pages in UC mode In-Reply-To: References: Message-ID: Sorry, little mistake copypasting and cleaning. The pages and vma structs should look like that: struct page *pages --> struct page *pages[MAX_PAGES]; struct vma_area_struct *vma --> struct vma_area_struct *vma[MAX_PAGES]; Where MAX_PAGES is defined to 5. Sabela. 2015-09-11 16:07 GMT+02:00 Sabela Ramos Garea : > Dear all, > > For research purposes I need some userspace memory pages to be in > uncacheable mode. I am using two different Intel architectures (Sandy > Bridge and Haswell) and two different kernels (2.6.32-358 and > 3.19.0-28). > > The non-temporal stores from Intel assembly are not a valid solution > so I am programming a kernel module that gets a set of pages from user > space reserved with posix_memalign (get_user_pages) and then sets them > as uncacheable (I have tried set_pages_uc and set_pages_array_uc). > When I use one page, the access times are not very coherent and with > more than one page the module crashes (in both architectures and both > kernels). > > I wonder if I am using the correct approach or if I have to use kernel > space pages in order to work with uncacheable memory. Or if I have to > remap the memory. Just in case it makes it clearer, I am attaching the > relevant lines of a kernel module function that should set the pages > as uncacheable. (This function is the .write of a misc device; count > is treated as the number of pages). > > Best and Thanks, > > Sabela. > > struct page *pages; //defined outside in order to be able to set them > to WB in the release function. > int numpages; > > static ssize_t setup_memory(struct file *filp, const char __user *buf, > size_t count, loff_t * ppos) > { > int res; > struct vm_area_struct *vmas; > > numpages = count/4096; > > down_read(¤t->mm->mmap_sem); > res = get_user_pages(current, current->mm, > (unsigned long) buf, > numpages, /* Number of pages */ > 0, /* Do want to write into it */ > 1, /* do force */ > &pages, > &vmas); > up_read(¤t->mm->mmap_sem); > > numpages=res; > > if (res > 0) { > set_pages_uc(pages, numpages); /* Uncached */ > printk("Write: %d pages set as uncacheable\n",numpages); > } > else{ > pr_err("Couldn't get pages to set them as UC :(\n"); > return -EAGAIN; > } > } From matlackdavid at gmail.com Fri Sep 11 14:10:15 2015 From: matlackdavid at gmail.com (David Matlack) Date: Fri, 11 Sep 2015 11:10:15 -0700 Subject: Userspace pages in UC mode In-Reply-To: References: Message-ID: On Fri, Sep 11, 2015 at 7:59 AM, Sabela Ramos Garea wrote: > Sorry, little mistake copypasting and cleaning. The pages and vma > structs should look like that: > > struct page *pages --> struct page *pages[MAX_PAGES]; > struct vma_area_struct *vma --> struct vma_area_struct *vma[MAX_PAGES]; > > Where MAX_PAGES is defined to 5. > > Sabela. > > 2015-09-11 16:07 GMT+02:00 Sabela Ramos Garea : >> Dear all, >> >> For research purposes I need some userspace memory pages to be in >> uncacheable mode. I am using two different Intel architectures (Sandy >> Bridge and Haswell) and two different kernels (2.6.32-358 and >> 3.19.0-28). >> >> The non-temporal stores from Intel assembly are not a valid solution >> so I am programming a kernel module that gets a set of pages from user >> space reserved with posix_memalign (get_user_pages) and then sets them >> as uncacheable (I have tried set_pages_uc and set_pages_array_uc). >> When I use one page, the access times are not very coherent and with >> more than one page the module crashes (in both architectures and both >> kernels). set_pages_uc might just set the kernel virtual address mappings for those pages as uncacheable via the Page Attribute Table, but you are accessing from userspace virtual addresses. If you have the userspace virtual address of the pages you can manually twiddle the PAT bits of the page tables in your module to make the pages UC. >> >> I wonder if I am using the correct approach or if I have to use kernel >> space pages in order to work with uncacheable memory. Or if I have to >> remap the memory. Just in case it makes it clearer, I am attaching the >> relevant lines of a kernel module function that should set the pages >> as uncacheable. (This function is the .write of a misc device; count >> is treated as the number of pages). >> >> Best and Thanks, >> >> Sabela. >> >> struct page *pages; //defined outside in order to be able to set them >> to WB in the release function. >> int numpages; >> >> static ssize_t setup_memory(struct file *filp, const char __user *buf, >> size_t count, loff_t * ppos) >> { >> int res; >> struct vm_area_struct *vmas; >> >> numpages = count/4096; >> >> down_read(¤t->mm->mmap_sem); >> res = get_user_pages(current, current->mm, >> (unsigned long) buf, >> numpages, /* Number of pages */ >> 0, /* Do want to write into it */ >> 1, /* do force */ >> &pages, >> &vmas); >> up_read(¤t->mm->mmap_sem); >> >> numpages=res; >> >> if (res > 0) { >> set_pages_uc(pages, numpages); /* Uncached */ >> printk("Write: %d pages set as uncacheable\n",numpages); >> } >> else{ >> pr_err("Couldn't get pages to set them as UC :(\n"); >> return -EAGAIN; >> } >> } > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies From pranjas at gmail.com Fri Sep 11 21:12:04 2015 From: pranjas at gmail.com (Pranay Srivastava) Date: Sat, 12 Sep 2015 06:42:04 +0530 Subject: Userspace pages in UC mode In-Reply-To: References: Message-ID: Hi Sabela, On Fri, Sep 11, 2015 at 8:29 PM, Sabela Ramos Garea wrote: > Sorry, little mistake copypasting and cleaning. The pages and vma > structs should look like that: > > struct page *pages --> struct page *pages[MAX_PAGES]; > struct vma_area_struct *vma --> struct vma_area_struct *vma[MAX_PAGES]; > > Where MAX_PAGES is defined to 5. > > Sabela. > > 2015-09-11 16:07 GMT+02:00 Sabela Ramos Garea : >> Dear all, >> >> For research purposes I need some userspace memory pages to be in >> uncacheable mode. I am using two different Intel architectures (Sandy >> Bridge and Haswell) and two different kernels (2.6.32-358 and >> 3.19.0-28). >> >> The non-temporal stores from Intel assembly are not a valid solution >> so I am programming a kernel module that gets a set of pages from user >> space reserved with posix_memalign (get_user_pages) and then sets them >> as uncacheable (I have tried set_pages_uc and set_pages_array_uc). >> When I use one page, the access times are not very coherent and with >> more than one page the module crashes (in both architectures and both >> kernels). >> >> I wonder if I am using the correct approach or if I have to use kernel >> space pages in order to work with uncacheable memory. Or if I have to >> remap the memory. Just in case it makes it clearer, I am attaching the >> relevant lines of a kernel module function that should set the pages >> as uncacheable. (This function is the .write of a misc device; count >> is treated as the number of pages). >> >> Best and Thanks, >> >> Sabela. >> >> struct page *pages; //defined outside in order to be able to set them >> to WB in the release function. >> int numpages; >> >> static ssize_t setup_memory(struct file *filp, const char __user *buf, >> size_t count, loff_t * ppos) >> { >> int res; >> struct vm_area_struct *vmas; >> shouldn't this be rounded this up? >> numpages = count/4096; >> >> down_read(¤t->mm->mmap_sem); >> res = get_user_pages(current, current->mm, >> (unsigned long) buf, >> numpages, /* Number of pages */ >> 0, /* Do want to write into it */ >> 1, /* do force */ >> &pages, >> &vmas); >> up_read(¤t->mm->mmap_sem); >> >> numpages=res; >> >> if (res > 0) { >> set_pages_uc(pages, numpages); /* Uncached */ what about high-mem pages. set_memory_uc does __pa, so perhaps that's the reason for your kernel oops? >> printk("Write: %d pages set as uncacheable\n",numpages); >> } >> else{ >> pr_err("Couldn't get pages to set them as UC :(\n"); >> return -EAGAIN; >> } >> } > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- ---P.K.S From tanure at linux.com Sat Sep 12 15:04:43 2015 From: tanure at linux.com (Lucas Tanure) Date: Sat, 12 Sep 2015 16:04:43 -0300 Subject: Tips for Kernel Module Debugging Message-ID: Hi, I'm testing the linux-next tree and I got this stack: [ 2.158054] Call Trace: [ 2.158058] [] dump_stack+0x4b/0x72 [ 2.158061] [] warn_slowpath_common+0x82/0xc0 [ 2.158063] [] warn_slowpath_null+0x1a/0x20 [ 2.158066] [] drm_dev_alloc+0x251/0x320 [drm] [ 2.158070] [] drm_get_pci_dev+0x3b/0x1e0 [drm] [ 2.158081] [] i915_pci_probe+0x34/0x50 [i915] How is the best way to debug this ? I really need to add a print, compile and boot many times ? How would you guys debug this ? I know a way to boot two kernels, and the second get the dump from the first. But this isn't a Oops or Panic, it's just a warning. So the second kernel will not be triggered. Tips ? Thanks -- Lucas Tanure +55 (19) 988176559 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150912/4f21001b/attachment.html From Valdis.Kletnieks at vt.edu Sat Sep 12 15:27:12 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 12 Sep 2015 15:27:12 -0400 Subject: Tips for Kernel Module Debugging In-Reply-To: References: Message-ID: <54540.1442086032@turing-police.cc.vt.edu> On Sat, 12 Sep 2015 16:04:43 -0300, Lucas Tanure said: > I'm testing the linux-next tree and I got this stack: > > [ 2.158054] Call Trace: > [ 2.158058] [] dump_stack+0x4b/0x72 > [ 2.158061] [] warn_slowpath_common+0x82/0xc0 > [ 2.158063] [] warn_slowpath_null+0x1a/0x20 > [ 2.158066] [] drm_dev_alloc+0x251/0x320 [drm] > [ 2.158070] [] drm_get_pci_dev+0x3b/0x1e0 [drm] > [ 2.158081] [] i915_pci_probe+0x34/0x50 [i915] > > How is the best way to debug this ? I really need to add a print, compile > and boot many times ? > How would you guys debug this ? Step 0: Include the last few lines *before* the Call Trace - if indeed it was a Warning, it will give you the file and line number of where the WARN_ON was.. [26636.029711] ------------[ cut here ]------------ [26636.029724] WARNING: CPU: 3 PID: 19157 at ./arch/x86/include/asm/thread_info.h:239 sigsuspend+0xa4/0xb0() Bummer of a birthmark, Hal. The one my laptop hit was a WARN_ON inside either a macro or static inline from that .h file. Fortunately, yours was inside a .c file and pointed in the right place (see below for how I know that...) That 'cut here' is where you should start the cut-n-paste, and include everything down to 'end trace'. Having said that, looking at drivers/gpu/drm/drm_drv.c:drm_dev_alloc() we find only one WARN_ON: if (drm_core_check_feature(dev, DRIVER_MODESET)) { ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL); if (ret) goto err_minors; WARN_ON(driver->suspend || driver->resume); } As to *why* that one triggered, you'll have to ask an actual i915 expert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150912/6ce9d989/attachment.bin From tanure at linux.com Sat Sep 12 15:41:39 2015 From: tanure at linux.com (Lucas Tanure) Date: Sat, 12 Sep 2015 16:41:39 -0300 Subject: Tips for Kernel Module Debugging In-Reply-To: <54540.1442086032@turing-police.cc.vt.edu> References: <54540.1442086032@turing-police.cc.vt.edu> Message-ID: On Sat, Sep 12, 2015 at 4:27 PM, wrote: > On Sat, 12 Sep 2015 16:04:43 -0300, Lucas Tanure said: > > > I'm testing the linux-next tree and I got this stack: > > > > [ 2.158054] Call Trace: > > [ 2.158058] [] dump_stack+0x4b/0x72 > > [ 2.158061] [] warn_slowpath_common+0x82/0xc0 > > [ 2.158063] [] warn_slowpath_null+0x1a/0x20 > > [ 2.158066] [] drm_dev_alloc+0x251/0x320 [drm] > > [ 2.158070] [] drm_get_pci_dev+0x3b/0x1e0 [drm] > > [ 2.158081] [] i915_pci_probe+0x34/0x50 [i915] > > > > How is the best way to debug this ? I really need to add a print, compile > > and boot many times ? > > How would you guys debug this ? > > Step 0: Include the last few lines *before* the Call Trace - if indeed > it was a Warning, it will give you the file and line number of where the > WARN_ON was.. > > [26636.029711] ------------[ cut here ]------------ > [26636.029724] WARNING: CPU: 3 PID: 19157 at > ./arch/x86/include/asm/thread_info.h:239 sigsuspend+0xa4/0xb0() > > Bummer of a birthmark, Hal. The one my laptop hit was a WARN_ON inside > either a macro or static inline from that .h file. Fortunately, yours > was inside a .c file and pointed in the right place (see below for how > I know that...) > > That 'cut here' is where you should start the cut-n-paste, and include > everything down to 'end trace'. > > Having said that, looking at drivers/gpu/drm/drm_drv.c:drm_dev_alloc() we > find only one WARN_ON: > > if (drm_core_check_feature(dev, DRIVER_MODESET)) { > ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL); > if (ret) > goto err_minors; > > WARN_ON(driver->suspend || driver->resume); > } > > As to *why* that one triggered, you'll have to ask an actual i915 expert. > Hi, My full warning: ------------[ cut here ]------------ WARNING: CPU: 3 PID: 243 at drivers/gpu/drm/drm_drv.c:569 drm_dev_alloc+0x251/0x320 [drm]() Modules linked in: i915(+) joydev input_leds mousedev intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ttm hid_generic drm_kms_helper crct10dif_pclmul snd_hda_intel crc32_pclmul usbhid snd_hda_codec crc32c_intel drm hid ghash_clmulni_intel snd_hda_core eeepc_wmi asus_wmi aesni_intel iTCO_wdt sparse_keymap snd_hwdep led_class aes_x86_64 lrw snd_pcm iTCO_vendor_support rfkill mxm_wmi evdev gf128mul intel_gtt e1000e glue_helper mac_hid snd_timer syscopyarea ablk_helper cryptd sysfillrect psmouse snd sysimgblt pcspkr fb_sys_fops ptp mei_me i2c_i801 i2c_algo_bit soundcore mei shpchp i2c_core pps_core lpc_ich serio_raw wmi fan battery processor thermal video button sch_fq_codel ip_tables x_tables ext4 crc16 mbcache jbd2 sd_mod atkbd libps2 ahci libahci libata xhci_pci xhci_hcd ehci_pci ehci_hcd scsi_mod usbcore usb_common i8042 serio CPU: 3 PID: 243 Comm: systemd-udevd Not tainted 4.2.0-next-20150912-ARCH #5 Hardware name: System manufacturer System Product Name/Maximus IV GENE-Z, BIOS 3603 11/09/2012 0000000000000000 000000005ca47666 ffff88060f70b9d0 ffffffff812b9159 0000000000000000 ffff88060f70ba08 ffffffff81074e62 ffff880612d39000 ffffffffa06c7100 ffff880612f66098 ffffffffa06c7100 ffffffffa0691760 Call Trace: [] dump_stack+0x4b/0x72 [] warn_slowpath_common+0x82/0xc0 [] warn_slowpath_null+0x1a/0x20 [] drm_dev_alloc+0x251/0x320 [drm] [] drm_get_pci_dev+0x3b/0x1e0 [drm] [] i915_pci_probe+0x34/0x50 [i915] [] local_pci_probe+0x45/0xa0 [] ? pci_match_device+0xe0/0x110 [] pci_device_probe+0x103/0x150 [] driver_probe_device+0x222/0x490 [] __driver_attach+0x84/0x90 [] ? driver_probe_device+0x490/0x490 [] bus_for_each_dev+0x6c/0xc0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x1eb/0x280 [] driver_register+0x60/0xe0 [] __pci_register_driver+0x4c/0x50 [] drm_pci_init+0xe0/0x110 [drm] [] ? 0xffffffffa06e6000 [] i915_init+0xa4/0xab [i915] [] do_one_initcall+0xb3/0x200 [] ? __vunmap+0x91/0xe0 [] do_init_module+0x5f/0x1ef [] load_module+0x2197/0x27e0 [] ? symbol_put_addr+0x50/0x50 [] ? __pte_alloc_kernel+0xa5/0xf0 [] SyS_init_module+0x14e/0x190 [] entry_SYSCALL_64_fastpath+0x12/0x71 ---[ end trace d2652104b24a32ff ]--- I could see that the real problem is drm_dev_alloc, because it's the function just before the warring warn_slowpath_null. And this warn_slowpath_null function is what prints the warn. So how I can debug this ? Thanks! -- Lucas Tanure +55 (19) 988176559 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150912/235b0932/attachment.html From zertsekel at gmail.com Sun Sep 13 02:24:36 2015 From: zertsekel at gmail.com (Kosta Zertsekel) Date: Sun, 13 Sep 2015 09:24:36 +0300 Subject: When to use threaded interrupts? In-Reply-To: References: Message-ID: ?>> I think I get the pro of using threaded interrupts - to decrease the maximum >> interrupt latency on RT workloads and/or RT machines (servers, embedded, >> etc.). ?>> So, I'd like to ask: >> - Why not **all** of the drivers use the threaded interrupts? >> - What are the cons of the threaded interrupts? >> > Just a wild assumption: maybe the cost of incurring context switches ? > (comparing to tasklets) I get that threaded IRQ is better than softIrqs because threaded IRQ supports priorities. On the other hand, added context switches surely get system slower. But from the practical point of view - why on relatively new Intel PC there are no threaded irqs at all? ``` $ uname -a Linux kostaz-OptiPlex-7010 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11 14:16:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ``` --- KostaZ On Thu, Sep 10, 2015 at 11:09 PM, Rami Rosen wrote: > Kosta, > > ?? > Just a wild assumption: maybe the cost of incurring context switches ? > (comparing to tasklets) > > Best Regards, > Rami Rosen > http://ramirose.wix.com/ramirosen > > > > On 10 September 2015 at 20:49, Kosta Zertsekel > wrote: > > Hi guys, > > > > I hope I'm on right mailing list. :-) > > I think I get the pro of using threaded interrupts - to decrease the > maximum > > interrupt latency on RT workloads and/or RT machines (servers, embedded, > > etc.). > > > > Also, I see that in 4.2 there are only ~76 drivers that use threaded > > interrupt: > > ``` > > $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l > > 76 > > ``` > > > ?? > > So, I'd like to ask: > > - Why not **all** of the drivers use the threaded interrupts? > > - What are the cons of the threaded interrupts? > > > > Thanks, > > --- KostaZ > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies at kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/88fc95e2/attachment-0001.html From roszenrami at gmail.com Sun Sep 13 07:16:48 2015 From: roszenrami at gmail.com (Rami Rosen) Date: Sun, 13 Sep 2015 14:16:48 +0300 Subject: When to use threaded interrupts? In-Reply-To: References: Message-ID: Kosta, This kernel and older ones include device drivers which use threaded IRQs (call request_threaded_irq(), etc). For example, many of the driver under drivers/input/touchscreen are using threaded IRQs: Following link is from kernel 3.18: http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c?v=3.18 How did you came to the conclusion that this kernel does not support threaded IRQs ? could it be that you simply do not use device drivers that use this mechanism ? Regards, Rami Rosen http://ramirose.wix.com/ramirosen On 13 September 2015 at 09:24, Kosta Zertsekel wrote: >>> I think I get the pro of using threaded interrupts - to decrease the >>> maximum >>> interrupt latency on RT workloads and/or RT machines (servers, embedded, >>> etc.). >>> So, I'd like to ask: >>> - Why not **all** of the drivers use the threaded interrupts? >>> - What are the cons of the threaded interrupts? >>> >> Just a wild assumption: maybe the cost of incurring context switches ? >> (comparing to tasklets) > > I get that threaded IRQ is better than softIrqs because threaded IRQ > supports > priorities. On the other hand, added context switches surely get system > slower. > But from the practical point of view - why on relatively new Intel PC there > are > no threaded irqs at all? > > ``` > $ uname -a > Linux kostaz-OptiPlex-7010 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11 > 14:16:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > ``` > > --- KostaZ > > On Thu, Sep 10, 2015 at 11:09 PM, Rami Rosen wrote: >> >> Kosta, >> >> Just a wild assumption: maybe the cost of incurring context switches ? >> (comparing to tasklets) >> >> Best Regards, >> Rami Rosen >> http://ramirose.wix.com/ramirosen >> >> >> >> On 10 September 2015 at 20:49, Kosta Zertsekel >> wrote: >> > Hi guys, >> > >> > I hope I'm on right mailing list. :-) >> > I think I get the pro of using threaded interrupts - to decrease the >> > maximum >> > interrupt latency on RT workloads and/or RT machines (servers, embedded, >> > etc.). >> > >> > Also, I see that in 4.2 there are only ~76 drivers that use threaded >> > interrupt: >> > ``` >> > $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l >> > 76 >> > ``` >> > >> > So, I'd like to ask: >> > - Why not **all** of the drivers use the threaded interrupts? >> > - What are the cons of the threaded interrupts? >> > >> > Thanks, >> > --- KostaZ >> > >> > _______________________________________________ >> > Kernelnewbies mailing list >> > Kernelnewbies at kernelnewbies.org >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > From tanure at linux.com Sun Sep 13 09:30:56 2015 From: tanure at linux.com (Lucas Tanure) Date: Sun, 13 Sep 2015 10:30:56 -0300 Subject: What's the difference between /proc/vmcore and /proc/kcore ? Message-ID: Hi, What's the difference between /proc/vmcore and /proc/kcore ? Thanks -- Lucas Tanure -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/e4055f69/attachment.html From dhylands at gmail.com Sun Sep 13 12:36:15 2015 From: dhylands at gmail.com (Dave Hylands) Date: Sun, 13 Sep 2015 09:36:15 -0700 Subject: What's the difference between /proc/vmcore and /proc/kcore ? In-Reply-To: References: Message-ID: My take on it is that /proc/kcore is a mapping of the raw virtual memory, so it looks like a humungous sparse file. /proc/vmcore is a ELF-formatted version of the same thing which would be more suitable for storing on a hard-drive. On Sun, Sep 13, 2015 at 6:30 AM, Lucas Tanure wrote: > Hi, > > What's the difference between /proc/vmcore and /proc/kcore ? > > Thanks > > -- > Lucas Tanure > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/d44d6d6e/attachment.html From tanure at linux.com Sun Sep 13 13:09:21 2015 From: tanure at linux.com (Lucas Tanure) Date: Sun, 13 Sep 2015 14:09:21 -0300 Subject: Help debugging linux-next. Message-ID: Hi, I would like some tips about how debug a issue with linux-next. I'm trying to find things to do in kernel, and the first thing is boot the linux-next tree. I'm able to compile the source, but when I boot I got a black screen a few times, or a just a warn in dmesg. I'm trying to understand the issue, but no success. I tried to get kdump from the issue, but didn't work. I also tried to go back a few commits in linux-next, but my system doesn't boot at all. How I can find the commit that create the problem, since every commit that I tested I got black screen ? Whats the best way to debug this kind of issue ? Thanks! My full warning: ------------[ cut here ]------------ WARNING: CPU: 3 PID: 243 at drivers/gpu/drm/drm_drv.c:569 drm_dev_alloc+0x251/0x320 [drm]() Modules linked in: i915(+) joydev input_leds mousedev intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ttm hid_generic drm_kms_helper crct10dif_pclmul snd_hda_intel crc32_pclmul usbhid snd_hda_codec crc32c_intel drm hid ghash_clmulni_intel snd_hda_core eeepc_wmi asus_wmi aesni_intel iTCO_wdt sparse_keymap snd_hwdep led_class aes_x86_64 lrw snd_pcm iTCO_vendor_support rfkill mxm_wmi evdev gf128mul intel_gtt e1000e glue_helper mac_hid snd_timer syscopyarea ablk_helper cryptd sysfillrect psmouse snd sysimgblt pcspkr fb_sys_fops ptp mei_me i2c_i801 i2c_algo_bit soundcore mei shpchp i2c_core pps_core lpc_ich serio_raw wmi fan battery processor thermal video button sch_fq_codel ip_tables x_tables ext4 crc16 mbcache jbd2 sd_mod atkbd libps2 ahci libahci libata xhci_pci xhci_hcd ehci_pci ehci_hcd scsi_mod usbcore usb_common i8042 serio CPU: 3 PID: 243 Comm: systemd-udevd Not tainted 4.2.0-next-20150912-ARCH #5 Hardware name: System manufacturer System Product Name/Maximus IV GENE-Z, BIOS 3603 11/09/2012 0000000000000000 000000005ca47666 ffff88060f70b9d0 ffffffff812b9159 0000000000000000 ffff88060f70ba08 ffffffff81074e62 ffff880612d39000 ffffffffa06c7100 ffff880612f66098 ffffffffa06c7100 ffffffffa0691760 Call Trace: [] dump_stack+0x4b/0x72 [] warn_slowpath_common+0x82/0xc0 [] warn_slowpath_null+0x1a/0x20 [] drm_dev_alloc+0x251/0x320 [drm] [] drm_get_pci_dev+0x3b/0x1e0 [drm] [] i915_pci_probe+0x34/0x50 [i915] [] local_pci_probe+0x45/0xa0 [] ? pci_match_device+0xe0/0x110 [] pci_device_probe+0x103/0x150 [] driver_probe_device+0x222/0x490 [] __driver_attach+0x84/0x90 [] ? driver_probe_device+0x490/0x490 [] bus_for_each_dev+0x6c/0xc0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x1eb/0x280 [] driver_register+0x60/0xe0 [] __pci_register_driver+0x4c/0x50 [] drm_pci_init+0xe0/0x110 [drm] [] ? 0xffffffffa06e6000 [] i915_init+0xa4/0xab [i915] [] do_one_initcall+0xb3/0x200 [] ? __vunmap+0x91/0xe0 [] do_init_module+0x5f/0x1ef [] load_module+0x2197/0x27e0 [] ? symbol_put_addr+0x50/0x50 [] ? __pte_alloc_kernel+0xa5/0xf0 [] SyS_init_module+0x14e/0x190 [] entry_SYSCALL_64_fastpath+0x12/0x71 ---[ end trace d2652104b24a32ff ]--- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/54e35b11/attachment.html From kirotawa at gmail.com Sun Sep 13 13:19:43 2015 From: kirotawa at gmail.com (leo kirotawa) Date: Sun, 13 Sep 2015 14:19:43 -0300 Subject: Help debugging linux-next. In-Reply-To: References: Message-ID: git bisect would be a choice. Seems your issue is around i915, that is related to intel graphics, isolate commits in this area would be another way On Sun, Sep 13, 2015 at 2:09 PM, Lucas Tanure wrote: > Hi, > > I would like some tips about how debug a issue with linux-next. > I'm trying to find things to do in kernel, and the first thing is boot the > linux-next tree. > > I'm able to compile the source, but when I boot I got a black screen a few > times, or a just a warn in dmesg. > > I'm trying to understand the issue, but no success. I tried to get kdump > from the issue, but didn't work. I also tried to go back a few commits in > linux-next, but my system doesn't boot at all. > > How I can find the commit that create the problem, since every commit that I > tested I got black screen ? > Whats the best way to debug this kind of issue ? > > Thanks! > > My full warning: > > ------------[ cut here ]------------ > WARNING: CPU: 3 PID: 243 at drivers/gpu/drm/drm_drv.c:569 > drm_dev_alloc+0x251/0x320 [drm]() > Modules linked in: i915(+) joydev input_leds mousedev intel_rapl iosf_mbi > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ttm hid_generic > drm_kms_helper crct10dif_pclmul snd_hda_intel crc32_pclmul usbhid > snd_hda_codec crc32c_intel drm hid ghash_clmulni_intel snd_hda_core > eeepc_wmi asus_wmi aesni_intel iTCO_wdt sparse_keymap snd_hwdep led_class > aes_x86_64 lrw snd_pcm iTCO_vendor_support rfkill mxm_wmi evdev gf128mul > intel_gtt e1000e glue_helper mac_hid snd_timer syscopyarea ablk_helper > cryptd sysfillrect psmouse snd sysimgblt pcspkr fb_sys_fops ptp mei_me > i2c_i801 i2c_algo_bit soundcore mei shpchp i2c_core pps_core lpc_ich > serio_raw wmi fan battery processor thermal video button sch_fq_codel > ip_tables x_tables ext4 crc16 mbcache jbd2 sd_mod atkbd libps2 ahci libahci > libata > xhci_pci xhci_hcd ehci_pci ehci_hcd scsi_mod usbcore usb_common i8042 serio > CPU: 3 PID: 243 Comm: systemd-udevd Not tainted 4.2.0-next-20150912-ARCH #5 > Hardware name: System manufacturer System Product Name/Maximus IV GENE-Z, > BIOS 3603 11/09/2012 > 0000000000000000 000000005ca47666 ffff88060f70b9d0 ffffffff812b9159 > 0000000000000000 ffff88060f70ba08 ffffffff81074e62 ffff880612d39000 > ffffffffa06c7100 ffff880612f66098 ffffffffa06c7100 ffffffffa0691760 > Call Trace: > [] dump_stack+0x4b/0x72 > [] warn_slowpath_common+0x82/0xc0 > [] warn_slowpath_null+0x1a/0x20 > [] drm_dev_alloc+0x251/0x320 [drm] > [] drm_get_pci_dev+0x3b/0x1e0 [drm] > [] i915_pci_probe+0x34/0x50 [i915] > [] local_pci_probe+0x45/0xa0 > [] ? pci_match_device+0xe0/0x110 > [] pci_device_probe+0x103/0x150 > [] driver_probe_device+0x222/0x490 > [] __driver_attach+0x84/0x90 > [] ? driver_probe_device+0x490/0x490 > [] bus_for_each_dev+0x6c/0xc0 > [] driver_attach+0x1e/0x20 > [] bus_add_driver+0x1eb/0x280 > [] driver_register+0x60/0xe0 > [] __pci_register_driver+0x4c/0x50 > [] drm_pci_init+0xe0/0x110 [drm] > [] ? 0xffffffffa06e6000 > [] i915_init+0xa4/0xab [i915] > [] do_one_initcall+0xb3/0x200 > [] ? __vunmap+0x91/0xe0 > [] do_init_module+0x5f/0x1ef > [] load_module+0x2197/0x27e0 > [] ? symbol_put_addr+0x50/0x50 > [] ? __pte_alloc_kernel+0xa5/0xf0 > [] SyS_init_module+0x14e/0x190 > [] entry_SYSCALL_64_fastpath+0x12/0x71 > ---[ end trace d2652104b24a32ff ]--- > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- ---------------------------------------------- Le?nidas S. Barbosa (Kirotawa) blog: corecode.wordpress.com From raulpblooper at gmail.com Sun Sep 13 13:24:53 2015 From: raulpblooper at gmail.com (Raul Piper) Date: Sun, 13 Sep 2015 22:54:53 +0530 Subject: Help debugging linux-next. In-Reply-To: References: Message-ID: I m a newbie.is there a doc which developers follow for using git-bisect.google misleads !! On Sep 13, 2015 10:50 PM, "leo kirotawa" wrote: > git bisect would be a choice. > Seems your issue is around i915, that is related to intel graphics, > isolate commits in this area would be another way > > > > On Sun, Sep 13, 2015 at 2:09 PM, Lucas Tanure wrote: > > Hi, > > > > I would like some tips about how debug a issue with linux-next. > > I'm trying to find things to do in kernel, and the first thing is boot > the > > linux-next tree. > > > > I'm able to compile the source, but when I boot I got a black screen a > few > > times, or a just a warn in dmesg. > > > > I'm trying to understand the issue, but no success. I tried to get kdump > > from the issue, but didn't work. I also tried to go back a few commits in > > linux-next, but my system doesn't boot at all. > > > > How I can find the commit that create the problem, since every commit > that I > > tested I got black screen ? > > Whats the best way to debug this kind of issue ? > > > > Thanks! > > > > My full warning: > > > > ------------[ cut here ]------------ > > WARNING: CPU: 3 PID: 243 at drivers/gpu/drm/drm_drv.c:569 > > drm_dev_alloc+0x251/0x320 [drm]() > > Modules linked in: i915(+) joydev input_leds mousedev intel_rapl iosf_mbi > > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ttm > hid_generic > > drm_kms_helper crct10dif_pclmul snd_hda_intel crc32_pclmul usbhid > > snd_hda_codec crc32c_intel drm hid ghash_clmulni_intel snd_hda_core > > eeepc_wmi asus_wmi aesni_intel iTCO_wdt sparse_keymap snd_hwdep led_class > > aes_x86_64 lrw snd_pcm iTCO_vendor_support rfkill mxm_wmi evdev gf128mul > > intel_gtt e1000e glue_helper mac_hid snd_timer syscopyarea ablk_helper > > cryptd sysfillrect psmouse snd sysimgblt pcspkr fb_sys_fops ptp mei_me > > i2c_i801 i2c_algo_bit soundcore mei shpchp i2c_core pps_core lpc_ich > > serio_raw wmi fan battery processor thermal video button sch_fq_codel > > ip_tables x_tables ext4 crc16 mbcache jbd2 sd_mod atkbd libps2 ahci > libahci > > libata > > xhci_pci xhci_hcd ehci_pci ehci_hcd scsi_mod usbcore usb_common i8042 > serio > > CPU: 3 PID: 243 Comm: systemd-udevd Not tainted 4.2.0-next-20150912-ARCH > #5 > > Hardware name: System manufacturer System Product Name/Maximus IV GENE-Z, > > BIOS 3603 11/09/2012 > > 0000000000000000 000000005ca47666 ffff88060f70b9d0 ffffffff812b9159 > > 0000000000000000 ffff88060f70ba08 ffffffff81074e62 ffff880612d39000 > > ffffffffa06c7100 ffff880612f66098 ffffffffa06c7100 ffffffffa0691760 > > Call Trace: > > [] dump_stack+0x4b/0x72 > > [] warn_slowpath_common+0x82/0xc0 > > [] warn_slowpath_null+0x1a/0x20 > > [] drm_dev_alloc+0x251/0x320 [drm] > > [] drm_get_pci_dev+0x3b/0x1e0 [drm] > > [] i915_pci_probe+0x34/0x50 [i915] > > [] local_pci_probe+0x45/0xa0 > > [] ? pci_match_device+0xe0/0x110 > > [] pci_device_probe+0x103/0x150 > > [] driver_probe_device+0x222/0x490 > > [] __driver_attach+0x84/0x90 > > [] ? driver_probe_device+0x490/0x490 > > [] bus_for_each_dev+0x6c/0xc0 > > [] driver_attach+0x1e/0x20 > > [] bus_add_driver+0x1eb/0x280 > > [] driver_register+0x60/0xe0 > > [] __pci_register_driver+0x4c/0x50 > > [] drm_pci_init+0xe0/0x110 [drm] > > [] ? 0xffffffffa06e6000 > > [] i915_init+0xa4/0xab [i915] > > [] do_one_initcall+0xb3/0x200 > > [] ? __vunmap+0x91/0xe0 > > [] do_init_module+0x5f/0x1ef > > [] load_module+0x2197/0x27e0 > > [] ? symbol_put_addr+0x50/0x50 > > [] ? __pte_alloc_kernel+0xa5/0xf0 > > [] SyS_init_module+0x14e/0x190 > > [] entry_SYSCALL_64_fastpath+0x12/0x71 > > ---[ end trace d2652104b24a32ff ]--- > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies at kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > -- > > ---------------------------------------------- > Le?nidas S. Barbosa (Kirotawa) > blog: corecode.wordpress.com > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/1b4afa5b/attachment-0001.html From tanure at linux.com Sun Sep 13 13:33:44 2015 From: tanure at linux.com (Lucas Tanure) Date: Sun, 13 Sep 2015 14:33:44 -0300 Subject: Help debugging linux-next. In-Reply-To: References: Message-ID: I'm tried to compile a few older commits and run, but none of them boot and I can't get the status of the issue. -- Lucas Tanure +55 (19) 988176559 On Sun, Sep 13, 2015 at 2:24 PM, Raul Piper wrote: > I m a newbie.is there a doc which developers follow for using > git-bisect.google misleads !! > On Sep 13, 2015 10:50 PM, "leo kirotawa" wrote: > >> git bisect would be a choice. >> Seems your issue is around i915, that is related to intel graphics, >> isolate commits in this area would be another way >> >> >> >> On Sun, Sep 13, 2015 at 2:09 PM, Lucas Tanure wrote: >> > Hi, >> > >> > I would like some tips about how debug a issue with linux-next. >> > I'm trying to find things to do in kernel, and the first thing is boot >> the >> > linux-next tree. >> > >> > I'm able to compile the source, but when I boot I got a black screen a >> few >> > times, or a just a warn in dmesg. >> > >> > I'm trying to understand the issue, but no success. I tried to get kdump >> > from the issue, but didn't work. I also tried to go back a few commits >> in >> > linux-next, but my system doesn't boot at all. >> > >> > How I can find the commit that create the problem, since every commit >> that I >> > tested I got black screen ? >> > Whats the best way to debug this kind of issue ? >> > >> > Thanks! >> > >> > My full warning: >> > >> > ------------[ cut here ]------------ >> > WARNING: CPU: 3 PID: 243 at drivers/gpu/drm/drm_drv.c:569 >> > drm_dev_alloc+0x251/0x320 [drm]() >> > Modules linked in: i915(+) joydev input_leds mousedev intel_rapl >> iosf_mbi >> > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ttm >> hid_generic >> > drm_kms_helper crct10dif_pclmul snd_hda_intel crc32_pclmul usbhid >> > snd_hda_codec crc32c_intel drm hid ghash_clmulni_intel snd_hda_core >> > eeepc_wmi asus_wmi aesni_intel iTCO_wdt sparse_keymap snd_hwdep >> led_class >> > aes_x86_64 lrw snd_pcm iTCO_vendor_support rfkill mxm_wmi evdev gf128mul >> > intel_gtt e1000e glue_helper mac_hid snd_timer syscopyarea ablk_helper >> > cryptd sysfillrect psmouse snd sysimgblt pcspkr fb_sys_fops ptp mei_me >> > i2c_i801 i2c_algo_bit soundcore mei shpchp i2c_core pps_core lpc_ich >> > serio_raw wmi fan battery processor thermal video button sch_fq_codel >> > ip_tables x_tables ext4 crc16 mbcache jbd2 sd_mod atkbd libps2 ahci >> libahci >> > libata >> > xhci_pci xhci_hcd ehci_pci ehci_hcd scsi_mod usbcore usb_common i8042 >> serio >> > CPU: 3 PID: 243 Comm: systemd-udevd Not tainted >> 4.2.0-next-20150912-ARCH #5 >> > Hardware name: System manufacturer System Product Name/Maximus IV >> GENE-Z, >> > BIOS 3603 11/09/2012 >> > 0000000000000000 000000005ca47666 ffff88060f70b9d0 ffffffff812b9159 >> > 0000000000000000 ffff88060f70ba08 ffffffff81074e62 ffff880612d39000 >> > ffffffffa06c7100 ffff880612f66098 ffffffffa06c7100 ffffffffa0691760 >> > Call Trace: >> > [] dump_stack+0x4b/0x72 >> > [] warn_slowpath_common+0x82/0xc0 >> > [] warn_slowpath_null+0x1a/0x20 >> > [] drm_dev_alloc+0x251/0x320 [drm] >> > [] drm_get_pci_dev+0x3b/0x1e0 [drm] >> > [] i915_pci_probe+0x34/0x50 [i915] >> > [] local_pci_probe+0x45/0xa0 >> > [] ? pci_match_device+0xe0/0x110 >> > [] pci_device_probe+0x103/0x150 >> > [] driver_probe_device+0x222/0x490 >> > [] __driver_attach+0x84/0x90 >> > [] ? driver_probe_device+0x490/0x490 >> > [] bus_for_each_dev+0x6c/0xc0 >> > [] driver_attach+0x1e/0x20 >> > [] bus_add_driver+0x1eb/0x280 >> > [] driver_register+0x60/0xe0 >> > [] __pci_register_driver+0x4c/0x50 >> > [] drm_pci_init+0xe0/0x110 [drm] >> > [] ? 0xffffffffa06e6000 >> > [] i915_init+0xa4/0xab [i915] >> > [] do_one_initcall+0xb3/0x200 >> > [] ? __vunmap+0x91/0xe0 >> > [] do_init_module+0x5f/0x1ef >> > [] load_module+0x2197/0x27e0 >> > [] ? symbol_put_addr+0x50/0x50 >> > [] ? __pte_alloc_kernel+0xa5/0xf0 >> > [] SyS_init_module+0x14e/0x190 >> > [] entry_SYSCALL_64_fastpath+0x12/0x71 >> > ---[ end trace d2652104b24a32ff ]--- >> > >> > _______________________________________________ >> > Kernelnewbies mailing list >> > Kernelnewbies at kernelnewbies.org >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > >> >> >> >> -- >> >> ---------------------------------------------- >> Le?nidas S. Barbosa (Kirotawa) >> blog: corecode.wordpress.com >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/feaa2963/attachment.html From Valdis.Kletnieks at vt.edu Sun Sep 13 13:36:22 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 13 Sep 2015 13:36:22 -0400 Subject: Help debugging linux-next. In-Reply-To: References: Message-ID: <137712.1442165782@turing-police.cc.vt.edu> On Sun, 13 Sep 2015 14:09:21 -0300, Lucas Tanure said: > I would like some tips about how debug a issue with linux-next. > I'm trying to find things to do in kernel, and the first thing is boot the > linux-next tree. > How I can find the commit that create the problem, since every commit that > I tested I got black screen ? > Whats the best way to debug this kind of issue ? Since you obviously had a non-linux-next kernel that *did* boot, 'git bisect' is the fastest way to find the buggy commit. The best part is that it requires almost no actual understanding of the code. General scheme for using git bisect, even if you have *no* idea what the problem is: Say you know that a 4.0 kernel works OK. You then do: git bisect start get bisect bad next-201150910 (or whatever the earliest known-bad is) git bisect good v4.0 (Round stable releases like 4.0.9 to the base) Repeat the following: Build the kernel. Boot it. Reboot to a known good kernel if needed. If it was good, use 'git bisect good' If it died, 'git bisect bad'. end repeat until it tells you the bad commit. (It won't take long - going from 4.0 to current linux-next will probably take 11 to 13 times around). And it's simple enough to do that most of the time I have to bisect something, I'll do it on my laptop while watching something on Netflix.... *** NOTE *** * Avoid the temptation to try to bisect between two next-2015... tags * because you know the problem commit is between two tags a week apart. * Due to the way that linux-next is built, this *won't* work. This is * probably the single biggest cause of failure to bisect a problem in * linux-next *** END NOTE Since you know the problem is i915 related, you can speed the process up even more by doing git bisect start -- drivers/gpu/drm/i915 which instead of considering *all* commits, will only bisect across commits that touch that part of the source tree... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/12646f86/attachment.bin From linuxcraz23 at gmail.com Sun Sep 13 14:10:22 2015 From: linuxcraz23 at gmail.com (Mayur Patil) Date: Sun, 13 Sep 2015 23:40:22 +0530 Subject: Advice on Linux Kernel Development Message-ID: hi all, I want to ask if I want to get started with Linux Kernel Development then is it feasible that I can do all my experiments on Virtual Machine as on Linux my Internet dongle does not work, I am asking in terms of performance and efficiency. Looking for guidance, Thanks ! -- *Mayur S Patil,* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/c0dc5531/attachment.html From mnm.kernel at gmail.com Sun Sep 13 14:13:37 2015 From: mnm.kernel at gmail.com (Manavendra Nath Manav) Date: Sun, 13 Sep 2015 18:13:37 +0000 Subject: Advice on Linux Kernel Development In-Reply-To: References: Message-ID: Yes you can. On Sun 13 Sep, 2015 23:40 Mayur Patil wrote: > hi all, > > I want to ask > > if I want to get started with Linux Kernel Development then is it feasible > that > > I can do all my experiments on Virtual Machine as on Linux my Internet > dongle does > > not work, I am asking in terms of performance and efficiency. > > Looking for guidance, > > Thanks ! > -- > > > *Mayur S Patil,* > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/7702fc5e/attachment.html From Valdis.Kletnieks at vt.edu Sun Sep 13 17:32:08 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 13 Sep 2015 17:32:08 -0400 Subject: Advice on Linux Kernel Development In-Reply-To: References: Message-ID: <152266.1442179928@turing-police.cc.vt.edu> On Sun, 13 Sep 2015 23:40:22 +0530, Mayur Patil said: > if I want to get started with Linux Kernel Development then is it feasible that > I can do all my experiments on Virtual Machine as on Linux my Internet > dongle does not work, I am asking in terms of performance and efficiency. A very large chunk of linux kernel development can be done in a virtual machine (use VirtualBox, or VMWare, or whatever). Note that very hardware dependent code (like messing around with MSR registers, or some device drivers) won't be easily debugged, because the VM gives you a virtualized version of a generic system. But stuff like filesystems or schedulers or new syscalls are easily done in a VM. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/8d6db6bc/attachment-0001.bin From karthik.188 at gmail.com Sun Sep 13 23:27:37 2015 From: karthik.188 at gmail.com (Karthik Nayak) Date: Mon, 14 Sep 2015 08:57:37 +0530 Subject: Advice on Linux Kernel Development In-Reply-To: References: Message-ID: On Sun, Sep 13, 2015 at 11:40 PM, Mayur Patil wrote: > hi all, > > I want to ask > > if I want to get started with Linux Kernel Development then is it feasible > that > > I can do all my experiments on Virtual Machine as on Linux my Internet > dongle does > > not work, I am asking in terms of performance and efficiency. > Just curious, which dongle do you use? and what did you try? > Looking for guidance, > > Thanks ! > -- > Mayur S Patil, > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Regards, Karthik Nayak From ronit.linux at gmail.com Sun Sep 13 23:33:53 2015 From: ronit.linux at gmail.com (Ronit Halder) Date: Mon, 14 Sep 2015 09:03:53 +0530 Subject: gfp_flag Message-ID: In drivers/staging/android/ion/ion.c in line 1475 and 1493 gfp_flag is set to -1 what are these lines doing? regards, Ronit From linuxcraz23 at gmail.com Mon Sep 14 00:07:41 2015 From: linuxcraz23 at gmail.com (Mayur Patil) Date: Mon, 14 Sep 2015 09:37:41 +0530 Subject: Advice on Linux Kernel Development In-Reply-To: References: Message-ID: Hi, I am using Reliance 3 (Netconnect+) Dongle......and with lots of tries, I have finally stopped trying to install it on CentOS 6.x. I have tried almost all instructions from posts and blogs which appears on first 2 pages of Google search. On Mon, Sep 14, 2015 at 8:57 AM, Karthik Nayak wrote: > On Sun, Sep 13, 2015 at 11:40 PM, Mayur Patil > wrote: > > hi all, > > > > I want to ask > > > > if I want to get started with Linux Kernel Development then is it > feasible > > that > > > > I can do all my experiments on Virtual Machine as on Linux my Internet > > dongle does > > > > not work, I am asking in terms of performance and efficiency. > > > > Just curious, which dongle do you use? and what did you try? > > > Looking for guidance, > > > > Thanks ! > > -- *-- * *Mayur S Patil,* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150914/af3cc55b/attachment.html From linuxcraz23 at gmail.com Mon Sep 14 00:17:19 2015 From: linuxcraz23 at gmail.com (Mayur Patil) Date: Mon, 14 Sep 2015 09:47:19 +0530 Subject: Advice on Linux Kernel Development In-Reply-To: <152266.1442179928@turing-police.cc.vt.edu> References: <152266.1442179928@turing-police.cc.vt.edu> Message-ID: Thanks Valdis for clear explanation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150914/c35e004a/attachment.html From gregkh at linuxfoundation.org Mon Sep 14 00:21:35 2015 From: gregkh at linuxfoundation.org (Greg KH) Date: Sun, 13 Sep 2015 21:21:35 -0700 Subject: gfp_flag In-Reply-To: References: Message-ID: <20150914042134.GA26591@kroah.com> On Mon, Sep 14, 2015 at 09:03:53AM +0530, Ronit Halder wrote: > In drivers/staging/android/ion/ion.c in line 1475 and 1493 gfp_flag > is set to -1 No, that's not what the code does, please read it again. greg k-h From Valdis.Kletnieks at vt.edu Mon Sep 14 02:09:19 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 14 Sep 2015 02:09:19 -0400 Subject: gfp_flag In-Reply-To: <20150914042134.GA26591@kroah.com> References: <20150914042134.GA26591@kroah.com> Message-ID: <48390.1442210959@turing-police.cc.vt.edu> On Sun, 13 Sep 2015 21:21:35 -0700, Greg KH said: > On Mon, Sep 14, 2015 at 09:03:53AM +0530, Ronit Halder wrote: > > In drivers/staging/android/ion/ion.c in line 1475 and 1493 gfp_flag > > is set to -1 > > No, that's not what the code does, please read it again. My guess is it's making some other routine work a lot harder in order to cover all possibilities, no matter how unusual :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150914/63c23ab3/attachment.bin From ishubist at gmail.com Mon Sep 14 02:03:31 2015 From: ishubist at gmail.com (Abhishek bist) Date: Mon, 14 Sep 2015 11:33:31 +0530 Subject: Advice on Linux Kernel Development In-Reply-To: <1442205450133.1820976330@boxbe> References: <1442205450133.1820976330@boxbe> Message-ID: Hi , It is generally recoomended to not to do the kernel development with virtual box and especially dealing with the device drivers. On 14 September 2015 at 09:37, Mayur Patil wrote: > [image: Boxbe] This message is eligible > for Automatic Cleanup! (linuxcraz23 at gmail.com) Add cleanup rule > > | More info > > > Hi, > > I am using Reliance 3 (Netconnect+) Dongle......and with lots of tries, I > have finally stopped trying to install it on CentOS 6.x. > > I have tried almost all instructions from posts and blogs which appears on > first 2 pages of Google search. > > > On Mon, Sep 14, 2015 at 8:57 AM, Karthik Nayak > wrote: > >> On Sun, Sep 13, 2015 at 11:40 PM, Mayur Patil >> wrote: >> > hi all, >> > >> > I want to ask >> > >> > if I want to get started with Linux Kernel Development then is it >> feasible >> > that >> > >> > I can do all my experiments on Virtual Machine as on Linux my Internet >> > dongle does >> > >> > not work, I am asking in terms of performance and efficiency. >> > >> >> Just curious, which dongle do you use? and what did you try? >> >> > Looking for guidance, >> > >> > Thanks ! >> > -- > > > *-- * > *Mayur S Patil,* > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150914/fb4c2556/attachment.html From ronit.crj at gmail.com Mon Sep 14 02:17:02 2015 From: ronit.crj at gmail.com (Ronit Halder) Date: Mon, 14 Sep 2015 11:47:02 +0530 Subject: gfp_flag In-Reply-To: <20150914042134.GA26591@kroah.com> References: <20150914042134.GA26591@kroah.com> Message-ID: Sorry, it is gfp_mask not gfp_flag. On Sep 14, 2015 9:51 AM, "Greg KH" wrote: > On Mon, Sep 14, 2015 at 09:03:53AM +0530, Ronit Halder wrote: > > In drivers/staging/android/ion/ion.c in line 1475 and 1493 gfp_flag > > is set to -1 > > No, that's not what the code does, please read it again. > > greg k-h > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150914/8bc190af/attachment-0001.html From sabelaraga at gmail.com Mon Sep 14 09:37:34 2015 From: sabelaraga at gmail.com (Sabela Ramos Garea) Date: Mon, 14 Sep 2015 15:37:34 +0200 Subject: Userspace pages in UC mode In-Reply-To: References: Message-ID: Hi Pranay, 2015-09-12 3:12 GMT+02:00 Pranay Srivastava : > Hi Sabela, > > On Fri, Sep 11, 2015 at 8:29 PM, Sabela Ramos Garea > wrote: >> Sorry, little mistake copypasting and cleaning. The pages and vma >> structs should look like that: >> >> struct page *pages --> struct page *pages[MAX_PAGES]; >> struct vma_area_struct *vma --> struct vma_area_struct *vma[MAX_PAGES]; >> >> Where MAX_PAGES is defined to 5. >> >> Sabela. >> >> 2015-09-11 16:07 GMT+02:00 Sabela Ramos Garea : >>> Dear all, >>> >>> For research purposes I need some userspace memory pages to be in >>> uncacheable mode. I am using two different Intel architectures (Sandy >>> Bridge and Haswell) and two different kernels (2.6.32-358 and >>> 3.19.0-28). >>> >>> The non-temporal stores from Intel assembly are not a valid solution >>> so I am programming a kernel module that gets a set of pages from user >>> space reserved with posix_memalign (get_user_pages) and then sets them >>> as uncacheable (I have tried set_pages_uc and set_pages_array_uc). >>> When I use one page, the access times are not very coherent and with >>> more than one page the module crashes (in both architectures and both >>> kernels). >>> >>> I wonder if I am using the correct approach or if I have to use kernel >>> space pages in order to work with uncacheable memory. Or if I have to >>> remap the memory. Just in case it makes it clearer, I am attaching the >>> relevant lines of a kernel module function that should set the pages >>> as uncacheable. (This function is the .write of a misc device; count >>> is treated as the number of pages). >>> >>> Best and Thanks, >>> >>> Sabela. >>> >>> struct page *pages; //defined outside in order to be able to set them >>> to WB in the release function. >>> int numpages; >>> >>> static ssize_t setup_memory(struct file *filp, const char __user *buf, >>> size_t count, loff_t * ppos) >>> { >>> int res; >>> struct vm_area_struct *vmas; >>> > shouldn't this be rounded this up? >>> numpages = count/4096; >>> For the current tests I am assuming that count is multiple of 4096 and the user *buf is aligned. Anyway, isn't it safer if I just round down so I don't mess with addresses outside the range of pages that have to be set as uncached? >>> down_read(¤t->mm->mmap_sem); >>> res = get_user_pages(current, current->mm, >>> (unsigned long) buf, >>> numpages, /* Number of pages */ >>> 0, /* Do want to write into it */ >>> 1, /* do force */ >>> &pages, >>> &vmas); >>> up_read(¤t->mm->mmap_sem); >>> >>> numpages=res; >>> >>> if (res > 0) { >>> set_pages_uc(pages, numpages); /* Uncached */ > > what about high-mem pages. set_memory_uc does __pa, so perhaps that's > the reason for your kernel oops? > I have used kmap to map the user addresses in kernel space as follows: if (res > 0) { for(i=0; i References: Message-ID: >> On 10 September 2015 at 20:49, Kosta Zertsekel >> Also, I see that in 4.2 there are only ~76 drivers that use threaded >> interrupt: >> ``` >> $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l >> 76 >> ``` > On Sun, Sep 13, 2015 at 2:16 PM, Rami Rosen wrote: > This kernel and older ones include device drivers which use threaded IRQs > (call request_threaded_irq(), etc). > For example, many of the driver under drivers/input/touchscreen are > using threaded IRQs: > Following link is from kernel 3.18: > http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c?v=3.18 > > How did you came to the conclusion that this kernel does not support > threaded IRQs ? could it be that you simply do not use device drivers > that use this mechanism ? In the given touch screen driver request_threaded_irq() provides NULL for the thread function pointer. Hence, the non-threaded IRQ mechanism is actually being used. This is why I grepped for IRQ_WAKE_THREAD and not for request_threaded_irq. So, the questions remains. Why only ~76 drivers use the threaded IRQ mechanism? What are the cons of the threaded IRQ mechanism? Thanks, --- KostaZ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150915/08d1c2e3/attachment.html From greg at kroah.com Tue Sep 15 15:05:13 2015 From: greg at kroah.com (Greg KH) Date: Tue, 15 Sep 2015 12:05:13 -0700 Subject: When to use threaded interrupts? In-Reply-To: References: Message-ID: <20150915190513.GA19292@kroah.com> On Tue, Sep 15, 2015 at 09:02:24PM +0300, Kosta Zertsekel wrote: > >> On 10 September 2015 at 20:49, Kosta Zertsekel > >> Also, I see that in 4.2 there are only ~76 drivers that use threaded > >> interrupt: > >> ``` > >> $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l > >> 76 > >> ``` > > > On Sun, Sep 13, 2015 at 2:16 PM, Rami Rosen wrote: > > This kernel and older ones include device drivers which use threaded IRQs > > (call request_threaded_irq(), etc). > > For example, many of the driver under drivers/input/touchscreen are > > using threaded IRQs: > > Following link is from kernel 3.18: > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c?v > =3.18 > > > > How did you came to the conclusion that this kernel does not support > > threaded IRQs ? could it be that you simply do not use device drivers > > that use this mechanism ? > > In the given touch screen driver request_threaded_irq() provides NULL > for the thread function pointer. Hence, the non-threaded IRQ mechanism > is actually being used.? This is why I grepped for IRQ_WAKE_THREAD and > not for request_threaded_irq. > > So, the questions remains. > Why only ~76 drivers use the threaded IRQ mechanism? Because people have not converted older code to the newer mechanism. > What are the cons of the threaded IRQ mechanism? Slower throughput and added complexity. From ranshalit at gmail.com Tue Sep 15 15:40:50 2015 From: ranshalit at gmail.com (Ran Shalit) Date: Tue, 15 Sep 2015 22:40:50 +0300 Subject: mmap - post/pre actions Message-ID: Hello, I need to implement mmap for non-volatile memory chip (NVRAM). I already did something simple, but now I understand that it is not complete: The nvram need to be unlock and locked after finishing the memory task of read/write. Does mmap can handle such post/pre actions or not ( I guess that if not - I will need to use read/write alternatives) ? Thank you, Ran From Valdis.Kletnieks at vt.edu Tue Sep 15 15:51:40 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Sep 2015 15:51:40 -0400 Subject: mmap - post/pre actions In-Reply-To: References: Message-ID: <13777.1442346700@turing-police.cc.vt.edu> On Tue, 15 Sep 2015 22:40:50 +0300, Ran Shalit said: > Hello, > > I need to implement mmap for non-volatile memory chip (NVRAM). > I already did something simple, but now I understand that it is not complete: > The nvram need to be unlock and locked after finishing the memory task > of read/write. > > Does mmap can handle such post/pre actions or not ( I guess that if > not - I will need to use read/write alternatives) ? Not sure if it does or not. But the unlock should be done when the mmap segment is first created, and locked when the last reference to the segment is removed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150915/3e8a7a8d/attachment.bin From pranjas at gmail.com Wed Sep 16 05:02:35 2015 From: pranjas at gmail.com (Pranay Srivastava) Date: Wed, 16 Sep 2015 14:32:35 +0530 Subject: mmap - post/pre actions In-Reply-To: References: Message-ID: Hi Ran On Wed, Sep 16, 2015 at 1:10 AM, Ran Shalit wrote: > Hello, > > I need to implement mmap for non-volatile memory chip (NVRAM). > I already did something simple, but now I understand that it is not complete: > The nvram need to be unlock and locked after finishing the memory task > of read/write. I guess you are better off with an ioctl call to the driver and be done with the read/write. You won't get faults once you've mapped it. So I don't think you can do locking via your driver after that. If you are thinking of doing something like below P1--->mmap--->driver [OK] P2-->mmap--->driver[OK] You won't be able to get the faults for the below cases as you would've already filled the vma for that in your vm_fault handler. P1--->writes to mmaped [No fault] P2--->writes to mmaped [No fault] You can't lock once both have mapped. What you can do is provide a different mapping[?] and then sync that mapping I guess? But that's just insane. If you say that subsequent mmap would fail then again you'll have to code user-space to work with this. Better off with ioctl rather than mmap. > > Does mmap can handle such post/pre actions or not ( I guess that if > not - I will need to use read/write alternatives) ? > > Thank you, > Ran > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- ---P.K.S From gtvrreddy at gmail.com Wed Sep 16 05:11:02 2015 From: gtvrreddy at gmail.com (Ramana Reddy) Date: Wed, 16 Sep 2015 14:41:02 +0530 Subject: A Question about TCP Sequence rollover Message-ID: Hi All, I would like to the code where exactly the TCP sequence number rollover happens in the linux kernel. Thanks & regards, Ramana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150916/e8aa203f/attachment.html From gtvrreddy at gmail.com Wed Sep 16 05:11:48 2015 From: gtvrreddy at gmail.com (Ramana Reddy) Date: Wed, 16 Sep 2015 14:41:48 +0530 Subject: A Question about TCP Sequence rollover In-Reply-To: References: Message-ID: I would like to know the code where exactly the TCP sequence number rollover happens in the linux kernel. On Wed, Sep 16, 2015 at 2:41 PM, Ramana Reddy wrote: > Hi All, > > I would like to the code where exactly the TCP sequence number rollover > happens > in the linux kernel. > > Thanks & regards, > Ramana > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150916/bac9cf9c/attachment.html From somlo at cmu.edu Tue Sep 1 12:12:04 2015 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Tue, 01 Sep 2015 16:12:04 -0000 Subject: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device In-Reply-To: <55DE0227.8090905@codeaurora.org> References: <1439977109-20314-1-git-send-email-ard.biesheuvel@linaro.org> <20150819204915.GA6164@GLSMBP.INI.CMU.EDU> <55DE0227.8090905@codeaurora.org> Message-ID: <20150901161144.GB13375@HEDWIG.INI.CMU.EDU> Hi Christopher, On Wed, Aug 26, 2015 at 02:15:03PM -0400, Christopher Covington wrote: > On 08/19/2015 04:49 PM, Gabriel L. Somlo wrote: > > On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote: > >> On 19 August 2015 at 11:38, Ard Biesheuvel wrote: > >>> From: "Gabriel L. Somlo" > >>>> Several different architectures supported by QEMU are set up with a > >>>> "firmware configuration" (fw_cfg) device, used to pass configuration > >>>> "blobs" into the guest by the host running QEMU. > >>>> > >>>> Historically, these config blobs were mostly of interest to the guest > >>>> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via > >>>> the command line, which makes them potentially interesting to userspace > >>>> (e.g. for passing early boot environment variables, etc.). > >>>> > >>> > >>> Does 'potentially interesting' mean you have a use case? Could you elaborate? > > > > My personal one would be something like: > > > > cat > guestinfo.txt << EOT > > KEY1="val1" > > KEY2="val2" > > ... > > EOT > > > > qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ... > > > > Then, from inside the guest: > > > > . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw > > > > do_something_with $KEY1 $KEY2 > > ... > > > > But I'm thinking this is only one of the many positive things one > > could do with the ability to access random host-supplied blobs from > > guest userspace :) > > I do this with kernel parameters: > > host: > qemu-system-aarch64 -append="KEY1=val1 KEY2=val2" > > guest: > KEY1=`sed -nr s/.*KEY1=([^ ]+).*/\1/ /proc/cmdline` > KEY2=`sed -nr s/.*KEY2=([^ ]+).*/\1/ /proc/cmdline` > > do_something_with $KEY1 $KEY2 > > In practice it's just script=hostfile, where hostfile is available to the > guest via a 9P passthrough filesystem mount. > > While quite architecture specific, I've also previously used an > "angel-cmdline" tool for similar purposes. Peter's recent semihosting patches > support such a tool for AArch64. (On AArch32 upstream QEMU disallows > semihosting from userspace.) > > Before I had 9P on all the simulators I regularly ran, I used a semihosting > based "angel-load" tool. Someone (maybe it was you) did suggest this during an early thread on the QEMU dev list. I had considered this, then thought about piggybacking on smbios (e.g. the type 40 "additional information" table), but then realized "wait, smbios is currently being inserted into the guest via fw_cfg, so maybe direct fw_cfg blob transfer *is* the most asynchronous and out-of-band way I can do this... :) True, writing a fw_cfg driver is still Linux-specific (leaves out Windows, which is something I still care about), but dumping a fw_cfg blob using 'cat' or 'cp' on linux has a certain appeal :) Yeah, the immediate use case I have personally can be worked around with kernel command line args, in a slightly less out-of-band, but still quite serviceable way. I'm thinking a fw_cfg driver is just a flexible way to make other use cases possible in a (IMHO) neat and clean way... Plus, it got me to learn about kobjects, now studying DTs on ARM, so it's fun ;) Thanks, --Gabriel From kborer at cpan.org Wed Sep 2 14:12:42 2015 From: kborer at cpan.org (Kris Borer) Date: Wed, 2 Sep 2015 14:12:42 -0400 Subject: EditorsGroup Message-ID: Hello, I would like to make some edits to the wiki. Would someone add KrisBorer to the EditorsGroup? Thanks, Kris From pria.mn9 at gmail.com Fri Sep 4 12:26:06 2015 From: pria.mn9 at gmail.com (priyamn) Date: Fri, 4 Sep 2015 16:26:06 +0000 (UTC) Subject: How to get the inode - no =?utf-8?b?cGF0aF9sb29rdXA=?= References: Message-ID: Hi, I happened to come across this discussion. I am having a similar issue. I am using Rhel7-3.10.0-123 kernel. I tried all the options that are mentioned above and none of the api's including kern_path() return valid dentry value. My requirement is to fetch directory name from filepath. Can anybody suggest a work-around for this ? From j.anaszewski at samsung.com Mon Sep 7 07:28:03 2015 From: j.anaszewski at samsung.com (Jacek Anaszewski) Date: Mon, 07 Sep 2015 13:28:03 +0200 Subject: How to properly unregister LED class devices? In-Reply-To: <20150907090556.GA2549@untxi.home> References: <20150906174806.GA16230@untxi.home> <20150907090556.GA2549@untxi.home> Message-ID: <55ED74C3.2090409@samsung.com> Hi Cl?ment, On 09/07/2015 11:05 AM, Cl?ment Vuchener wrote: > On Mon, Sep 07, 2015 at 12:08:17PM +0530, Pranay Srivastava wrote: >> On Sun, Sep 6, 2015 at 11:18 PM, Cl?ment Vuchener >> wrote: >>> Hello, >>> >>> I am trying to write a driver that uses LED class devices using works for setting the LED brightness but I am not sure of how to unregister the devices. >>> >>> I have been using code like this: >>> led_classdev_unregister(&drvdata->backlight.cdev); >>> cancel_work_sync(&drvdata->backlight.work); >>> trying with both flush_work or cancel_work_sync as I have seen it in other drivers. >>> >>> Using flush_work, the kernel oops in my work function when I unplug the device. cancel_work_sync seems to fix that, but I am not sure it will work every time. I would like to understand what happens and if I am doing something wrong, to be sure it will not break in some different setup. >> >> Can you post the backtrace? >> > > I could not get it with my patched kernel (I must be missing some config option) so I used the code as a module on my fedora 22 (4.1.6) kernel. > > general protection fault: 0000 [#1] SMP > Modules linked in: hid_corsair_k90(OE) bnep bluetooth nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_g > snd_hda_codec_hdmi coretemp arc4 kvm_intel snd_hda_codec_realtek iwldvm kvm snd_hda_codec_generic mac80211 snd_hda_intel snd_hda_controller snd_hda_co > CPU: 2 PID: 491 Comm: kworker/2:3 Tainted: G OE 4.1.6-200.fc22.x86_64 #1 > Hardware name: CLEVO CO. W350ET/W350ET, BIOS 1.02.21PM v3 07/01/2013 > Workqueue: events k90_record_led_work [hid_corsair_k90] > task: ffff880223bd4f00 ti: ffff8800c92a0000 task.ti: ffff8800c92a0000 > RIP: 0010:[] [] __dev_printk+0x26/0x90 > RSP: 0018:ffff8800c92a3d48 EFLAGS: 00010202 > RAX: 657079740000009d RBX: ffff8801fcee7800 RCX: 000000000001a2e1 > RDX: ffff8800c92a3d58 RSI: ffff8801fcee7800 RDI: ffffffff81a2673f > RBP: ffff8800c92a3d48 R08: 0000001400730102 R09: ffff8800c92a3d58 > R10: ffffffff81578c4b R11: 0000000000000000 R12: ffff88022f317000 > R13: ffff88022f31b900 R14: 0000000000000080 R15: ffff8801fcc7d320 > FS: 0000000000000000(0000) GS:ffff88022f300000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000002eee850 CR3: 0000000002c0b000 CR4: 00000000001406e0 > Stack: > ffff8800c92a3db8 ffffffff814e8bd2 ffffffffa09701f8 ffff8800c92a3d68 > ffff880100000010 ffff8800c92a3dc8 ffff8800c92a3d88 000000002440e468 > 0000000000000000 ffff8801fcee7800 00000000ffffffed 000000000001a2e1 > Call Trace: > [] dev_warn+0x62/0x80 > [] k90_record_led_work+0x8c/0xa0 [hid_corsair_k90] > [] ? __schedule+0x241/0x720 > [] process_one_work+0x1bb/0x410 > [] worker_thread+0x1bc/0x480 > [] ? process_one_work+0x410/0x410 > [] ? process_one_work+0x410/0x410 > [] kthread+0xd8/0xf0 > [] ? kthread_worker_fn+0x180/0x180 > [] ret_from_fork+0x42/0x70 > [] ? kthread_worker_fn+0x180/0x180 > Code: 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 49 89 d1 48 89 e5 74 60 4c 8b 46 50 4d 85 c0 74 26 48 8b 86 90 00 00 00 48 85 c0 74 2a <48> 8b 08 0f be > RIP [] __dev_printk+0x26/0x90 As your backtrace shows, the problem originates from dev_warn call from k90_record_led_work. dev_warn takes dev in its first argument, which is already released at the time when it is called as a result of the call to flush_work. In order to work this around you could set some flag on remove to indicate that LED class device has been released and return from k90_record_led_work immediately. The same applies to your question regarding retaining the LED state on remove. Hope this helps. Is the backtrace always the same? It could likely happen also earlier, during dereference of dev in the following line: struct device *dev = led->cdev.dev->parent; -- Best Regards, Jacek Anaszewski From sodar at riseup.net Mon Sep 14 04:40:43 2015 From: sodar at riseup.net (Dario) Date: Mon, 14 Sep 2015 10:40:43 +0200 Subject: git sendmail configuration example for mail.reiseup Message-ID: <55F6880B.3080303@riseup.net> Hi All, i'm trying to use mail.reiseup.net with git sendmail. my configuration of git is: [sendemail] smtpEncryption = ssl smtpServer = reiseup.net smtpUser = USER at reiseup.net smtpServerPort = 465 smtppass = MYSECRETPASS At the moment i get the error "unable to initialize SMTP properly. Check config and use --smtp-debug " I'm on opensuse and i have postfix al mua. I use Mutt with imap and i don't have problems. I try the flag smtp-debug but i don't see any details for logging. Do have some hints? Thank you in advance Regards From greg at kroah.com Wed Sep 16 18:31:54 2015 From: greg at kroah.com (Greg KH) Date: Wed, 16 Sep 2015 15:31:54 -0700 Subject: How to get the inode - no path_lookup In-Reply-To: References: Message-ID: <20150916223154.GA22045@kroah.com> On Fri, Sep 04, 2015 at 04:26:06PM +0000, priyamn wrote: > > Hi, > > I happened to come across this discussion. I am having a similar issue. > I am using Rhel7-3.10.0-123 > kernel. I tried all the options that are mentioned above and none of the api's > including kern_path() return valid dentry value. > My requirement is to fetch directory name from filepath. Why do you need a directory name from a filepath within the kernel? What problem are you trying to solve that you feel a directory name is the correct solution? And remember, namespaces, what does a "directory name" really mean... :) thanks, greg k-h From bino at riseup.net Wed Sep 16 23:25:16 2015 From: bino at riseup.net (Albino B Neto) Date: Thu, 17 Sep 2015 00:25:16 -0300 Subject: git sendmail configuration example for mail.reiseup In-Reply-To: <55F6880B.3080303@riseup.net> References: <55F6880B.3080303@riseup.net> Message-ID: 2015-09-14 5:40 GMT-03:00 Dario : > my configuration of git is: > > [sendemail] > smtpEncryption = ssl > smtpServer = reiseup.net > smtpUser = USER at reiseup.net > smtpServerPort = 465 > smtppass = MYSECRETPASS Look: ~/.gitconfig $ cat .gitconfig [user] name = email = @riseup.net [sendemail] smtpserver = mail.riseup.net smtpserverport = 587 smtpencryption = tls smtpuser = @riseup.net Albino From bino at riseup.net Wed Sep 16 23:29:19 2015 From: bino at riseup.net (Albino B Neto) Date: Thu, 17 Sep 2015 00:29:19 -0300 Subject: kernel.c//Starting for The Journey of The Kernel; In-Reply-To: References: Message-ID: 2015-08-23 17:45 GMT-03:00 GanesH AvacharE : > #include , > I am Ganesh, I am New Here, I want to Learn the Kernel Code , How Kernel > Handles the all the things?, Each and Everything Real Mysteries of the > Kernel, So Please Help me, From where should I start, What Sequence Should I > Follow to get Started with Kernel. > Please Help me Guys and Have a NICE Day. Welcome. Here help [0]. Subscribe on mailing linux-kernel [1]. 0 - http://kernelnewbies.org/Documents 1 - http://vger.kernel.org/ Albino From ganeshavachare007 at gmail.com Thu Sep 17 00:53:29 2015 From: ganeshavachare007 at gmail.com (GanesH AvacharE) Date: Thu, 17 Sep 2015 10:23:29 +0530 Subject: kernel.c//Starting for The Journey of The Kernel; In-Reply-To: References: Message-ID: Return_val = Thank you; ;but I don't have basic knowledge of the OS so, should I start from basic or directly kernel documents?; return Return_val; Regards, - Ganesh Avachare On Thu, Sep 17, 2015 at 8:59 AM, Albino B Neto wrote: > 2015-08-23 17:45 GMT-03:00 GanesH AvacharE : > > #include , > > I am Ganesh, I am New Here, I want to Learn the Kernel Code , How Kernel > > Handles the all the things?, Each and Everything Real Mysteries of the > > Kernel, So Please Help me, From where should I start, What Sequence > Should I > > Follow to get Started with Kernel. > > Please Help me Guys and Have a NICE Day. > > Welcome. > > Here help [0]. Subscribe on mailing linux-kernel [1]. > > 0 - http://kernelnewbies.org/Documents > 1 - http://vger.kernel.org/ > > Albino > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150917/eda03ce7/attachment.html From ganeshavachare007 at gmail.com Thu Sep 17 00:56:54 2015 From: ganeshavachare007 at gmail.com (GanesH AvacharE) Date: Thu, 17 Sep 2015 10:26:54 +0530 Subject: kernel.c//Starting for The Journey of The Kernel; In-Reply-To: References: Message-ID: if I have to start with the basics of the OS then what sequence should I follow? Regards, - Ganesh Avachare On Thu, Sep 17, 2015 at 10:23 AM, GanesH AvacharE < ganeshavachare007 at gmail.com> wrote: > Return_val = Thank you; > > ;but I don't have basic knowledge of the OS so, should I start from basic > or directly kernel documents?; > > return Return_val; > > Regards, > - Ganesh Avachare > > On Thu, Sep 17, 2015 at 8:59 AM, Albino B Neto wrote: > >> 2015-08-23 17:45 GMT-03:00 GanesH AvacharE : >> > #include , >> > I am Ganesh, I am New Here, I want to Learn the Kernel Code , How Kernel >> > Handles the all the things?, Each and Everything Real Mysteries of the >> > Kernel, So Please Help me, From where should I start, What Sequence >> Should I >> > Follow to get Started with Kernel. >> > Please Help me Guys and Have a NICE Day. >> >> Welcome. >> >> Here help [0]. Subscribe on mailing linux-kernel [1]. >> >> 0 - http://kernelnewbies.org/Documents >> 1 - http://vger.kernel.org/ >> >> Albino >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150917/07176564/attachment.html From daniel.baluta at gmail.com Thu Sep 17 03:33:46 2015 From: daniel.baluta at gmail.com (Daniel Baluta) Date: Thu, 17 Sep 2015 10:33:46 +0300 Subject: kernel.c//Starting for The Journey of The Kernel; In-Reply-To: References: Message-ID: On Thu, Sep 17, 2015 at 7:56 AM, GanesH AvacharE wrote: > if I have to start with the basics of the OS then what sequence should I > follow? You can start with Operating Systems Concepts book. http://www.amazon.com/Operating-System-Concepts-Abraham-Silberschatz/dp/0470128720 From rohan.puri15 at gmail.com Thu Sep 17 04:10:38 2015 From: rohan.puri15 at gmail.com (Rohan Puri) Date: Thu, 17 Sep 2015 13:40:38 +0530 Subject: How to get the inode - no path_lookup In-Reply-To: <20150916223154.GA22045@kroah.com> References: <20150916223154.GA22045@kroah.com> Message-ID: On 17 Sep 2015 04:02, "Greg KH" wrote: > > On Fri, Sep 04, 2015 at 04:26:06PM +0000, priyamn wrote: > > > > Hi, > > > > I happened to come across this discussion. I am having a similar issue. > > I am using Rhel7-3.10.0-123 > > kernel. I tried all the options that are mentioned above and none of the api's > > including kern_path() return valid dentry value. > > My requirement is to fetch directory name from filepath. > > Why do you need a directory name from a filepath within the kernel? > What problem are you trying to solve that you feel a directory name is > the correct solution? > > And remember, namespaces, what does a "directory name" really mean... :) > > thanks, > > greg k-h > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Hi Priya, Please make use of a single thread for one topic. There was another thread by you on the same topic. Anyways, I am replying to this one. Greg has asked questions that you should ask yourself before going on with choosing one approach. I had suggested you using kern_path() earlier, since it doesn't makes use of nameidata, but as you are telling its not working too. Here I would like to know the actual context of the approach so as to figure out if something I know that can work for you or maybe you shouldn't be doing it that way. Enjoy life, Rohan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150917/8a6be1e8/attachment.html From bino at riseup.net Thu Sep 17 07:53:09 2015 From: bino at riseup.net (Albino B Neto) Date: Thu, 17 Sep 2015 08:53:09 -0300 Subject: git sendmail configuration example for mail.reiseup In-Reply-To: References: <55F6880B.3080303@riseup.net> Message-ID: 2015-09-17 8:41 GMT-03:00 Silvan Jegen : >>> my configuration of git is: >>> >>> [sendemail] >>> smtpEncryption = ssl >>> smtpServer = reiseup.net > > > reiseup.net (a domain which I cannot find) vs. Thank you. Error type. Albino From bino at riseup.net Thu Sep 17 07:53:45 2015 From: bino at riseup.net (Albino B Neto) Date: Thu, 17 Sep 2015 08:53:45 -0300 Subject: git sendmail configuration example for mail.reiseup In-Reply-To: <55FAA816.7050403@riseup.net> References: <55F6880B.3080303@riseup.net> <55FAA816.7050403@riseup.net> Message-ID: 2015-09-17 8:46 GMT-03:00 Dario Maiocchi : > Thank You Albino. It works for me now. So good. :-) Albino From david.scaperoth at gmail.com Thu Sep 17 08:54:28 2015 From: david.scaperoth at gmail.com (David Scaperoth) Date: Thu, 17 Sep 2015 08:54:28 -0400 Subject: Wireless Driver issue (Atheros AR9485) Message-ID: I'm attempting to run pm-suspend on my laptop (by shutting my lid and on command line), and its putting my AR9485 wifi card into a funk (i.e. wlan0 interface seen through ifconfig never returns upon resume). I know theres a lot to this (power management - pm-utils and kernel, wireless drivers, general linux drivers, and possibly other things), just need a little direction on which rabbit hole to start down...haha. Ive looked through the ath9k and wireless list archives and had no luck finding the same issue. I have tried different solutions (mostly related to pm-utils) from ubuntu's forums too. an example of where it failed /var/log/pm-powersave.log Running hook /usr/lib/pm-utils/power.d/wireless true: Turning powersave for wlan0 on...Error for wireless request "Set Power Management" (8B2C) : SET failed on device wlan0 ; Operation not supported. Failed. /usr/lib/pm-utils/power.d/wireless true: success. AND...according to https://wireless.wiki.kernel.org/en/users/documentation/dynamic-power-save I tried: iw dev wlan0 set power_save on command failed: Operation not supported (-95) This is my first post to this list, so I'm not sure what information would be useful to help find a solution (or workaround). Here goes nothing (perhaps I should attach text files next time for large diagnostic information?): I built an upstream kernel against gregkh staging tree with a Ubuntu distro just to see if this would fix my issue and it did not. Either way, here is some information: >> uname -a Linux xxx 4.2.0+ #1 SMP Sun Sep 6 05:53:34 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux >> lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Codename: trusty cat /proc/version Linux version 4.2.0+ (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) ) #1 SMP Sun Sep 6 05:53:34 EDT 2015 >>lspci -vvnn 01:00.0 Network controller [0280]: Qualcomm Atheros AR9485 Wireless Network Adapter [168c:0032] (rev 01) Subsystem: Hewlett-Packard Company AR9485/HB125 802.11bgn 1?1 Wi-Fi Adapter [103c:1838] I could provide more information from lspci and lshw but I'm not sure what would help (if at all). The strangest thing about the whole matter is that if I reboot, the card comes back online just fine. Thanks again for any help you can provide! David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150917/b3671954/attachment-0001.html From shraddha.6596 at gmail.com Fri Sep 18 00:49:37 2015 From: shraddha.6596 at gmail.com (Shraddha Barke) Date: Fri, 18 Sep 2015 10:19:37 +0530 Subject: No subject Message-ID: I updated my local kernel repository with all recent commits using the following commands- git checkout staging-next git pull After that when I try to compile, I'm getting an error scripts/sign-file.c:20:25: fatal error: openssl/bio.h: No such file or directory #include ^ compilation terminated. scripts/Makefile.host:91: recipe for target 'scripts/sign-file' failed make[1]: *** [scripts/sign-file] Error 1 Makefile:545: recipe for target 'scripts' failed make: *** [scripts] Error 2 What should I do to fix it? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/0617fe64/attachment.html From kirotawa at gmail.com Fri Sep 18 01:17:28 2015 From: kirotawa at gmail.com (leo kirotawa) Date: Fri, 18 Sep 2015 02:17:28 -0300 Subject: In-Reply-To: References: Message-ID: You need to install openssl-devel, so it'll fix this issue :) On Fri, Sep 18, 2015 at 1:49 AM, Shraddha Barke wrote: > I updated my local kernel repository with all recent commits using the > following commands- > git checkout staging-next > git pull > > After that when I try to compile, I'm getting an error > > scripts/sign-file.c:20:25: fatal error: openssl/bio.h: No such file or > directory > #include > ^ > compilation terminated. > scripts/Makefile.host:91: recipe for target 'scripts/sign-file' failed > make[1]: *** [scripts/sign-file] Error 1 > Makefile:545: recipe for target 'scripts' failed > make: *** [scripts] Error 2 > > > What should I do to fix it? > > Thanks in advance. > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- ---------------------------------------------- Le?nidas S. Barbosa (Kirotawa) blog: corecode.wordpress.com From j.l.madushan at gmail.com Fri Sep 18 01:25:17 2015 From: j.l.madushan at gmail.com (NISHANTHA) Date: Fri, 18 Sep 2015 10:55:17 +0530 Subject: Hijack a weak syscall Message-ID: Hi, I'm trying to implement kexec as a module. When I do "cat /proc/kallsyms | grep kexec" it gives a out output like this c01b3478 W compat_sys_kexec_load c01b3478 W sys_kexec_load my sys_call_table page is not write protected. So I did *syscall_table[__NR_kexec_load] = (void *)my_kexec; but when I run kexec, It still says "kexec_load function not implimented" When if dig more, The W above means it's a weak symbol. Can I hijack those or, will I have to find another way? Thank you -madushan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/bcfc0704/attachment.html From gtvrreddy at gmail.com Fri Sep 18 02:51:59 2015 From: gtvrreddy at gmail.com (Ramana Reddy) Date: Fri, 18 Sep 2015 12:21:59 +0530 Subject: Would like know when the tcp sequence no is rollover Message-ID: Hi all, I would like to know, when the TCP sequence no is rollover. Who will do it. Is it happens in tcp code or through the hardware. If is it is in the tcp code, can some one please point the code in the linux kernel where it happens. Thanks & Regards, Ramana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/6cd9fc39/attachment.html From bjorn at mork.no Fri Sep 18 03:50:20 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 18 Sep 2015 09:50:20 +0200 Subject: Would like know when the tcp sequence no is rollover In-Reply-To: (Ramana Reddy's message of "Fri, 18 Sep 2015 12:21:59 +0530") References: Message-ID: <87si6cf9oj.fsf@nemi.mork.no> Ramana Reddy writes: > Hi all, > > I would like to know, when the TCP sequence no is rollover. > Who will do it. Is it happens in tcp code or through the hardware. > If is it is in the tcp code, can some one please point the code in the > linux kernel > where it happens. Why this interest in TCP sequence numbers? I believe RFC793 is a better source for understanding how this works: It is essential to remember that the actual sequence number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with sequence numbers must be performed modulo 2**32. Do you still think you'll find an explicit rollover code path? Why would you write code like that? Bj?rn From punitvara at gmail.com Fri Sep 18 07:12:03 2015 From: punitvara at gmail.com (punit vara) Date: Fri, 18 Sep 2015 16:42:03 +0530 Subject: [PATCH 2662/2662] Staging: android: Fix 80 character length In-Reply-To: References: <1442560101-3619-1-git-send-email-punitvara@gmail.com> <20150918082104.GA23813@sudip-pc> Message-ID: I have created one patch and already submitted. Now I have created another patch for another directory . What should be the subject of patch [Patch 2/2] or just [patch ] ??? On Fri, Sep 18, 2015 at 3:00 PM, punit vara wrote: > Thank you sir I will do the same If I would find any patch > > On Fri, Sep 18, 2015 at 2:45 PM, Sudip Mukherjee > wrote: >> usually i will create the patch with git format-patch -1 to generate the >> last patch >> >> On Fri, Sep 18, 2015 at 2:42 PM, punit vara wrote: >>> >>> before changing the file I did git fetch and then git remote update >>> .At that time all patches came automatically with update .Then I >>> simply create patch with git format-patch master..my_local_branch >>> 2662-... >>> >>> That is why subject was like [2662/2662] . >>> >>> On Fri, Sep 18, 2015 at 2:37 PM, Sudip Mukherjee >>> wrote: >>> > I will also do git fetch but numbers will not show. what command you >>> > gave to >>> > generate the patch? >>> > >>> > On Fri, Sep 18, 2015 at 2:26 PM, punit vara wrote: >>> >> >>> >> Sorry sir about that ..I have done git fetch so another 2661 patches >>> >> fetched .that's why mistakenly it subject was like that.I again >>> >> changed patch as you guide and send.Thank you for feedback sir >>> >> >>> >> On Fri, Sep 18, 2015 at 1:52 PM, Sudip Mukherjee >>> >> wrote: >>> >> > On Fri, Sep 18, 2015 at 12:38:21PM +0530, Punit Vara wrote: >>> >> >> This patch is to the Kconfig file which fixes up lines which >>> >> >> exceeded the standard 80 character limitation. >>> >> >> This file also fixes up 3 warnings regarding paragraph. >>> >> >> >>> >> >> Signed-off-by: Punit Vara >>> >> >> --- >>> >> > Your subject says 2662/2662. Then where are your 2661 earlier patches >>> >> > of >>> >> > the series? >>> >> > No, that is wrong. The numbers we use when we submit a series of >>> >> > patches. But for a single patch (1/1) numbers are not required and >>> >> > 2662 >>> >> > is definitely wrong. >>> >> > >>> >> > regards >>> >> > sudip >>> >> >>> >> >>> >> >>> >> -- >>> >> Regards, >>> >> Punit Vara >>> >> 9033553488 >>> > >>> > >>> >>> >>> >>> -- >>> Regards, >>> Punit Vara >>> 9033553488 >> >> > > > > -- > Regards, > Punit Vara > 9033553488 -- Regards, Punit Vara 9033553488 From karthik.188 at gmail.com Fri Sep 18 08:41:57 2015 From: karthik.188 at gmail.com (Karthik Nayak) Date: Fri, 18 Sep 2015 18:11:57 +0530 Subject: [PATCH 2662/2662] Staging: android: Fix 80 character length In-Reply-To: References: <1442560101-3619-1-git-send-email-punitvara@gmail.com> <20150918082104.GA23813@sudip-pc> Message-ID: On Fri, Sep 18, 2015 at 4:42 PM, punit vara wrote: > I have created one patch and already submitted. Now I have created > another patch for another directory . What should be the subject of > patch [Patch 2/2] or just [patch ] ??? If its different, keep it different ;) -- Regards, Karthik Nayak From roszenrami at gmail.com Fri Sep 18 10:04:03 2015 From: roszenrami at gmail.com (Rami Rosen) Date: Fri, 18 Sep 2015 17:04:03 +0300 Subject: Preceding a method call with (void) In-Reply-To: <25475.1441867160@turing-police.cc.vt.edu> References: <25475.1441867160@turing-police.cc.vt.edu> Message-ID: Hi, Well, there are rare cases in the kernel when you add (void) before calling the method. For example, if the method returns int or other type and you want to emphasize that you are aware of that and deliberately not check the return value. See for example: http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbxfload.c#L156 Regards, Rami Rosen ?????? 10 ???? 2015 09:39, ???: > On Thu, 10 Sep 2015 07:52:49 +0300, Kevin Wilson said: > > > (void) myFunc(param1); > > > > I did not encounter such cases in the kernel code that I read, thus far. > > > > On the other hand, I did not saw in the kernel coding style doc > > anything which prohibits such usage. > > > > If I remember, using (void) before the method name is a way to tell > > explicitly that this method does not return any value, > > but I am not sure as for the exact reasons it is used (in userspace). > > Well, if the function actually returns nothing, in kernel code we usually > declare it as: > > void myFunc( int param1) > { > /* yadda yadda yadda *. > } > > Given that, what reason is there for casting the return value with (void)? > > (And if the function is actually 'int myFunc ( int param1) {...}', > why are you calling it and then ignoring the return value? That's a clue > that you're abusing the API...) > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/ae10377a/attachment-0001.html From mudongliangabcd at gmail.com Fri Sep 18 10:35:18 2015 From: mudongliangabcd at gmail.com (=?UTF-8?B?5oWV5Yas5Lqu?=) Date: Fri, 18 Sep 2015 22:35:18 +0800 Subject: error when make pdfdocs Message-ID: I git clone and git pull the latest linux kernel. When I make pdfdocs, it reports the following error to me. But I checked the filesystems.xml:14946, no error found. ----------------------------------------------------------------------------------------------- PDF Documentation/DocBook/filesystems.pdf Using catalogs: /etc/sgml/catalog Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#print Working on: /home/mdl/Repos/linux/Documentation/DocBook/filesystems.xml openjade:/home/mdl/Repos/linux/Documentation/DocBook/filesystems.xml:14946:16:E: end tag for "variablelist" which is not finished Documentation/DocBook/Makefile:131: recipe for target 'Documentation/DocBook/filesystems.pdf' failed make[1]: *** [Documentation/DocBook/filesystems.pdf] Error 8 Makefile:1339: recipe for target 'pdfdocs' failed ----------------------------------------------------------------------------------------------- - mudongliang From Valdis.Kletnieks at vt.edu Fri Sep 18 11:02:17 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 18 Sep 2015 11:02:17 -0400 Subject: Preceding a method call with (void) In-Reply-To: References: <25475.1441867160@turing-police.cc.vt.edu> Message-ID: <50077.1442588537@turing-police.cc.vt.edu> On Fri, 18 Sep 2015 17:04:03 +0300, Rami Rosen said: > Well, there are rare cases in the kernel when you add (void) before calling > the method. For example, if the method returns int or other type and you > want to emphasize that you are aware of that and deliberately not check the > return value. > See for example: > http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbxfload.c#L156 The fact something is done in the tree doesn't mean it's *correct*. If you check the tree, there are 80 instances of it being cast to (void), and 9 instances of 'status ='. Now if you go look at the source of the function in drivers/acpi/acpica/utmutex.c we discover that there's 3 or 4 possible return(..) conditions in the function (one only if _DEBUG is defined). Looking at the places that places that bother checking the return code, they all look something like this: nsxfeval.c: status = acpi_ut_release_mutex(ACPI_MTX_NAMESPACE); nsxfeval.c- if (ACPI_FAILURE(status)) { nsxfeval.c- return (status); nsxfeval.c- } Now, given that 80 other sites don't bother checking, there's a good chance that these 9 call sites shouldn't bother either, and the calling code should be changed to not check the status either, and then make the function definition a void. (Of course a more careful examination of the code should be undertaken, but it's more likely that there's 9 sites that are checking a return code that doesn't actually matter than the chances that it really *does* matter in 9 places but not in 80 others... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/4fc20184/attachment.bin From shraddha.6596 at gmail.com Fri Sep 18 13:23:35 2015 From: shraddha.6596 at gmail.com (Shraddha Barke) Date: Fri, 18 Sep 2015 22:53:35 +0530 Subject: No subject Message-ID: By mistake I made some changes to staging-next branch Now I've reverted those changes but I'm getting this message when I checkout to staging-next Your branch is ahead of 'origin/staging-next' by 4 commits. (use "git push" to publish your local commits) How do I fix this? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/82c325ad/attachment.html From omerjerk at gmail.com Fri Sep 18 13:28:43 2015 From: omerjerk at gmail.com (Umair Khan) Date: Fri, 18 Sep 2015 17:28:43 +0000 Subject: In-Reply-To: References: Message-ID: You have made 4 commits on your local branch. You need to remove them by git reset. One way is to do git reset --hard origin/staging-next . Note that this will revert all the changes made by you. On Fri, Sep 18, 2015, 10:53 PM Shraddha Barke wrote: > By mistake I made some changes to staging-next branch > Now I've reverted those changes but I'm getting this message when I > checkout to staging-next > > Your branch is ahead of 'origin/staging-next' by 4 commits. > (use "git push" to publish your local commits) > > How do I fix this? > > Thanks in advance > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/0ee16de3/attachment.html From shraddha.6596 at gmail.com Fri Sep 18 13:36:56 2015 From: shraddha.6596 at gmail.com (Shraddha Barke) Date: Fri, 18 Sep 2015 23:06:56 +0530 Subject: In-Reply-To: References: Message-ID: On Fri, Sep 18, 2015 at 10:58 PM, Umair Khan wrote: > You have made 4 commits on your local branch. > You need to remove them by git reset. > One way is to do git reset --hard origin/staging-next . > Note that this will revert all the changes made by you. > > Yes. Thanks a lot :) > On Fri, Sep 18, 2015, 10:53 PM Shraddha Barke > wrote: > >> By mistake I made some changes to staging-next branch >> Now I've reverted those changes but I'm getting this message when I >> checkout to staging-next >> >> Your branch is ahead of 'origin/staging-next' by 4 commits. >> (use "git push" to publish your local commits) >> >> How do I fix this? >> >> Thanks in advance >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/2579d641/attachment.html From luis at debethencourt.com Fri Sep 18 18:12:42 2015 From: luis at debethencourt.com (Luis de Bethencourt) Date: Sat, 19 Sep 2015 00:12:42 +0200 Subject: Wireless Driver issue (Atheros AR9485) In-Reply-To: References: Message-ID: <20150918221242.GA9624@goodgumbo.baconseed.org> On Thu, Sep 17, 2015 at 08:54:28AM -0400, David Scaperoth wrote: > I'm attempting to run pm-suspend on my laptop (by shutting my lid and on > command line), and its putting my AR9485 wifi card into a funk (i.e. wlan0 > interface seen through ifconfig never returns upon resume). > > I know theres a lot to this (power management - pm-utils and kernel, > wireless drivers, general linux drivers, and possibly other things), just > need a little direction on which rabbit hole to start down...haha. > > Ive looked through the ath9k and wireless list archives and had no luck > finding the same issue. I have tried different solutions (mostly related > to pm-utils) from ubuntu's forums too. > > an example of where it failed /var/log/pm-powersave.log > > Running hook /usr/lib/pm-utils/power.d/wireless true: > Turning powersave for wlan0 on...Error for wireless request "Set Power > Management" (8B2C) : > SET failed on device wlan0 ; Operation not supported. > Failed. > /usr/lib/pm-utils/power.d/wireless true: success. > > > AND...according to > https://wireless.wiki.kernel.org/en/users/documentation/dynamic-power-save > I tried: > iw dev wlan0 set power_save on > command failed: Operation not supported (-95) > > This is my first post to this list, so I'm not sure what information would > be useful to help find a solution (or workaround). Here goes nothing > (perhaps I should attach text files next time for large diagnostic > information?): > > I built an upstream kernel against gregkh staging tree with a Ubuntu distro > just to see if this would fix my issue and it did not. Either way, here is > some information: > > >> uname -a > Linux xxx 4.2.0+ #1 SMP Sun Sep 6 05:53:34 EDT 2015 x86_64 x86_64 x86_64 > GNU/Linux > > >> lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 14.04.3 LTS > Release: 14.04 > Codename: trusty > > cat /proc/version > Linux version 4.2.0+ (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) ) #1 > SMP Sun Sep 6 05:53:34 EDT 2015 > > >>lspci -vvnn > > 01:00.0 Network controller [0280]: Qualcomm Atheros AR9485 Wireless Network > Adapter [168c:0032] (rev 01) > Subsystem: Hewlett-Packard Company AR9485/HB125 802.11bgn 1??1 Wi-Fi > Adapter [103c:1838] > > > I could provide more information from lspci and lshw but I'm not sure what > would help (if at all). The strangest thing about the whole matter is that > if I reboot, the card comes back online just fine. > > Thanks again for any help you can provide! > > David Hi David, I recommend you start with the support community of your distribution, which in your case is Ubuntu. https://help.ubuntu.com/community/WifiDocs/WirelessTroubleShootingGuide That has a trouble shooting guide and a link to where to ask if the problem persists. Distribution communities are great to solve issues like this. The Kernel Newbies mailing list focuses in people new to Linux Kernel development. Hopefully your wifi works well soon :) Luis From gunjanmehta08 at gmail.com Sat Sep 19 12:56:34 2015 From: gunjanmehta08 at gmail.com (Gunjan Mehta) Date: Sat, 19 Sep 2015 22:26:34 +0530 Subject: Issue using kernel linked list in user space Message-ID: I have a linked list like this http://pastebin.com/bwF3jLb6 . The problem i am facing is i have initialized the list head and then i am doing malloc for that struct object. What i need is i want to make struct abc_st *r as head of linked list and other nodes after it. typedef struct abc { char client_id[18]; char mac[18]; st_list_head list; }abc_st; abc_st* check_fields (abc_st *ptr) { char cmd[500]; MYSQL_RES *result; MYSQL_ROW row; int num_rows; abc_st *r=NULL,*temp=NULL; INIT_LIST_HEAD(&r->list); // i have intialized the head here sprintf(cmd, "SELECT * FROM ABCD_TABLE WHERE MAC = %.4x", ptr->mac); /* Running the sql query to check for fields with value in database */ if (mysql_query(abc_db.db_handle, cmd)) { num_rows = -1; goto done; } result = mysql_store_result(abc_db.db_handle); if (result == NULL) { num_rows = -1; goto done; } num_rows = mysql_num_rows(result); while ((row = mysql_fetch_row(result))) { r= (abc_st *)malloc(sizeof(abc_st)); memcpy(r->mac,row[1],strlen(row[1])+1); memcpy(r->client_id,row[0],strlen(row[0])+1); How should i use list_add ? //list_add(struct list_head *new, struct list_head *head) //prototype of list_add // list_add(&temp->list,&r->list); //it will go wrong here, i want to make r(structure r as head and then add other strutcure objects) // r->link = NULL; //list_add(r, ptr); } done: mysql_free_result(result); return r; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150919/a1854c7c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: list.h Type: text/x-chdr Size: 1970 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150919/a1854c7c/attachment.bin From gunjanmehta08 at gmail.com Sat Sep 19 14:29:16 2015 From: gunjanmehta08 at gmail.com (Gunjan Mehta) Date: Sat, 19 Sep 2015 23:59:16 +0530 Subject: Regirect /var/log/log/syslog messages to our own txt file Message-ID: Hi, I am working on a project, where i print my log messages in /var/log/log/syslog like project_my:info::project started project_my:debug::value of a is 1 i want to redirect project_my:info messages in info.txt file and project_my:debug in debug.txt file. Regards Gunjan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150919/3f448d96/attachment.html From daniel.baluta at gmail.com Sat Sep 19 14:52:55 2015 From: daniel.baluta at gmail.com (Daniel Baluta) Date: Sat, 19 Sep 2015 21:52:55 +0300 Subject: Regirect /var/log/log/syslog messages to our own txt file In-Reply-To: References: Message-ID: On Sat, Sep 19, 2015 at 9:29 PM, Gunjan Mehta wrote: > Hi, > > I am working on a project, where i print my log messages in > /var/log/log/syslog like > > project_my:info::project started > project_my:debug::value of a is 1 > > i want to redirect project_my:info messages in info.txt file and > project_my:debug in debug.txt file. Hi Gunjan, If I'm not wrong this depends on your syslog daemon. For example using rsyslog, you have an /etc/rsyslog.conf file useful for configuring rsyslog. If you are talking about kernel messages than adding: kern.debug -/your/debug/file.txt kern.info -/your/info/file.txt HTH, Daniel. From pranjas at gmail.com Sun Sep 20 03:05:34 2015 From: pranjas at gmail.com (Pranay Srivastava) Date: Sun, 20 Sep 2015 12:35:34 +0530 Subject: Issue using kernel linked list in user space In-Reply-To: References: Message-ID: On Sat, Sep 19, 2015 at 10:26 PM, Gunjan Mehta wrote: > I have a linked list like this http://pastebin.com/bwF3jLb6 . The problem i > am facing is i have initialized the list head and > then i am doing malloc for that struct object. What i need is i want to > make struct abc_st *r as head of linked list and other nodes after it. > > typedef struct abc { > char client_id[18]; > char mac[18]; > st_list_head list; > }abc_st; > > abc_st* check_fields (abc_st *ptr) > { > char cmd[500]; > MYSQL_RES *result; > MYSQL_ROW row; > int num_rows; > abc_st *r=NULL,*temp=NULL; huh? this is initialized? > INIT_LIST_HEAD(&r->list); // i have intialized the head here > > sprintf(cmd, "SELECT * FROM ABCD_TABLE WHERE MAC = %.4x", ptr->mac); > /* Running the sql query to check for fields with value in database > */ > if (mysql_query(abc_db.db_handle, cmd)) { > num_rows = -1; > goto done; > } > result = mysql_store_result(abc_db.db_handle); > if (result == NULL) { > num_rows = -1; > goto done; > } > num_rows = mysql_num_rows(result); > > while ((row = mysql_fetch_row(result))) > { > r= (abc_st *)malloc(sizeof(abc_st)); > memcpy(r->mac,row[1],strlen(row[1])+1); > memcpy(r->client_id,row[0],strlen(row[0])+1); > How should i use list_add ? > //list_add(struct list_head *new, struct list_head *head) > //prototype of list_add > // list_add(&temp->list,&r->list); //it will go wrong here, i want > to make r(structure r as head and then add other strutcure objects) > // r->link = NULL; > //list_add(r, ptr); > > } > done: > mysql_free_result(result); > > return r; > > } > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- ---P.K.S From gtvrreddy at gmail.com Sun Sep 20 05:19:02 2015 From: gtvrreddy at gmail.com (Ramana Reddy) Date: Sun, 20 Sep 2015 14:49:02 +0530 Subject: Would like know when the tcp sequence no is rollover In-Reply-To: References: <87si6cf9oj.fsf@nemi.mork.no> Message-ID: Hi Bj?rn, Thanks for your reply. Actually, I want to do some small experiment, so would need this tcp sequence roll over code. If you know some thing in this regards, please let me know. Thanks & Regards, Ramana On Fri, Sep 18, 2015 at 7:17 PM, Ramana Reddy wrote: > Hi, > Thanks for your reply. Actually, I want to restrict the TCP Sequence range > to a half range and rollover after > crosses that value. In anotherway, I want to use only half the TCP > sequence and once it crosses that value will rollover. > > Thanks, > Ramana > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150920/02aef304/attachment.html From bjorn at mork.no Sun Sep 20 05:33:02 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sun, 20 Sep 2015 11:33:02 +0200 Subject: Would like know when the tcp sequence no is rollover In-Reply-To: (Ramana Reddy's message of "Sun, 20 Sep 2015 14:49:02 +0530") References: <87si6cf9oj.fsf@nemi.mork.no> Message-ID: <871tdt5tbl.fsf@nemi.mork.no> Ramana Reddy writes: > Hi Bj?rn, > > Thanks for your reply. Actually, I want to do some small experiment, so > would need this tcp sequence roll over code. > If you know some thing in this regards, please let me know. There isn't much more to say, I think. All that's left is hard work. Since there is no existing rollover logic, you'll have to track down every single sequence number calculation in the kernel and modify them with additional rollover code. Note that this includes every sequence number comparison too. I'm afraid I still don't see the point. The end result will of course not be TCP anymore, and will only be capable of talking to itself. What use is that? Bj?rn From pravinshedage2008 at gmail.com Mon Sep 21 02:56:12 2015 From: pravinshedage2008 at gmail.com (Pravin Shedage) Date: Mon, 21 Sep 2015 12:26:12 +0530 Subject: Issue using kernel linked list in user space In-Reply-To: References: Message-ID: On Sun, Sep 20, 2015 at 12:35 PM, Pranay Srivastava wrote: > On Sat, Sep 19, 2015 at 10:26 PM, Gunjan Mehta wrote: >> I have a linked list like this http://pastebin.com/bwF3jLb6 . The problem i >> am facing is i have initialized the list head and >> then i am doing malloc for that struct object. What i need is i want to >> make struct abc_st *r as head of linked list and other nodes after it. >> >> typedef struct abc { >> char client_id[18]; >> char mac[18]; >> st_list_head list; >> }abc_st; >> >> abc_st* check_fields (abc_st *ptr) >> { >> char cmd[500]; >> MYSQL_RES *result; >> MYSQL_ROW row; >> int num_rows; >> abc_st *r=NULL,*temp=NULL; > > huh? this is initialized? >> INIT_LIST_HEAD(&r->list); // i have intialized the head here > >> >> sprintf(cmd, "SELECT * FROM ABCD_TABLE WHERE MAC = %.4x", ptr->mac); >> /* Running the sql query to check for fields with value in database >> */ >> if (mysql_query(abc_db.db_handle, cmd)) { >> num_rows = -1; >> goto done; >> } >> result = mysql_store_result(abc_db.db_handle); >> if (result == NULL) { >> num_rows = -1; >> goto done; >> } >> num_rows = mysql_num_rows(result); >> >> while ((row = mysql_fetch_row(result))) >> { >> r= (abc_st *)malloc(sizeof(abc_st)); >> memcpy(r->mac,row[1],strlen(row[1])+1); >> memcpy(r->client_id,row[0],strlen(row[0])+1); >> How should i use list_add ? >> //list_add(struct list_head *new, struct list_head *head) >> //prototype of list_add >> // list_add(&temp->list,&r->list); //it will go wrong here, i want >> to make r(structure r as head and then add other strutcure objects) >> // r->link = NULL; >> //list_add(r, ptr); >> >> } >> done: >> mysql_free_result(result); >> >> return r; >> >> } >> >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > > -- > ---P.K.S > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies INIT_LIST_HEAD gets a struct list head * and initializes list->next & list->prev. Use calloc to initialize other members from struct abc. st_list_head list; I hope this will be typedef of struct list_head. INIT_LIST_HEAD(&r->list); <-- This indicate r as a List Head. Just small change you need. r remains be your list head. To add new node, create newnode of type (abc_st *) and add it in the list. check the code modification which clarify you better. typedef struct abc { char client_id[18]; char mac[18]; st_list_head list; }abc_st; abc_st* check_fields (abc_st *ptr) { char cmd[500]; MYSQL_RES *result; MYSQL_ROW row; int num_rows; abc_st *r=NULL,*temp=NULL; abc_st *newnode = NULL; INIT_LIST_HEAD(&r->list); // i have intialized the head here sprintf(cmd, "SELECT * FROM ABCD_TABLE WHERE MAC = %.4x", ptr->mac); /* Running the sql query to check for fields with value in database */ if (mysql_query(abc_db.db_handle, cmd)) { num_rows = -1; goto done; } result = mysql_store_result(abc_db.db_handle); if (result == NULL) { num_rows = -1; goto done; } num_rows = mysql_num_rows(result); while ((row = mysql_fetch_row(result))) { if ((newnode = (abc_st *)calloc(sizeof(abc_st))) == NULL) { fprintf(stderr, "%s\n", strerror(errno)); goto done; } memcpy(newnode->mac,row[1],strlen(row[1])+1); memcpy(newnode->client_id,row[0],strlen(row[0])+1); list_add(&(newnode->list), &(r->list)); } done: mysql_free_result(result); return r; } - Thanks & Regards, PraviN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150921/3df3f2ee/attachment.html From chrysn at fsfe.org Tue Sep 22 12:28:47 2015 From: chrysn at fsfe.org (chrysn) Date: Tue, 22 Sep 2015 18:28:47 +0200 Subject: Adding GPIO/SPI/I2C functionality to FTDI driver Message-ID: <20150922162847.GC16144@hephaistos.amsuess.com> Hello kernelnewbies list, I've run into situations where it would be practical to have the GPIO, I2C and SPI functionality some FTDI chips provide as kernel devices. (The chips are more often used as USB serial adapters; only that feature is supported by the current kernel drivers). The presence of an extensive userspace library (libftdi) and the observation of a project in a similar situation[1] that has not made it into the kernel makes me doubt that implementing that in the kernel is the way to go. I've written up more thoughts on this on [2], including exploration of userspace SPI/GPIO/I2C devices (think FUSE / USBIP / uinput), but it boils down to a simple question: Is support for alternative operation modes in FTDI chips something that is welcome and (easily) feasible in the kernel? Best regards chrysn [1] http://danielthesantos.blogspot.co.at/2013/08/why-mcp2210-driver.html [2] http://christian.amsuess.com/idea-incubator/ftdi-kernel-support/ -- You don't become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process. -- Marie Curie (as quoted by Randall Munroe) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150922/f2c84960/attachment.bin From greg at kroah.com Tue Sep 22 15:02:03 2015 From: greg at kroah.com (Greg KH) Date: Tue, 22 Sep 2015 12:02:03 -0700 Subject: Adding GPIO/SPI/I2C functionality to FTDI driver In-Reply-To: <20150922162847.GC16144@hephaistos.amsuess.com> References: <20150922162847.GC16144@hephaistos.amsuess.com> Message-ID: <20150922190203.GA31705@kroah.com> On Tue, Sep 22, 2015 at 06:28:47PM +0200, chrysn wrote: > Hello kernelnewbies list, > > I've run into situations where it would be practical to have the GPIO, > I2C and SPI functionality some FTDI chips provide as kernel devices. > (The chips are more often used as USB serial adapters; only that feature > is supported by the current kernel drivers). > > The presence of an extensive userspace library (libftdi) and the > observation of a project in a similar situation[1] that has not made it > into the kernel makes me doubt that implementing that in the kernel is > the way to go. > > I've written up more thoughts on this on [2], including exploration of > userspace SPI/GPIO/I2C devices (think FUSE / USBIP / uinput), but it > boils down to a simple question: > > > Is support for alternative operation modes in FTDI chips something that > is welcome and (easily) feasible in the kernel? This comes up every other month or so on the linux-usb mailing list. See the discussions there about how to do this properly in a way that will be accepted by the USB maintainers if you wish to do this work. And yes, this would be very welcome, but no one seems to be willing to do the work :( thanks, greg k-h From prem.it.kumar at gmail.com Tue Sep 22 16:08:31 2015 From: prem.it.kumar at gmail.com (Prem Kumar) Date: Tue, 22 Sep 2015 15:08:31 -0500 Subject: Active Memory never reclaimed please help me understand Message-ID: Dear All, I have done quite a bit of reading on Active memory reported in /proc/meminfo and in short says it is never reclaimed unless absolutely necessary, and it caches the recently used files/pages in memory. Although I fail to understand the consequences that I face here. I have disk-less and swap-less nodes. So all I have to do, is play with the RAM on the box. Issue that brought me here is investigating why after running some applications, used memory is never available for use with any other applications. In other words I cannot run any programs that requests memory more than what is shown as free in the output of free command and MemFree in the output of the cat /proc/meminfo For example if I ran any program that requires more than 6GB on the first node below and more than 1GB on the second node below they fail instantly, and work fine if within the limist of free. There is nothing else running on the system other than system processes/services. total used free shared buffers cached Mem: 23 17 6 0 0 9 -/+ buffers/cache: 8 15 Swap: 0 0 0 total used free shared buffers cached Mem: 23 22 1 0 0 0 -/+ buffers/cache: 21 1 Swap: 0 0 0 Since the applications that ran previously are not running any more "even though they died out of memory because they requested more memory than available", shouldn't the OS see that any memory used previously as useless and can it not reclaim that for use with the next job/program on that machine. On every machine that I have run into this problem the out put of /proc/meminfo shows that Active memory is used up the amount shown in the free command and limits my further runs. This is driving me insane and making me feel stupid knowing that OS is smart enough to handle this, then what am I missing here to understand? Please advise. Appreciate any insight into this. Best Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150922/905eeab4/attachment.html From prem.it.kumar at gmail.com Tue Sep 22 17:47:25 2015 From: prem.it.kumar at gmail.com (Prem Kumar) Date: Tue, 22 Sep 2015 16:47:25 -0500 Subject: Active Memory never reclaimed please help me understand In-Reply-To: References: Message-ID: also wondering if there is a way I can list Active memory map showing me what is cached? -regards. On Tue, Sep 22, 2015 at 3:08 PM, Prem Kumar wrote: > Dear All, > > I have done quite a bit of reading on Active memory reported in > /proc/meminfo and in short says it is never reclaimed unless absolutely > necessary, and it caches the recently used files/pages in memory. Although > I fail to understand the consequences that I face here. > > I have disk-less and swap-less nodes. So all I have to do, is play with > the RAM on the box. Issue that brought me here is investigating why after > running some applications, used memory is never available for use with any > other applications. > > In other words I cannot run any programs that requests memory more than > what is shown as free in the output of free command and MemFree in the > output of the cat /proc/meminfo > For example if I ran any program that requires more than 6GB on the first > node below and more than 1GB on the second node below they fail instantly, > and work fine if within the limist of free. There is nothing else running > on the system other than system processes/services. > > total used free shared buffers cached > Mem: 23 17 6 0 0 9 > -/+ buffers/cache: 8 15 > Swap: 0 0 0 > > total used free shared buffers cached > Mem: 23 22 1 0 0 0 > -/+ buffers/cache: 21 1 > Swap: 0 0 0 > > Since the applications that ran previously are not running any more "even > though they died out of memory because they requested more memory than > available", shouldn't the OS see that any memory used previously as useless > and can it not reclaim that for use with the next job/program on that > machine. > > On every machine that I have run into this problem the out put of > /proc/meminfo shows that Active memory is used up the amount shown in the > free command and limits my further runs. > > This is driving me insane and making me feel stupid knowing that OS is > smart enough to handle this, then what am I missing here to understand? > Please advise. > > Appreciate any insight into this. > > Best Regards, > Prem > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150922/4353bee9/attachment.html From chrysn at fsfe.org Wed Sep 23 11:40:58 2015 From: chrysn at fsfe.org (chrysn) Date: Wed, 23 Sep 2015 17:40:58 +0200 Subject: Adding GPIO/SPI/I2C functionality to FTDI driver In-Reply-To: <20150922190203.GA31705@kroah.com> References: <20150922162847.GC16144@hephaistos.amsuess.com> <20150922190203.GA31705@kroah.com> Message-ID: <20150923154058.GB24018@hephaistos.amsuess.com> Hallo Stefan, hallo Philipp, hello Johan and Greg, On Tue, Sep 22, 2015 at 12:02:03PM -0700, Greg KH wrote: > On Tue, Sep 22, 2015 at 06:28:47PM +0200, chrysn wrote: > > Is support for alternative operation modes in FTDI chips something that > > is welcome and (easily) feasible in the kernel? > > This comes up every other month or so on the linux-usb mailing list. > See the discussions there about how to do this properly in a way that > will be accepted by the USB maintainers if you wish to do this work. I've overlooked your two recent approaches when looking for existing approaches towards extending FTDI support in the kernel (probably due to me being too focused at SPI). Stefan and Philipp, has any of your patch sets received updates in the meantime that have not been sent to the mailing list? It seems that one issue that needs to be solved for either of those to continue is the decision of whether to base the FTDI driver on the MFD infrastructure (which would probably be a first step then before even implementing any of SPI, GPIO or I2C interfaces). There have been conflicting opinions on this in different threads ([1], [2]); my impression is that it would be a good idea, given that many of the more recent FTDI devices can be switched to half a dozen configurations, and that they are also shipped in products[3] where several of them would be used in a coordinated fashion similar to the shields of widespread embedded systems. Johan and Greg, can you reconcile your opinions on that? Or whom is that question best discussed with? devicetree? linux-usb? linux-gpio / -spi / -i2c? Best regards chrysn PS. I've updated the summary I'm keeping of what led to this thread on [4] -- all directly relevant information / questions should be in the mails, but the page should provide further background for the curious. [1] https://lkml.org/lkml/2014/6/1/250 [2] https://lkml.org/lkml/2015/6/22/451 [3] http://www.mikroe.com/click/usb-adapter/ [4] http://christian.amsuess.com/idea-incubator/ftdi-kernel-support/ -- I shouldn't have written all those tank programs. -- Kevin Flynn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150923/a46e66ab/attachment-0001.bin From mulyadi.santosa at gmail.com Wed Sep 23 12:07:33 2015 From: mulyadi.santosa at gmail.com (Mulyadi Santosa) Date: Wed, 23 Sep 2015 23:07:33 +0700 Subject: Active Memory never reclaimed please help me understand In-Reply-To: References: Message-ID: On Wed, Sep 23, 2015 at 4:47 AM, Prem Kumar wrote: > also wondering if there is a way I can list Active memory map showing me > what is cached? > > -regards. > > On Tue, Sep 22, 2015 at 3:08 PM, Prem Kumar > wrote: > >> Dear All, >> >> I have done quite a bit of reading on Active memory reported in >> /proc/meminfo and in short says it is never reclaimed unless absolutely >> necessary, and it caches the recently used files/pages in memory. Although >> I fail to understand the consequences that I face here. >> >> I have disk-less and swap-less nodes. So all I have to do, is play with >> the RAM on the box. Issue that brought me here is investigating why after >> running some applications, used memory is never available for use with any >> other applications. >> >> In other words I cannot run any programs that requests memory more than >> what is shown as free in the output of free command and MemFree in the >> output of the cat /proc/meminfo >> For example if I ran any program that requires more than 6GB on the first >> node below and more than 1GB on the second node below they fail instantly, >> and work fine if within the limist of free. There is nothing else running >> on the system other than system processes/services. >> >> total used free shared buffers cached >> Mem: 23 17 6 0 0 9 >> -/+ buffers/cache: 8 15 >> Swap: 0 0 0 >> >> total used free shared buffers cached >> Mem: 23 22 1 0 0 0 >> -/+ buffers/cache: 21 1 >> Swap: 0 0 0 >> >> Since the applications that ran previously are not running any more "even >> though they died out of memory because they requested more memory than >> available", shouldn't the OS see that any memory used previously as useless >> and can it not reclaim that for use with the next job/program on that >> machine. >> >> On every machine that I have run into this problem the out put of >> /proc/meminfo shows that Active memory is used up the amount shown in the >> free command and limits my further runs. >> >> This is driving me insane and making me feel stupid knowing that OS is >> smart enough to handle this, then what am I missing here to understand? >> Please advise. >> >> Appreciate any insight into this. >> >> Best Regards, >> Prem >> >> >> > > > Dear Prem welcome to kernelnewbies :) First of all, please don't do top posting when replying. Follow like what I and the rest of list member do. Btw, looking from the free output, I have a doubt about your statement that your first application took 6 GB and secondly it took 1 GB. Assuming your application doesn't thing like memory locking in kernel space, i guess it takes 20+ GB of RAM. So, before we go further, could you re run your applications and use ps or top to see both the VSIZE and RSS they take ? Regarding memory claiming, yes after app is killed (using any ways possible: ctrl-c, sending kill/term/quit signal, OOM etc), any memory allocated by this task are freed. It happen on both active and inactive pages -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150923/2290e2ad/attachment.html From rgroner at RTD.com Wed Sep 23 15:22:08 2015 From: rgroner at RTD.com (Rob Groner) Date: Wed, 23 Sep 2015 19:22:08 +0000 Subject: Question about "Creating first patch" guide Message-ID: The OutreachyfirstpatchSetup has been very helpful in setting up my computer to develop a patch to submit to the kernel overlords. I'm at the point where I've changed the kernel code, ran and test it, and see just my changes with "git diff". What has me a little confused is that before I actually create the patch file (to submit to the appropriate mailing list), it says to actually commit the change. Perhaps I don't understand how git handles commit (I primarily use svn), but it seems like actually committing the change is kind of presumptuous before even posting anything on the mailing list of those that control the git repository. What part am I not understanding? Thank you. Rob Groner -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150923/f5b23671/attachment.html From greg at kroah.com Wed Sep 23 15:43:46 2015 From: greg at kroah.com (Greg KH) Date: Wed, 23 Sep 2015 12:43:46 -0700 Subject: Question about "Creating first patch" guide In-Reply-To: References: Message-ID: <20150923194346.GA15366@kroah.com> On Wed, Sep 23, 2015 at 07:22:08PM +0000, Rob Groner wrote: > The OutreachyfirstpatchSetup has been very helpful in setting up my computer to > develop a patch to submit to the kernel overlords. > > > > I?m at the point where I?ve changed the kernel code, ran and test it, and see > just my changes with ?git diff?. What has me a little confused is that before > I actually create the patch file (to submit to the appropriate mailing list), > it says to actually commit the change. Perhaps I don?t understand how git > handles commit (I primarily use svn), but it seems like actually committing the > change is kind of presumptuous before even posting anything on the mailing list > of those that control the git repository. > > > > What part am I not understanding? You should create a branch and work on that, making a commit there, then it is trivial to turn that into a patch, as the tutorial suggests. With git, everything can be local, svn requires you to push your changes to the server, which is the big difference here. hope this helps, greg k-h From rgroner at RTD.com Wed Sep 23 16:01:19 2015 From: rgroner at RTD.com (Rob Groner) Date: Wed, 23 Sep 2015 20:01:19 +0000 Subject: Question about "Creating first patch" guide In-Reply-To: <20150923194346.GA15366@kroah.com> References: <20150923194346.GA15366@kroah.com> Message-ID: Helps very much, thank you! I think I read somewhere in that tutorial that posting your patch to kernel-newbie was a safe thing to do to get comments/criticism before submitting to the maintainer mailing list (linux-serial in this case). Is that true? Thanks again. Rob Groner > -----Original Message----- > From: Greg KH [mailto:greg at kroah.com] > Sent: Wednesday, September 23, 2015 3:44 PM > To: Rob Groner > Cc: kernelnewbies at kernelnewbies.org > Subject: Re: Question about "Creating first patch" guide > > On Wed, Sep 23, 2015 at 07:22:08PM +0000, Rob Groner wrote: > > The OutreachyfirstpatchSetup has been very helpful in setting up my > > computer to develop a patch to submit to the kernel overlords. > > > > > > > > I?m at the point where I?ve changed the kernel code, ran and test it, > > and see just my changes with ?git diff?. What has me a little > > confused is that before I actually create the patch file (to submit to > > the appropriate mailing list), it says to actually commit the change. > > Perhaps I don?t understand how git handles commit (I primarily use > > svn), but it seems like actually committing the change is kind of > > presumptuous before even posting anything on the mailing list of those > that control the git repository. > > > > > > > > What part am I not understanding? > > You should create a branch and work on that, making a commit there, then it > is trivial to turn that into a patch, as the tutorial suggests. > > With git, everything can be local, svn requires you to push your changes to > the server, which is the big difference here. > > hope this helps, > > greg k-h From prem.it.kumar at gmail.com Wed Sep 23 16:46:50 2015 From: prem.it.kumar at gmail.com (Prem Kumar) Date: Wed, 23 Sep 2015 15:46:50 -0500 Subject: Active Memory never reclaimed please help me understand In-Reply-To: References: Message-ID: Dear Mulyadi, Thank you for your response. Sorry for top posting it, I was waiting for my posting to arrive in my mail-box but it took for ever and hence top posted in eagerness. You are right in your observation that I couldn't possibly have had my first application crash at 6GB. I should have said about 15GB. I have many nodes I just picked the outputs from couple and presented by observation. Below here I will try to dissect my observation in the hope you can help me understand this, my OS concepts have become a little and haven't been in touch with them. Here is a machine that Currently has this state: $ free -g total used free shared buffers cached Mem: 23 14 8 0 0 0 -/+ buffers/cache: 14 9 Swap: 0 0 0 I have a program that just globs memory here is what happens when I run this: $ ./eatmemory 8.99G Eating 8589934592 bytes in chunks of 1024... Done, press any key to free the memory $ ./eatmemory 9G Eating 9663676416 bytes in chunks of 1024... Killed I believe the above observation is nothing wrong, because RAM is used by what other(assuming running) applications and I only have so much available for my program to run. But my issue is nothing else other than system services are running on this machine, this renders this node un-usable for the next program that runs on this machine and when request more than what 9G as above. Below here is the output of /proc/meminfo from the same machine $ cat /proc/meminfo MemTotal: 24724728 kB MemFree: 9402768 kB Buffers: 0 kB Cached: 217464 kB SwapCached: 0 kB Active: 14650896 kB Inactive: 60456 kB Active(anon): 14647052 kB Inactive(anon): 40632 kB Active(file): 3844 kB Inactive(file): 19824 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 14493928 kB Mapped: 19544 kB Shmem: 193720 kB Slab: 109720 kB SReclaimable: 12300 kB SUnreclaim: 97420 kB KernelStack: 2968 kB PageTables: 39100 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 12362364 kB Committed_AS: 15684044 kB VmallocTotal: 34359738367 kB VmallocUsed: 493316 kB VmallocChunk: 34346062668 kB HardwareCorrupted: 0 kB AnonHugePages: 13936640 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 7652 kB DirectMap2M: 25145344 kB Also here is my ulimit which is unlimited: $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 192912 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 81920 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited And /proc/self/maps $ cat /proc/self/maps 00400000-0040b000 r-xp 00000000 00:10 67455633 /bin/cat 0060a000-0060b000 rw-p 0000a000 00:10 67455633 /bin/cat 0060b000-0060c000 rw-p 00000000 00:00 0 0080a000-0080b000 rw-p 0000a000 00:10 67455633 /bin/cat 0209f000-020c0000 rw-p 00000000 00:00 0 [heap] 36d7e00000-36d7e20000 r-xp 00000000 00:10 67454760 /lib64/ld-2.12.so 36d801f000-36d8020000 r--p 0001f000 00:10 67454760 /lib64/ld-2.12.so 36d8020000-36d8021000 rw-p 00020000 00:10 67454760 /lib64/ld-2.12.so 36d8021000-36d8022000 rw-p 00000000 00:00 0 36d8200000-36d838a000 r-xp 00000000 00:10 67456999 /lib64/libc-2.12.so 36d838a000-36d858a000 ---p 0018a000 00:10 67456999 /lib64/libc-2.12.so 36d858a000-36d858e000 r--p 0018a000 00:10 67456999 /lib64/libc-2.12.so 36d858e000-36d858f000 rw-p 0018e000 00:10 67456999 /lib64/libc-2.12.so 36d858f000-36d8594000 rw-p 00000000 00:00 0 7f754caad000-7f754cab0000 rw-p 00000000 00:00 0 7f754cac2000-7f754cac3000 rw-p 00000000 00:00 0 7fff5e496000-7fff5e4ab000 rw-p 00000000 00:00 0 [stack] 7fff5e5f8000-7fff5e5f9000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] On every machine i ran into this problem, anonpages are eating up the memory,in effect shrinking the available RAM for the programs to run. Q) Now my question is since the previous job/program that ran on this machines has finished or died: My OS concepts tell me that the recently used cached-anonpages will be released to meet the request of another application requesting to use up the memory/vm. What am I missing here to understand? Also what I fail to understand is the state in which my diskelss & swapless nodes remain: What/who has control over the used up memory, why is it not being granted for the next owner of the machine to run at full scale? I understand that I will not have all of it but at least 19GB out of 24GB. Also below is the list of top process on the machines: Looking at it I don't see any heave use of memory ...mystery make me feel dumb?? $ ps aux --sort -rss USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 8402 0.0 0.0 119712 15896 ? S 12:11 0:00 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files root 9555 0.0 0.0 3508796 4680 ? S Aug18 0:33 /usr/sbin/slurmd useralap 8231 0.0 0.0 27224 4604 pts/0 S 12:06 0:00 -bash root 8401 0.0 0.0 151052 4264 ? S 12:11 0:00 /usr/libexec/sssd/sssd_be --domain default --uid 0 --gid 0 --debug-to-files root 8153 0.0 0.0 111192 3240 pts/0 Ss 12:05 0:00 -bash root 2078 0.0 0.0 720600 2968 ? Ssl Aug10 1:39 automount --pid-file /var/run/autofs.pid root 1752 0.0 0.0 249344 2784 ? Sl Aug10 0:04 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5 useralap 9898 1.0 0.0 26196 1468 pts/0 R+ 15:42 0:00 ps aux --sort -rss root 8150 0.0 0.0 111816 1296 ? Ss 12:05 0:00 sshd: root at pts/0 munge 2146 0.0 0.0 225004 1292 ? Sl Aug10 0:36 /usr/sbin/munged 68 2006 0.0 0.0 41976 1228 ? Ssl Aug10 0:10 hald root 1671 0.0 0.0 9120 976 ? Ss Aug10 0:00 /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-em1.leases -pf /var/run/dhclient-em1.pid root 8400 0.0 0.0 114288 900 ? Ss 12:11 0:00 /usr/sbin/sssd -f -D root 8403 0.0 0.0 105264 876 ? S 12:11 0:00 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files root 2174 0.0 0.0 20000 868 ? Ss Aug10 0:42 crond root 2111 0.0 0.0 66188 712 ? Ss Aug10 0:00 /usr/sbin/sshd root 3625 0.0 0.0 334616 648 ? SLsl Aug10 0:00 /usr/sbin/ibacm root 863 0.0 0.0 10832 592 ? S wrote: > > > On Wed, Sep 23, 2015 at 4:47 AM, Prem Kumar > wrote: > >> also wondering if there is a way I can list Active memory map showing me >> what is cached? >> >> -regards. >> >> On Tue, Sep 22, 2015 at 3:08 PM, Prem Kumar >> wrote: >> >>> Dear All, >>> >>> I have done quite a bit of reading on Active memory reported in >>> /proc/meminfo and in short says it is never reclaimed unless absolutely >>> necessary, and it caches the recently used files/pages in memory. Although >>> I fail to understand the consequences that I face here. >>> >>> I have disk-less and swap-less nodes. So all I have to do, is play with >>> the RAM on the box. Issue that brought me here is investigating why after >>> running some applications, used memory is never available for use with any >>> other applications. >>> >>> In other words I cannot run any programs that requests memory more than >>> what is shown as free in the output of free command and MemFree in the >>> output of the cat /proc/meminfo >>> For example if I ran any program that requires more than 6GB on the >>> first node below and more than 1GB on the second node below they fail >>> instantly, and work fine if within the limist of free. There is nothing >>> else running on the system other than system processes/services. >>> >>> total used free shared buffers cached >>> Mem: 23 17 6 0 0 9 >>> -/+ buffers/cache: 8 15 >>> Swap: 0 0 0 >>> >>> total used free shared buffers cached >>> Mem: 23 22 1 0 0 0 >>> -/+ buffers/cache: 21 1 >>> Swap: 0 0 0 >>> >>> Since the applications that ran previously are not running any more >>> "even though they died out of memory because they requested more memory >>> than available", shouldn't the OS see that any memory used previously as >>> useless and can it not reclaim that for use with the next job/program on >>> that machine. >>> >>> On every machine that I have run into this problem the out put of >>> /proc/meminfo shows that Active memory is used up the amount shown in the >>> free command and limits my further runs. >>> >>> This is driving me insane and making me feel stupid knowing that OS is >>> smart enough to handle this, then what am I missing here to understand? >>> Please advise. >>> >>> Appreciate any insight into this. >>> >>> Best Regards, >>> Prem >>> >>> >>> >> >> >> > Dear Prem > > welcome to kernelnewbies :) First of all, please don't do top posting when > replying. Follow like what I and the rest of list member do. > > Btw, looking from the free output, I have a doubt about your statement > that your first application took 6 GB and secondly it took 1 GB. Assuming > your application doesn't thing like memory locking in kernel space, i guess > it takes 20+ GB of RAM. > > So, before we go further, could you re run your applications and use ps or > top to see both the VSIZE and RSS they take ? > > Regarding memory claiming, yes after app is killed (using any ways > possible: ctrl-c, sending kill/term/quit signal, OOM etc), any memory > allocated by this task are freed. It happen on both active and inactive > pages > > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150923/94d5241f/attachment-0001.html From greg at kroah.com Wed Sep 23 17:04:10 2015 From: greg at kroah.com (Greg KH) Date: Wed, 23 Sep 2015 14:04:10 -0700 Subject: Question about "Creating first patch" guide In-Reply-To: References: <20150923194346.GA15366@kroah.com> Message-ID: <20150923210410.GA19059@kroah.com> On Wed, Sep 23, 2015 at 08:01:19PM +0000, Rob Groner wrote: > Helps very much, thank you! > > I think I read somewhere in that tutorial that posting your patch to > kernel-newbie was a safe thing to do to get comments/criticism before > submitting to the maintainer mailing list (linux-serial in this case). > Is that true? Sure, that works, especially as the maintainer of that subsystem is on both lists :) greg k-h From rgroner at RTD.com Wed Sep 23 17:02:26 2015 From: rgroner at RTD.com (Rob Groner) Date: Wed, 23 Sep 2015 21:02:26 +0000 Subject: Question about "Creating first patch" guide In-Reply-To: <20150923194346.GA15366@kroah.com> References: <20150923194346.GA15366@kroah.com> Message-ID: > -----Original Message----- > From: Greg KH [mailto:greg at kroah.com] > Sent: Wednesday, September 23, 2015 3:44 PM > To: Rob Groner > Cc: kernelnewbies at kernelnewbies.org > Subject: Re: Question about "Creating first patch" guide > > On Wed, Sep 23, 2015 at 07:22:08PM +0000, Rob Groner wrote: > > The OutreachyfirstpatchSetup has been very helpful in setting up my > > computer to develop a patch to submit to the kernel overlords. > > > > > > > > I?m at the point where I?ve changed the kernel code, ran and test it, > > and see just my changes with ?git diff?. What has me a little > > confused is that before I actually create the patch file (to submit to > > the appropriate mailing list), it says to actually commit the change. > > Perhaps I don?t understand how git handles commit (I primarily use > > svn), but it seems like actually committing the change is kind of > > presumptuous before even posting anything on the mailing list of those > that control the git repository. > > > > > > > > What part am I not understanding? > > You should create a branch and work on that, making a commit there, then it > is trivial to turn that into a patch, as the tutorial suggests. > > With git, everything can be local, svn requires you to push your changes to > the server, which is the big difference here. > > hope this helps, > > greg k-h And sorry for the top-posting. I had no idea that was a thing until 5 minutes ago. Mailing lists are a completely new thing to me (at age 44+). Rob From mudongliangabcd at gmail.com Wed Sep 23 23:21:36 2015 From: mudongliangabcd at gmail.com (=?UTF-8?B?5oWV5Yas5Lqu?=) Date: Thu, 24 Sep 2015 11:21:36 +0800 Subject: Question about "Creating first patch" guide In-Reply-To: References: <20150923194346.GA15366@kroah.com> Message-ID: I don't know whether my procedure to generate patch is right.Share it with you and you can comment it ,feed back to me! First, I change the document in the master branch, but don't commit to master branch. Then I use "git diff" to generate the patch. At last , I do a check with checkpatch.pl. If there is no error, I will post it to the according subsystem. If there are any wrong tips, point it out for me. Thank you. - mdongliang 2015-09-24 5:02 GMT+08:00 Rob Groner : >> -----Original Message----- >> From: Greg KH [mailto:greg at kroah.com] >> Sent: Wednesday, September 23, 2015 3:44 PM >> To: Rob Groner >> Cc: kernelnewbies at kernelnewbies.org >> Subject: Re: Question about "Creating first patch" guide >> >> On Wed, Sep 23, 2015 at 07:22:08PM +0000, Rob Groner wrote: >> > The OutreachyfirstpatchSetup has been very helpful in setting up my >> > computer to develop a patch to submit to the kernel overlords. >> > >> > >> > >> > I?m at the point where I?ve changed the kernel code, ran and test it, >> > and see just my changes with ?git diff?. What has me a little >> > confused is that before I actually create the patch file (to submit to >> > the appropriate mailing list), it says to actually commit the change. >> > Perhaps I don?t understand how git handles commit (I primarily use >> > svn), but it seems like actually committing the change is kind of >> > presumptuous before even posting anything on the mailing list of those >> that control the git repository. >> > >> > >> > >> > What part am I not understanding? >> >> You should create a branch and work on that, making a commit there, then it >> is trivial to turn that into a patch, as the tutorial suggests. >> >> With git, everything can be local, svn requires you to push your changes to >> the server, which is the big difference here. >> >> hope this helps, >> >> greg k-h > > And sorry for the top-posting. I had no idea that was a thing until 5 minutes ago. Mailing lists are a completely new thing to me (at age 44+). > > Rob > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies From karthik.188 at gmail.com Thu Sep 24 01:56:01 2015 From: karthik.188 at gmail.com (Karthik Nayak) Date: Thu, 24 Sep 2015 11:26:01 +0530 Subject: Question about "Creating first patch" guide In-Reply-To: References: <20150923194346.GA15366@kroah.com> Message-ID: On Thu, Sep 24, 2015 at 8:51 AM, ??? wrote: > I don't know whether my procedure to generate patch is right.Share it > with you and you can comment it ,feed back to me! > > First, I change the document in the master branch, but don't commit to > master branch. Then I use "git diff" to generate the patch. Why not commit? A simple way to do this would be. 1. Make changes as per requirements 2. Commit them 3. Use `git format-patch` to generate patches. 4. Check using checkpatch 5. `Use git send-email` to mail those patches to the required list. -- Regards, Karthik Nayak From mudongliangabcd at gmail.com Thu Sep 24 02:47:44 2015 From: mudongliangabcd at gmail.com (=?UTF-8?B?5oWV5Yas5Lqu?=) Date: Thu, 24 Sep 2015 14:47:44 +0800 Subject: Question about "Creating first patch" guide In-Reply-To: References: <20150923194346.GA15366@kroah.com> Message-ID: 2015-09-24 13:56 GMT+08:00 Karthik Nayak : > On Thu, Sep 24, 2015 at 8:51 AM, ??? wrote: >> I don't know whether my procedure to generate patch is right.Share it >> with you and you can comment it ,feed back to me! >> >> First, I change the document in the master branch, but don't commit to >> master branch. Then I use "git diff" to generate the patch. > > Why not commit? > A simple way to do this would be. Why do I not commit? Because I don't this easy method to generate patch file. I read SubmittingPatches, just to understand I can use git diff to get my patch. Then I don't search any advanced, good method. This shows that I am not familiar with git. > > 1. Make changes as per requirements > 2. Commit them > 3. Use `git format-patch` to generate patches. "git format-patch" is great. The format is very nice to read. > 4. Check using checkpatch > 5. `Use git send-email` to mail those patches to the required list. But I don't find git "send-email" in my system. I test in git 2.1.4 and git 2.5.1 on my Debian. Search it , I find I lost a package git-email. I still have much to learn.Thank you. - mudongliang > > -- > Regards, > Karthik Nayak From karthik.188 at gmail.com Thu Sep 24 02:55:07 2015 From: karthik.188 at gmail.com (Karthik Nayak) Date: Thu, 24 Sep 2015 12:25:07 +0530 Subject: Question about "Creating first patch" guide In-Reply-To: References: <20150923194346.GA15366@kroah.com> Message-ID: On Thu, Sep 24, 2015 at 12:17 PM, ??? wrote: > 2015-09-24 13:56 GMT+08:00 Karthik Nayak : >> On Thu, Sep 24, 2015 at 8:51 AM, ??? wrote: >>> I don't know whether my procedure to generate patch is right.Share it >>> with you and you can comment it ,feed back to me! >>> >>> First, I change the document in the master branch, but don't commit to >>> master branch. Then I use "git diff" to generate the patch. >> >> Why not commit? >> A simple way to do this would be. > Why do I not commit? Because I don't this easy method to generate patch file. > I read SubmittingPatches, just to understand I can use git diff to get my patch. > Then I don't search any advanced, good method. > This shows that I am not familiar with git. > I personally suggest having a different branch for each feature/bug you might want to work on and also committing these changes in their respective branches. Why use 'diff' when 'git format-patch' is solely meant to create patches? ;) -- Regards, Karthik Nayak From bino at riseup.net Thu Sep 24 09:07:07 2015 From: bino at riseup.net (Albino B Neto) Date: Thu, 24 Sep 2015 10:07:07 -0300 Subject: Question about "Creating first patch" guide In-Reply-To: References: Message-ID: 2015-09-23 16:22 GMT-03:00 Rob Groner : > What part am I not understanding? Help [0] ? 0 - http://kernelnewbies.org/FirstKernelPatch Albino From wkevils at gmail.com Thu Sep 24 10:25:15 2015 From: wkevils at gmail.com (Kevin Wilson) Date: Thu, 24 Sep 2015 17:25:15 +0300 Subject: getting warning when a method parameter in a kernel module is not used Message-ID: Hi, When a method parameter in a kernel module is not used, we do not get any warning (as opposed to a variable which is not used). Is there any compilation flag which enables getting warning in such a case ? Regards, Kevin From Valdis.Kletnieks at vt.edu Thu Sep 24 11:00:02 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Sep 2015 11:00:02 -0400 Subject: getting warning when a method parameter in a kernel module is not used In-Reply-To: References: Message-ID: <3590.1443106802@turing-police.cc.vt.edu> On Thu, 24 Sep 2015 17:25:15 +0300, Kevin Wilson said: > Hi, > > When a method parameter in a kernel module is not used, we do not get > any warning (as opposed to a variable which is not used). > > Is there any compilation flag which enables getting warning in such a case ? No, and it's unclear that it would be worthwhile. Consider a kernel module that implements a device driver, and the ->ioctl() only implements ioctl(fd,START|STOP|PAUSE|RESUME,/* ignored parameter */). Or any other case where there's a generic struct of pointers to functions that have fixed signatures, but for a given module, we don't need to access one. From prem.it.kumar at gmail.com Thu Sep 24 12:09:23 2015 From: prem.it.kumar at gmail.com (Prem Kumar) Date: Thu, 24 Sep 2015 11:09:23 -0500 Subject: Active Memory never reclaimed please help me understand In-Reply-To: References: Message-ID: Dear Mulyadi, Another observation I wanted to add to this: On some nodes, when the cached memory is high, for example when I look at the atop output, it showed me about 15G cached. Now when I run a simple malloc program to grab all available virtual memory and wait for OOM killer to kill it. To my surprise and obvious in retrospect I see all of my cached memory is now released and amount of free bumps up closer to the total RAM excluding the minimal used by the system services, which is what I would like to see. Now I thought If I use this simple trick it would clear up similar issues on other machines, but this was not true and the big difference was in the amount of cached memory. Another big difference between them are AnonHugePages and AnonPages. On the machine A below AnonHugePages is about 13.9G(13936640 kB), while on machine B below AnonHugePages is about 1.5G(1153024 kB). If I run my simple malloc program to infinitely claim virtual memory on the below two machines: Machine A's run will fail at 9G and no change on MemFree. And machine B's run will fail at 1.7TB (1735372 MB). Note the reclaimed space on Machine-B below after a simple malloc run to glob available virtual memory. This basically tells me that AnonHugePages limit the amount of RAM available in the user space. Now I wonder what is using up the AnonPages on Machine-A and how can I claim that back without a reboot since there is no other user using the machine? Also is there a way I can peek into what process has allocated AnonPages so that I can tell if it is/was user related? Please advise. -regards!! Prem A# free -g total used free shared buffers cached Mem: 23 14 8 0 0 0 -/+ buffers/cache: 14 9 Swap: 0 0 0 B# free -g total used free shared buffers cached Mem: 23 20 3 0 0 14 -/+ buffers/cache: 5 18 Swap: 0 0 0 MachineB after Malloc-run $ free -g total used free shared buffers cached Mem: 23 2 21 0 0 0 -/+ buffers/cache: 1 21 Swap: 0 0 0 On Wed, Sep 23, 2015 at 11:07 AM, Mulyadi Santosa wrote: > > > On Wed, Sep 23, 2015 at 4:47 AM, Prem Kumar > wrote: > >> also wondering if there is a way I can list Active memory map showing me >> what is cached? >> >> -regards. >> >> On Tue, Sep 22, 2015 at 3:08 PM, Prem Kumar >> wrote: >> >>> Dear All, >>> >>> I have done quite a bit of reading on Active memory reported in >>> /proc/meminfo and in short says it is never reclaimed unless absolutely >>> necessary, and it caches the recently used files/pages in memory. Although >>> I fail to understand the consequences that I face here. >>> >>> I have disk-less and swap-less nodes. So all I have to do, is play with >>> the RAM on the box. Issue that brought me here is investigating why after >>> running some applications, used memory is never available for use with any >>> other applications. >>> >>> In other words I cannot run any programs that requests memory more than >>> what is shown as free in the output of free command and MemFree in the >>> output of the cat /proc/meminfo >>> For example if I ran any program that requires more than 6GB on the >>> first node below and more than 1GB on the second node below they fail >>> instantly, and work fine if within the limist of free. There is nothing >>> else running on the system other than system processes/services. >>> >>> total used free shared buffers cached >>> Mem: 23 17 6 0 0 9 >>> -/+ buffers/cache: 8 15 >>> Swap: 0 0 0 >>> >>> total used free shared buffers cached >>> Mem: 23 22 1 0 0 0 >>> -/+ buffers/cache: 21 1 >>> Swap: 0 0 0 >>> >>> Since the applications that ran previously are not running any more >>> "even though they died out of memory because they requested more memory >>> than available", shouldn't the OS see that any memory used previously as >>> useless and can it not reclaim that for use with the next job/program on >>> that machine. >>> >>> On every machine that I have run into this problem the out put of >>> /proc/meminfo shows that Active memory is used up the amount shown in the >>> free command and limits my further runs. >>> >>> This is driving me insane and making me feel stupid knowing that OS is >>> smart enough to handle this, then what am I missing here to understand? >>> Please advise. >>> >>> Appreciate any insight into this. >>> >>> Best Regards, >>> Prem >>> >>> >>> >> >> >> > Dear Prem > > welcome to kernelnewbies :) First of all, please don't do top posting when > replying. Follow like what I and the rest of list member do. > > Btw, looking from the free output, I have a doubt about your statement > that your first application took 6 GB and secondly it took 1 GB. Assuming > your application doesn't thing like memory locking in kernel space, i guess > it takes 20+ GB of RAM. > > So, before we go further, could you re run your applications and use ps or > top to see both the VSIZE and RSS they take ? > > Regarding memory claiming, yes after app is killed (using any ways > possible: ctrl-c, sending kill/term/quit signal, OOM etc), any memory > allocated by this task are freed. It happen on both active and inactive > pages > > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150924/30613ab6/attachment.html From rgroner at RTD.com Thu Sep 24 16:03:53 2015 From: rgroner at RTD.com (Rob Groner) Date: Thu, 24 Sep 2015 20:03:53 +0000 Subject: Which git for developing patch? Message-ID: I am developing a patch for the 8250_pci.c file. Looking at the MAINTAINERS file for 8250 serial, it listed a git repo so I checked that out and figured that was what I should make it from. However, it won't build for me (openssl/bio.h is missing) after a cloning. Am I supposed to use the git repo shown in the MAINTAINERS file (git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git) or some different one for making a patch for a serial file? Thank you. Rob Groner Software Engineer Level II -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150924/4bdedd18/attachment.html From Valdis.Kletnieks at vt.edu Thu Sep 24 16:25:38 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Sep 2015 16:25:38 -0400 Subject: Which git for developing patch? In-Reply-To: References: Message-ID: <30536.1443126338@turing-police.cc.vt.edu> On Thu, 24 Sep 2015 20:03:53 -0000, Rob Groner said: > However, it won't build for me (openssl/bio.h is missing) after a cloning. That's for userspace code. You need to install openssl-devel (or whatever your distro calls the development headers/libraries). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150924/f2577fce/attachment.bin From jim.epost at gmail.com Thu Sep 24 16:25:50 2015 From: jim.epost at gmail.com (Jim Davis) Date: Thu, 24 Sep 2015 13:25:50 -0700 Subject: Which git for developing patch? In-Reply-To: References: Message-ID: On Thu, Sep 24, 2015 at 1:03 PM, Rob Groner wrote: > I am developing a patch for the 8250_pci.c file. Looking at the MAINTAINERS > file for 8250 serial, it listed a git repo so I checked that out and figured > that was what I should make it from. However, it won?t build for me > (openssl/bio.h is missing) after a cloning. Installing something like libssl-dev or openssl-devel, depending on your distro, might fix that. -- Jim From jim.epost at gmail.com Thu Sep 24 16:40:56 2015 From: jim.epost at gmail.com (Jim Davis) Date: Thu, 24 Sep 2015 13:40:56 -0700 Subject: error when make pdfdocs In-Reply-To: References: Message-ID: On Fri, Sep 18, 2015 at 7:35 AM, ??? wrote: > I git clone and git pull the latest linux kernel. > When I make pdfdocs, it reports the following error to me. > But I checked the filesystems.xml:14946, no error found. > > ----------------------------------------------------------------------------------------------- > PDF Documentation/DocBook/filesystems.pdf > Using catalogs: /etc/sgml/catalog > Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#print > Working on: /home/mdl/Repos/linux/Documentation/DocBook/filesystems.xml > openjade:/home/mdl/Repos/linux/Documentation/DocBook/filesystems.xml:14946:16:E: The last time I tried (and failed) to get make pdfdocs to work it seemed to depend in very sensitive ways on the xml converter being used, among other issues, so if it's bombing with openjade you might see if there are alternatives you can try. See https://www.mail-archive.com/kernelnewbies%40kernelnewbies.org/msg14306.html for some of the painful details. -- Jim From mudongliangabcd at gmail.com Fri Sep 25 04:53:51 2015 From: mudongliangabcd at gmail.com (=?UTF-8?B?5oWV5Yas5Lqu?=) Date: Fri, 25 Sep 2015 16:53:51 +0800 Subject: error when make pdfdocs In-Reply-To: References: Message-ID: 2015-09-25 4:40 GMT+08:00 Jim Davis : > On Fri, Sep 18, 2015 at 7:35 AM, ??? wrote: >> I git clone and git pull the latest linux kernel. >> When I make pdfdocs, it reports the following error to me. >> But I checked the filesystems.xml:14946, no error found. >> >> ----------------------------------------------------------------------------------------------- >> PDF Documentation/DocBook/filesystems.pdf >> Using catalogs: /etc/sgml/catalog >> Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#print >> Working on: /home/mdl/Repos/linux/Documentation/DocBook/filesystems.xml >> openjade:/home/mdl/Repos/linux/Documentation/DocBook/filesystems.xml:14946:16:E: > > The last time I tried (and failed) to get make pdfdocs to work it > seemed to depend in very sensitive ways on the xml converter being > used, among other issues, so if it's bombing with openjade you might > see if there are alternatives you can try. See > https://www.mail-archive.com/kernelnewbies%40kernelnewbies.org/msg14306.html > for some of the painful details. I did checkout linux-stable : linux-4.1.y, linux 4.2.y and master. However, I always failed to generate pdf docs. I have given up generating pdf of Document. I can "make mandocs" to generate man pages.It is the same content with pdf. - mudongliang > > -- > Jim From rgroner at rtd.com Fri Sep 25 11:46:29 2015 From: rgroner at rtd.com (Rob Groner) Date: Fri, 25 Sep 2015 11:46:29 -0400 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. Message-ID: <20150925154629.GA2603@kernel-dev> Serial boards made by RTD using the Exar XR17V358 chip rely on the extra capabilities of the Exar-provided driver to allow configuration of the board. When support for the Exar chip was added to the kernel 8250_pci driver, this then prevented easy use of the board by customers for anything other than standard serial usage in RS232 mode. This patch prevents RTD sub-vendor boards from being bound by the 8250_pci driver, if it uses the XR17V358 chip. Other RTD boards using Exar chips are not affected. Signed-off-by Rob Groner --- drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c index 68042dd..89baf7f 100644 --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -359,6 +359,16 @@ static void pci_ni8430_exit(struct pci_dev *dev) iounmap(p); } +/* + * RTD Embedded Technologies, Inc. boards + * Prevent from being bound to 8250 driver + */ +static int +pci_xr17v35x_rtd_probe(struct pci_dev *dev) +{ + return -ENODEV; +} + /* SBS Technologies Inc. PMC-OCTPRO and P-OCTAL cards */ static int sbs_setup(struct serial_private *priv, const struct pciserial_board *board, @@ -2105,6 +2115,8 @@ pci_wch_ch38x_setup(struct serial_private *priv, #define PCI_DEVICE_ID_PERICOM_PI7C9X7954 0x7954 #define PCI_DEVICE_ID_PERICOM_PI7C9X7958 0x7958 +#define PCI_SUBVENDOR_ID_RTD 0x1435 + /* Unknown vendors/cards - this should not be in linux/pci_ids.h */ #define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584 #define PCI_SUBDEVICE_ID_UNKNOWN_0x1588 0x1588 @@ -2608,6 +2620,14 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = { { .vendor = PCI_VENDOR_ID_EXAR, .device = PCI_DEVICE_ID_EXAR_XR17V358, + .subvendor = PCI_SUBVENDOR_ID_RTD, + .subdevice = PCI_ANY_ID, + .probe = pci_xr17v35x_rtd_probe, + .setup = pci_xr17v35x_setup, + }, + { + .vendor = PCI_VENDOR_ID_EXAR, + .device = PCI_DEVICE_ID_EXAR_XR17V358, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, .setup = pci_xr17v35x_setup, -- 1.9.1 From Valdis.Kletnieks at vt.edu Fri Sep 25 12:47:40 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 25 Sep 2015 12:47:40 -0400 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <20150925154629.GA2603@kernel-dev> References: <20150925154629.GA2603@kernel-dev> Message-ID: <67224.1443199660@turing-police.cc.vt.edu> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > Serial boards made by RTD using the Exar XR17V358 chip > rely on the extra capabilities of the Exar-provided driver > to allow configuration of the board. When support for > the Exar chip was added to the kernel 8250_pci driver, this > then prevented easy use of the board by customers for anything > other than standard serial usage in RS232 mode. Was it your intent to also prevent the use of this board in standard serial usage in RS232 mode (which I'd expect is the most common use case)? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150925/c19f0fe7/attachment.bin From greg at kroah.com Fri Sep 25 13:18:51 2015 From: greg at kroah.com (Greg KH) Date: Fri, 25 Sep 2015 10:18:51 -0700 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <20150925154629.GA2603@kernel-dev> References: <20150925154629.GA2603@kernel-dev> Message-ID: <20150925171851.GA548@kroah.com> On Fri, Sep 25, 2015 at 11:46:29AM -0400, Rob Groner wrote: > Serial boards made by RTD using the Exar XR17V358 chip > rely on the extra capabilities of the Exar-provided driver > to allow configuration of the board. When support for > the Exar chip was added to the kernel 8250_pci driver, this > then prevented easy use of the board by customers for anything > other than standard serial usage in RS232 mode. > > This patch prevents RTD sub-vendor boards from being bound > by the 8250_pci driver, if it uses the XR17V358 chip. Other > RTD boards using Exar chips are not affected. > > Signed-off-by Rob Groner > --- > drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c > index 68042dd..89baf7f 100644 > --- a/drivers/tty/serial/8250/8250_pci.c > +++ b/drivers/tty/serial/8250/8250_pci.c > @@ -359,6 +359,16 @@ static void pci_ni8430_exit(struct pci_dev *dev) > iounmap(p); > } > > +/* > + * RTD Embedded Technologies, Inc. boards > + * Prevent from being bound to 8250 driver > + */ > +static int > +pci_xr17v35x_rtd_probe(struct pci_dev *dev) > +{ > + return -ENODEV; > +} > + > /* SBS Technologies Inc. PMC-OCTPRO and P-OCTAL cards */ > static int > sbs_setup(struct serial_private *priv, const struct pciserial_board *board, > @@ -2105,6 +2115,8 @@ pci_wch_ch38x_setup(struct serial_private *priv, > #define PCI_DEVICE_ID_PERICOM_PI7C9X7954 0x7954 > #define PCI_DEVICE_ID_PERICOM_PI7C9X7958 0x7958 > > +#define PCI_SUBVENDOR_ID_RTD 0x1435 > + > /* Unknown vendors/cards - this should not be in linux/pci_ids.h */ > #define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584 > #define PCI_SUBDEVICE_ID_UNKNOWN_0x1588 0x1588 > @@ -2608,6 +2620,14 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = { > { > .vendor = PCI_VENDOR_ID_EXAR, > .device = PCI_DEVICE_ID_EXAR_XR17V358, > + .subvendor = PCI_SUBVENDOR_ID_RTD, > + .subdevice = PCI_ANY_ID, > + .probe = pci_xr17v35x_rtd_probe, > + .setup = pci_xr17v35x_setup, Why do you need the .setup callback if you are just not wanting to bind to this driver? thanks, greg k-h From rgroner at RTD.com Fri Sep 25 13:30:14 2015 From: rgroner at RTD.com (Rob Groner) Date: Fri, 25 Sep 2015 17:30:14 +0000 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <20150925171851.GA548@kroah.com> References: <20150925154629.GA2603@kernel-dev> <20150925171851.GA548@kroah.com> Message-ID: > -----Original Message----- > From: Greg KH [mailto:greg at kroah.com] > Sent: Friday, September 25, 2015 1:19 PM > To: Rob Groner > Cc: kernelnewbies at kernelnewbies.org > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > On Fri, Sep 25, 2015 at 11:46:29AM -0400, Rob Groner wrote: > > Serial boards made by RTD using the Exar XR17V358 chip rely on the > > extra capabilities of the Exar-provided driver to allow configuration > > of the board. When support for the Exar chip was added to the kernel > > 8250_pci driver, this then prevented easy use of the board by > > customers for anything other than standard serial usage in RS232 mode. > > > > This patch prevents RTD sub-vendor boards from being bound by the > > 8250_pci driver, if it uses the XR17V358 chip. Other RTD boards using > > Exar chips are not affected. > > > > Signed-off-by Rob Groner > > --- > > drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++ > > 1 file changed, 20 insertions(+) > > > > diff --git a/drivers/tty/serial/8250/8250_pci.c > > b/drivers/tty/serial/8250/8250_pci.c > > index 68042dd..89baf7f 100644 > > --- a/drivers/tty/serial/8250/8250_pci.c > > +++ b/drivers/tty/serial/8250/8250_pci.c > > @@ -359,6 +359,16 @@ static void pci_ni8430_exit(struct pci_dev *dev) > > iounmap(p); > > } > > > > +/* > > + * RTD Embedded Technologies, Inc. boards > > + * Prevent from being bound to 8250 driver */ static int > > +pci_xr17v35x_rtd_probe(struct pci_dev *dev) { > > + return -ENODEV; > > +} > > + > > /* SBS Technologies Inc. PMC-OCTPRO and P-OCTAL cards */ static int > > sbs_setup(struct serial_private *priv, const struct pciserial_board > > *board, @@ -2105,6 +2115,8 @@ pci_wch_ch38x_setup(struct > serial_private *priv, > > #define PCI_DEVICE_ID_PERICOM_PI7C9X7954 0x7954 > > #define PCI_DEVICE_ID_PERICOM_PI7C9X7958 0x7958 > > > > +#define PCI_SUBVENDOR_ID_RTD 0x1435 > > + > > /* Unknown vendors/cards - this should not be in linux/pci_ids.h */ > > #define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584 > > #define PCI_SUBDEVICE_ID_UNKNOWN_0x1588 0x1588 > > @@ -2608,6 +2620,14 @@ static struct pci_serial_quirk pci_serial_quirks[] > __refdata = { > > { > > .vendor = PCI_VENDOR_ID_EXAR, > > .device = PCI_DEVICE_ID_EXAR_XR17V358, > > + .subvendor = PCI_SUBVENDOR_ID_RTD, > > + .subdevice = PCI_ANY_ID, > > + .probe = pci_xr17v35x_rtd_probe, > > + .setup = pci_xr17v35x_setup, > > Why do you need the .setup callback if you are just not wanting to bind to > this driver? > You're right, that doesn't need to be set. Rob Groner From rgroner at RTD.com Fri Sep 25 13:37:03 2015 From: rgroner at RTD.com (Rob Groner) Date: Fri, 25 Sep 2015 17:37:03 +0000 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <67224.1443199660@turing-police.cc.vt.edu> References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> Message-ID: > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Friday, September 25, 2015 12:48 PM > To: Rob Groner > Cc: kernelnewbies at kernelnewbies.org > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > Serial boards made by RTD using the Exar XR17V358 chip rely on the > > extra capabilities of the Exar-provided driver to allow configuration > > of the board. When support for the Exar chip was added to the kernel > > 8250_pci driver, this then prevented easy use of the board by > > customers for anything other than standard serial usage in RS232 mode. > > Was it your intent to also prevent the use of this board in standard serial > usage in RS232 mode (which I'd expect is the most common use case)? That is a byproduct of giving the non-average user the ability to reconfigure their board. This will basically move us back to pre-3.8, where the customer would simply have to insmod the provided Exar driver. The small inconvenience to that more common user seems (to us in Tech Support) outweighed by the much greater inconvenience to the user who wants to reconfigure. Rob Groner From greg at kroah.com Fri Sep 25 14:37:29 2015 From: greg at kroah.com (Greg KH) Date: Fri, 25 Sep 2015 11:37:29 -0700 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> Message-ID: <20150925183729.GA3269@kroah.com> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > > -----Original Message----- > > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > Sent: Friday, September 25, 2015 12:48 PM > > To: Rob Groner > > Cc: kernelnewbies at kernelnewbies.org > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > > Serial boards made by RTD using the Exar XR17V358 chip rely on the > > > extra capabilities of the Exar-provided driver to allow configuration > > > of the board. When support for the Exar chip was added to the kernel > > > 8250_pci driver, this then prevented easy use of the board by > > > customers for anything other than standard serial usage in RS232 mode. > > > > Was it your intent to also prevent the use of this board in standard serial > > usage in RS232 mode (which I'd expect is the most common use case)? > > That is a byproduct of giving the non-average user the ability to > reconfigure their board. This will basically move us back to pre-3.8, > where the customer would simply have to insmod the provided Exar > driver. The small inconvenience to that more common user seems (to us > in Tech Support) outweighed by the much greater inconvenience to the > user who wants to reconfigure. Where is the exar driver, in the kernel already? confused, greg k-h From greg at kroah.com Fri Sep 25 15:14:12 2015 From: greg at kroah.com (Greg KH) Date: Fri, 25 Sep 2015 12:14:12 -0700 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> <20150925183729.GA3269@kroah.com> Message-ID: <20150925191412.GA4248@kroah.com> On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: > > -----Original Message----- > > From: Greg KH [mailto:greg at kroah.com] > > Sent: Friday, September 25, 2015 2:37 PM > > To: Rob Groner > > Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > > > > > > -----Original Message----- > > > > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > > > Sent: Friday, September 25, 2015 12:48 PM > > > > To: Rob Groner > > > > Cc: kernelnewbies at kernelnewbies.org > > > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > > > > > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > > > > Serial boards made by RTD using the Exar XR17V358 chip rely on the > > > > > extra capabilities of the Exar-provided driver to allow > > > > > configuration of the board. When support for the Exar chip was > > > > > added to the kernel 8250_pci driver, this then prevented easy use > > > > > of the board by customers for anything other than standard serial usage > > in RS232 mode. > > > > > > > > Was it your intent to also prevent the use of this board in standard > > > > serial usage in RS232 mode (which I'd expect is the most common use > > case)? > > > > > > That is a byproduct of giving the non-average user the ability to > > > reconfigure their board. This will basically move us back to pre-3.8, > > > where the customer would simply have to insmod the provided Exar > > > driver. The small inconvenience to that more common user seems (to us > > > in Tech Support) outweighed by the much greater inconvenience to the > > > user who wants to reconfigure. > > > > Where is the exar driver, in the kernel already? > > > > confused, > > I'm sorry for the confusion. Let me summup: > > We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). > > Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. > > Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. > > The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. Can you point me at the driver and I'll be glad to add it to the kernel so that the proper driver will bind to the device and this will not be an issue for users? thanks, greg k-h From rgroner at RTD.com Fri Sep 25 15:08:32 2015 From: rgroner at RTD.com (Rob Groner) Date: Fri, 25 Sep 2015 19:08:32 +0000 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <20150925183729.GA3269@kroah.com> References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> <20150925183729.GA3269@kroah.com> Message-ID: > -----Original Message----- > From: Greg KH [mailto:greg at kroah.com] > Sent: Friday, September 25, 2015 2:37 PM > To: Rob Groner > Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > > > > -----Original Message----- > > > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > > Sent: Friday, September 25, 2015 12:48 PM > > > To: Rob Groner > > > Cc: kernelnewbies at kernelnewbies.org > > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > > > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > > > Serial boards made by RTD using the Exar XR17V358 chip rely on the > > > > extra capabilities of the Exar-provided driver to allow > > > > configuration of the board. When support for the Exar chip was > > > > added to the kernel 8250_pci driver, this then prevented easy use > > > > of the board by customers for anything other than standard serial usage > in RS232 mode. > > > > > > Was it your intent to also prevent the use of this board in standard > > > serial usage in RS232 mode (which I'd expect is the most common use > case)? > > > > That is a byproduct of giving the non-average user the ability to > > reconfigure their board. This will basically move us back to pre-3.8, > > where the customer would simply have to insmod the provided Exar > > driver. The small inconvenience to that more common user seems (to us > > in Tech Support) outweighed by the much greater inconvenience to the > > user who wants to reconfigure. > > Where is the exar driver, in the kernel already? > > confused, I'm sorry for the confusion. Let me summup: We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. Thank you, Rob Groner From rgroner at rtd.com Fri Sep 25 15:21:46 2015 From: rgroner at rtd.com (Rob Groner) Date: Fri, 25 Sep 2015 15:21:46 -0400 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <20150925191412.GA4248@kroah.com> References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> <20150925183729.GA3269@kroah.com> <20150925191412.GA4248@kroah.com> Message-ID: <56059ECA.1070803@rtd.com> On 09/25/2015 03:14 PM, Greg KH wrote: > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: >>> -----Original Message----- >>> From: Greg KH [mailto:greg at kroah.com] >>> Sent: Friday, September 25, 2015 2:37 PM >>> To: Rob Groner >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. >>> >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: >>>>> -----Original Message----- >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >>>>> Sent: Friday, September 25, 2015 12:48 PM >>>>> To: Rob Groner >>>>> Cc: kernelnewbies at kernelnewbies.org >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. >>>>> >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the >>>>>> extra capabilities of the Exar-provided driver to allow >>>>>> configuration of the board. When support for the Exar chip was >>>>>> added to the kernel 8250_pci driver, this then prevented easy use >>>>>> of the board by customers for anything other than standard serial usage >>> in RS232 mode. >>>>> Was it your intent to also prevent the use of this board in standard >>>>> serial usage in RS232 mode (which I'd expect is the most common use >>> case)? >>>> That is a byproduct of giving the non-average user the ability to >>>> reconfigure their board. This will basically move us back to pre-3.8, >>>> where the customer would simply have to insmod the provided Exar >>>> driver. The small inconvenience to that more common user seems (to us >>>> in Tech Support) outweighed by the much greater inconvenience to the >>>> user who wants to reconfigure. >>> Where is the exar driver, in the kernel already? >>> >>> confused, >> I'm sorry for the confusion. Let me summup: >> >> We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). >> >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. >> >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. >> >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. > Can you point me at the driver and I'll be glad to add it to the kernel > so that the proper driver will bind to the device and this will > not be an issue for users? > > thanks, > > greg k-h That would be WONDERFUL. https://www.exar.com/common/content/document.ashx?id=20121 Thank you, Rob Groner From greg at kroah.com Fri Sep 25 20:45:52 2015 From: greg at kroah.com (Greg KH) Date: Fri, 25 Sep 2015 17:45:52 -0700 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <56059ECA.1070803@rtd.com> References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> <20150925183729.GA3269@kroah.com> <20150925191412.GA4248@kroah.com> <56059ECA.1070803@rtd.com> Message-ID: <20150926004552.GB10629@kroah.com> On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote: > > On 09/25/2015 03:14 PM, Greg KH wrote: > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: > >>> -----Original Message----- > >>> From: Greg KH [mailto:greg at kroah.com] > >>> Sent: Friday, September 25, 2015 2:37 PM > >>> To: Rob Groner > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > >>> > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > >>>>> -----Original Message----- > >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > >>>>> Sent: Friday, September 25, 2015 12:48 PM > >>>>> To: Rob Groner > >>>>> Cc: kernelnewbies at kernelnewbies.org > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > >>>>> > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the > >>>>>> extra capabilities of the Exar-provided driver to allow > >>>>>> configuration of the board. When support for the Exar chip was > >>>>>> added to the kernel 8250_pci driver, this then prevented easy use > >>>>>> of the board by customers for anything other than standard serial usage > >>> in RS232 mode. > >>>>> Was it your intent to also prevent the use of this board in standard > >>>>> serial usage in RS232 mode (which I'd expect is the most common use > >>> case)? > >>>> That is a byproduct of giving the non-average user the ability to > >>>> reconfigure their board. This will basically move us back to pre-3.8, > >>>> where the customer would simply have to insmod the provided Exar > >>>> driver. The small inconvenience to that more common user seems (to us > >>>> in Tech Support) outweighed by the much greater inconvenience to the > >>>> user who wants to reconfigure. > >>> Where is the exar driver, in the kernel already? > >>> > >>> confused, > >> I'm sorry for the confusion. Let me summup: > >> > >> We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). > >> > >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. > >> > >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. > >> > >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. > > Can you point me at the driver and I'll be glad to add it to the kernel > > so that the proper driver will bind to the device and this will > > not be an issue for users? > > > > thanks, > > > > greg k-h > That would be WONDERFUL. > > https://www.exar.com/common/content/document.ashx?id=20121 At first glance, the driver looks pretty good. Let me do a bit of cleanup on it for mostly coding style changes and removing some old api support and see what the patch is. Would you mind testing it if I make a patch, given that I don't have the hardware and you do? :) thanks, greg k-h From vibnwis at gmail.com Sat Sep 26 10:16:11 2015 From: vibnwis at gmail.com (vibnwis) Date: Sun, 27 Sep 2015 03:16:11 +1300 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT Message-ID: Hi all, I need to unset default value of LOCKDEP(=y) and TRACE_IRQFLAGS_SUPPORT(=y) to both "n". Having asked around and had tried for at least 3 days, seriously I still couldn't get both items configured as "n" Perhaps someone can help me on this item first. For instance, Symbol TRACE_IRQFLAGS description below, to set it, it will need the logics below: PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y] && STACKTRACE_SUPPORT [=y] && LOCKDEP_SUPPORT [=y] || IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE To unset it, I could either set DEBUG_KERNEL=n or set TRACING_SUPPORT=n (or FTRACE=n). However, having set it, yet I don't see symbol TRACE_IRQFLAGS is unset. Anything wrong of my interpretation of the logics above? Copied from "/" type TRACE_IRQFLAGS in menuconfig ? Symbol: TRACE_IRQFLAGS [=y] ? ? Type : boolean ? ? Defined at lib/Kconfig.debug:1047 ? ? Selected by: PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y] && STACKTRACE_SUPPORT [=y] && LOCKDEP_SUPPORT [=y] || IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE [=n ? ? ? ? ? ? Symbol: TRACE_IRQFLAGS_SUPPORT [=y] ? ? Type : boolean ? ? Defined at arch/arm/Kconfig:174 Appreciate any comments. Thanks in advance. Lim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/7370de28/attachment-0001.html From Valdis.Kletnieks at vt.edu Sat Sep 26 12:03:20 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 26 Sep 2015 12:03:20 -0400 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: References: Message-ID: <58262.1443283400@turing-police.cc.vt.edu> On Sun, 27 Sep 2015 03:16:11 +1300, vibnwis said: > To unset it, I could either set DEBUG_KERNEL=n or set TRACING_SUPPORT=n (or > FTRACE=n). However, having set it, yet I don't see symbol TRACE_IRQFLAGS > is unset. Refresher course in Boolean logic. If there's an OR in there, you need to set *both* to =n, not just one or the other. The bigger question is: *WHY* do you think you need to unset the value of these two things? What problem are you trying to solve by turning them off? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150926/766ed3bb/attachment.bin From choon-zone.teoh at vie.com.my Tue Sep 22 11:49:18 2015 From: choon-zone.teoh at vie.com.my (Teoh Choon Zone) Date: Tue, 22 Sep 2015 23:49:18 +0800 Subject: Unable to get stmmac driver of Altera Cyclone V to support MTU9000 Message-ID: According to the technical reference manual, Cyclone V does support jumbo frame up to 9.6KB, which I read as it will support MTU up to 9000. But I couldn't get it to work properly with MTU9000. I define working as in I can ping with a packet size of 9000 bytes, e.g "ping -s 9000", the ping process just won't start when I set the MTU anything larger then 8144. FYI, tx is running in store-and-forward mode and rx is running in threshold mode. Anyone know how I can tweak the stmmac driver to support MTU9000? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150922/923bdbb9/attachment.html From hachti at hachti.de Wed Sep 23 20:19:50 2015 From: hachti at hachti.de (Philipp Hachtmann) Date: Thu, 24 Sep 2015 02:19:50 +0200 Subject: Adding GPIO/SPI/I2C functionality to FTDI driver In-Reply-To: <20150923154058.GB24018@hephaistos.amsuess.com> References: <20150922162847.GC16144@hephaistos.amsuess.com> <20150922190203.GA31705@kroah.com> <20150923154058.GB24018@hephaistos.amsuess.com> Message-ID: <560341A6.7070502@hachti.de> > Stefan and Philipp, has any of your patch sets received updates in the > meantime that have not been sent to the mailing list? No, sorry. They did not even want to have my syncmode patch. For me the biggest problem is that the ftdi_sio driver is buried in that generic tty/usb-tty stuff which I don't have fully understood yet (and not found the time to really investigate) Kind regards Philipp From Valdis.Kletnieks at vt.edu Sat Sep 26 16:07:43 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 26 Sep 2015 16:07:43 -0400 Subject: Unable to get stmmac driver of Altera Cyclone V to support MTU9000 In-Reply-To: References: Message-ID: <73853.1443298063@turing-police.cc.vt.edu> On Tue, 22 Sep 2015 23:49:18 +0800, Teoh Choon Zone said: > I define working as in I can ping with a packet size of 9000 bytes, e.g > "ping -s 9000", the ping process just won't start when I set the MTU > anything larger then 8144. 1) When you set the MTU, does it show up as set if you do 'ifconfig eth2' or whatever it is?> 2) In what way *exactly* does the ping "just won't start"? Any error messages? If you run 'strace ping' where does it look like it all goes astray? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150926/827332af/attachment.bin From shraddha.6596 at gmail.com Sat Sep 26 16:22:48 2015 From: shraddha.6596 at gmail.com (Shraddha Barke) Date: Sun, 27 Sep 2015 01:52:48 +0530 Subject: Avoid Camelcase Message-ID: What should be done about the "Avoid Camelcase" CHECK detected by checkpatch.pl for patches ? Thanks, Shraddha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/accdfa82/attachment.html From greg at kroah.com Sat Sep 26 16:31:03 2015 From: greg at kroah.com (Greg KH) Date: Sat, 26 Sep 2015 13:31:03 -0700 Subject: Avoid Camelcase In-Reply-To: References: Message-ID: <20150926203103.GA17373@kroah.com> On Sun, Sep 27, 2015 at 01:52:48AM +0530, Shraddha Barke wrote: > What should be done about the "Avoid Camelcase" CHECK detected by checkpatch.pl > for patches ? Fix up the code to not use CamelCase :) See https://en.wikipedia.org/wiki/CamelCase for what this is, and read the CodingStyle kernel file for what to use instead. hope this helps, greg k-h From vibnwis at gmail.com Sat Sep 26 19:06:49 2015 From: vibnwis at gmail.com (vibnwis) Date: Sun, 27 Sep 2015 12:06:49 +1300 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: <58262.1443283400@turing-police.cc.vt.edu> References: <58262.1443283400@turing-police.cc.vt.edu> Message-ID: To unset TRACE_IRQFLAGS PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y] && STACKTRACE_SUPPORT [=y] && LOCKDEP_SUPPORT [=y] } || IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE Let's say L1= PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y] L2 = IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE Setting DEBUG_KERNEL->n will unset L1 [=0] and setting IRQSOFF_TRACER [=y] || TRACING_SUPPORT [=n] || FTRACE [= n] will unset L2 [=0] L1 || L2 => TRACE_IRQFLAGS ->0 This is my boolean logics. Any comments? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/61f1665e/attachment.html From Valdis.Kletnieks at vt.edu Sat Sep 26 20:54:47 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 26 Sep 2015 20:54:47 -0400 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: References: <58262.1443283400@turing-police.cc.vt.edu> Message-ID: <94398.1443315287@turing-police.cc.vt.edu> On Sun, 27 Sep 2015 12:06:49 +1300, vibnwis said: > Setting DEBUG_KERNEL->n will unset L1 [=0] > and And. Right. > setting IRQSOFF_TRACER [=y] || TRACING_SUPPORT [=n] || FTRACE [= n] will > unset L2 [=0] In your first post, you had implied that you had tried doing one or the other, not both. Why are you trying to unset TRACE_IRQFLAGS, anyhow? Does it cause a problem for you? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150926/f38cc717/attachment.bin From vibnwis at gmail.com Sat Sep 26 21:09:07 2015 From: vibnwis at gmail.com (vibnwis) Date: Sun, 27 Sep 2015 14:09:07 +1300 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: <94398.1443315287@turing-police.cc.vt.edu> References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> Message-ID: > > > In your first post, you had implied that you had tried doing one or > the other, not both. > My mistake. Apologies for the confusion > > Why are you trying to unset TRACE_IRQFLAGS, anyhow? Does it cause a problem > for you? > Long story. I need to incorporate Xenoma, the open sournce real-time patch of Linux. I could not get it work and the assistance I got suggested that the symbols would need to unset. With it enabled would cause the Xenomai to fail. However, I had made so much efforts trying to get it unset, yet no luck. I am a new newbie, with some experience, but not having the substantial knowledge. For instance, I do know how to run menuconfig, but for this case I don't know if I am wrong or inadequate knowledge for solving that problems. However, a simple logic I applied before applying the logics I presented above, was simply, disabled all symbols in menuconfig, and had the .config opened in an editor. Any changes on the .config would trigger reload contents in the editor. Having disabled all symbols, yet I did not see any changes in terms of the two symbols. Strange right? Can the two symbols ever able to unset? Anyone has tried that before? Appreciate any comments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/dfcdeb0b/attachment-0001.html From Valdis.Kletnieks at vt.edu Sat Sep 26 21:53:20 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 26 Sep 2015 21:53:20 -0400 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> Message-ID: <98526.1443318800@turing-police.cc.vt.edu> On Sun, 27 Sep 2015 14:09:07 +1300, vibnwis said: > Long story. I need to incorporate Xenoma, the open sournce real-time patch > of Linux. First thing to do is to verify that you *really* need the patch at all. 95% of people who think they need special real-time patches don't actually need them. Linux already has fairly good soft real-time support, which is good for most stuff. > . I could not get it work and the assistance I got suggested that the symbols > would need to unset So what *exactly* happened when it failed to work? The patch didn't apply? The kernel wouldn't compile? won't boot? Boots but no realtime? Any error messages? What suggested that TRACE_IRQFLAGS would make a difference? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150926/3f6e3307/attachment.bin From vibnwis at gmail.com Sat Sep 26 22:08:57 2015 From: vibnwis at gmail.com (vibnwis) Date: Sun, 27 Sep 2015 15:08:57 +1300 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: <98526.1443318800@turing-police.cc.vt.edu> References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> <98526.1443318800@turing-police.cc.vt.edu> Message-ID: So what *exactly* happened when it failed to work? The patch didn't apply? The kernel wouldn't compile? won't boot? Boots but no realtime? Any error messages? What suggested that TRACE_IRQFLAGS would make a difference? Xenomai patching succeeded but when running one of is test apps, "latency" showing > > > > > > >> > 0"000.000| BUG in low_init(): [main] mlockall: Cannot allocate > > > > memory And the mailing list member suggested the following "The problematic option is CONFIG_TRACE_IRQFLAGS, not > > CONFIG_CONTEXT_TRACKING, and you have it enabled, since without it, > > you would not be able to enable CONFIG_LOCKDEP. Please disable > > CONFIG_TRACE_IRQFLAGS. You will need to disable all the options > > depending on that option, such as CONFIG_LOCKDEP." First thing to do is to verify that you *really* need the patch at all. 95% of people who think they need special real-time patches don't actually need them. Linux already has fairly good soft real-time support, which is good for most stuff. Experimenting for automation and for educational purposes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/78a88552/attachment.html From vibnwis at gmail.com Sun Sep 27 02:00:44 2015 From: vibnwis at gmail.com (vibnwis) Date: Sun, 27 Sep 2015 19:00:44 +1300 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> <98526.1443318800@turing-police.cc.vt.edu> Message-ID: Okie, I think one of the reason I am not able to unset CONFIG_TRACE_IRQFLAGS and CONFIG_LOCKDEP is, "kernel debugging" in menuconfig is being greyed-out. Would anyone please share some knowledge in getting the DEBUG_KERNEL disabled. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/9c734779/attachment.html From Valdis.Kletnieks at vt.edu Sun Sep 27 10:52:30 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Sep 2015 10:52:30 -0400 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> <98526.1443318800@turing-police.cc.vt.edu> Message-ID: <147623.1443365550@turing-police.cc.vt.edu> On Sun, 27 Sep 2015 15:08:57 +1300, vibnwis said: > Xenomai patching succeeded but when running one of is test apps, "latency" > showing > > > > > > > >> > 0"000.000| BUG in low_init(): [main] mlockall: Cannot > allocate > > > > > memory > And the mailing list member suggested the following Is that in dmesg, or output from the test program? Is there more output, or is that it? Personally, if TRACE_IRQFLAGS is causing an issue with mlock, I'd suspect a very buggy patch indeed. If it can't tolerate a trace function being turned on, there;s probably some very questionable coding in there..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/1ebac361/attachment.bin From Valdis.Kletnieks at vt.edu Sun Sep 27 10:56:31 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Sep 2015 10:56:31 -0400 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> <98526.1443318800@turing-police.cc.vt.edu> Message-ID: <147862.1443365791@turing-police.cc.vt.edu> On Sun, 27 Sep 2015 19:00:44 +1300, vibnwis said: > Would anyone please share some knowledge in getting the DEBUG_KERNEL > disabled. Same way you disable anything ese.... 'make menuconfig', and hit / and enter DEBUG_KERNEL. Turn off whatever is causing it to be set. Recursively apply until done. Though to be honest, I don't think it will do you much good until you figure out *why* DEBUG_KERNEL needs to be off.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/94fd3695/attachment.bin From Valdis.Kletnieks at vt.edu Sun Sep 27 18:22:12 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Sep 2015 18:22:12 -0400 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> <98526.1443318800@turing-police.cc.vt.edu> <147623.1443365550@turing-police.cc.vt.edu> Message-ID: <179284.1443392532@turing-police.cc.vt.edu> On Mon, 28 Sep 2015 09:58:21 +1300, vibnwis said: > Thanks for sharing. Being a newbie, I would have to have some sort faith > until it is proven otherwise. Hence, I am tasked to get the TRACE_IRQFLAGS > turn off. Once, I have got it done and the results would tell us if the > patches were fine or not. The fact they may work with a specific option turned off is *not* proof that they are "fine" - merely that it doesn't trip over the problem. It's kind of like being told your car's brakes are possibly defective and you should avoid heavy braking - and your response is to choose a path home that doesn't involve any heavy braking and then saying your brakes are "fine". It's even more worrisome that people are suggesting "just turn it off" without being able to point at a reason *why* it needs to be turned off. Which gives you more confidence: NVidia's modules won't work on a kernel defined with LOCKDEP enables, we don't know why, so just turn it off.. versus NVidia's modules won't work on a LOCKDEP kernel because with that defined, the locking functions called by the module are redirected to debugging LOCKDEP variants that are EXPORT_SYMBOL_GPL. When you try to modprobe it, the _GPL variants aren't available to the NVidia module due to its licensing, so you get 'unresolved symbol' errors. This information should be enough for you to figure out how to fix your personal copy and make it work (but not to make that copy redistributable). See the difference? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/1c7d2ea1/attachment.bin From Valdis.Kletnieks at vt.edu Sun Sep 27 20:17:30 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Sep 2015 20:17:30 -0400 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> <98526.1443318800@turing-police.cc.vt.edu> <147623.1443365550@turing-police.cc.vt.edu> <179284.1443392532@turing-police.cc.vt.edu> Message-ID: <186829.1443399450@turing-police.cc.vt.edu> On Mon, 28 Sep 2015 11:42:34 +1300, vibnwis said: > > See the difference? > The kernel I work is for Pandaboard. Hence NVidia will not in the picture. The point is that one explanation gives a lot more confidence and understanding than the other. I'll let you figure out for yourself which the suggestions to turn off TRACE_IRQFLAGS sounds more like.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/eae5e053/attachment.bin From choon-zone.teoh at vie.com.my Sun Sep 27 21:47:43 2015 From: choon-zone.teoh at vie.com.my (Teoh Choon Zone) Date: Mon, 28 Sep 2015 09:47:43 +0800 Subject: Unable to get stmmac driver of Altera Cyclone V to support MTU9000 In-Reply-To: <73853.1443298063@turing-police.cc.vt.edu> References: <73853.1443298063@turing-police.cc.vt.edu> Message-ID: > When you set the MTU, does it show up as set if you do 'ifconfig eth2' > or whatever it is? I can see it being set successfully. > In what way *exactly* does the ping "just won't start"? Any error > messages? If you run 'strace ping' where does it look like it all goes > astray? When I "ping 192.168.128.99 -s 9000", what I can only see is "PING 192.168.128.99 (192.168.128.99) 9000(9028) bytes of data.", nothing else. But when I "ping 192.168.128.99 -s 8144", I can get "8152 bytes from 192.168.128.99: icmp_req=2 ttl=64 time=1.05 ms" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/5af82570/attachment.html From pranjas at gmail.com Sun Sep 27 22:03:55 2015 From: pranjas at gmail.com (Pranay Srivastava) Date: Mon, 28 Sep 2015 07:33:55 +0530 Subject: Unable to get stmmac driver of Altera Cyclone V to support MTU9000 In-Reply-To: References: <73853.1443298063@turing-police.cc.vt.edu> Message-ID: Hi Teoh, On Mon, Sep 28, 2015 at 7:17 AM, Teoh Choon Zone wrote: >> When you set the MTU, does it show up as set if you do 'ifconfig eth2' >> or whatever it is? > I can see it being set successfully. > > >> In what way *exactly* does the ping "just won't start"? Any error >> messages? If you run 'strace ping' where does it look like it all goes >> astray? > When I "ping 192.168.128.99 -s 9000", what I can only see is "PING > 192.168.128.99 (192.168.128.99) 9000(9028) bytes of data.", nothing else. Have you tried the above with 8972 to instead of 9000. > But when I "ping 192.168.128.99 -s 8144", I can get "8152 bytes from > 192.168.128.99: icmp_req=2 ttl=64 time=1.05 ms" > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- ---P.K.S From vibnwis at gmail.com Sun Sep 27 16:58:21 2015 From: vibnwis at gmail.com (vibnwis) Date: Mon, 28 Sep 2015 09:58:21 +1300 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: <147623.1443365550@turing-police.cc.vt.edu> References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> <98526.1443318800@turing-police.cc.vt.edu> <147623.1443365550@turing-police.cc.vt.edu> Message-ID: On 28 September 2015 at 03:52, wrote: > On Sun, 27 Sep 2015 15:08:57 +1300, vibnwis said: > > > Xenomai patching succeeded but when running one of is test apps, > "latency" > > showing > > > > > > > > >> > 0"000.000| BUG in low_init(): [main] mlockall: Cannot > > allocate > > > > > > memory > > And the mailing list member suggested the following > > Is that in dmesg, or output from the test program? > Is there more output, or is that it? > The above error message is from the output of the test app, "latency" > > Personally, if TRACE_IRQFLAGS is causing an issue with mlock, I'd suspect > a very buggy patch indeed. If it can't tolerate a trace function being > turned on, there;s probably some very questionable coding in there..... > Thanks for sharing. Being a newbie, I would have to have some sort faith until it is proven otherwise. Hence, I am tasked to get the TRACE_IRQFLAGS turn off. Once, I have got it done and the results would tell us if the patches were fine or not. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/e5accb85/attachment.html From choon-zone.teoh at vie.com.my Sun Sep 27 22:14:47 2015 From: choon-zone.teoh at vie.com.my (Teoh Choon Zone) Date: Mon, 28 Sep 2015 10:14:47 +0800 Subject: Unable to get stmmac driver of Altera Cyclone V to support MTU9000 In-Reply-To: References: <73853.1443298063@turing-police.cc.vt.edu> Message-ID: > Have you tried the above with 8972 to instead of 9000. Yes, but nothing above 8144 works. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/72c9644d/attachment.html From vibnwis at gmail.com Sun Sep 27 18:42:34 2015 From: vibnwis at gmail.com (vibnwis) Date: Mon, 28 Sep 2015 11:42:34 +1300 Subject: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT In-Reply-To: <179284.1443392532@turing-police.cc.vt.edu> References: <58262.1443283400@turing-police.cc.vt.edu> <94398.1443315287@turing-police.cc.vt.edu> <98526.1443318800@turing-police.cc.vt.edu> <147623.1443365550@turing-police.cc.vt.edu> <179284.1443392532@turing-police.cc.vt.edu> Message-ID: The fact they may work with a specific option turned off is *not* proof > that they are "fine" - merely that it doesn't trip over the problem. It's > kind of like being told your car's brakes are possibly defective and you > should avoid heavy braking - and your response is to choose a path home > that > doesn't involve any heavy braking and then saying your brakes are "fine". > > It's even more worrisome that people are suggesting "just turn it off" > without being able to point at a reason *why* it needs to be turned off. > > Which gives you more confidence: > Totally understand your points. However, Xenomai has been in many distribution, like Ubuntu. it is simply a kind of interest to get something to work. I had been an embedded engineer for many years, ( but never dealt with Linux or Linux kernel). There are many Realtime OSes out there, but costs a bomb and for hobbyist like me would not spend money buying it. Having said that, there are a few open realtime patches that make LInux to be realtime, deterministic. To what level, I am going to test it out. That is my intention. If you are interested, please have a look at www.xenomia.org. It has nothing to do with confidence, it is pure experiment, hobby. However, I do appreciate sharing your opinions. When times, I will have the answers. > NVidia's modules won't work on a kernel defined with LOCKDEP enables, we > don't know why, so just turn it off.. > > versus > > NVidia's modules won't work on a LOCKDEP kernel because with that defined, > the locking functions called by the module are redirected to debugging > LOCKDEP > variants that are EXPORT_SYMBOL_GPL. When you try to modprobe it, the _GPL > variants aren't available to the NVidia module due to its licensing, so you > get 'unresolved symbol' errors. This information should be enough for you > to > figure out how to fix your personal copy and make it work (but not to make > that copy redistributable). > > See the difference? > The kernel I work is for Pandaboard. Hence NVidia will not in the picture. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/1ec24c30/attachment-0001.html From Valdis.Kletnieks at vt.edu Sun Sep 27 23:39:25 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Sep 2015 23:39:25 -0400 Subject: Unable to get stmmac driver of Altera Cyclone V to support MTU9000 In-Reply-To: References: <73853.1443298063@turing-police.cc.vt.edu> Message-ID: <200286.1443411565@turing-police.cc.vt.edu> On Mon, 28 Sep 2015 10:14:47 +0800, Teoh Choon Zone said: > > Have you tried the above with 8972 to instead of 9000. > Yes, but nothing above 8144 works. It's possible it's a defective design, and is crippled so it can manage 8144 but not the 9000 most chipsets can do. The fact that 8144 works is proof the chipset *does* have a concept of jumbograms - but there's been a *lot* of misdesigned chips that have this sort of issue.... Your choices may be limited to running the subnet with an MTU of 8144, or replacing the defective card. Have you found anything online claiming that the card *can* specifically support MTU=9000?, or reached out to the company? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/a389272a/attachment.bin From choon-zone.teoh at vie.com.my Mon Sep 28 02:14:30 2015 From: choon-zone.teoh at vie.com.my (Teoh Choon Zone) Date: Mon, 28 Sep 2015 14:14:30 +0800 Subject: Unable to get stmmac driver of Altera Cyclone V to support MTU9000 In-Reply-To: <200286.1443411565@turing-police.cc.vt.edu> References: <73853.1443298063@turing-police.cc.vt.edu> <200286.1443411565@turing-police.cc.vt.edu> Message-ID: On Mon, Sep 28, 2015 at 11:39 AM, wrote: > It's possible it's a defective design, and is crippled so it can manage > 8144 but not the 9000 most chipsets can do. The fact that 8144 works > is proof the chipset *does* have a concept of jumbograms - but there's > been a *lot* of misdesigned chips that have this sort of issue.... > > Your choices may be limited to running the subnet with an MTU of 8144, or > replacing the defective card. Have you found anything online claiming that > the card *can* specifically support MTU=9000?, or reached out to the > company? > Actually initially I can only ping up to MTU 4042, and I have clarified with Altera, they also said that is the maximum MTU supported. But after that I learned from the technical reference manual and play around with the stmmac driver, if I run Tx in store-and-forward mode and Rx in threshold mode, I can ping up to MTU 8144. And according to the TRM, the GMAC indeed can support up to MTU 9.6KB. That's why I'm thinking maybe is the ethernet driver has some parts need to be configured properly to suit my particular GMAC. In particular, I've a hunch that this is related to the FIFO size and descriptor offset. The GMAC that I'm using has Tx and Rx FIFO size of 4kB each and supports up to 8kB descriptor. The confusing part are the following lines in ring_mode.c: In functions stmmac_jumbo_frm, desc->des2 = dma_map_single(priv->device, skb->data, bmax, DMA_TO_DEVICE); // where bmax is 8192 desc->des3 = desc->des2 + BUF_SIZE_4KiB; In functions stmmac_refill_desc3 and stmmac_init_desc3 p->des3 = p->des2 + BUF_SIZE_8KiB; Although the maximum FIFO size are 8kB for both of them (verified from descs.h), why is the offset are different? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/49a0cee8/attachment.html From rgroner at rtd.com Mon Sep 28 08:53:49 2015 From: rgroner at rtd.com (Rob Groner) Date: Mon, 28 Sep 2015 08:53:49 -0400 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <20150926004552.GB10629@kroah.com> References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> <20150925183729.GA3269@kroah.com> <20150925191412.GA4248@kroah.com> <56059ECA.1070803@rtd.com> <20150926004552.GB10629@kroah.com> Message-ID: <1443444829.2619.7.camel@kernel-dev> On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote: > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote: > > > > On 09/25/2015 03:14 PM, Greg KH wrote: > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: > > >>> -----Original Message----- > > >>> From: Greg KH [mailto:greg at kroah.com] > > >>> Sent: Friday, September 25, 2015 2:37 PM > > >>> To: Rob Groner > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > >>> > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > >>>>> -----Original Message----- > > >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > >>>>> Sent: Friday, September 25, 2015 12:48 PM > > >>>>> To: Rob Groner > > >>>>> Cc: kernelnewbies at kernelnewbies.org > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > >>>>> > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the > > >>>>>> extra capabilities of the Exar-provided driver to allow > > >>>>>> configuration of the board. When support for the Exar chip was > > >>>>>> added to the kernel 8250_pci driver, this then prevented easy use > > >>>>>> of the board by customers for anything other than standard serial usage > > >>> in RS232 mode. > > >>>>> Was it your intent to also prevent the use of this board in standard > > >>>>> serial usage in RS232 mode (which I'd expect is the most common use > > >>> case)? > > >>>> That is a byproduct of giving the non-average user the ability to > > >>>> reconfigure their board. This will basically move us back to pre-3.8, > > >>>> where the customer would simply have to insmod the provided Exar > > >>>> driver. The small inconvenience to that more common user seems (to us > > >>>> in Tech Support) outweighed by the much greater inconvenience to the > > >>>> user who wants to reconfigure. > > >>> Where is the exar driver, in the kernel already? > > >>> > > >>> confused, > > >> I'm sorry for the confusion. Let me summup: > > >> > > >> We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). > > >> > > >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. > > >> > > >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. > > >> > > >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. > > > Can you point me at the driver and I'll be glad to add it to the kernel > > > so that the proper driver will bind to the device and this will > > > not be an issue for users? > > > > > > thanks, > > > > > > greg k-h > > That would be WONDERFUL. > > > > https://www.exar.com/common/content/document.ashx?id=20121 > > At first glance, the driver looks pretty good. Let me do a bit of > cleanup on it for mostly coding style changes and removing some old api > support and see what the patch is. > > Would you mind testing it if I make a patch, given that I don't have the > hardware and you do? :) > > thanks, > > greg k-h I don't mind in the slightest, it's the least I can do! I've got my test station ready and have 3 different CPUs I can test with. Being new to the whole patching thing, I may need a few hints and helps to make sure I apply the patch correctly... Will it be showing up here in kernel newbies mailing list, or linux-serial, or other? Thank you. Rob Groner From greg at kroah.com Mon Sep 28 10:11:59 2015 From: greg at kroah.com (Greg KH) Date: Mon, 28 Sep 2015 07:11:59 -0700 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <1443444829.2619.7.camel@kernel-dev> References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> <20150925183729.GA3269@kroah.com> <20150925191412.GA4248@kroah.com> <56059ECA.1070803@rtd.com> <20150926004552.GB10629@kroah.com> <1443444829.2619.7.camel@kernel-dev> Message-ID: <20150928141159.GC20559@kroah.com> On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote: > On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote: > > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote: > > > > > > On 09/25/2015 03:14 PM, Greg KH wrote: > > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: > > > >>> -----Original Message----- > > > >>> From: Greg KH [mailto:greg at kroah.com] > > > >>> Sent: Friday, September 25, 2015 2:37 PM > > > >>> To: Rob Groner > > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org > > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > >>> > > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > > >>>>> -----Original Message----- > > > >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM > > > >>>>> To: Rob Groner > > > >>>>> Cc: kernelnewbies at kernelnewbies.org > > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > >>>>> > > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the > > > >>>>>> extra capabilities of the Exar-provided driver to allow > > > >>>>>> configuration of the board. When support for the Exar chip was > > > >>>>>> added to the kernel 8250_pci driver, this then prevented easy use > > > >>>>>> of the board by customers for anything other than standard serial usage > > > >>> in RS232 mode. > > > >>>>> Was it your intent to also prevent the use of this board in standard > > > >>>>> serial usage in RS232 mode (which I'd expect is the most common use > > > >>> case)? > > > >>>> That is a byproduct of giving the non-average user the ability to > > > >>>> reconfigure their board. This will basically move us back to pre-3.8, > > > >>>> where the customer would simply have to insmod the provided Exar > > > >>>> driver. The small inconvenience to that more common user seems (to us > > > >>>> in Tech Support) outweighed by the much greater inconvenience to the > > > >>>> user who wants to reconfigure. > > > >>> Where is the exar driver, in the kernel already? > > > >>> > > > >>> confused, > > > >> I'm sorry for the confusion. Let me summup: > > > >> > > > >> We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). > > > >> > > > >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. > > > >> > > > >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. > > > >> > > > >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. > > > > Can you point me at the driver and I'll be glad to add it to the kernel > > > > so that the proper driver will bind to the device and this will > > > > not be an issue for users? > > > > > > > > thanks, > > > > > > > > greg k-h > > > That would be WONDERFUL. > > > > > > https://www.exar.com/common/content/document.ashx?id=20121 > > > > At first glance, the driver looks pretty good. Let me do a bit of > > cleanup on it for mostly coding style changes and removing some old api > > support and see what the patch is. > > > > Would you mind testing it if I make a patch, given that I don't have the > > hardware and you do? :) > > > > thanks, > > > > greg k-h > > I don't mind in the slightest, it's the least I can do! I've got my > test station ready and have 3 different CPUs I can test with. Being new > to the whole patching thing, I may need a few hints and helps to make > sure I apply the patch correctly... > > Will it be showing up here in kernel newbies mailing list, or > linux-serial, or other? How about let's take it to linux-serial, and I'll cc: you as well, that's the proper place for this. Note, the driver does do some "odd" things in that it has some "custom" ioctls for unknown reasons, and it grabs a major number of another driver, both things that I can't accept upstream. It also seems to duplicate a lot of existing code, so maybe it doesn't really need to be a separate driver. I'll dig around in it and see what I can come up with, give me a week or so... thanks, greg k-h From johan at kernel.org Sat Sep 26 14:20:09 2015 From: johan at kernel.org (Johan Hovold) Date: Sat, 26 Sep 2015 11:20:09 -0700 Subject: Adding GPIO/SPI/I2C functionality to FTDI driver In-Reply-To: <20150923154058.GB24018@hephaistos.amsuess.com> References: <20150922162847.GC16144@hephaistos.amsuess.com> <20150922190203.GA31705@kroah.com> <20150923154058.GB24018@hephaistos.amsuess.com> Message-ID: <20150926182009.GJ2286@localhost> On Wed, Sep 23, 2015 at 05:40:58PM +0200, chrysn wrote: > Hallo Stefan, hallo Philipp, > hello Johan and Greg, > > On Tue, Sep 22, 2015 at 12:02:03PM -0700, Greg KH wrote: > > On Tue, Sep 22, 2015 at 06:28:47PM +0200, chrysn wrote: > > > Is support for alternative operation modes in FTDI chips something that > > > is welcome and (easily) feasible in the kernel? > > > > This comes up every other month or so on the linux-usb mailing list. > > See the discussions there about how to do this properly in a way that > > will be accepted by the USB maintainers if you wish to do this work. > > I've overlooked your two recent approaches when looking for existing > approaches towards extending FTDI support in the kernel (probably due to > me being too focused at SPI). > > Stefan and Philipp, has any of your patch sets received updates in the > meantime that have not been sent to the mailing list? > > It seems that one issue that needs to be solved for either of those to > continue is the decision of whether to base the FTDI driver on the MFD > infrastructure (which would probably be a first step then before even > implementing any of SPI, GPIO or I2C interfaces). There have been > conflicting opinions on this in different threads ([1], [2]); my > impression is that it would be a good idea, given that many of the more > recent FTDI devices can be switched to half a dozen configurations, and > that they are also shipped in products[3] where several of them would be > used in a coordinated fashion similar to the shields of widespread > embedded systems. > > Johan and Greg, can you reconcile your opinions on that? Or whom is that > question best discussed with? devicetree? linux-usb? linux-gpio / -spi > / -i2c? That would be linux-usb. These devices are serial device and there's no need to use MFD when implementing support for controlling any additional pins that can be used for GPIO. Just hang the gpio controller off the usb-serial device (i.e. the USB Interface). If these devices can be programmed to be used in other modes, then we'd need a way to detect that and refuse to bind the serial driver at probe. A dedicated I2C or SPI driver could then be allowed to bind instead. Thanks, Johan From rgroner at rtd.com Mon Sep 28 11:33:25 2015 From: rgroner at rtd.com (Rob Groner) Date: Mon, 28 Sep 2015 11:33:25 -0400 Subject: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. In-Reply-To: <20150928141159.GC20559@kroah.com> References: <20150925154629.GA2603@kernel-dev> <67224.1443199660@turing-police.cc.vt.edu> <20150925183729.GA3269@kroah.com> <20150925191412.GA4248@kroah.com> <56059ECA.1070803@rtd.com> <20150926004552.GB10629@kroah.com> <1443444829.2619.7.camel@kernel-dev> <20150928141159.GC20559@kroah.com> Message-ID: <1443454405.2244.3.camel@kernel-dev> On Mon, 2015-09-28 at 07:11 -0700, Greg KH wrote: > On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote: > > On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote: > > > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote: > > > > > > > > On 09/25/2015 03:14 PM, Greg KH wrote: > > > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: > > > > >>> -----Original Message----- > > > > >>> From: Greg KH [mailto:greg at kroah.com] > > > > >>> Sent: Friday, September 25, 2015 2:37 PM > > > > >>> To: Rob Groner > > > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org > > > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > >>> > > > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > > > >>>>> -----Original Message----- > > > > >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM > > > > >>>>> To: Rob Groner > > > > >>>>> Cc: kernelnewbies at kernelnewbies.org > > > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > >>>>> > > > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the > > > > >>>>>> extra capabilities of the Exar-provided driver to allow > > > > >>>>>> configuration of the board. When support for the Exar chip was > > > > >>>>>> added to the kernel 8250_pci driver, this then prevented easy use > > > > >>>>>> of the board by customers for anything other than standard serial usage > > > > >>> in RS232 mode. > > > > >>>>> Was it your intent to also prevent the use of this board in standard > > > > >>>>> serial usage in RS232 mode (which I'd expect is the most common use > > > > >>> case)? > > > > >>>> That is a byproduct of giving the non-average user the ability to > > > > >>>> reconfigure their board. This will basically move us back to pre-3.8, > > > > >>>> where the customer would simply have to insmod the provided Exar > > > > >>>> driver. The small inconvenience to that more common user seems (to us > > > > >>>> in Tech Support) outweighed by the much greater inconvenience to the > > > > >>>> user who wants to reconfigure. > > > > >>> Where is the exar driver, in the kernel already? > > > > >>> > > > > >>> confused, > > > > >> I'm sorry for the confusion. Let me summup: > > > > >> > > > > >> We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). > > > > >> > > > > >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. > > > > >> > > > > >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. > > > > >> > > > > >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. > > > > > Can you point me at the driver and I'll be glad to add it to the kernel > > > > > so that the proper driver will bind to the device and this will > > > > > not be an issue for users? > > > > > > > > > > thanks, > > > > > > > > > > greg k-h > > > > That would be WONDERFUL. > > > > > > > > https://www.exar.com/common/content/document.ashx?id=20121 > > > > > > At first glance, the driver looks pretty good. Let me do a bit of > > > cleanup on it for mostly coding style changes and removing some old api > > > support and see what the patch is. > > > > > > Would you mind testing it if I make a patch, given that I don't have the > > > hardware and you do? :) > > > > > > thanks, > > > > > > greg k-h > > > > I don't mind in the slightest, it's the least I can do! I've got my > > test station ready and have 3 different CPUs I can test with. Being new > > to the whole patching thing, I may need a few hints and helps to make > > sure I apply the patch correctly... > > > > Will it be showing up here in kernel newbies mailing list, or > > linux-serial, or other? > > How about let's take it to linux-serial, and I'll cc: you as well, > that's the proper place for this. > > Note, the driver does do some "odd" things in that it has some "custom" > ioctls for unknown reasons, and it grabs a major number of another > driver, both things that I can't accept upstream. It also seems to > duplicate a lot of existing code, so maybe it doesn't really need to be > a separate driver. I'll dig around in it and see what I can come up > with, give me a week or so... > > thanks, > > greg k-h Ok, I'll keep an eye out for it. Thanks for the effort you've offered and I'll help how I can. Rob Groner From danielhilst at gmail.com Mon Sep 28 12:51:28 2015 From: danielhilst at gmail.com (Daniel.) Date: Mon, 28 Sep 2015 13:51:28 -0300 Subject: Accessing pointers inside struct passed as argument to ioctl calls Message-ID: Hi all, I have a doubt about using pointers inside structs that are passed (as pointers) to ioctl argument. Since pointers passed from userspace can't be trusted, I need to copy they to kernel before accessing they. In this case I have a pointer inside a struct that is passed to the ioctl call also as pointer. So I need to copy the whole struct to kernel space and only then dereference the pointer. If this is true, two copy_from_user is needed right? Suppose I have a struct like this struct myioctl_arg { char *tx_buf; int tx_siz; } and this ioctl definition #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg *); At userspace program I do something like this: struct myioctl_arg arg = { .tx_buf = somebuf, .tx_siz = 32 } ioctl(fd, MYIOCTL_TX, &arg); And in my ioclt implementation static ioctl(struct file *fp, unsigned int cmd, unsigned long arg) { struct myioctl_arg karg; char kbuf[100]; ... case MYIOCTL_TX: copy_from_user(&karg, arg, sizeof(karg)); copy_from_user(kbuf, karg.tx_buf, karg.tx_siz); // now kbuf has the same contents of somebuf in userspace ... } I'm in doubt if this is the right way to access the userspace tx_buf. Since the .tx_buf from arg is a userspace pointer, accessible from userspace pointer arg, I can't type arg->tx_buf directly, doing this is dereferencing a userspace pointer inside kernel. So I need to copy the whole struct and dereference from the kernel space copy of it. So this two calls of copy_from_user() is the right way to do it? They are needed at all or is there better way of doing it? Cheers, -- "Do or do not. There is no try" Yoda Master From kennethadammiller at gmail.com Mon Sep 28 13:09:08 2015 From: kennethadammiller at gmail.com (Kenneth Adam Miller) Date: Mon, 28 Sep 2015 13:09:08 -0400 Subject: Accessing pointers inside struct passed as argument to ioctl calls In-Reply-To: References: Message-ID: You are right, and thank you for bringing this to the mailing list to be sure about it. There are several catastrophic vulnerabilities I can see waiting to happen. First, you should be sure that the pointer that they passed in is checked, as in the pointer to the buffer should only reside in the mapped memory for their process. Second, you trust the size that they pass in with tx_size. You should take the minimum of tx_siz and size of your kbuf (which is a static 100). Be careful that when you record a static value to stub out this size, a number is implicitly by default a signed word size int to the compiler. So a #define would be signed, but if you change the type of int tx_siz, be careful. Also, likely you don't want negative buffer sizes. size_t or uint16_t should suit your purposes. On Mon, Sep 28, 2015 at 12:51 PM, Daniel. wrote: > Hi all, I have a doubt about using pointers inside structs that are > passed (as pointers) to ioctl argument. Since pointers passed from > userspace can't be trusted, I need to copy they to kernel before > accessing they. In this case I have a pointer inside a struct that is > passed to the ioctl call also as pointer. So I need to copy the whole > struct to kernel space and only then dereference the pointer. If this > is true, two copy_from_user is needed right? > > Suppose I have a struct like this > > struct myioctl_arg { > char *tx_buf; > int tx_siz; > } > > and this ioctl definition > > #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg *); > > At userspace program I do something like this: > > struct myioctl_arg arg = { .tx_buf = somebuf, .tx_siz = 32 } > ioctl(fd, MYIOCTL_TX, &arg); > > And in my ioclt implementation > static ioctl(struct file *fp, unsigned int cmd, unsigned long arg) > { > struct myioctl_arg karg; > char kbuf[100]; > ... > case MYIOCTL_TX: > copy_from_user(&karg, arg, sizeof(karg)); > copy_from_user(kbuf, karg.tx_buf, karg.tx_siz); > // now kbuf has the same contents of somebuf in userspace > ... > } > > > I'm in doubt if this is the right way to access the userspace tx_buf. > Since the .tx_buf from arg is a userspace pointer, accessible from > userspace pointer arg, I can't type arg->tx_buf directly, doing this > is dereferencing a userspace pointer inside kernel. So I need to copy > the whole struct and dereference from the kernel space copy of it. So > this two calls of copy_from_user() is the right way to do it? They are > needed at all or is there better way of doing it? > > Cheers, > -- > "Do or do not. There is no try" > Yoda Master > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/20330fe4/attachment.html From danielhilst at gmail.com Mon Sep 28 15:57:30 2015 From: danielhilst at gmail.com (Daniel.) Date: Mon, 28 Sep 2015 16:57:30 -0300 Subject: Accessing pointers inside struct passed as argument to ioctl calls In-Reply-To: References: Message-ID: Okay, thank you for the tips Kenneth! This is not real code but the case is, so I will do that checks that you pointed out!! Thanks again! Best regards, - dhs 2015-09-28 14:09 GMT-03:00 Kenneth Adam Miller : > You are right, and thank you for bringing this to the mailing list to be > sure about it. > > There are several catastrophic vulnerabilities I can see waiting to happen. > > First, you should be sure that the pointer that they passed in is checked, > as in the pointer to the buffer should only reside in the mapped memory for > their process. > > Second, you trust the size that they pass in with tx_size. You should take > the minimum of tx_siz and size of your kbuf (which is a static 100). Be > careful that when you record a static value to stub out this size, a number > is implicitly by default a signed word size int to the compiler. So a > #define would be signed, but if you change the type of int tx_siz, be > careful. Also, likely you don't want negative buffer sizes. size_t or > uint16_t should suit your purposes. > > On Mon, Sep 28, 2015 at 12:51 PM, Daniel. wrote: > >> Hi all, I have a doubt about using pointers inside structs that are >> passed (as pointers) to ioctl argument. Since pointers passed from >> userspace can't be trusted, I need to copy they to kernel before >> accessing they. In this case I have a pointer inside a struct that is >> passed to the ioctl call also as pointer. So I need to copy the whole >> struct to kernel space and only then dereference the pointer. If this >> is true, two copy_from_user is needed right? >> >> Suppose I have a struct like this >> >> struct myioctl_arg { >> char *tx_buf; >> int tx_siz; >> } >> >> and this ioctl definition >> >> #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg *); >> >> At userspace program I do something like this: >> >> struct myioctl_arg arg = { .tx_buf = somebuf, .tx_siz = 32 } >> ioctl(fd, MYIOCTL_TX, &arg); >> >> And in my ioclt implementation >> static ioctl(struct file *fp, unsigned int cmd, unsigned long arg) >> { >> struct myioctl_arg karg; >> char kbuf[100]; >> ... >> case MYIOCTL_TX: >> copy_from_user(&karg, arg, sizeof(karg)); >> copy_from_user(kbuf, karg.tx_buf, karg.tx_siz); >> // now kbuf has the same contents of somebuf in userspace >> ... >> } >> >> >> I'm in doubt if this is the right way to access the userspace tx_buf. >> Since the .tx_buf from arg is a userspace pointer, accessible from >> userspace pointer arg, I can't type arg->tx_buf directly, doing this >> is dereferencing a userspace pointer inside kernel. So I need to copy >> the whole struct and dereference from the kernel space copy of it. So >> this two calls of copy_from_user() is the right way to do it? They are >> needed at all or is there better way of doing it? >> >> Cheers, >> -- >> "Do or do not. There is no try" >> Yoda Master >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > -- *"Do or do not. There is no try"* *Yoda Master* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/631d1430/attachment.html From ydroneaud at opteya.com Mon Sep 28 16:08:11 2015 From: ydroneaud at opteya.com (Yann Droneaud) Date: Mon, 28 Sep 2015 22:08:11 +0200 Subject: Accessing pointers inside struct passed as argument to ioctl calls In-Reply-To: References: Message-ID: <1443470891.4306.9.camel@opteya.com> Hi, Le lundi 28 septembre 2015 ? 13:51 -0300, Daniel. a ?crit : > Hi all, I have a doubt about using pointers inside structs that are > passed (as pointers) to ioctl argument. Since pointers passed from > userspace can't be trusted, I need to copy they to kernel before > accessing they. In this case I have a pointer inside a struct that is > passed to the ioctl call also as pointer. So I need to copy the whole > struct to kernel space and only then dereference the pointer. If this > is true, two copy_from_user is needed right? > > Suppose I have a struct like this > > struct myioctl_arg { > char *tx_buf; __u8 __user *tx_buf; > int tx_siz; __u32 tx_siz; > } > > and this ioctl definition > > #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg *); > #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg); > At userspace program I do something like this: > > struct myioctl_arg arg = { .tx_buf = somebuf, .tx_siz = 32 } > ioctl(fd, MYIOCTL_TX, &arg); > > And in my ioclt implementation > static ioctl(struct file *fp, unsigned int cmd, unsigned long arg) > { > struct myioctl_arg karg; > char kbuf[100]; > ... > case MYIOCTL_TX: > copy_from_user(&karg, arg, sizeof(karg)); if (copy_from_user(&karg, (const void __user *)arg, sizeof(karg)) return -EFAULT; if (!karg.tx_siz) return -EINVAL; if (karg.tx_siz > sizeof(kbuf)) return -EINVAL; > copy_from_user(kbuf, karg.tx_buf, karg.tx_siz); if (copy_from_user(kbuf, karg.tx_buf, karg.tx_siz)) return -EFAULT; > // now kbuf has the same contents of somebuf in userspace > ... > } > > > I'm in doubt if this is the right way to access the userspace tx_buf. > Since the .tx_buf from arg is a userspace pointer, accessible from > userspace pointer arg, I can't type arg->tx_buf directly, doing this > is dereferencing a userspace pointer inside kernel. So I need to copy > the whole struct and dereference from the kernel space copy of it. So > this two calls of copy_from_user() is the right way to do it? They are > needed at all or is there better way of doing it? > They are needed. Add __user annotation, install sparse and build with make C=1. For the second one, if the tx_buf is large enough, you may be well using something like get_user_page() to pin userspace memory inside the kernel memory so that you don't have to copy the memory to access it. Regards. -- Yann Droneaud OPTEYA From danielhilst at gmail.com Mon Sep 28 18:59:41 2015 From: danielhilst at gmail.com (Daniel.) Date: Mon, 28 Sep 2015 19:59:41 -0300 Subject: Accessing pointers inside struct passed as argument to ioctl calls In-Reply-To: <1443470891.4306.9.camel@opteya.com> References: <1443470891.4306.9.camel@opteya.com> Message-ID: Hi Yann, thank you, as I said this isn't real code, I just use to show my case. Anyway I will take the considerations in account. Thank you so much! And this get_user_page is new to me, thanks for pointing me out, I will read about it. The real thing is a driver to nrf24l01+ driver from Nordic. I may use this non copying aproach to exchange lot of frames without copying. This would improve driver's performance. :) Best regards! -dhs Em 28/09/2015 17:08, "Yann Droneaud" escreveu: > Hi, > > Le lundi 28 septembre 2015 ? 13:51 -0300, Daniel. a ?crit : > > Hi all, I have a doubt about using pointers inside structs that are > > passed (as pointers) to ioctl argument. Since pointers passed from > > userspace can't be trusted, I need to copy they to kernel before > > accessing they. In this case I have a pointer inside a struct that is > > passed to the ioctl call also as pointer. So I need to copy the whole > > struct to kernel space and only then dereference the pointer. If this > > is true, two copy_from_user is needed right? > > > > Suppose I have a struct like this > > > > struct myioctl_arg { > > char *tx_buf; > > __u8 __user *tx_buf; > > > int tx_siz; > > __u32 tx_siz; > > > } > > > > and this ioctl definition > > > > #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg *); > > > > #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg); > > > At userspace program I do something like this: > > > > struct myioctl_arg arg = { .tx_buf = somebuf, .tx_siz = 32 } > > ioctl(fd, MYIOCTL_TX, &arg); > > > > And in my ioclt implementation > > static ioctl(struct file *fp, unsigned int cmd, unsigned long arg) > > { > > struct myioctl_arg karg; > > char kbuf[100]; > > ... > > case MYIOCTL_TX: > > copy_from_user(&karg, arg, sizeof(karg)); > > if (copy_from_user(&karg, (const void __user *)arg, sizeof(karg)) > return -EFAULT; > > if (!karg.tx_siz) > return -EINVAL; > > if (karg.tx_siz > sizeof(kbuf)) > return -EINVAL; > > > copy_from_user(kbuf, karg.tx_buf, karg.tx_siz); > > if (copy_from_user(kbuf, karg.tx_buf, karg.tx_siz)) > return -EFAULT; > > > // now kbuf has the same contents of somebuf in userspace > > ... > > } > > > > > > I'm in doubt if this is the right way to access the userspace tx_buf. > > Since the .tx_buf from arg is a userspace pointer, accessible from > > userspace pointer arg, I can't type arg->tx_buf directly, doing this > > is dereferencing a userspace pointer inside kernel. So I need to copy > > the whole struct and dereference from the kernel space copy of it. So > > this two calls of copy_from_user() is the right way to do it? They are > > needed at all or is there better way of doing it? > > > > They are needed. Add __user annotation, install sparse and build with > make C=1. > > For the second one, if the tx_buf is large enough, you may be well using > something like get_user_page() to pin userspace memory inside the kernel > memory so that you don't have to copy the memory to access it. > > Regards. > > -- > Yann Droneaud > OPTEYA > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/74a19d64/attachment-0001.html From kennethadammiller at gmail.com Mon Sep 28 19:08:03 2015 From: kennethadammiller at gmail.com (Kenneth Adam Miller) Date: Mon, 28 Sep 2015 19:08:03 -0400 Subject: Accessing pointers inside struct passed as argument to ioctl calls In-Reply-To: References: <1443470891.4306.9.camel@opteya.com> Message-ID: I'm pretty sure that exchanging ownership of memory pages between the kernel and userland is a really huge no-go for security as well. If you do that, you've implicitly given the user control of the memory map table contents, so you have to think like a malicious abuser of your api would. Copy from user exists for a reason, and I'm pretty sure that every budding kernel developer has suggested what you have because we want performance. But keep in mind you can only be as performant as reasonable without sacrificing your user's data on their behalf. On Mon, Sep 28, 2015 at 6:59 PM, Daniel. wrote: > Hi Yann, thank you, as I said this isn't real code, I just use to show my > case. Anyway I will take the considerations in account. Thank you so much! > And this get_user_page is new to me, thanks for pointing me out, I will > read about it. > > The real thing is a driver to nrf24l01+ driver from Nordic. I may use this > non copying aproach to exchange lot of frames without copying. This would > improve driver's performance. :) > > Best regards! > -dhs > Em 28/09/2015 17:08, "Yann Droneaud" escreveu: > >> Hi, >> >> Le lundi 28 septembre 2015 ? 13:51 -0300, Daniel. a ?crit : >> > Hi all, I have a doubt about using pointers inside structs that are >> > passed (as pointers) to ioctl argument. Since pointers passed from >> > userspace can't be trusted, I need to copy they to kernel before >> > accessing they. In this case I have a pointer inside a struct that is >> > passed to the ioctl call also as pointer. So I need to copy the whole >> > struct to kernel space and only then dereference the pointer. If this >> > is true, two copy_from_user is needed right? >> > >> > Suppose I have a struct like this >> > >> > struct myioctl_arg { >> > char *tx_buf; >> >> __u8 __user *tx_buf; >> >> > int tx_siz; >> >> __u32 tx_siz; >> >> > } >> > >> > and this ioctl definition >> > >> > #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg *); >> > >> >> #define MYIOCTL_TX _IOWR(MY_MAGIC, MY_BASE, struct myioctl_arg); >> >> > At userspace program I do something like this: >> > >> > struct myioctl_arg arg = { .tx_buf = somebuf, .tx_siz = 32 } >> > ioctl(fd, MYIOCTL_TX, &arg); >> > >> > And in my ioclt implementation >> > static ioctl(struct file *fp, unsigned int cmd, unsigned long arg) >> > { >> > struct myioctl_arg karg; >> > char kbuf[100]; >> > ... >> > case MYIOCTL_TX: >> > copy_from_user(&karg, arg, sizeof(karg)); >> >> if (copy_from_user(&karg, (const void __user *)arg, sizeof(karg)) >> return -EFAULT; >> >> if (!karg.tx_siz) >> return -EINVAL; >> >> if (karg.tx_siz > sizeof(kbuf)) >> return -EINVAL; >> >> > copy_from_user(kbuf, karg.tx_buf, karg.tx_siz); >> >> if (copy_from_user(kbuf, karg.tx_buf, karg.tx_siz)) >> return -EFAULT; >> >> > // now kbuf has the same contents of somebuf in userspace >> > ... >> > } >> > >> > >> > I'm in doubt if this is the right way to access the userspace tx_buf. >> > Since the .tx_buf from arg is a userspace pointer, accessible from >> > userspace pointer arg, I can't type arg->tx_buf directly, doing this >> > is dereferencing a userspace pointer inside kernel. So I need to copy >> > the whole struct and dereference from the kernel space copy of it. So >> > this two calls of copy_from_user() is the right way to do it? They are >> > needed at all or is there better way of doing it? >> > >> >> They are needed. Add __user annotation, install sparse and build with >> make C=1. >> >> For the second one, if the tx_buf is large enough, you may be well using >> something like get_user_page() to pin userspace memory inside the kernel >> memory so that you don't have to copy the memory to access it. >> >> Regards. >> >> -- >> Yann Droneaud >> OPTEYA >> >> >> > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/14a8d0ea/attachment.html From Valdis.Kletnieks at vt.edu Mon Sep 28 21:20:24 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 28 Sep 2015 21:20:24 -0400 Subject: Accessing pointers inside struct passed as argument to ioctl calls In-Reply-To: References: <1443470891.4306.9.camel@opteya.com> Message-ID: <7065.1443489624@turing-police.cc.vt.edu> On Mon, 28 Sep 2015 19:59:41 -0300, "Daniel." said: > The real thing is a driver to nrf24l01+ driver from Nordic. I may use this > non copying aproach to exchange lot of frames without copying. This would > improve driver's performance. :) There is already well-developed zero-copy code for several network drivers in the kernel tree. Don't re-invent existing code that's already debugged. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/4dea63dc/attachment.bin From navych at 126.com Tue Sep 29 11:58:06 2015 From: navych at 126.com (Navy Cheng) Date: Tue, 29 Sep 2015 23:58:06 +0800 Subject: Can I send a patch about 00-INDEX? Message-ID: <20150929155805.GA23373@debian> Hi, I read some document about schedule in Documentation/schedule/ but I find that there are 9 files in 00-INDEX (include itself), however there are 10 files in the Documentation/schedule/* . *completoin.txt* is added in 2015 and 00-INDEX is not include it. Should I send a patch like this? Thank you? From mulyadi.santosa at gmail.com Wed Sep 30 05:41:03 2015 From: mulyadi.santosa at gmail.com (Mulyadi Santosa) Date: Wed, 30 Sep 2015 16:41:03 +0700 Subject: Help In-Reply-To: References: Message-ID: On Fri, Sep 25, 2015 at 10:14 PM, Prem Kumar wrote: > Dear Mulyadi, > > Sorry for sending direct email. I am at a deadlock pulling my hairs and > can't seem to figure out ( > http://lists.kernelnewbies.org/pipermail/kernelnewbies/2015-September/015111.html) > how to reclaim the AnonHugePage allocations when only system services are > running on them. Reboot is an option but too many nodes and this happening > frequently i need to know an alternate way out. > > Any help is greatly appreciated. > Regards, > Prem > > > Dear Prem Sorry that I can not promptly answer any question these days. My quick conclusion is that, since you said you alocate huge page above, then I guess huge page has different reclaim policy, that's why it might not be released when your application terminated. maybe you forgot to explicitly release them? All in all, I appreciate you ask my help, but next time please make sure that person is inviting you for direct discussion first, so you won't be considered as impolite. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150930/c895df81/attachment.html