Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
On Tue, May 7, 2024 at 5:14 PM Muni Sekhar wrote: > > On Tue, May 7, 2024 at 1:20 AM Alan Stern wrote: > > > > On Mon, May 06, 2024 at 09:44:52PM +0530, Muni Sekhar wrote: > > > On Mon, May 6, 2024 at 7:59 PM Alan Stern > > > wrote: > > > > > > > > On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote: > > > > > While we have successfully converted most of the USB device driver > > > > > functionality from kernel space to user space using libusb, we are now > > > > > seeking guidance on how to implement USB device suspend/resume in user > > > > > space. Specifically, we would like to know if libusb provides support > > > > > for achieving the suspend/resume functionality mentioned above. > > > > > Additionally, any insights or suggestions on how to accomplish this > > > > > task would be greatly appreciated. > > > > > > > > Your question is about libusb, right? So you'll get better answers if > > > > you post it on the libusb mailing list rather than the linux-usb mailing > > > > list. > > > Can USB device suspend\resume be implemented in user space driver > > > using software other than libusb? > > > > Yes, a userspace driver can use the usbfs interface and can employ the > > ioctl commands listed in /usr/include/linux/usbdevfs.h. It's possible In the context of the Linux kernel and USB devices, what are the similarities and differences between usbfs and sysfs? Before invoking the ioctl() system call, we need to obtain a file descriptor by invoking the open() system call. How do we identify the device node in the usbfs interface? For example, can you please explain how to identify the device node location of a Human Interface Device(shown below in lsusb -t output) as the first argument in the open() system call. $ lsusb -t /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M > > that libusb also provides facilities for controlling suspend and resume; > > I don't know whether it does. > > > > > If so, what are those methods or techniques to achieve USB device > > > suspend\resume , can you please provide clarity on this. > > > > As far as I know, these usbfs ioctl commands are not documented > > anywhere. > > > > The USBDEVFS_FORBID_SUSPEND ioctl prevents the device from being > > suspended, and wakes it up if it is currently suspended. > > > > The USBDEVFS_ALLOW_SUSPEND ioctl allows the device to be suspended. The > > suspend may not happen immediately; it is controlled by the settings in > > the device's power/control and power/autosuspend (or > > power/autosuspend_delay_ms) sysfs attribute files. > > > > The USBDEVFS_WAIT_FOR_RESUME ioctl waits until the device resumes, > > whether because of a remote wakeup or because another process has > > resumed it, and then forbids the device from suspending again until > > you perform another USBDEVFS_ALLOW_SUSPEND ioctl. > > > Thank you, it is very helpful. > > To verify the USB device suspend\resume functionality, I configured > the USB Power Management variables as follows: > > # cat /sys/bus/usb/devices/2-1.7/power/wakeup > enabled > > # cat /sys/bus/usb/devices/2-1.7/power/control > on > > # cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms > 0 > > # cat /sys/module/usbcore/parameters/autosuspend > 2 > > > So, I configured the system to autosuspend the USB device as soon as > it becomes idle, with no transactions running through the USB device. > Now, how can I verify that the USB device has entered suspend mode > from user space? When checking /var/log/kern.log, there are no > relevant print statements. Are there any other log files related to > power management or USB subsystems? > Please correct me if anything in the test procedure mentioned above is > incorrect. > > > Alan Stern > > > > -- > Thanks, > Sekhar -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Inquiry Regarding Handling of Kernel Crashes
Dear Linux Kernel Community, I hope this email finds you well. I am currently engaged in testing device drivers in Linux kernel mode, and I have encountered various types of kernel crashes during my testing process. Among these, some examples of kernel crashes include OOPS, lockups and others. I have a few questions regarding the handling of kernel crashes during testing: When encountering a kernel crash during testing, is it advisable to continue testing without rebooting the system? Or is it preferable to reboot the system after each kernel crash and then resume testing? Can the first kernel crash, whether it is an OOPS, or any other type crash, potentially lead to subsequent crashes of the same or different types? If so, should debugging efforts focus only on the first kernel crash, or should all subsequent crashes also be considered and addressed? In the event that the system needs to be rebooted after a kernel crash, how can user space test utilities be informed that a kernel crash has occurred? Additionally, how can the system be configured to automatically reboot in the event of a kernel crash? I would greatly appreciate any insights or best practices you can share regarding the handling of kernel crashes during testing. Your expertise and guidance on this matter would be invaluable to my testing efforts. Thank you very much for your time and assistance. I look forward to your response. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
On Thu, May 9, 2024 at 11:27 PM Billie Alsup (balsup) wrote: > > >From: Muni Sekhar > >In the scenario where an interrupt occurs while we are servicing the > >interrupt, and in the scenario where it doesn't occur while we are > >servicing the interrupt, when should we use the > >spin_lock_irqsave/spin_unlock_irqrestore APIs? > > In my experience, the interrupts are masked by the infrastructure before > invoking the > interrupt service routine. So unless you explicitly re-enable them, there > shouldn't be > a nested interrupt for the same interrupt number. > > It is the code run at process context that must be protected using the > irqsave/irqrestore > versions. You want to not only enter the critical section, but also prevent > the interrupt from occurring (on the same cpu at least). If you enter the > critical section in > process context, but then take an interrupt and attempt to again enter the > critical section, then your interrupt routine will deadlock. the interrupt > routine will never > be able to acquire the lock, and the process context code that was > interrupted will never be > able to complete to release the lock. So the process context code requires > the > irqsave/irqrestore variant to not only take the lock, but also prevent a > competing interrupt > routine from being triggered while you hold the lock. > > Bottom line is that if a critical section can be entered via both process > context > and interrupt context, then the process context invocation should use the > irqsave/irqrestore > variants to disable the interrupt before taking the lock. If it is common > code shared between > process context and interrupt context, then there is no harm in calling the > irqsave/irqrestore > version from both contexts. Thanks a lot for the detailed clarification. > > Otherwise, the standard spin_lock/spin_unlock variants (without > irqsave/irqrestore) would be > used for a critical section shared by multiple threads (different cpus), or > when your code has > already (separately) handled disabling interrupts as needed before invoking > spin_lock. > > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
On Thu, May 9, 2024 at 8:56 PM Billie Alsup (balsup) wrote: > > >From: Muni Sekhar > > >Here is a brief overview of how I have implemented spin locks in my module: > > > >spinlock_t my_spinlock; // Declare a spin lock > > > >// In ISR context (interrupt handler): > >spin_lock_irqsave(_spinlock, flags); > >// ... Critical section ... > >spin_unlock_irqrestore(_spinlock, flags); > > > > > >// In process context: (struct file_operations.read) > >spin_lock(_spinlock); > >// ... Critical section ... > >spin_unlock(_spinlock); > > from my understanding, you have the usage backwards. It is the > irqsave/irqrestore versions that should be used within process context to > prevent the interrupt from being handled on the same cpu while executing in > your critical section. > > The use of irqsave/irqrestore within the isr itself is ok, although perhaps > unnecessary. It depends on whether the interrupt can occur again while you > are servicing the interrupt (whether on this cpu or another). Usually (?) > the same interrupt does not nest, unless you have explicitly coded to allow > it (for example, by acknowledging and re-enabling the interrupt early in your > ISR). Certainly the spinlock is necessary to protect the critical section > from running in an isr on one cpu and process space on another cpu. > In the scenario where an interrupt occurs while we are servicing the interrupt, and in the scenario where it doesn't occur while we are servicing the interrupt, when should we use the spin_lock_irqsave/spin_unlock_irqrestore APIs? > From a lockup perspective, not doing the irqsave/irqrestore from process > context could explain your problem. Also look for code (anywhere!) that > blindly enables interrupts, rather than doing irqrestore from a prior irqsave. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
Dear Linux Kernel Community, I am reaching out to seek assistance regarding the usage of spin locks in the Linux kernel and to address a recurring issue related to hard LOCKUP errors that I have encountered during testing. Recently, I developed a small kernel module that involves ISR handling and utilizes the spinlock_t primitive. In my module, I have employed spin locks both in process context using spin_lock() and spin_unlock() APIs, as well as in ISR context using spin_lock_irqsave() and spin_unlock_irqrestore() APIs. Here is a brief overview of how I have implemented spin locks in my module: spinlock_t my_spinlock; // Declare a spin lock // In ISR context (interrupt handler): spin_lock_irqsave(_spinlock, flags); // ... Critical section ... spin_unlock_irqrestore(_spinlock, flags); // In process context: (struct file_operations.read) spin_lock(_spinlock); // ... Critical section ... spin_unlock(_spinlock); However, during testing, I have encountered a scenario where a hard LOCKUP (NMI watchdog: Watchdog detected hard LOCKUP on cpu 2) error occurs, specifically when a process context code execution triggers the spin_lock() function and is preempted by an interrupt that enters the ISR context and encounters the spin_lock_irqsave() function. This situation leads to the CPU being stuck indefinitely. My primary concern is to understand the appropriate usage of spin locks in both process and ISR contexts to avoid such hard LOCKUP errors. I am seeking clarification on the following points: Is it safe to use spin_lock_irqsave() and spin_unlock_irqrestore() APIs in ISR context and spin_lock() and spin_unlock() APIs in process context simultaneously? In scenarios where a process context code execution is preempted by an interrupt and enters ISR context, how should spin locks be used to prevent hard LOCKUP errors? Are there any specific guidelines or best practices for using spin locks in scenarios involving both process and ISR contexts? I would greatly appreciate any insights, guidance, or suggestions from the experienced members of the Linux kernel community to help address this issue and ensure the correct and efficient usage of spin locks in my kernel module. Thank you very much for your time and assistance. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
On Tue, May 7, 2024 at 11:21 PM Alan Stern wrote: > > On Tue, May 07, 2024 at 10:08:13PM +0530, Muni Sekhar wrote: > > Now, I can verify USB device auto-suspend and auto-resume through the > > kernel log. > > > > In my test system, I found three buses "Bus 001, 002, and 003" using > > the lsusb command. > > > > The USB device I want to test is located on "Bus 002". > > > > > > # lsusb | grep "Bus 002" | wc > > 4 37 224 > > > > As per the output of the above command, there are 4 USB devices on > > "Bus 002" in my test system. > > > > > > # ls -l /sys/bus/usb/devices/2* > > lrwxrwxrwx 1 root root 0 Feb 14 14:48 /sys/bus/usb/devices/2-0:1.0 -> > > ../../../devices/pci:00/:00:14.0/usb2/2-0:1.0 > > lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1 -> > > ../../../devices/pci:00/:00:14.0/usb2/2-1 > > lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1 -> > > ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1 > > lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1:1.0 -> > > ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0 > > lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1:1.0 > > -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0 > > lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7 -> > > ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7 > > lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7:1.0 > > -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7/2-1.7:1.0 > > > > # ls -l /sys/bus/usb/devices/2* | wc > > 7 77 892 > > > > > > The above command shows seven nodes in /sys/bus/usb/devices/2* directory. > > > > The wakeup, control, and autosuspend_delay_ms attribute files are > > controlled via /sys/bus/usb/devices/.../power/, where "..." represents > > the device's ID. > > > > I identified my test device in /sys/bus/usb/devices/.../power/ by > > iterating through all the directories, reading the idVendor attribute > > file, and then manipulating the power management attribute files. > > > > Is there a way to manually map /sys/bus/usb/devices/.../power/ from > > the lsusb output? Can this mapping be done from a user space program > > as well? Do you have any reference examples for this? If so, could you > > share their GitHub location? > > libusb already can do this for you. > > However, if you want to do it by hand then you can match up devices > based on the devnum attribute file in the devices sysfs directory. For > example, if you were trying to identify which device corresonds to the > lsusb entry for device 003 on bus 002, you should look through all the > directories in /sys/bus/usb/devices/2-* and see which one has "3" in its > devnum file. > > There's another way of doing it more directly, using the output from > "lsusb -t". For example, on my system: > > $ lsusb -t > /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M > /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M > |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M > /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M > /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M > |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M > |__ Port 002: Dev 003, If 0, Class=Human Interface Device, > Driver=usbhid, 1.5M > /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M > /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M > /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M > > Let's say we want to locate the Human Interface Device in sysfs. > According to the listing, it is on port 002 below port 001 below bus > 004. You reverse the numbers, put a '-' after the bus number, > and separate the port numbers with a '.', which gives "4-1.2": > > $ cat /sys/bus/usb/devices/4-1.2/product > Microsoft 5-Button Mouse with IntelliEye(TM) Thank you for the clear explanation on how to identify devices associated with root hubs. Could you please provide clarity on whether the root hub devices have attribute files in the devices sysfs directory? Upon checking the sysfs directory, I couldn't find any relevant information about these attribute files. Thank you again for your assistance. > > Alan Stern -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
On Tue, May 7, 2024 at 7:50 PM Alan Stern wrote: > > On Tue, May 07, 2024 at 05:14:25PM +0530, Muni Sekhar wrote: > > Thank you, it is very helpful. > > > > To verify the USB device suspend\resume functionality, I configured > > the USB Power Management variables as follows: > > > > # cat /sys/bus/usb/devices/2-1.7/power/wakeup > > enabled > > > > # cat /sys/bus/usb/devices/2-1.7/power/control > > on > > This means that the device will be permanently on, and so it will never > be suspended. If you want to allow the device to be suspended, you > have to write "auto" to the file. Thanks a lot for these inputs. Now, I can verify USB device auto-suspend and auto-resume through the kernel log. In my test system, I found three buses "Bus 001, 002, and 003" using the lsusb command. The USB device I want to test is located on "Bus 002". # lsusb | grep "Bus 002" | wc 4 37 224 As per the output of the above command, there are 4 USB devices on "Bus 002" in my test system. # ls -l /sys/bus/usb/devices/2* lrwxrwxrwx 1 root root 0 Feb 14 14:48 /sys/bus/usb/devices/2-0:1.0 -> ../../../devices/pci:00/:00:14.0/usb2/2-0:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1 -> ../../../devices/pci:00/:00:14.0/usb2/2-1 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1 -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1:1.0 -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1:1.0 -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7 -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7:1.0 -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7/2-1.7:1.0 # ls -l /sys/bus/usb/devices/2* | wc 7 77 892 The above command shows seven nodes in /sys/bus/usb/devices/2* directory. The wakeup, control, and autosuspend_delay_ms attribute files are controlled via /sys/bus/usb/devices/.../power/, where "..." represents the device's ID. I identified my test device in /sys/bus/usb/devices/.../power/ by iterating through all the directories, reading the idVendor attribute file, and then manipulating the power management attribute files. Is there a way to manually map /sys/bus/usb/devices/.../power/ from the lsusb output? Can this mapping be done from a user space program as well? Do you have any reference examples for this? If so, could you share their GitHub location? > > > # cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms > > 0 > > > > # cat /sys/module/usbcore/parameters/autosuspend > > 2 > > > > > > So, I configured the system to autosuspend the USB device as soon as > > it becomes idle, with no transactions running through the USB device. > > Now, how can I verify that the USB device has entered suspend mode > > from user space? When checking /var/log/kern.log, there are no > > relevant print statements. Are there any other log files related to > > power management or USB subsystems? > > Please correct me if anything in the test procedure mentioned above is > > incorrect. > > You can see the device's current state by reading the > power/runtime_status attribute file in sysfs. There are lots of other > informative files in that directory; you should look at them. > > If you want to get more debugging information in the kernel log, you can > enable dynamic debugging for usbcore: > > echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control > > Alan Stern -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
On Tue, May 7, 2024 at 1:20 AM Alan Stern wrote: > > On Mon, May 06, 2024 at 09:44:52PM +0530, Muni Sekhar wrote: > > On Mon, May 6, 2024 at 7:59 PM Alan Stern wrote: > > > > > > On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote: > > > > While we have successfully converted most of the USB device driver > > > > functionality from kernel space to user space using libusb, we are now > > > > seeking guidance on how to implement USB device suspend/resume in user > > > > space. Specifically, we would like to know if libusb provides support > > > > for achieving the suspend/resume functionality mentioned above. > > > > Additionally, any insights or suggestions on how to accomplish this > > > > task would be greatly appreciated. > > > > > > Your question is about libusb, right? So you'll get better answers if > > > you post it on the libusb mailing list rather than the linux-usb mailing > > > list. > > Can USB device suspend\resume be implemented in user space driver > > using software other than libusb? > > Yes, a userspace driver can use the usbfs interface and can employ the > ioctl commands listed in /usr/include/linux/usbdevfs.h. It's possible > that libusb also provides facilities for controlling suspend and resume; > I don't know whether it does. > > > If so, what are those methods or techniques to achieve USB device > > suspend\resume , can you please provide clarity on this. > > As far as I know, these usbfs ioctl commands are not documented > anywhere. > > The USBDEVFS_FORBID_SUSPEND ioctl prevents the device from being > suspended, and wakes it up if it is currently suspended. > > The USBDEVFS_ALLOW_SUSPEND ioctl allows the device to be suspended. The > suspend may not happen immediately; it is controlled by the settings in > the device's power/control and power/autosuspend (or > power/autosuspend_delay_ms) sysfs attribute files. > > The USBDEVFS_WAIT_FOR_RESUME ioctl waits until the device resumes, > whether because of a remote wakeup or because another process has > resumed it, and then forbids the device from suspending again until > you perform another USBDEVFS_ALLOW_SUSPEND ioctl. > Thank you, it is very helpful. To verify the USB device suspend\resume functionality, I configured the USB Power Management variables as follows: # cat /sys/bus/usb/devices/2-1.7/power/wakeup enabled # cat /sys/bus/usb/devices/2-1.7/power/control on # cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms 0 # cat /sys/module/usbcore/parameters/autosuspend 2 So, I configured the system to autosuspend the USB device as soon as it becomes idle, with no transactions running through the USB device. Now, how can I verify that the USB device has entered suspend mode from user space? When checking /var/log/kern.log, there are no relevant print statements. Are there any other log files related to power management or USB subsystems? Please correct me if anything in the test procedure mentioned above is incorrect. > Alan Stern -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
On Mon, May 6, 2024 at 7:59 PM Alan Stern wrote: > > On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote: > > Dear Linux USB Subsystem Community, > > > > I hope this email finds you well. We are currently working on a USB > > device driver in the Linux kernel space, which supports the > > suspend/resume functionality for a USB device using the struct > > usb_driver's .suspend and .resume callbacks. > > > > > > In our driver code, we perform a check to determine if the device has > > remote wakeup capability. If the device supports remote wakeup, we > > enable the device's autosuspend mode by setting the struct > > usb_device->dev.power.autosuspend_delay parameter and then calling > > usb_enable_autosuspend(). > > > > > > Similarly, to resume the suspended device, we expose an API to user > > space via IOCTL. In this process, we set struct > > usb_device->dev.power.autosuspend_delay to -1 and then call > > usb_disable_autosuspend(). > > > > > > While we have successfully converted most of the USB device driver > > functionality from kernel space to user space using libusb, we are now > > seeking guidance on how to implement USB device suspend/resume in user > > space. Specifically, we would like to know if libusb provides support > > for achieving the suspend/resume functionality mentioned above. > > Additionally, any insights or suggestions on how to accomplish this > > task would be greatly appreciated. > > Your question is about libusb, right? So you'll get better answers if > you post it on the libusb mailing list rather than the linux-usb mailing > list. Can USB device suspend\resume be implemented in user space driver using software other than libusb? If so, what are those methods or techniques to achieve USB device suspend\resume , can you please provide clarity on this. > > Alan Stern > > > It's worth mentioning that our USB device driver also supports > > Bulk\Coontrol I/O transfers and other functionalities. > > > > > > Thank you in advance for any assistance you can provide. I look > > forward to your valuable inputs and recommendations. > > > > > > -- > > Thanks, > > Sekhar > > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
On Mon, 6 May, 2024, 7:59 pm Alan Stern, wrote: > On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote: > > Dear Linux USB Subsystem Community, > > > > I hope this email finds you well. We are currently working on a USB > > device driver in the Linux kernel space, which supports the > > suspend/resume functionality for a USB device using the struct > > usb_driver's .suspend and .resume callbacks. > > > > > > In our driver code, we perform a check to determine if the device has > > remote wakeup capability. If the device supports remote wakeup, we > > enable the device's autosuspend mode by setting the struct > > usb_device->dev.power.autosuspend_delay parameter and then calling > > usb_enable_autosuspend(). > > > > > > Similarly, to resume the suspended device, we expose an API to user > > space via IOCTL. In this process, we set struct > > usb_device->dev.power.autosuspend_delay to -1 and then call > > usb_disable_autosuspend(). > > > > > > While we have successfully converted most of the USB device driver > > functionality from kernel space to user space using libusb, we are now > > seeking guidance on how to implement USB device suspend/resume in user > > space. Specifically, we would like to know if libusb provides support > > for achieving the suspend/resume functionality mentioned above. > > Additionally, any insights or suggestions on how to accomplish this > > task would be greatly appreciated. > > Your question is about libusb, right? So you'll get better answers if > you post it on the libusb mailing list rather than the linux-usb mailing > list. > Can USB device suspend\resume be implemented in user space driver using software other than libusb? Alan Stern > > > It's worth mentioning that our USB device driver also supports > > Bulk\Coontrol I/O transfers and other functionalities. > > > > > > Thank you in advance for any assistance you can provide. I look > > forward to your valuable inputs and recommendations. > > > > > > -- > > Thanks, > > Sekhar > > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
Dear Linux USB Subsystem Community, I hope this email finds you well. We are currently working on a USB device driver in the Linux kernel space, which supports the suspend/resume functionality for a USB device using the struct usb_driver's .suspend and .resume callbacks. In our driver code, we perform a check to determine if the device has remote wakeup capability. If the device supports remote wakeup, we enable the device's autosuspend mode by setting the struct usb_device->dev.power.autosuspend_delay parameter and then calling usb_enable_autosuspend(). Similarly, to resume the suspended device, we expose an API to user space via IOCTL. In this process, we set struct usb_device->dev.power.autosuspend_delay to -1 and then call usb_disable_autosuspend(). While we have successfully converted most of the USB device driver functionality from kernel space to user space using libusb, we are now seeking guidance on how to implement USB device suspend/resume in user space. Specifically, we would like to know if libusb provides support for achieving the suspend/resume functionality mentioned above. Additionally, any insights or suggestions on how to accomplish this task would be greatly appreciated. It's worth mentioning that our USB device driver also supports Bulk\Coontrol I/O transfers and other functionalities. Thank you in advance for any assistance you can provide. I look forward to your valuable inputs and recommendations. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Guidance for New SPI Driver in Mainline Linux Kernel
In the previous email, I mentioned that the FPGA hardware(SPI block) was connected to the Linux system using the PCIe interface. Here, when I refer to the Linux system, I mean an x86-based Linux system, not an ARM-based embedded system. On Fri, Aug 18, 2023 at 7:28 PM Raul Piper wrote: > > Have you gone through the bindings documentation for spi driver? > What are the pin configuration for your hardware sli? > Br > > On Fri, 18 Aug 2023 at 6:40 PM, Muni Sekhar wrote: >> >> Dear Linux Kernel Community, >> >> I hope this email finds you well. >> I am writing to seek your guidance and assistance regarding the >> development of a new SPI device driver for our hardware system. >> Our hardware, implemented on an FPGA, features an SPI interface that >> acts as a Master, offering two distinct modes for data transmission >> and reception. >> This hardware is connected to the Linux system via the PCIe bus. >> This hardware offers two modes for communication: using registers for >> debugging purposes and utilizing DMA channels for high-bandwidth >> applications. Both modes leverage the PCIe interface for data >> exchange. >> The hardware boasts several noteworthy features, including support for >> multiple speed settings, SPI port switching, configurable sample edge >> programming, and adjustable SPI transfer sizes. >> >> As we embark on the task of developing a device driver for this SPI >> interface, we intend to follow best practices and leverage existing >> resources within the Mainline Linux kernel tree. To achieve this, we >> plan to refer to and adapt existing SPI drivers. >> We kindly request your recommendations on which existing SPI driver >> within the Mainline Linux kernel tree would serve as the most suitable >> reference for our endeavor. Your invaluable expertise would greatly >> aid us in ensuring the success of this driver development process. >> Thank you for your time and consideration. We eagerly anticipate your >> guidance and insights. >> >> Warm regards, >> Sekhar >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Seeking Guidance for New SPI Driver in Mainline Linux Kernel
Dear Linux Kernel Community, I hope this email finds you well. I am writing to seek your guidance and assistance regarding the development of a new SPI device driver for our hardware system. Our hardware, implemented on an FPGA, features an SPI interface that acts as a Master, offering two distinct modes for data transmission and reception. This hardware is connected to the Linux system via the PCIe bus. This hardware offers two modes for communication: using registers for debugging purposes and utilizing DMA channels for high-bandwidth applications. Both modes leverage the PCIe interface for data exchange. The hardware boasts several noteworthy features, including support for multiple speed settings, SPI port switching, configurable sample edge programming, and adjustable SPI transfer sizes. As we embark on the task of developing a device driver for this SPI interface, we intend to follow best practices and leverage existing resources within the Mainline Linux kernel tree. To achieve this, we plan to refer to and adapt existing SPI drivers. We kindly request your recommendations on which existing SPI driver within the Mainline Linux kernel tree would serve as the most suitable reference for our endeavor. Your invaluable expertise would greatly aid us in ensuring the success of this driver development process. Thank you for your time and consideration. We eagerly anticipate your guidance and insights. Warm regards, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Seeking Guidance for New SPI Driver in Mainline Linux Kernel
Dear Linux Kernel Community, I hope this email finds you well. I am writing to seek your guidance and assistance regarding the development of a new SPI device driver for our hardware system. Our hardware, implemented on an FPGA, features an SPI interface that acts as a Master, offering two distinct modes for data transmission and reception. This hardware is connected to the Linux system via the PCIe bus. This hardware offers two modes for communication: using registers for debugging purposes and utilizing DMA channels for high-bandwidth applications. Both modes leverage the PCIe interface for data exchange. The hardware boasts several noteworthy features, including support for multiple speed settings, SPI port switching, configurable sample edge programming, and adjustable SPI transfer sizes. As we embark on the task of developing a device driver for this SPI interface, we intend to follow best practices and leverage existing resources within the Mainline Linux kernel tree. To achieve this, we plan to refer to and adapt existing SPI drivers. We kindly request your recommendations on which existing SPI driver within the Mainline Linux kernel tree would serve as the most suitable reference for our endeavor. Your invaluable expertise would greatly aid us in ensuring the success of this driver development process. Thank you for your time and consideration. We eagerly anticipate your guidance and insights. Warm regards, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
ALSA: arecord : silennce recorded as 0x80
Hi all, I recorded the silence on the default audio card by running "arecord -d 5 test.wav." Once it exited, I checked the contents by running "hexdump test.wav," and I see that silence is recorded as a sequence of 0x80 instead of 0x00. 000 4952 4646 0024 8000 4157 4556 6d66 2074 010 0010 0001 0001 1f40 1f40 020 0001 0008 6164 6174 8000 8080 8080 030 8080 8080 8080 8080 8080 8080 8080 8080 040 8080 8080 8080 8080 8080 8080 8080 8080 ... What might be the reason for silence being recorded as 0x80 instead of 0x0? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kconfig rules (depends, imply)
Thank you for the clarification. On Wed, Jun 1, 2022 at 1:55 AM Randy Dunlap wrote: > > Hi-- > > On 5/31/22 05:14, Muni Sekhar wrote: > > Hi all, > > > > menuconfig SOUNDWIRE > > tristate "SoundWire support" > > depends on ACPI || OF > > > > "depends on ACPI || OF" mean, SOUNDWIRE depends on both ACPI and OF modules? > > > > "||" is logical OR, so SOUNDWIRE depends on either ACPI or OF (or both > of them can be enabled). > > > > > > config SOUNDWIRE_QCOM > > tristate "Qualcomm SoundWire Master driver" > > imply SLIMBUS > > > > What does "imply SLIMBUS" mean? > > See Documentation/kbuild/kconfig-language.rst: > > - weak reverse dependencies: "imply" ["if" ] > > This is similar to "select" as it enforces a lower limit on another > symbol except that the "implied" symbol's value may still be set to n > from a direct dependency or with a visible prompt. > > So (in your example) SLIMBUS is desired but not required. > That means that the code that is built for SOUNDWIRE_QCOM > probably needs to use IS_REACHABLE(CONFIG_SLIMBUS) to > see if that SLIMBUS code is available at build time. > > HTH. > -- > ~Randy -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kconfig rules (depends, imply)
Hi all, menuconfig SOUNDWIRE tristate "SoundWire support" depends on ACPI || OF "depends on ACPI || OF" mean, SOUNDWIRE depends on both ACPI and OF modules? config SOUNDWIRE_QCOM tristate "Qualcomm SoundWire Master driver" imply SLIMBUS What does "imply SLIMBUS" mean? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
X86 : system call
Hi all, 32-bit system call numbers and entry vectors are defined in the format "". What is the difference between and ? The abi is always "i386" for arch/x86/entry/syscalls/syscall_32.tbl, whereas for 64-bit(arch/x86/entry/syscalls/syscall_64.tbl) it is used as "common" and "64", "x32". What is the difference between "common" and "64", "x32"? While adding a new system call(for example: mlock) to kernel, /kernel/sys_ni.c file modified as mentioned below: +cond_syscall(sys_mlock2); Why do we pass to cond_syscall()? Also, could someone please point me to a document which explains about "how to add a new system call" and the "system call flow from user space to kernel space" in X86 ARCHITECTURE (32-BIT AND 64-BIT). -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Time: new clocksource
On Sat, Dec 4, 2021 at 3:18 AM Daniel Lezcano wrote: > > Hi Sekhar, > > On 03/12/2021 17:50, Muni Sekhar wrote: > > Hi All, > > > > We have a Digital PLL with 64 bit timer counter hardware and the > > counter is accessible from the CPU over the PCIe bus. > > > > Is it possible to add this timer counter hardware as new clocksource > > driver? To do this, can someone please point me to the existing > > reference source code(or patch) for this task. > > You can refer to the drivers located in drivers/clocksource > > git annotate on one of the driver can give you the initial commit where > recent submissions explain the timer internals. > > > Suppose if it is possible to add a new clocksource driver for this > > hardware then does any userspace get_timestamp* API would get the time > > from this new hardware? > > It should if the timer is selected as the clocksource /var/log/kern.log file use a absolute time, like "Nov 29 12:26:13", as well as relative time in seconds and microseconds since startup , like "[1263900.984287] Is the relative time calculated by the clocksource driver module (tsc or acpi_pm)? Which module is responsible for resulting in the absolute time? Is absolute time synchronized across multiple systems connected on the network? > > > -- > <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > <http://twitter.com/#!/linaroorg> Twitter | > <http://www.linaro.org/linaro-blog/> Blog -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Time: new clocksource
On Mon, Dec 6, 2021 at 11:59 AM Daniel Lezcano wrote: > > On 06/12/2021 07:00, Muni Sekhar wrote: > > On Sat, Dec 4, 2021 at 3:18 AM Daniel Lezcano > > wrote: > >> > >> Hi Sekhar, > >> > >> On 03/12/2021 17:50, Muni Sekhar wrote: > >>> Hi All, > >>> > >>> We have a Digital PLL with 64 bit timer counter hardware and the > >>> counter is accessible from the CPU over the PCIe bus. > >>> > >>> Is it possible to add this timer counter hardware as new clocksource > >>> driver? To do this, can someone please point me to the existing > >>> reference source code(or patch) for this task. > >> > >> You can refer to the drivers located in drivers/clocksource > > I don't see the option in menuconfig to build the clocksource driver > > as a loadable kernel module, for example CONFIG_X86_PM_TIMER=m instead > > of CONFIG_X86_PM_TIMER=y. > > So a clocksource driver should always be part of the kernel built-in > > module? > > Yes, that is the case today. > > > If so, what's the reason for that? > > The timer is a component needed at boot time, so a module version does > really not make sense. > > So I would return back the question : what is the reason for a module? For built-in module we need to compile the whole kernel, but we are currently using the kernel via linux-image-4.15.0-54-generic.deb file installation. > > > >> git annotate on one of the driver can give you the initial commit where > >> recent submissions explain the timer internals. > >> > >>> Suppose if it is possible to add a new clocksource driver for this > >>> hardware then does any userspace get_timestamp* API would get the time > >>> from this new hardware? > >> > >> It should if the timer is selected as the clocksource > >> > >> > >> -- > >> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > >> > >> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > >> <http://twitter.com/#!/linaroorg> Twitter | > >> <http://www.linaro.org/linaro-blog/> Blog > > > > > > > > > -- > <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > <http://twitter.com/#!/linaroorg> Twitter | > <http://www.linaro.org/linaro-blog/> Blog -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Time: new clocksource
On Sat, Dec 4, 2021 at 3:18 AM Daniel Lezcano wrote: > > Hi Sekhar, > > On 03/12/2021 17:50, Muni Sekhar wrote: > > Hi All, > > > > We have a Digital PLL with 64 bit timer counter hardware and the > > counter is accessible from the CPU over the PCIe bus. > > > > Is it possible to add this timer counter hardware as new clocksource > > driver? To do this, can someone please point me to the existing > > reference source code(or patch) for this task. > > You can refer to the drivers located in drivers/clocksource I don't see the option in menuconfig to build the clocksource driver as a loadable kernel module, for example CONFIG_X86_PM_TIMER=m instead of CONFIG_X86_PM_TIMER=y. So a clocksource driver should always be part of the kernel built-in module? If so, what's the reason for that? > > git annotate on one of the driver can give you the initial commit where > recent submissions explain the timer internals. > > > Suppose if it is possible to add a new clocksource driver for this > > hardware then does any userspace get_timestamp* API would get the time > > from this new hardware? > > It should if the timer is selected as the clocksource > > > -- > <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > <http://twitter.com/#!/linaroorg> Twitter | > <http://www.linaro.org/linaro-blog/> Blog -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Time: new clocksource
Hi All, We have a Digital PLL with 64 bit timer counter hardware and the counter is accessible from the CPU over the PCIe bus. Is it possible to add this timer counter hardware as new clocksource driver? To do this, can someone please point me to the existing reference source code(or patch) for this task. Suppose if it is possible to add a new clocksource driver for this hardware then does any userspace get_timestamp* API would get the time from this new hardware? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: x86, nmi: IOCK error
On Tue, Nov 23, 2021 at 10:44 AM Jeffrey Walton wrote: > > On Mon, Nov 22, 2021 at 11:03 PM Muni Sekhar wrote: > > > > The following message is seen on the console "NMI: IOCK error (debug > > interrupt?) for reason 60 on CPU 0.", what does it mean? > > Red Hat has a good article on the subject at > https://access.redhat.com/solutions/42261. NMI: IOCK error (debug interrupt?) for reason 60 on CPU 0. NMI: IOCK error (debug interrupt?) for reason 70 on CPU 0. What's the difference between reason 60 & reason 70? I was not able to find it in the above mentioned link. > > Jeff -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
x86, nmi: IOCK error
Hi all, The following message is seen on the console "NMI: IOCK error (debug interrupt?) for reason 60 on CPU 0.", what does it mean? Does this likely confirm the CPU is faulty? If so, how to resolve this? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
USB: invalid maxpacket 8
Hi all, I'm trying to connect to a USB device on Linux PC and getting an error about "invalid maxpacket 8". What does it mean? Does this error causes USB packet transfer failures? Any ideas how to fix this? Thank you for any pointers. dmesg log: --- [1920549.030669] usb 2-2: New USB device found, idVendor=05c6, idProduct=9500 [1920549.030682] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [1920549.032623] hub 2-2:1.0: USB hub found [1920549.032672] hub 2-2:1.0: 7 ports detected [1920549.302875] usb 2-2.1: new high-speed USB device number 98 using xhci_hcd [1920549.391765] usb 2-2.1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 8 [1920549.391777] usb 2-2.1: config 1 interface 0 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 8 -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ALSA kernel projects - for academic purposes
On Fri, Sep 24, 2021 at 10:46 PM wrote: > > On Fri, Sep 24, 2021 at 10:58 AM Muni Sekhar wrote: > > > > On Fri, Sep 24, 2021 at 10:02 PM Valdis Klētnieks > > wrote: > > > > > > On Fri, 24 Sep 2021 19:34:59 +0530, Muni Sekhar said: > > > > What small projects would you suggest to a novice with the ALSA > > > > kernel. The aim is to develop a familiarity with the ALSA kernel > > > > source code, and also to submit it for academic purposes. > > > > > > A good place to start is getting a good handle on what the phrase "the > > > ALSA > > > kernel" even means. > > Basically looking for kernel space audio subsystem projects rather > > than its user-space library(alsa-lib) and utilities(alsa-utils). > > why ? > if your interest is better sound, then improving user-space is going > to be more productive. > > also, theres now pipewire, which is new, and all the buzz. > its apparently the future of linux audio Sounds interesting. Could you please give few more pointers on how to start on pipewire project. > > > > > > > > There's the Linux kernel, a small corner of which is the ALSA subsystem > > > for > > > sound. > > > > > > > > > -- > > Thanks, > > Sekhar > > > > ___ > > Kernelnewbies mailing list > > Kernelnewbies@kernelnewbies.org > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ALSA kernel projects - for academic purposes
On Fri, Sep 24, 2021 at 10:02 PM Valdis Klētnieks wrote: > > On Fri, 24 Sep 2021 19:34:59 +0530, Muni Sekhar said: > > What small projects would you suggest to a novice with the ALSA > > kernel. The aim is to develop a familiarity with the ALSA kernel > > source code, and also to submit it for academic purposes. > > A good place to start is getting a good handle on what the phrase "the ALSA > kernel" even means. Basically looking for kernel space audio subsystem projects rather than its user-space library(alsa-lib) and utilities(alsa-utils). > > There's the Linux kernel, a small corner of which is the ALSA subsystem for > sound. > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
ALSA kernel projects - for academic purposes
Hi all, What small projects would you suggest to a novice with the ALSA kernel. The aim is to develop a familiarity with the ALSA kernel source code, and also to submit it for academic purposes. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB-Audio: Device or resource busy (strace log)
On Wed, Aug 11, 2021 at 6:48 PM Muni Sekhar wrote: > > On Wed, Aug 11, 2021 at 6:19 PM vishnu wrote: > > > > can you paste output of > > arecord -l (list of capture devices). > $ arecord -l > List of CAPTURE Hardware Devices > card 0: USB [Plantronics .Audio 628 USB], device 0: USB Audio [USB Audio] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > > > Which device you are using and os. > > Does this instance is already open by default? like any video playing or > > something like that? > lsof does not catch it. > > > > > Yes you can stop pulse audio and try.. > > > > On Wed, Aug 11, 2021 at 6:17 PM Jaroslav Kysela wrote: > >> > >> On 11. 08. 21 14:36, Muni Sekhar wrote: > >> > Hi All, > >> > > >> > $ cat /proc/asound/cards > >> > 0 [USB]: USB-Audio - Plantronics .Audio 628 USB > >> > Plantronics Plantronics .Audio 628 USB at > >> > usb-:00:14.0-2, full speed > >> > > >> > I am using a Plantronics USB Audio headset. > >> > > >> > $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz > >> > x.wav > >> > arecord: main:722: audio open error: Device or resource busy > >> > > >> > > >> > 'arecord' command always fails the first time after system boot in my > >> > system. But subsequent execution of the 'arecord' command runs fine. > >> > > >> > > >> > I've attached the strace log for the "audio open error: Device or > >> > resource busy" failure. Is there any fix available for this issue? > >> > >> You may check which other task blocks the PCM device: > >> > >> lsof /dev/snd/pcmC0D0c > It does not output any process. > $ lsof /dev/snd/pcmC0D0c > > 1st run: > -- > $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz x.wav > arecord: main:722: audio open error: Device or resource busy > > 2nd run: > -- > $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz x.wav > Recording WAVE 'x.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo > ^CAborted by signal Interrupt... > > > >> > >> I guess that it will be pulseaudio (device enumeration). I see that pulseaudio is getting loaded on invoking the 1st run of 'arecord' command. Here is the log: After system boot I verified that pulseaudio is not in the memory. test@test594:~$ uptime 21:39:27 up 0 min, 1 user, load average: 0.70, 0.25, 0.09 test@test594:~$ ls -ltr /dev/snd/controlC1 crw-rw 1 root audio 116, 2 Aug 13 21:38 /dev/snd/controlC1 test@test594:~$ ls -ltr /dev/snd/ total 0 crw-rw 1 root audio 116, 33 Aug 13 21:38 timer crw-rw 1 root audio 116, 1 Aug 13 21:38 seq crw-rw 1 root audio 116, 3 Aug 13 21:38 pcmC1D0p crw-rw 1 root audio 116, 4 Aug 13 21:38 pcmC1D0c crw-rw 1 root audio 116, 2 Aug 13 21:38 controlC1 drwxr-xr-x 2 root root 60 Aug 13 21:38 by-path drwxr-xr-x 2 root root 60 Aug 13 21:38 by-id test@test594:~$ lsof /dev/snd/controlC1 test@test594:~$ lsof /dev/snd/pcmC1D0c test@test594:~$ 1st run of 'arecord': - I triggered 'arecord' after 2 mins of the system boot. In the 1st run, it failed with "Device or resource busy" and I see that pulseaudio loaded in the memory. Why does pulseaudio get triggered on running the alsa-utils command? How is the failure message "Device or resource busy" from the kernel code? test@test594:~$ arecord --device hw:1,0 --channels 2 --format S16_LE --rate 44100Hz x.wav arecord: main:722: audio open error: Device or resource busy test@test594:~$ test@test594:~$ lsof /dev/snd/pcmC1D0c COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME pulseaudi 1550 test memCHR 116,4 463 /dev/snd/pcmC1D0c pulseaudi 1550 test 27u CHR 116,4 0t0 463 /dev/snd/pcmC1D0c test@test594:~$ lsof /dev/snd/controlC1 COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME pulseaudi 1550 test 20u CHR 116,2 0t0 461 /dev/snd/controlC1 pulseaudi 1550 test 26u CHR 116,2 0t0 461 /dev/snd/controlC1 test@test594:~$ lsof /dev/snd/pcmC1D0p test@test594:~$ test@test594:~$ uptime 21:41:06 up 2 min, 1 user, load average: 0.20, 0.19, 0.08 2nd run of 'arecord': - The subsequent run of arecord runs fine without any issues even though pulseaudio is still in memory. test@test594:~$ arecord --device hw:1,0 --channels 2 --format S16_LE --rate 44100Hz x.wav Recording WAVE 'x.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo ^CAborted by signal Interrupt... test@test594:~$ uptime 21:41:22 up 2 min, 1 u
Re: USB-Audio: Device or resource busy (strace log)
On Wed, Aug 11, 2021 at 6:19 PM vishnu wrote: > > can you paste output of > arecord -l (list of capture devices). $ arecord -l List of CAPTURE Hardware Devices card 0: USB [Plantronics .Audio 628 USB], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 > Which device you are using and os. > Does this instance is already open by default? like any video playing or > something like that? lsof does not catch it. > > Yes you can stop pulse audio and try.. > > On Wed, Aug 11, 2021 at 6:17 PM Jaroslav Kysela wrote: >> >> On 11. 08. 21 14:36, Muni Sekhar wrote: >> > Hi All, >> > >> > $ cat /proc/asound/cards >> > 0 [USB]: USB-Audio - Plantronics .Audio 628 USB >> > Plantronics Plantronics .Audio 628 USB at >> > usb-:00:14.0-2, full speed >> > >> > I am using a Plantronics USB Audio headset. >> > >> > $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz x.wav >> > arecord: main:722: audio open error: Device or resource busy >> > >> > >> > 'arecord' command always fails the first time after system boot in my >> > system. But subsequent execution of the 'arecord' command runs fine. >> > >> > >> > I've attached the strace log for the "audio open error: Device or >> > resource busy" failure. Is there any fix available for this issue? >> >> You may check which other task blocks the PCM device: >> >> lsof /dev/snd/pcmC0D0c It does not output any process. $ lsof /dev/snd/pcmC0D0c 1st run: -- $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz x.wav arecord: main:722: audio open error: Device or resource busy 2nd run: -- $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz x.wav Recording WAVE 'x.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo ^CAborted by signal Interrupt... >> >> I guess that it will be pulseaudio (device enumeration). >> >> Jaroslav >> >> -- >> Jaroslav Kysela >> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
USB-Audio: Device or resource busy
Hi All, $ cat /proc/asound/cards 0 [USB]: USB-Audio - Plantronics .Audio 628 USB Plantronics Plantronics .Audio 628 USB at usb-:00:14.0-2, full speed I am using a Plantronics USB Audio headset. $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz x.wav arecord: main:722: audio open error: Device or resource busy 'arecord' command always fails the first time after system boot in my system. But subsequent execution of the 'arecord' command runs fine. I've attached the strace log for the "audio open error: Device or resource busy" failure. Is there any fix available for this issue? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: read() via USB bus
On Tue, 10 Aug, 2021, 7:50 pm Oliver Neukum, wrote: > > On 10.08.21 16:13, Muni Sekhar wrote: > > On Mon, Aug 9, 2021 at 1:45 PM Oliver Neukum wrote: > >> > >> On 09.08.21 09:58, Muni Sekhar wrote: > >>> Hi all, > >>> > >>> PCIe memory mapped registers can be read via readb(), readw(), readl() > >>> kernel API's. Similarly what are the kernel API to read the device > >>> registers via USB bus > >>> > >> Hi, > >> > >> I am afraid this is based on a fundamental misunderstanding on how > >> USB works. It is based on passing messages, not reading and writing > >> registers. > > I am referring to the code mentioned in > > > https://patchwork.kernel.org/project/linux-arm-msm/patch/1534464348-8227-3-git-send-email-pher...@codeaurora.org/ > > > > As per this driver gets access to the Qcomm’s USB h/w device registers > > via devm_extcon_dev_allocate(), devm_extcon_dev_register(), > > platform_get_resource() and devm_ioremap_resource API’s. > > > > What does the USB external connector EXTCON_USB \ EXTCON_USB_HOST > > devices means? Are these different from normal USB devices? > > > Hi, > > those are not USB devices. Those are devices associated with a USB bus > and are to be > found on the host's CPU's bus. This is like a graphics card is from the > driver's view > not a DisplayPort device or a SCSI controller is not a SCSI device for > its driver. Any other examples of devices associated with the USB bus? Do we have any reference driver in the mainline kernel tree? Does lsusb reports these devices? > > A host controller and associated devices can be on any bus. Such > controllers follow > their separate specifications and how they are to be driven is strictly > speaking > not part of USB: > > Regards > Oliver > > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: read() via USB bus
On Mon, Aug 9, 2021 at 1:45 PM Oliver Neukum wrote: > > > On 09.08.21 09:58, Muni Sekhar wrote: > > Hi all, > > > > PCIe memory mapped registers can be read via readb(), readw(), readl() > > kernel API's. Similarly what are the kernel API to read the device > > registers via USB bus > > > > Hi, > > I am afraid this is based on a fundamental misunderstanding on how > USB works. It is based on passing messages, not reading and writing > registers. I am referring to the code mentioned in https://patchwork.kernel.org/project/linux-arm-msm/patch/1534464348-8227-3-git-send-email-pher...@codeaurora.org/ As per this driver gets access to the Qcomm’s USB h/w device registers via devm_extcon_dev_allocate(), devm_extcon_dev_register(), platform_get_resource() and devm_ioremap_resource API’s. What does the USB external connector EXTCON_USB \ EXTCON_USB_HOST devices means? Are these different from normal USB devices? > > USB devices are primarily based on endpoints, not registers. A literal > answer to your question would point you to the clear/set/get_feature > standard requests of chapter 9 of the specification, but that really > will not help you, as you are making assumption that fundamentally > do not apply. > > I hope this list stays friendly to newcomers and we will answer > specific questions, but at this point I must advise you to first > read an introductory book. > > HTH > Oliver > > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: read() via USB bus
On Mon, Aug 9, 2021 at 1:45 PM Oliver Neukum wrote: > > > On 09.08.21 09:58, Muni Sekhar wrote: > > Hi all, > > > > PCIe memory mapped registers can be read via readb(), readw(), readl() > > kernel API's. Similarly what are the kernel API to read the device > > registers via USB bus > > > > Hi, > > I am afraid this is based on a fundamental misunderstanding on how > USB works. It is based on passing messages, not reading and writing > registers. > > USB devices are primarily based on endpoints, not registers. A literal > answer to your question would point you to the clear/set/get_feature > standard requests of chapter 9 of the specification, but that really > will not help you, as you are making assumption that fundamentally > do not apply. > > I hope this list stays friendly to newcomers and we will answer > specific questions, but at this point I must advise you to first > read an introductory book. Thank you, I will check it out. > > HTH > Oliver > > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
read() via USB bus
Hi all, PCIe memory mapped registers can be read via readb(), readw(), readl() kernel API's. Similarly what are the kernel API to read the device registers via USB bus -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
PCM prepare callback
Hi all, Is there any document which explains the sequence of snd_pcm_ops callbacks called during playback and capture? What driver is supposed to return from the PCM prepare callback if the sound card is not ready for playback\capture? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: trigger timestamp
On Thu, Jul 8, 2021 at 6:02 PM Takashi Iwai wrote: > > On Thu, 08 Jul 2021 14:19:12 +0200, > Muni Sekhar wrote: > > > > On Thu, Jul 8, 2021 at 4:59 PM Takashi Iwai wrote: > > > > > > On Thu, 01 Jul 2021 01:41:29 +0200, > > > Muni Sekhar wrote: > > > > > > > > Hi all, > > > > > > > > >From the user space test application , Is it possible to get the > > > > trigger timestamp corresponding to SNDRV_PCM_TRIGGER_START & > > > > SNDRV_PCM_TRIGGER_STOP events for audio playback capture? > > > > > > That's exactly what trigger_tstamp of snd_pcm_status corresponds for. > > Does aplay and arecord have any command line options to get the > > trigger_tstamp? If not how to get it? > > Implement some code :) > > Alternatively you can check the proc output contents in > /proc/asound/card*/pcm*/sub*/status. It'd be difficult to see the > stop timestamp, though (as the application closes the stream > immediately after that). How to specify if i want the REALTIME/MONOTONIC_RAW trigger_time timestamp type output in /proc/asound/card*/pcm*/sub*/status? > > > Takashi -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: trigger timestamp
On Thu, Jul 8, 2021 at 4:59 PM Takashi Iwai wrote: > > On Thu, 01 Jul 2021 01:41:29 +0200, > Muni Sekhar wrote: > > > > Hi all, > > > > >From the user space test application , Is it possible to get the > > trigger timestamp corresponding to SNDRV_PCM_TRIGGER_START & > > SNDRV_PCM_TRIGGER_STOP events for audio playback capture? > > That's exactly what trigger_tstamp of snd_pcm_status corresponds for. Does aplay and arecord have any command line options to get the trigger_tstamp? If not how to get it? > > > HTH, > > Takashi -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
trigger timestamp
Hi all, >From the user space test application , Is it possible to get the trigger timestamp corresponding to SNDRV_PCM_TRIGGER_START & SNDRV_PCM_TRIGGER_STOP events for audio playback capture? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB sound card issues
On Tue, Jun 15, 2021 at 11:44 AM Valdis Klētnieks wrote: > > On Sat, 12 Jun 2021 16:45:00 +0530, Muni Sekhar said: > > > > And if it's configurable for multiple formats, was it set for the correct > > > one? > > Is there a way to verify was it set for the correct one or not? > > arecord -v gives what it thinks the setup is. > > > > Does the record die immediately, or hang for a few seconds and timeout? > > What is the difference between these two ways? > > An immediate failure is usually related to a "Can't do it" situation where the > USB interaction to configure the device has failed, while a timeout usually > indicates that the configuration at least *claimed* to succeed, but is failing > to properly transfer valid data. > > > For my hardware, I noticed that it hangs for a few seconds and gives EIO > > (arecord: > > pcm_read:2032: read error: Input/output error). > > Given that the usbmon output ran to several megabytes, that's tending to > point at "the card was returning lots of packets, but they weren't actually > the > format/data that arecord was expecting. So, is it a USB card issue? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB sound card issues
On Sat, Jun 12, 2021 at 5:16 AM Valdis Klētnieks wrote: > > On Tue, 08 Jun 2021 16:20:07 +0530, Muni Sekhar said: > > > $ arecord --device hw:1,0 --channels 1 --format S16_LE --rate 32000_Hz x.wav > > Recording WAVE 'x.wav' : Signed 16 bit Little Endian, Rate 32000 Hz, Mono > > arecord: pcm_read:2032: read error: Input/output error > > Always check the obvious stuff first does the card support S16_LE 32Khz data? Yes , it supports. > And if it's configurable for multiple formats, was it set for the correct one? Is there a way to verify was it set for the correct one or not? > > Does wireshark or other USB snoop program show any traffic at all? > Does the record die immediately, or hang for a few seconds and timeout? What is the difference between these two ways? For my hardware, I noticed that it hangs for a few seconds and gives EIO (arecord: pcm_read:2032: read error: Input/output error). > Does 'arecord -v' or arecord -vv' tell us anything more about the situation? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
SNDRV_PCM_IOCTL_READI_FRAMES returns EIO
Hi all, I noticed recording(arecord) audio data on a USB sound card fails at SNDRV_PCM_IOCTL_READI_FRAMES is giving EIO. Can someone please clarify when the kernel returns EIO for Ioctl SNDRV_PCM_IOCTL_READI_FRAMES? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB sound card issues
On Tue, Jun 8, 2021 at 6:02 PM Greg KH wrote: > > On Tue, Jun 08, 2021 at 05:44:42PM +0530, Muni Sekhar wrote: > > On Tue, Jun 8, 2021 at 4:44 PM Greg KH wrote: > > > > > > On Tue, Jun 08, 2021 at 04:20:07PM +0530, Muni Sekhar wrote: > > > > Hi all, > > > > > > > > I am using a USB sound card(snd-usb-audio), and it fails while doing > > > > the audio recording "arecord: pcm_read:2032: read error: Input/output > > > > error". > > > > > > > > What could be the problem? and is there a workaround for this? > > > > > > > > $ arecord -l > > > > List of CAPTURE Hardware Devices > > > > card 1: BT_AG [BT_002], device 0: USB Audio [USB Audio] > > > > Subdevices: 1/1 > > > > Subdevice #0: subdevice #0 > > > > > > > > > > > > $ arecord --device hw:1,0 --channels 1 --format S16_LE --rate 32000_Hz > > x.wav > > > > Recording WAVE 'x.wav' : Signed 16 bit Little Endian, Rate 32000 Hz, > > Mono > > > > arecord: pcm_read:2032: read error: Input/output error > > > > > > What kernel version is this, and what other kernel messages are printed > > > when you plug your device in? > > > What kernel version is this? 4.15.0-54-generic > > > [12932.016672] usb 2-1: USB disconnect, device number 5 > > [12932.016683] usb 2-1.1: USB disconnect, device number 6 > > [12962.085766] usb 2-1: new full-speed USB device number 7 using xhci_hcd > > [12962.275849] usb 2-1: New USB device found, idVendor=0a12, idProduct=4010 > > [12962.275861] usb 2-1: New USB device strings: Mfr=0, Product=0, > > SerialNumber=0 > > [12962.276538] usb 2-1: ep 0x81 - rounding interval to 1024 microframes, ep > > desc says 2040 microframes > > [12962.279699] hub 2-1:1.0: USB hub found > > [12962.280663] hub 2-1:1.0: 4 ports detected > > [12962.875024] usb 2-1.1: new full-speed USB device number 8 using xhci_hcd > > [12962.980977] usb 2-1.1: New USB device found, idVendor=0a12, > > idProduct=4007 > > [12962.980991] usb 2-1.1: New USB device strings: Mfr=1, Product=2, > > SerialNumber=5 > > [12962.981000] usb 2-1.1: Product: BT_002 > > [12962.981008] usb 2-1.1: Manufacturer: Qualcomm > > [12962.981015] usb 2-1.1: SerialNumber: ABC4C25B > > [12962.992667] input: Qualcomm BT_002 as > > /devices/pci:00/:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:0A12:4007.0003/input/input6 > > [12963.048083] hid-generic 0003:0A12:4007.0003: input,hiddev0,hidraw0: USB > > HID v1.11 Device [Qualcomm BT_002] on usb-:00:14.0-1.1/input0 > > [12963.066910] hid-generic 0003:0A12:4007.0004: hiddev0,hidraw1: USB HID > > v1.11 Device [Qualcomm BT_002] on usb-:00:14.0-1.1/input1 > > > > Same error (arecord: pcm_read:2032: read error: Input/output error) > > observed on 4.4, 4.15 and 5.4 kernel version. > > What exact versions of these are you using? 4.4.0-66-generic 4.15.0-54-generic Ubuntu 20.04 > > And what about the latest 5.12.y release? I don't have this test setup. > > thanks, > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB sound card issues
On Tue, Jun 8, 2021 at 4:44 PM Greg KH wrote: > > On Tue, Jun 08, 2021 at 04:20:07PM +0530, Muni Sekhar wrote: > > Hi all, > > > > I am using a USB sound card(snd-usb-audio), and it fails while doing > > the audio recording "arecord: pcm_read:2032: read error: Input/output > > error". > > > > What could be the problem? and is there a workaround for this? > > > > $ arecord -l > > List of CAPTURE Hardware Devices > > card 1: BT_AG [BT_002], device 0: USB Audio [USB Audio] > > Subdevices: 1/1 > > Subdevice #0: subdevice #0 > > > > > > $ arecord --device hw:1,0 --channels 1 --format S16_LE --rate 32000_Hz x.wav > > Recording WAVE 'x.wav' : Signed 16 bit Little Endian, Rate 32000 Hz, Mono > > arecord: pcm_read:2032: read error: Input/output error > > What kernel version is this, and what other kernel messages are printed > when you plug your device in? [12932.016672] usb 2-1: USB disconnect, device number 5 [12932.016683] usb 2-1.1: USB disconnect, device number 6 [12962.085766] usb 2-1: new full-speed USB device number 7 using xhci_hcd [12962.275849] usb 2-1: New USB device found, idVendor=0a12, idProduct=4010 [12962.275861] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [12962.276538] usb 2-1: ep 0x81 - rounding interval to 1024 microframes, ep desc says 2040 microframes [12962.279699] hub 2-1:1.0: USB hub found [12962.280663] hub 2-1:1.0: 4 ports detected [12962.875024] usb 2-1.1: new full-speed USB device number 8 using xhci_hcd [12962.980977] usb 2-1.1: New USB device found, idVendor=0a12, idProduct=4007 [12962.980991] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [12962.981000] usb 2-1.1: Product: BT_002 [12962.981008] usb 2-1.1: Manufacturer: Qualcomm [12962.981015] usb 2-1.1: SerialNumber: ABC4C25B [12962.992667] input: Qualcomm BT_002 as /devices/pci:00/:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:0A12:4007.0003/input/input6 [12963.048083] hid-generic 0003:0A12:4007.0003: input,hiddev0,hidraw0: USB HID v1.11 Device [Qualcomm BT_002] on usb-:00:14.0-1.1/input0 [12963.066910] hid-generic 0003:0A12:4007.0004: hiddev0,hidraw1: USB HID v1.11 Device [Qualcomm BT_002] on usb-:00:14.0-1.1/input1 Same error (arecord: pcm_read:2032: read error: Input/output error) observed on 4.4, 4.15 and 5.4 kernel version. > > thanks, > > greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
USB sound card issues
Hi all, I am using a USB sound card(snd-usb-audio), and it fails while doing the audio recording "arecord: pcm_read:2032: read error: Input/output error". What could be the problem? and is there a workaround for this? $ arecord -l List of CAPTURE Hardware Devices card 1: BT_AG [BT_002], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 $ arecord --device hw:1,0 --channels 1 --format S16_LE --rate 32000_Hz x.wav Recording WAVE 'x.wav' : Signed 16 bit Little Endian, Rate 32000 Hz, Mono arecord: pcm_read:2032: read error: Input/output error -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
kernel projects for students
Hi all, What are some good Linux projects in kernel space for final year computer.science engineering students? Could someone help and share your ideas on this please. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
sound: PCM/I2S Digital Mic & SPDIF
Hello all, I’m having a Linux X86 machine and interfacing with Xilinx FPGA endpoint over PCIe. FPGA endpoint supports various audio engines like PCM/I2S ,Digital Mic & SPDIF. I’m looking for any existing linux device driver to port it for my hardware. Does the Linux kernel tree have any reference examples for these audio engines which I can use for porting it to my hardware? If so can someone please share your inputs on this. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Scheduler benchmarks
On Tue, Aug 18, 2020 at 11:45 PM peter enderborg wrote: > > On 8/18/20 7:53 PM, Muni Sekhar wrote: > > On Tue, Aug 18, 2020 at 11:06 PM Greg KH wrote: > >> On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote: > >>> On Tue, Aug 18, 2020 at 10:44 PM Greg KH wrote: > >>>> On Tue, Aug 18, 2020 at 10:24:13PM +0530, Muni Sekhar wrote: > >>>>> On Tue, Aug 18, 2020 at 8:06 PM Greg KH wrote: > >>>>>> On Tue, Aug 18, 2020 at 08:00:11PM +0530, Muni Sekhar wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> I’ve two identical Linux systems with only kernel differences. > >>>>>> What are the differences in the kernels? > >>>> You didn't answer this question, is this the same kernel source being > >>>> compared here? Same version? Same compiler? Everything identical? > >>> Both systems are having exactly the same hardware configuration. > >>> Compiler and kernel versions are different. One system has Ubuntu > >>> 16.04.4 LTS(4.4.0-66-generic kernel with gcc version 5.4.0) kernel and > >>> the other one has Ubuntu 18.04.4 LTS(4.15.0-91-generic kernel with gcc > >>> version 7.5.0). > >> Those are _very_ different kernel versions, with many years and tens of > >> thousands of different changes between them. > >> > >> Hopefully the newer kernel is faster, so just stick with that :) > > But unfortunately the newer kernel is very slow, that is the reason > > for starting this investigation :) > > Any type of help, and guidelines to dive deeper will be highly appreciated. > > On the 4.4 kernel you dont have > > +CONFIG_RETPOLINE=y > +CONFIG_INTEL_RDT=y Thanks! That is helpful. Yes, I see 4.4 kernel don't have the above two config options. What analysis can be done to narrow down the root cause? Any example of reference could be helpful to understand. > > And your base is very different two. > > Try to use mainline on both system and see. > > You can also use the same base kernel version from ubuntu and > > run your test. > > > >> greg k-h > > > > > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Scheduler benchmarks
On Tue, Aug 18, 2020 at 11:06 PM Greg KH wrote: > > On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote: > > On Tue, Aug 18, 2020 at 10:44 PM Greg KH wrote: > > > > > > On Tue, Aug 18, 2020 at 10:24:13PM +0530, Muni Sekhar wrote: > > > > On Tue, Aug 18, 2020 at 8:06 PM Greg KH wrote: > > > > > > > > > > On Tue, Aug 18, 2020 at 08:00:11PM +0530, Muni Sekhar wrote: > > > > > > Hi all, > > > > > > > > > > > > I’ve two identical Linux systems with only kernel differences. > > > > > > > > > > What are the differences in the kernels? > > > > > > You didn't answer this question, is this the same kernel source being > > > compared here? Same version? Same compiler? Everything identical? > > Both systems are having exactly the same hardware configuration. > > Compiler and kernel versions are different. One system has Ubuntu > > 16.04.4 LTS(4.4.0-66-generic kernel with gcc version 5.4.0) kernel and > > the other one has Ubuntu 18.04.4 LTS(4.15.0-91-generic kernel with gcc > > version 7.5.0). > > Those are _very_ different kernel versions, with many years and tens of > thousands of different changes between them. > > Hopefully the newer kernel is faster, so just stick with that :) But unfortunately the newer kernel is very slow, that is the reason for starting this investigation :) Any type of help, and guidelines to dive deeper will be highly appreciated. > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Scheduler benchmarks
On Tue, Aug 18, 2020 at 10:44 PM Greg KH wrote: > > On Tue, Aug 18, 2020 at 10:24:13PM +0530, Muni Sekhar wrote: > > On Tue, Aug 18, 2020 at 8:06 PM Greg KH wrote: > > > > > > On Tue, Aug 18, 2020 at 08:00:11PM +0530, Muni Sekhar wrote: > > > > Hi all, > > > > > > > > I’ve two identical Linux systems with only kernel differences. > > > > > > What are the differences in the kernels? > > You didn't answer this question, is this the same kernel source being > compared here? Same version? Same compiler? Everything identical? Both systems are having exactly the same hardware configuration. Compiler and kernel versions are different. One system has Ubuntu 16.04.4 LTS(4.4.0-66-generic kernel with gcc version 5.4.0) kernel and the other one has Ubuntu 18.04.4 LTS(4.15.0-91-generic kernel with gcc version 7.5.0). > > > > > While doing kernel profiling with perf, I got the below mentioned > > > > metrics for Scheduler benchmarks. > > > > > > > > 1st system (older kernel version compared to the other system) > > > > benchmark result: > > > > > > > > $ perf bench sched messaging -g 64 > > > > # Running 'sched/messaging' benchmark: > > > > # 20 sender and receiver processes per group > > > > # 64 groups == 2560 processes run > > > > > > > > Total time: 2.936 [sec] > > > > > > > > > > > > 2nd system benchmark result: > > > > > > > > $ perf bench sched messaging -g 64 > > > > # Running 'sched/messaging' benchmark: > > > > # 20 sender and receiver processes per group > > > > # 64 groups == 2560 processes run > > > > > > > > Total time: 10.074 [sec] > > > > > > > > > > > > So as per scheduler benchmark results, clearly a huge difference > > > > between two systems. > > > > Can anyone suggest to me how to dive deeper to know the root cause for > > > > it. > > > > > > Look a the differences between your different kernels, that would be a > > > great start :) > > I created the difference between two kernel config files and then > > tried to spot the CONFIG*SCHED* differences. > > Interestingly I see the difference in I/O scheduler config, 1st system > > is set to “deadline” and other one is set to “cfq”. So I made it equal > > by echoing to “/sys/block//queue/scheduler" but still no > > change in scheduler benchmark metrics. > > > > Is it the correct way to find the differences between kernels? If so, > > what other important CONFIG_* variables need to consider? > > > > > > $ cat config.patch | grep -i sched > > > > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y > > CONFIG_CGROUP_SCHED=y > > CONFIG_FAIR_GROUP_SCHED=y > > # CONFIG_RT_GROUP_SCHED is not set > > # IO Schedulers > > @@ -369,10 +434,14 @@ CONFIG_IOSCHED_NOOP=y > > CONFIG_IOSCHED_DEADLINE=y > > CONFIG_IOSCHED_CFQ=y > > CONFIG_CFQ_GROUP_IOSCHED=y > > -CONFIG_DEFAULT_IOSCHED="deadline" > > +CONFIG_DEFAULT_IOSCHED="cfq" > > +CONFIG_MQ_IOSCHED_DEADLINE=m > > +CONFIG_MQ_IOSCHED_KYBER=m > > +CONFIG_IOSCHED_BFQ=m > > +CONFIG_BFQ_GROUP_IOSCHED=y > > CONFIG_SCHED_SMT=y > > CONFIG_SCHED_MC=y > > +CONFIG_SCHED_MC_PRIO=y > > +# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set > > +CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y > > There's lots of other options that affect performance, depending on your > specific benchmark, other than these. > > good luck! > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Scheduler benchmarks
On Tue, Aug 18, 2020 at 8:06 PM Greg KH wrote: > > On Tue, Aug 18, 2020 at 08:00:11PM +0530, Muni Sekhar wrote: > > Hi all, > > > > I’ve two identical Linux systems with only kernel differences. > > What are the differences in the kernels? > > > While doing kernel profiling with perf, I got the below mentioned > > metrics for Scheduler benchmarks. > > > > 1st system (older kernel version compared to the other system) benchmark > > result: > > > > $ perf bench sched messaging -g 64 > > # Running 'sched/messaging' benchmark: > > # 20 sender and receiver processes per group > > # 64 groups == 2560 processes run > > > > Total time: 2.936 [sec] > > > > > > 2nd system benchmark result: > > > > $ perf bench sched messaging -g 64 > > # Running 'sched/messaging' benchmark: > > # 20 sender and receiver processes per group > > # 64 groups == 2560 processes run > > > > Total time: 10.074 [sec] > > > > > > So as per scheduler benchmark results, clearly a huge difference > > between two systems. > > Can anyone suggest to me how to dive deeper to know the root cause for > > it. > > Look a the differences between your different kernels, that would be a > great start :) I created the difference between two kernel config files and then tried to spot the CONFIG*SCHED* differences. Interestingly I see the difference in I/O scheduler config, 1st system is set to “deadline” and other one is set to “cfq”. So I made it equal by echoing to “/sys/block//queue/scheduler" but still no change in scheduler benchmark metrics. Is it the correct way to find the differences between kernels? If so, what other important CONFIG_* variables need to consider? $ cat config.patch | grep -i sched CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set # IO Schedulers @@ -369,10 +434,14 @@ CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y -CONFIG_DEFAULT_IOSCHED="deadline" +CONFIG_DEFAULT_IOSCHED="cfq" +CONFIG_MQ_IOSCHED_DEADLINE=m +CONFIG_MQ_IOSCHED_KYBER=m +CONFIG_IOSCHED_BFQ=m +CONFIG_BFQ_GROUP_IOSCHED=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y +CONFIG_SCHED_MC_PRIO=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set +CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y > > good luck! > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Scheduler benchmarks
Hi all, I’ve two identical Linux systems with only kernel differences. While doing kernel profiling with perf, I got the below mentioned metrics for Scheduler benchmarks. 1st system (older kernel version compared to the other system) benchmark result: $ perf bench sched messaging -g 64 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 64 groups == 2560 processes run Total time: 2.936 [sec] 2nd system benchmark result: $ perf bench sched messaging -g 64 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 64 groups == 2560 processes run Total time: 10.074 [sec] So as per scheduler benchmark results, clearly a huge difference between two systems. Can anyone suggest to me how to dive deeper to know the root cause for it. Also are there any tunable kernel parameters related to this one? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: pcie: kernel log - BAR 15: no space for... BAR 15: failed to assign..
On Tue, Feb 11, 2020 at 8:10 PM Bjorn Helgaas wrote: > > On Tue, Feb 11, 2020 at 07:36:00PM +0530, Muni Sekhar wrote: > > On Tue, Feb 11, 2020 at 3:58 AM Bjorn Helgaas wrote: > > > On Sun, Feb 09, 2020 at 07:59:41AM +0530, Muni Sekhar wrote: > > > > Hi all, > > > > > > > > After rebooting the system following messages are seen in dmesg. > > > > Not sure if these indicate a problem. Can some one look at these and > > > > confirm if this is problem or can be ignored ? > > > > > > > > Also any suggestions as to what would cause this? > > > > > > > > [1.084728] pci :00:1c.0: BAR 15: no space for [mem size > > > > 0x0020 64bit pref] > > > > [1.084813] pci :00:1c.0: BAR 15: failed to assign [mem size > > > > 0x0020 64bit pref] > > > > [1.084890] pci :00:1c.2: BAR 14: no space for [mem size > > > > 0x0020] > > > > [1.084949] pci :00:1c.2: BAR 14: failed to assign [mem size > > > > 0x0020] > > > > [1.085037] pci :00:1c.2: BAR 15: no space for [mem size > > > > 0x0020 64bit pref] > > > > [1.085108] pci :00:1c.2: BAR 15: failed to assign [mem size > > > > 0x0020 64bit pref] > > > > [1.085199] pci :00:1c.3: BAR 15: no space for [mem size > > > > 0x0020 64bit pref] > > > > [1.085270] pci :00:1c.3: BAR 15: failed to assign [mem size > > > > 0x0020 64bit pref] > > > > [1.085343] pci :00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] > > > > [1.085403] pci :00:1c.2: BAR 13: assigned [io 0x2000-0x2fff] > > > > [1.085470] pci :00:1c.3: BAR 15: no space for [mem size > > > > 0x0020 64bit pref] > > > > [1.085540] pci :00:1c.3: BAR 15: failed to assign [mem size > > > > 0x0020 64bit pref] > > > > [1.085613] pci :00:1c.2: BAR 14: no space for [mem size > > > > 0x0020] > > > > [1.085672] pci :00:1c.2: BAR 14: failed to assign [mem size > > > > 0x0020] > > > > [1.085738] pci :00:1c.2: BAR 15: no space for [mem size > > > > 0x0020 64bit pref] > > > > [1.085808] pci :00:1c.2: BAR 15: failed to assign [mem size > > > > 0x0020 64bit pref] > > > > [1.085884] pci :00:1c.0: BAR 15: no space for [mem size > > > > 0x0020 64bit pref] > > > > [1.085954] pci :00:1c.0: BAR 15: failed to assign [mem size > > > > 0x0020 64bit pref] > > > > [1.086026] pci :00:1c.0: PCI bridge to [bus 01] > > > > [1.086083] pci :00:1c.0: bridge window [io 0x1000-0x1fff] > > > > [1.086144] pci :00:1c.0: bridge window [mem > > > > 0xd040-0xd07f] > > > > > > The "no space" and "failed to assign" messages are all for bridge > > > windows (13 is the I/O window, 14 is the MMIO window, 15 is the MMIO > > > pref window). I can't tell if you have any devices below these > > > bridges (lspci would show them). If you don't have any devices below > > > these bridges, you can ignore the messages. > > > > I have the devices below these bridges. FPGA endpoint is connected to > > '00:1c.0 PCI bridge' and Ethernet controller is connected to '00:1c.3 > > PCI bridge'. > > Does these messages impact the functionality of the connected devices? > > Yes. We tried to allocate 0x0020 of prefetchable MMIO to 00:1c.0 > for use by the FPGA endpoint. But this failed, so there is no > prefetchable MMIO available for the FPGA. The 0xd040-0xd07f > non-prefetachable MMIO space *is* available for it. > > Similarly, we were unable to allocate 0x0020 of prefetchable MMIO > for the 00:1c.3 bridge for use by the ethernet controller. I don't > know what non-prefetchable MMIO space was allocated or what the NIC > needs. > > "lspci -v" will show you what the FPGA and the NIC need. > > > If so what kind of impact and is there any solution for this? > > > Also, I'd like to know why "no space" and "failed to assign" > > messages displayed? > > These messages mean we tried to allocate space for the bridges but we > unable to do so. This is because either the host bridge didn't have > big enough apertures (on x86, these usually come from ACPI _CRS > methods), or there's a bug in the Linux allocation algorithms. > > I can't tell anything more without seeing the complete dmesg log, > which contains the host bridge aperture information and the BAR sizes > of the FPGA and NIC. Thank you for the clarification. dmesg log is attached. If PCI bridge aperture is small, What is the most sensible way to proceed? > > Bjorn -- Thanks, Sekhar dmesg_log Description: Binary data ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: pcie: kernel log - BAR 15: no space for... BAR 15: failed to assign..
On Wed, Feb 12, 2020 at 1:46 AM Bjorn Helgaas wrote: > > On Tue, Feb 11, 2020 at 10:02:13PM +0530, Muni Sekhar wrote: > > On Tue, Feb 11, 2020 at 8:10 PM Bjorn Helgaas wrote: > > > On Tue, Feb 11, 2020 at 07:36:00PM +0530, Muni Sekhar wrote: > > > > On Tue, Feb 11, 2020 at 3:58 AM Bjorn Helgaas > > > > wrote: > > > > > On Sun, Feb 09, 2020 at 07:59:41AM +0530, Muni Sekhar wrote: > > > > > > Hi all, > > > > > > > > > > > > After rebooting the system following messages are seen in dmesg. > > > > > > Not sure if these indicate a problem. Can some one look at these and > > > > > > confirm if this is problem or can be ignored ? > > > > > > > > > > > > Also any suggestions as to what would cause this? > > > > > > > > > > > > [1.084728] pci :00:1c.0: BAR 15: no space for [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.084813] pci :00:1c.0: BAR 15: failed to assign [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.084890] pci :00:1c.2: BAR 14: no space for [mem size > > > > > > 0x0020] > > > > > > [1.084949] pci :00:1c.2: BAR 14: failed to assign [mem size > > > > > > 0x0020] > > > > > > [1.085037] pci :00:1c.2: BAR 15: no space for [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085108] pci :00:1c.2: BAR 15: failed to assign [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085199] pci :00:1c.3: BAR 15: no space for [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085270] pci :00:1c.3: BAR 15: failed to assign [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085343] pci :00:1c.0: BAR 13: assigned [io > > > > > > 0x1000-0x1fff] > > > > > > [1.085403] pci :00:1c.2: BAR 13: assigned [io > > > > > > 0x2000-0x2fff] > > > > > > [1.085470] pci :00:1c.3: BAR 15: no space for [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085540] pci :00:1c.3: BAR 15: failed to assign [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085613] pci :00:1c.2: BAR 14: no space for [mem size > > > > > > 0x0020] > > > > > > [1.085672] pci :00:1c.2: BAR 14: failed to assign [mem size > > > > > > 0x0020] > > > > > > [1.085738] pci :00:1c.2: BAR 15: no space for [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085808] pci :00:1c.2: BAR 15: failed to assign [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085884] pci :00:1c.0: BAR 15: no space for [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.085954] pci :00:1c.0: BAR 15: failed to assign [mem size > > > > > > 0x0020 64bit pref] > > > > > > [1.086026] pci :00:1c.0: PCI bridge to [bus 01] > > > > > > [1.086083] pci :00:1c.0: bridge window [io 0x1000-0x1fff] > > > > > > [1.086144] pci :00:1c.0: bridge window [mem > > > > > > 0xd040-0xd07f] > > > > > > > > > > The "no space" and "failed to assign" messages are all for bridge > > > > > windows (13 is the I/O window, 14 is the MMIO window, 15 is the MMIO > > > > > pref window). I can't tell if you have any devices below these > > > > > bridges (lspci would show them). If you don't have any devices below > > > > > these bridges, you can ignore the messages. > > > > > > > > I have the devices below these bridges. FPGA endpoint is connected to > > > > '00:1c.0 PCI bridge' and Ethernet controller is connected to '00:1c.3 > > > > PCI bridge'. > > > > Does these messages impact the functionality of the connected devices? > > > > > > Yes. We tried to allocate 0x0020 of prefetchable MMIO to 00:1c.0 > > > for use by the FPGA endpoint. But this failed, so there is no > > > prefetchable MMIO available for the FPGA. The 0xd040-0xd07f > > > non-prefetachable MMIO space *is* available for it. > &
Re: pcie: kernel log - BAR 15: no space for... BAR 15: failed to assign..
On Tue, Feb 11, 2020 at 3:58 AM Bjorn Helgaas wrote: > > On Sun, Feb 09, 2020 at 07:59:41AM +0530, Muni Sekhar wrote: > > Hi all, > > > > After rebooting the system following messages are seen in dmesg. > > Not sure if these indicate a problem. Can some one look at these and > > confirm if this is problem or can be ignored ? > > > > Also any suggestions as to what would cause this? > > > > [1.084728] pci :00:1c.0: BAR 15: no space for [mem size > > 0x0020 64bit pref] > > [1.084813] pci :00:1c.0: BAR 15: failed to assign [mem size > > 0x0020 64bit pref] > > [1.084890] pci :00:1c.2: BAR 14: no space for [mem size 0x0020] > > [1.084949] pci :00:1c.2: BAR 14: failed to assign [mem size > > 0x0020] > > [1.085037] pci :00:1c.2: BAR 15: no space for [mem size > > 0x0020 64bit pref] > > [1.085108] pci :00:1c.2: BAR 15: failed to assign [mem size > > 0x0020 64bit pref] > > [1.085199] pci :00:1c.3: BAR 15: no space for [mem size > > 0x0020 64bit pref] > > [1.085270] pci :00:1c.3: BAR 15: failed to assign [mem size > > 0x0020 64bit pref] > > [1.085343] pci :00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] > > [1.085403] pci :00:1c.2: BAR 13: assigned [io 0x2000-0x2fff] > > [1.085470] pci :00:1c.3: BAR 15: no space for [mem size > > 0x0020 64bit pref] > > [1.085540] pci :00:1c.3: BAR 15: failed to assign [mem size > > 0x0020 64bit pref] > > [1.085613] pci :00:1c.2: BAR 14: no space for [mem size 0x0020] > > [1.085672] pci :00:1c.2: BAR 14: failed to assign [mem size > > 0x0020] > > [1.085738] pci :00:1c.2: BAR 15: no space for [mem size > > 0x0020 64bit pref] > > [1.085808] pci :00:1c.2: BAR 15: failed to assign [mem size > > 0x0020 64bit pref] > > [1.085884] pci :00:1c.0: BAR 15: no space for [mem size > > 0x0020 64bit pref] > > [1.085954] pci :00:1c.0: BAR 15: failed to assign [mem size > > 0x0020 64bit pref] > > [1.086026] pci :00:1c.0: PCI bridge to [bus 01] > > [1.086083] pci :00:1c.0: bridge window [io 0x1000-0x1fff] > > [1.086144] pci :00:1c.0: bridge window [mem 0xd040-0xd07f] > > The "no space" and "failed to assign" messages are all for bridge > windows (13 is the I/O window, 14 is the MMIO window, 15 is the MMIO > pref window). I can't tell if you have any devices below these > bridges (lspci would show them). If you don't have any devices below > these bridges, you can ignore the messages. I have the devices below these bridges. FPGA endpoint is connected to '00:1c.0 PCI bridge' and Ethernet controller is connected to '00:1c.3 PCI bridge'. Does these messages impact the functionality of the connected devices? If so what kind of impact and is there any solution for this? Also, I'd like to know why "no space" and "failed to assign" messages displayed? > > Bjorn -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
pcie: kernel log - BAR 15: no space for... BAR 15: failed to assign..
Hi all, After rebooting the system following messages are seen in dmesg. Not sure if these indicate a problem. Can some one look at these and confirm if this is problem or can be ignored ? Also any suggestions as to what would cause this? [1.084728] pci :00:1c.0: BAR 15: no space for [mem size 0x0020 64bit pref] [1.084813] pci :00:1c.0: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.084890] pci :00:1c.2: BAR 14: no space for [mem size 0x0020] [1.084949] pci :00:1c.2: BAR 14: failed to assign [mem size 0x0020] [1.085037] pci :00:1c.2: BAR 15: no space for [mem size 0x0020 64bit pref] [1.085108] pci :00:1c.2: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.085199] pci :00:1c.3: BAR 15: no space for [mem size 0x0020 64bit pref] [1.085270] pci :00:1c.3: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.085343] pci :00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] [1.085403] pci :00:1c.2: BAR 13: assigned [io 0x2000-0x2fff] [1.085470] pci :00:1c.3: BAR 15: no space for [mem size 0x0020 64bit pref] [1.085540] pci :00:1c.3: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.085613] pci :00:1c.2: BAR 14: no space for [mem size 0x0020] [1.085672] pci :00:1c.2: BAR 14: failed to assign [mem size 0x0020] [1.085738] pci :00:1c.2: BAR 15: no space for [mem size 0x0020 64bit pref] [1.085808] pci :00:1c.2: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.085884] pci :00:1c.0: BAR 15: no space for [mem size 0x0020 64bit pref] [1.085954] pci :00:1c.0: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.086026] pci :00:1c.0: PCI bridge to [bus 01] [1.086083] pci :00:1c.0: bridge window [io 0x1000-0x1fff] [1.086144] pci :00:1c.0: bridge window [mem 0xd040-0xd07f] -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: read the memory mapped address - pcie - kernel hangs
Thanks, I'll check it out. On Sat, 11 Jan, 2020, 4:33 AM Onur Atilla, wrote: > On 10.01.20 15:58, Muni Sekhar wrote: > > On Fri, Jan 10, 2020 at 4:46 PM Primoz Beltram > wrote: > >> > >> Hi, > >> Have read also other replays to this topic. > >> I have seen-debug such deadlock problems with FPGA based PCIe endpoint > >> devices (Xilinx chips) and usually (if not signal integrity problems), > >> the problem was in wrong AXI master/slave bus handling in FPGA design. > >> I guess you have FPGA Xilinx PCIe endpoint IP core attached as AXI > >> master to FPGA internal AXI bus (access to AXI slaves inside FPGA > design). > >> If FPGA code in your design does not handle correctly AXI master > >> read/write requests, e.g. FPGA AXI slave does not generate bus ACK in > >> correct way, the PCIe bus will stay locked (no PCIe completion sent > >> back), resulting in complete system lock. Some PCIe root chips have > >> diagnostic LEDs to help decode PCIe problems. > >> From your notice about doing two 32bit reads on 64bit CPU, I would > >> guess the problem is in handling AXI transfer size signals in FPGA slave > >> code. > >> I would suggest you to check the code in FPGA design. You can use FPGA > >> test bench simulation to check the behaviour of PCIe endpoint originated > >> AXI read/write requests. > >> Xilinx provides test bench simulation code for their PCIe IP's. > >> They provide also PCIe root port model, so you can simulate AXI > >> read/writes accesses as they would come from CPU I/O memory requests via > >> PCIe TLPs. > > Thank you so much for sharing valuable information, will work on this. > > > >> WBR Primoz > > Hi, > > you may also want to have a look at the AXI Timeout Block (ATB) to > prevent system/core locks due to a missing ACK of a slave. If given by > the HW, ATB generates an alternative response in case the slave fails to > respond within a given time. It may also trigger an interrupt to help > handle/debug the error. > > Regards, > Onur > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: read the memory mapped address - pcie - kernel hangs
On Fri, Jan 10, 2020 at 4:46 PM Primoz Beltram wrote:
>
> Hi,
> Have read also other replays to this topic.
> I have seen-debug such deadlock problems with FPGA based PCIe endpoint
> devices (Xilinx chips) and usually (if not signal integrity problems),
> the problem was in wrong AXI master/slave bus handling in FPGA design.
> I guess you have FPGA Xilinx PCIe endpoint IP core attached as AXI
> master to FPGA internal AXI bus (access to AXI slaves inside FPGA design).
> If FPGA code in your design does not handle correctly AXI master
> read/write requests, e.g. FPGA AXI slave does not generate bus ACK in
> correct way, the PCIe bus will stay locked (no PCIe completion sent
> back), resulting in complete system lock. Some PCIe root chips have
> diagnostic LEDs to help decode PCIe problems.
> From your notice about doing two 32bit reads on 64bit CPU, I would
> guess the problem is in handling AXI transfer size signals in FPGA slave
> code.
> I would suggest you to check the code in FPGA design. You can use FPGA
> test bench simulation to check the behaviour of PCIe endpoint originated
> AXI read/write requests.
> Xilinx provides test bench simulation code for their PCIe IP's.
> They provide also PCIe root port model, so you can simulate AXI
> read/writes accesses as they would come from CPU I/O memory requests via
> PCIe TLPs.
Thank you so much for sharing valuable information, will work on this.
> WBR Primoz
>
> On 8. 01. 20 20:00, Muni Sekhar wrote:
> > Hi All,
> >
> > I have module with Xilinx FPGA. It implements UART(s), SPI(s),
> > parallel I/O and interfaces them to the Host CPU via PCI Express bus.
> > I see that my system freezes without capturing the crash dump for certain
> > tests.
> > I debugged this issue and it was tracked down to the ‘readl()’ in
> > interrupt handler code
> >
> > In ISR, first reads the Interrupt Status register using ‘readl()’ as
> > given below.
> > status = readl(ctrl->reg + INT_STATUS);
> >
> > And then clears the pending interrupts using ‘writel()’ as given blow.
> > writel(status, ctrl->reg + INT_STATUS);
> >
> > I've noticed a kernel hang if INT_STATUS register read again after
> > clearing the pending interrupts.
> >
> > My system freezes only after executing the same ISR code after
> > millions of interrupts. Basically reading the memory mapped register
> > in ISR resulting this behavior.
> > If I comment “status = readl(ctrl->reg + INT_STATUS);” after clearing
> > the pending interrupts then system is stable .
> >
> > As a temporary workaround I avoided reading the INT_STATUS register
> > after clearing the pending bits, and this code change works fine.
> >
> > Can someone clarify me why the kernel hangs without crash dump incase
> > if I read the INT_STATUS register using readl() after
> > clearing(writel()) the pending bits?
> >
> > To read the memory mapped IO kernel provides {read}{b,w,l,q}() API’s.
> > If PCIe card is not responsive , can call to readl() from interrupt
> > context makes system freeze?
> >
> > Thanks for any suggestions and solutions to this problem!
> >
> > Snippet of the ISR code is given blow:
> > https://pastebin.com/as2tSPwE
> >
> >
> > static irqreturn_t pcie_isr(int irq, void *data)
> >
> > {
> >
> > struct test_device *ctrl = (struct test_device *)data;
> >
> > u32 status;
> >
> > …
> >
> >
> >
> > status = readl(ctrl->reg + INT_STATUS);
> >
> > /*
> >
> > * Check to see if it was our interrupt
> >
> > */
> >
> > if (!(status & 0x000C))
> >
> > return IRQ_NONE;
> >
> >
> >
> > /* Clear the interrupt */
> >
> > writel(status, ctrl->reg + INT_STATUS);
> >
> >
> >
> > if (status & 0x0004) {
> >
> > /*
> >
> > * Tx interrupt pending.
> >
> > */
> >
> >
> >
> > }
> >
> >
> >
> > if (status & 0x0008) {
> >
> > /* Rx interrupt Pending */
> >
> > /* The system freezes if I read again the INT_STATUS
> > register as given below */
> >
> > status = readl(ctrl->reg + INT_STATUS);
> >
> >
> >
> > }
> >
> > ..
> >
> > return IRQ_HANDLED;
> > }
> >
>
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: read the memory mapped address - pcie - kernel hangs
On Thu, Jan 9, 2020 at 5:07 PM Greg KH wrote: > > On Thu, Jan 09, 2020 at 04:44:16PM +0530, Muni Sekhar wrote: > > On Thu, Jan 9, 2020 at 1:15 AM Greg KH wrote: > > > > > > On Thu, Jan 09, 2020 at 12:30:20AM +0530, Muni Sekhar wrote: > > > > Hi All, > > > > > > > > I have module with Xilinx FPGA. It implements UART(s), SPI(s), > > > > parallel I/O and interfaces them to the Host CPU via PCI Express bus. > > > > I see that my system freezes without capturing the crash dump for > > > > certain tests. > > > > I debugged this issue and it was tracked down to the ‘readl()’ in > > > > interrupt handler code > > > > > > > > In ISR, first reads the Interrupt Status register using ‘readl()’ as > > > > given below. > > > > status = readl(ctrl->reg + INT_STATUS); > > > > > > > > And then clears the pending interrupts using ‘writel()’ as given blow. > > > > writel(status, ctrl->reg + INT_STATUS); > > > > > > > > I've noticed a kernel hang if INT_STATUS register read again after > > > > clearing the pending interrupts. > > > > > > Why would you read that register again after writing to it? > > > > > > And are you sure you are reading/writing the correct size of the irq > > > field? I thought it was a "word" not "long"? But that might depend on > > > your hardware, do you have a pointer to the kernel driver source you are > > > using for all of this? > > Actually no need to read that register again. But reading that > > register again should not freeze the system, right? > > It might, depends on your hardware. Go talk to the hardware vendor if > you have questions about this. > > > INT_STATUS register is 32-bit width, so readl() API is used(my system > > is x86_64, Intel(R) Atom(TM) CPU). Instead of readl(), do I need to > > use readw() twice? If so what is reason for this code change? > > Ok, if that register is 32 bits, that's fine. It all depends on your > hardware. > > > I’m trying to understand why system freezes without any crash dump > > while reading the memory mapped IO from interrupt context? > > Because your hardware locked things up? Here hardware means PCI controller on host side or PCI endpoint(FPGA) device? > > > FPGA code might be buggy, it may not send the completion for Memory > > Read request. But CPU should not get stuck at LOAD instruction level.. > > PCI hardware can do lots of bad things to a system, it _IS_ part of the > memory bus, right? So of course it can lock the CPU at a read. > > > When it hung, it does not even respond for SYSRQ button(SYSRQ is > > enabled – in normal scenario it works), only way to recover is reboot > > the system. I enabled almost all the kernel.panic* variables. I set > > the kernel.panic to positive, so it should reboot after panic instead > > of just hang. But it’s not rebooting by itself. Even 'pstore\ramoops’ > > also not helped. > > After reboot I looked at the kern.log and most of the times it has > > “^@^@^@^ ...“ line just before reboot. > > > > Okay, I will write the minimalistic code to reproduce this one and > > then share with you guys. > > What's wrong with the real/full driver source? > > And again, why are you trying to read the register twice? I’m not the original author of this driver, so no idea why it implemented like that. May be to verify the register contents after clearing the bits… > > thanks, > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: read the memory mapped address - pcie - kernel hangs
On Thu, Jan 9, 2020 at 1:15 AM Greg KH wrote: > > On Thu, Jan 09, 2020 at 12:30:20AM +0530, Muni Sekhar wrote: > > Hi All, > > > > I have module with Xilinx FPGA. It implements UART(s), SPI(s), > > parallel I/O and interfaces them to the Host CPU via PCI Express bus. > > I see that my system freezes without capturing the crash dump for certain > > tests. > > I debugged this issue and it was tracked down to the ‘readl()’ in > > interrupt handler code > > > > In ISR, first reads the Interrupt Status register using ‘readl()’ as > > given below. > > status = readl(ctrl->reg + INT_STATUS); > > > > And then clears the pending interrupts using ‘writel()’ as given blow. > > writel(status, ctrl->reg + INT_STATUS); > > > > I've noticed a kernel hang if INT_STATUS register read again after > > clearing the pending interrupts. > > Why would you read that register again after writing to it? > > And are you sure you are reading/writing the correct size of the irq > field? I thought it was a "word" not "long"? But that might depend on > your hardware, do you have a pointer to the kernel driver source you are > using for all of this? Actually no need to read that register again. But reading that register again should not freeze the system, right? INT_STATUS register is 32-bit width, so readl() API is used(my system is x86_64, Intel(R) Atom(TM) CPU). Instead of readl(), do I need to use readw() twice? If so what is reason for this code change? I’m trying to understand why system freezes without any crash dump while reading the memory mapped IO from interrupt context? FPGA code might be buggy, it may not send the completion for Memory Read request. But CPU should not get stuck at LOAD instruction level.. When it hung, it does not even respond for SYSRQ button(SYSRQ is enabled – in normal scenario it works), only way to recover is reboot the system. I enabled almost all the kernel.panic* variables. I set the kernel.panic to positive, so it should reboot after panic instead of just hang. But it’s not rebooting by itself. Even 'pstore\ramoops’ also not helped. After reboot I looked at the kern.log and most of the times it has “^@^@^@^ ...“ line just before reboot. Okay, I will write the minimalistic code to reproduce this one and then share with you guys. > > thanks, > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
read the memory mapped address - pcie - kernel hangs
Hi All,
I have module with Xilinx FPGA. It implements UART(s), SPI(s),
parallel I/O and interfaces them to the Host CPU via PCI Express bus.
I see that my system freezes without capturing the crash dump for certain tests.
I debugged this issue and it was tracked down to the ‘readl()’ in
interrupt handler code
In ISR, first reads the Interrupt Status register using ‘readl()’ as
given below.
status = readl(ctrl->reg + INT_STATUS);
And then clears the pending interrupts using ‘writel()’ as given blow.
writel(status, ctrl->reg + INT_STATUS);
I've noticed a kernel hang if INT_STATUS register read again after
clearing the pending interrupts.
My system freezes only after executing the same ISR code after
millions of interrupts. Basically reading the memory mapped register
in ISR resulting this behavior.
If I comment “status = readl(ctrl->reg + INT_STATUS);” after clearing
the pending interrupts then system is stable .
As a temporary workaround I avoided reading the INT_STATUS register
after clearing the pending bits, and this code change works fine.
Can someone clarify me why the kernel hangs without crash dump incase
if I read the INT_STATUS register using readl() after
clearing(writel()) the pending bits?
To read the memory mapped IO kernel provides {read}{b,w,l,q}() API’s.
If PCIe card is not responsive , can call to readl() from interrupt
context makes system freeze?
Thanks for any suggestions and solutions to this problem!
Snippet of the ISR code is given blow:
https://pastebin.com/as2tSPwE
static irqreturn_t pcie_isr(int irq, void *data)
{
struct test_device *ctrl = (struct test_device *)data;
u32 status;
…
status = readl(ctrl->reg + INT_STATUS);
/*
* Check to see if it was our interrupt
*/
if (!(status & 0x000C))
return IRQ_NONE;
/* Clear the interrupt */
writel(status, ctrl->reg + INT_STATUS);
if (status & 0x0004) {
/*
* Tx interrupt pending.
*/
}
if (status & 0x0008) {
/* Rx interrupt Pending */
/* The system freezes if I read again the INT_STATUS
register as given below */
status = readl(ctrl->reg + INT_STATUS);
}
..
return IRQ_HANDLED;
}
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to printk synchronously
On Wed, Nov 27, 2019 at 2:48 PM Valdis Klētnieks wrote: > > On Tue, 26 Nov 2019 22:31:08 +, Lucas Tanure said: > > Hi, > > > > What about ftrace ? Documentation/trace/ftrace.txt > > That won't help - his ^@^@^@ is a result of the system stopping and no longer > writing to disk, so his logfile has blocks allocated to it but not yet written > to. > > Using ftrace will have the same problem, if his kernel is locking up and not > syncing to disk. I too noticed this kind of behavior i.e. kernel locks up and won’t respond for SYSRQ key(even it is enabled), just system freezes. Only way to recover is hard reboot, after reboot I looked at the kernel log and most of the times it has ^@^@^@. My system is installed with crashdump tools and it captures the crashed Linux kernel dump for soft\hard lockups triggered via /sys/kernel/debug/provoke-crash/DIRECT file, but the crashdump tool not helped in the original scenario. Apart from soft\hard lockups, are there any other scenarios kernel locks up and won’t respond for SYSRQ key? Is there any kernel patch I can apply to get the stack trace of each CPU before it stops? I enabled “kernel.softlockup_panic = 1” and “kernel.hardlockup_panic = 1” variables, but just system freezes without panic, so can we say this fault neither soft lockup nor hard lockup? Does machine check exceptions result the system to freeze? If so how to capture the dump\log for this scenario? I build the kernel with lockdep too, but does not show any possible lockups. Netconsole also not helped. > > A better approach would be to use netconsole to send all the console output to > another machine, or serial console if that's an option. > > Though I have to wonder how he's determining it's a deadlock issue rather than > a panic that's just plain stopping the system - building the kernel with > lockdep support should reveal the issue before a lockup. And if it *is* a > deadlock, there should be sufficient info in the watchdog logging (assuming > the > hardware has some sort of watchdog support, as most systems do). > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
NMI injection
Hi All, Can someone clarify me what is “NMI injection” means? Does it helps when system is frozen? If so how to do this for Intel Atom processor machines? I configured my system to respond for SysRq key press, but I see when system is frozen then SysRq key press has no effect. I’ve read that when kernel is locked up it won’t respond for SysRq key press actions. What is the definition for “kernel locked up” means? And how to solve this? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
how to get kernel crashdump
Hi All, I’m having a Linux system, I’m seeing it gets hung during certain tests. When it hung, it does not even respond for SYSRQ button, only way to recover is power-button-only. No response for SYSRQ button means kernel crashed? After reboot I looked at the kern.log and most of the times it has “^@^@^@^ ...“ line just before reboot. Can someone clarify me what the kernel log entry “^@^@^@^ ...“ means? I suspect kernel is crashed, but it does give any crashdump in kern.log. Later I enabled the kernel crash dump(sudo apt install linux-crashdump) and rerun the test but still nothing copied to the disk(/var/crash/). I don’t have onboard serial port in my machine, so I tried get the crash dump via netconsole, but this method also does not able to catch the crash dump. Can someone help me how to debug in this scenario? And I'd like to know what other options available to get the crash dump? Any help will be greatly appreciated. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: wait_event()\ wait_event_interruptible()\ wait_event_interruptible_timeout() and wake_up()
On Tue, Aug 6, 2019 at 5:12 PM Valdis Klētnieks wrote: > > On Tue, 06 Aug 2019 14:15:53 +0530, Muni Sekhar said: > > > If they do different things, does the waiting threads wakeup order is > > the same in which they were enqueued (FIFO order)? > > You missed the point - if you have (for example) something that's waiting for > mouse I/O and something that's waiting for a network packet, under what > conditions will they be using the same wait event? In this example they won't wait on the same wait event. Let us consider buggy code is written like that and more than one process(they do different things) waiting on the same wait event which process gets woken up? Is the process at the head of the list? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: wait_event()\ wait_event_interruptible()\ wait_event_interruptible_timeout() and wake_up()
On Mon, Jul 29, 2019 at 11:57 PM Valdis Klētnieks wrote: > > On Mon, 29 Jul 2019 22:48:57 +0530, Muni Sekhar said: > > Let us assume that multiple processes are waiting on wait_event()\ > > wait_event_interruptible()\ wait_event_interruptible_timeout(), which > > process gets woken up on calling wake_up()?? > > > > I presume wake_up() picks one process, but is there any algorithm to > > pick which process? > > Hint: If you have more than one process waiting, and they do the same thing > (think multiple copies of the same kthread), it probably doesn't matter. > > If they do different things and which one gets picked matters for correctness, > you're doing it wrong and probably need some locking. > > If they do different things and the results will be correct no matter which > order they're picked, but you want one to go first for latency/througput > considerations, you have a scheduling/priority issue and probably need to fix > it using the vast plethora of knobs and tools available for that purpose. If they do different things, does the waiting threads wakeup order is the same in which they were enqueued (FIFO order)? > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: wait_event()\ wait_event_interruptible()\ wait_event_interruptible_timeout() and wake_up()
On Mon, Jul 29, 2019 at 11:57 PM Valdis Klētnieks wrote: > > On Mon, 29 Jul 2019 22:48:57 +0530, Muni Sekhar said: > > Let us assume that multiple processes are waiting on wait_event()\ > > wait_event_interruptible()\ wait_event_interruptible_timeout(), which > > process gets woken up on calling wake_up()?? > > > > I presume wake_up() picks one process, but is there any algorithm to > > pick which process? > > Hint: If you have more than one process waiting, and they do the same thing > (think multiple copies of the same kthread), it probably doesn't matter. > > If they do different things and which one gets picked matters for correctness, > you're doing it wrong and probably need some locking. > > If they do different things and the results will be correct no matter which > order they're picked, but you want one to go first for latency/througput > considerations, you have a scheduling/priority issue and probably need to fix > it using the vast plethora of knobs and tools available for that purpose. What are those tools? Can you give some more details on how to fix latency/throughput issues using those tools.. > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: wait_event()\ wait_event_interruptible()\ wait_event_interruptible_timeout() and wake_up()
On Mon, Jul 29, 2019 at 11:31 PM Bharath Vedartham wrote: > > On Mon, Jul 29, 2019 at 10:48:57PM +0530, Muni Sekhar wrote: > > Hi All, > > > > Let us assume that multiple processes are waiting on wait_event()\ > > wait_event_interruptible()\ wait_event_interruptible_timeout(), which > > process gets woken up on calling wake_up()?? > > > > I presume wake_up() picks one process, but is there any algorithm to > > pick which process? > > > > > > -- > > Thanks, > > Sekhar > Sorry to spoil the fun here. But check out what the queue data structure > is all about. 'wait_queue' :) A wait queue is a doubly linked list of wait_queue_t structures that hold pointers to the process task structures of the processes that are blocking. Each list is headed up by a wait_queue_head_t structure, which marks the head of the list and holds the spinlock to the list to prevent wait_queue_t additional race conditions > > Thank you > Bharath > > ___ > > Kernelnewbies mailing list > > Kernelnewbies@kernelnewbies.org > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
interrupt latency
Hi All, I used the Linux kernel’s ‘Ftrace’ framework for tracing the interrupt latencies. Sometimes I noticed a delay(time between do_IRQ() to start of ISR()) in start of ISR(interrupt service routine) to execute , some other times I noticed ISR execution time(entering and exiting a function) is very high. I’d like to know in which scenarios, ISR gets executed lately? In which scenarios, ISR execution time is very high? Can someone please clarify me on this. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
wait_event()\ wait_event_interruptible()\ wait_event_interruptible_timeout() and wake_up()
Hi All, Let us assume that multiple processes are waiting on wait_event()\ wait_event_interruptible()\ wait_event_interruptible_timeout(), which process gets woken up on calling wake_up()?? I presume wake_up() picks one process, but is there any algorithm to pick which process? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CONFIG_CC_STACKPROTECTOR_STRONG
On Tue, 9 Jul, 2019, 11:16 PM Denis Kirjanov, wrote: > > > On Tuesday, July 9, 2019, Muni Sekhar wrote: > >> On Tue, Jul 9, 2019 at 10:56 PM Denis Kirjanov >> wrote: >> > >> > >> > >> > On Tuesday, July 9, 2019, Muni Sekhar wrote: >> >> >> >> Hi All, >> >> >> >> >> >> My Kernel is built with the following options: >> >> >> >> >> >> >> >> CONFIG_CC_STACKPROTECTOR=y >> >> >> >> CONFIG_CC_STACKPROTECTOR_STRONG=y >> >> >> >> >> >> >> >> >> >> >> >> We use out-of-tree kernel modules in our project and I need to measure >> the performance of it by using a bit older gcc version 4.8.5. >> >> >> >> >> >> >> >> I can build the modules with gcc above 5 version, but when I try to >> use gcc version 4.8.5 I’m getting the following error: >> >> >> >> >> >> >> >> Makefile:693: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: >> -fstack-protector-strong not supported by compiler >> >> >> >> >> >> >> >> So it looks like gcc 4.8.5 does not support >> CONFIG_CC_STACKPROTECTOR_STRONG option, but how to instruct gcc to ignore >> this one? >> >> >> >> >> >> >> >> In runtime, is it possible to instruct kernel to ignore >> “CONFIG_CC_STACKPROTECTOR_STRONG=y” (without building the kernel) by using >> sysctl or any other method? >> >> >> >> >> > >> > >> > Just disable it in your .config file >> >> I disabled in /lib/modules/$(uname -r)/build/.config, but still get >> that error. Does kernel needs to be recompiled? >> >> CONFIG_CC_STACKPROTECTOR=y >> # CONFIG_CC_STACKPROTECTOR_NONE is not set >> # CONFIG_CC_STACKPROTECTOR_REGULAR is not set >> # CONFIG_CC_STACKPROTECTOR_STRONG is not set >> >> > You have to disable it in your kernel source directory > and then run ‘make oldconfig’ > I got this error while building out of tree module in Ubuntu system. I'm directly using the Ubuntu distribution kernel , so where should I suppose to run the 'make old config'? Because I didn't have the kernel source code. > > >> > >> >> >> >> Any help is appreciated. >> >> >> >> >> >> >> >> -- >> >> Thanks, >> >> Sekhar >> > >> > >> > >> > -- >> > Regards / Mit besten Grüßen, >> > Denis >> > >> >> >> -- >> Thanks, >> Sekhar >> > > > -- > Regards / Mit besten Grüßen, > Denis > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CONFIG_CC_STACKPROTECTOR_STRONG
On Tue, Jul 9, 2019 at 10:56 PM Denis Kirjanov wrote: > > > > On Tuesday, July 9, 2019, Muni Sekhar wrote: >> >> Hi All, >> >> >> My Kernel is built with the following options: >> >> >> >> CONFIG_CC_STACKPROTECTOR=y >> >> CONFIG_CC_STACKPROTECTOR_STRONG=y >> >> >> >> >> >> We use out-of-tree kernel modules in our project and I need to measure the >> performance of it by using a bit older gcc version 4.8.5. >> >> >> >> I can build the modules with gcc above 5 version, but when I try to use gcc >> version 4.8.5 I’m getting the following error: >> >> >> >> Makefile:693: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: >> -fstack-protector-strong not supported by compiler >> >> >> >> So it looks like gcc 4.8.5 does not support CONFIG_CC_STACKPROTECTOR_STRONG >> option, but how to instruct gcc to ignore this one? >> >> >> >> In runtime, is it possible to instruct kernel to ignore >> “CONFIG_CC_STACKPROTECTOR_STRONG=y” (without building the kernel) by using >> sysctl or any other method? >> >> > > > Just disable it in your .config file I disabled in /lib/modules/$(uname -r)/build/.config, but still get that error. Does kernel needs to be recompiled? CONFIG_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_NONE is not set # CONFIG_CC_STACKPROTECTOR_REGULAR is not set # CONFIG_CC_STACKPROTECTOR_STRONG is not set > > >> >> Any help is appreciated. >> >> >> >> -- >> Thanks, >> Sekhar > > > > -- > Regards / Mit besten Grüßen, > Denis > -- Thanks, Sekhar
CONFIG_CC_STACKPROTECTOR_STRONG
Hi All, My Kernel is built with the following options: CONFIG_CC_STACKPROTECTOR=y CONFIG_CC_STACKPROTECTOR_STRONG=y We use out-of-tree kernel modules in our project and I need to measure the performance of it by using a bit older gcc version 4.8.5. I can build the modules with gcc above 5 version, but when I try to use gcc version 4.8.5 I’m getting the following error: Makefile:693: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler So it looks like gcc 4.8.5 does not support CONFIG_CC_STACKPROTECTOR_STRONG option, but how to instruct gcc to ignore this one? In runtime, is it possible to instruct kernel to ignore “CONFIG_CC_STACKPROTECTOR_STRONG=y” (without building the kernel) by using sysctl or any other method? Any help is appreciated. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
drivers/char/efirtc.c - efi_rtc_open\ efi_rtc_close
Hello All, The drivers/char/efirtc.c file has ‘struct file_operations.open’ & ‘struct file_operations.close’ functions efi_rtc_open()\ efi_rtc_close() does nothing, just returns ‘0’. So it accept multiple open files at the same time. If we don’t define these empty function, still driver accepts multiple open() calls at the same time, right? If so I’d like to know what is the advantage of keeping these function which does nothing instead of removing it from driver? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
gcov tool data - for a specific kernel module
Hi All, I’m trying to use the ‘gcov’ tool for an out-of-tree kernel module. For this, I configured the kernel with “CONFIG_DEBUGFS=y” , “CONFIG_GCOV_KERNEL=y” and mounted the debugfs. I noticed that “file.gcno” file generated by gcc when compiling with option -ftest-coverage. I’d like to know how to generate “file.gcda”? I’ve few test utilities(ELF 64-bit LSB executables and python test scripts) to test our driver. I’d like to understand how to get the code coverage data for my driver on running my test scripts, can someone please clarify me on this? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
gcov tool data - for a specific kernel module
Hi All, I’m trying to use the ‘gcov’ tool for an out-of-tree kernel module. For this, I configured the kernel with “CONFIG_DEBUGFS=y” , “CONFIG_GCOV_KERNEL=y” and mounted the debugfs. I noticed that “file.gcno” file generated by gcc when compiling with option -ftest-coverage. I’d like to know how to generate “file.gcda”? I’ve few test utilities(ELF 64-bit LSB executables and python test scripts) to test our driver. I’d like to understand how to get the code coverage data for my driver on running my test scripts, can someone please clarify me on this? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
interruptible sleep tasks
Hi All, During kernel drivers testing I see lot of user mode applications blocks forever in interruptible sleep mode. Is there any way to get the corresponding kernel functions stack trace ? I see kernel has “hung_task_timeout_secs” parameter and when a task in D state did not get scheduled for more than this value report a warning. Similarly is it possible to get a warning or kernel functions stack trace when a task in “S - interruptible sleep mode” and did not get scheduled for certain duration? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
sound: ALSA PCM Timestamps
[ Please keep me in CC as I'm not subscribed to the list] Hi All, There are several time stamping functions in ALSA: snd_pcm_status_get_trigger_tstamp snd_pcm_status_get_trigger_htstamp snd_pcm_status_get_tstamp snd_pcm_status_get_htstamp snd_pcm_status_get_audio_htstamp snd_pcm_status_get_driver_htstamp I would like to understand what points in time the resulting functions represent and what is the corresponding kernel mode callback for those API’s. I'd be really grateful if someone took the time to help me clearing my doubt. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: sound: latency and synchronization measurements
On Fri, May 18, 2018 at 6:42 PM, Greg KH <g...@kroah.com> wrote: > On Fri, May 18, 2018 at 06:07:29PM +0530, Muni Sekhar wrote: >> [ Please keep me in CC as I'm not subscribed to the list] >> >> Hi All, >> >> I am trying to characterize the audio synchronization between two >> systems. There is a mechanism to route audio between two systems, we >> run ‘aplay’ at one system and ‘arecord’ in other system. >> >> We need to measure the time difference when audio sample is out at one >> port and arriving at another port in different system. >> >> I plan to add printk’s in “struct snd_pcm_ops” call backs, but does >> these call backs tells when it received first and last audio >> frames\samples? >> >> Or else please suggest any other best method. > > First off you need a "shared timer/clock" between the two systems in > order to have a chance to determine what actually happens here. Good > luck with that! :) Yes, we do have the shared clock. > > Also, there's been tons of research in this area over the years, please > look into that, odds are these problems have been solved already. I > know of several commercial devices that already handle this just fine. > Can you point me some information on this. > best of luck! > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: sound: latency and synchronization measurements
On Fri, May 18, 2018 at 6:53 PM, Aris Aris <father.a...@gmail.com> wrote: > Hi, > > You could try bitbanging any availiable peripheral(i.e gpio) from each > system at the callbacks and have a logic analyzer measuring and reporting > time delay. Thank you very much Aris for this information. I am fairly new to sound sub system, I’m glad if you can point me on the callbacks. Does the sound driver will be notified aplay\arecord open via “snd_xxx_open(struct snd_pcm_substeam *substream)” callback? Which callbacks of sound driver will tell when it received first and last audio frames\samples? > > Best regards, > > Aris > > On Fri, May 18, 2018 at 3:37 PM, Muni Sekhar <munisekhar...@gmail.com> > wrote: >> >> [ Please keep me in CC as I'm not subscribed to the list] >> >> Hi All, >> >> I am trying to characterize the audio synchronization between two >> systems. There is a mechanism to route audio between two systems, we >> run ‘aplay’ at one system and ‘arecord’ in other system. >> >> We need to measure the time difference when audio sample is out at one >> port and arriving at another port in different system. >> >> I plan to add printk’s in “struct snd_pcm_ops” call backs, but does >> these call backs tells when it received first and last audio >> frames\samples? >> >> Or else please suggest any other best method. >> >> >> -- >> Thanks, >> Sekhar >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
sound: latency and synchronization measurements
[ Please keep me in CC as I'm not subscribed to the list] Hi All, I am trying to characterize the audio synchronization between two systems. There is a mechanism to route audio between two systems, we run ‘aplay’ at one system and ‘arecord’ in other system. We need to measure the time difference when audio sample is out at one port and arriving at another port in different system. I plan to add printk’s in “struct snd_pcm_ops” call backs, but does these call backs tells when it received first and last audio frames\samples? Or else please suggest any other best method. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
serial: uart_port->type
Hi All, For the uart_port structure’s “type”, I see the permitted types are none, 8250, 16450, 16550, 16550A, 16650, 16650V2, 16654, 16750, 16850, 16950, and 16954 etc. For FPGA based UART hardware(it has 512 bytes FIFO and supports up to 4Mbps speed) what should be the ‘type’ value? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: serial: start_tx & buffer handling
On Fri, May 4, 2018 at 5:44 PM, loïc tourlonias
<loic.tourlon...@gmail.com> wrote:
> Hi
>
> On Fri, May 4, 2018 at 6:31 AM, Muni Sekhar <munisekhar...@gmail.com> wrote:
>>>
>>> On Fri, May 4, 2018 at 12:04 AM, Greg KH <g...@kroah.com> wrote:
>>> > On Thu, May 03, 2018 at 08:08:48PM +0530, Muni Sekhar wrote:
>>> >> Hi All,
>>> >>
>>> >> I’m trying to understand how user mode buffer is written to low level
>>> >> serial hardware registers.
>>> >>
>>> >> For this I read the kernel code and I came to know that from user mode
>>> >> write() API lands into kernel’s tty_write() ("drivers/tty/tty_io.c")
>>> >> and then it calls a uart_write() ("drivers/tty/serial/serial_core.c").
>>> >>
>>> >> In uart_write(), the buffer is copied to circ_buf and then it calls
>>> >> low level serial hardware driver’s start_tx() (struct uart_ops
>>> >> .start_tx). But here I could not find how the buffer kept in circ_buf
>>> >> is copied to serial port’s TX_FIFO registers?
>>> >>
>>> >> Can someone take a moment to explain me on this?
>>> >
>>> > It all depends on which specific UART driver you are looking at, they
>>> > all do it a bit different depending on the hardware.
>>> >
>>> > Which one are you looking at? Look at what the start_tx callback does
>>> > for that specific driver, that should give you a hint as to how data
>>> > starts flowing. Usually an interrupt is enabled that is used to flush
>>> > the buffer out to the hardware.
>>> >
>>>
>>> I’m looking for any existing sample code which does DMA transfers of
>>> UART transmitted data. I looked at the bcm63xx_uart.c, it looks it
>>> does not handle DMA transfers. Even copying the Tx buffer (from
>>> circ_buf) to UART_FIFO_REG happening in ISR.
>
>
> You can have a look at atmel_serial kernel module (built for ARM).
>
> https://elixir.bootlin.com/linux/latest/source/drivers/tty/serial/atmel_serial.c
>
> The dma buffer is linked to uart circular buffer in prepare_tx() function
> called from uart_startup(). It's released in release_tx() function called
> from uart_shutdown(). DMA buffer is managed in schedule_tx() function called
> from a tasklet triggered by the ISR.
Thanks a lot for this information.
>
> HTH
>
>>>
>>>
>>> > thanks,
>>> >
>>> > greg k-h
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Sekhar
>>>
>>> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: serial: start_tx & buffer handling
On Fri, May 4, 2018 at 12:04 AM, Greg KH <g...@kroah.com> wrote:
> On Thu, May 03, 2018 at 08:08:48PM +0530, Muni Sekhar wrote:
>> Hi All,
>>
>> I’m trying to understand how user mode buffer is written to low level
>> serial hardware registers.
>>
>> For this I read the kernel code and I came to know that from user mode
>> write() API lands into kernel’s tty_write() ("drivers/tty/tty_io.c")
>> and then it calls a uart_write() ("drivers/tty/serial/serial_core.c").
>>
>> In uart_write(), the buffer is copied to circ_buf and then it calls
>> low level serial hardware driver’s start_tx() (struct uart_ops
>> .start_tx). But here I could not find how the buffer kept in circ_buf
>> is copied to serial port’s TX_FIFO registers?
>>
>> Can someone take a moment to explain me on this?
>
> It all depends on which specific UART driver you are looking at, they
> all do it a bit different depending on the hardware.
>
> Which one are you looking at? Look at what the start_tx callback does
> for that specific driver, that should give you a hint as to how data
> starts flowing. Usually an interrupt is enabled that is used to flush
> the buffer out to the hardware.
>
I’m looking for any existing sample code which does DMA transfers of
UART transmitted data. I looked at the bcm63xx_uart.c, it looks it
does not handle DMA transfers. Even copying the Tx buffer (from
circ_buf) to UART_FIFO_REG happening in ISR.
> thanks,
>
> greg k-h
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
serial: start_tx & buffer handling
Hi All,
I’m trying to understand how user mode buffer is written to low level
serial hardware registers.
For this I read the kernel code and I came to know that from user mode
write() API lands into kernel’s tty_write() ("drivers/tty/tty_io.c")
and then it calls a uart_write() ("drivers/tty/serial/serial_core.c").
In uart_write(), the buffer is copied to circ_buf and then it calls
low level serial hardware driver’s start_tx() (struct uart_ops
.start_tx). But here I could not find how the buffer kept in circ_buf
is copied to serial port’s TX_FIFO registers?
Can someone take a moment to explain me on this?
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
serial: custom baud rate
Hi All, >From include/asm-generic/termbits.h , I see baudrate can be one of the standard values: 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 50, 576000, 921600, 100, 1152000, 150, 200, 250, 300, 350, 400. If I need to set a custom baud rates(e.g. 14400, 128000, 256000), does Linux serial framework has any supporting method? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
uart throughput
Hi All, I’ve an uart hardware implemented on Xilinx FPGA image and it connects to host CPU(Intel based chip) on PCIe bus in Linux platform. The following parameters were fixed or varied when measuring the UART throughput in internal loopback mode(UART_RX and UART_TX pins were internally connected): • Uart baud rate • Parity Bit • Stop Bit(s) The primary factor affecting UART throughput is the baud rate, apart from this any other factors affect the UART throughput? For 400 bps uart baud rate, what should be the theoretical peak data throughput? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
sound driver reference
Hi All, I’ve an audio hardware with eight audio engines and it supports “PCM/I2S Inputs , PCM/I2S Outputs, ADC (Analogue Line Inputs), DAC (Analogue Line Outputs), Digital Microphone” interfaces. All these interfaces are implemented on Xilinx FPGA image and it connects to host CPU(Intel based chip) on PCIe bus in Linux platform. I need to implement a sound driver for this. I’m looking for an existing sound driver(without platform driver) for reference. Does the Linux kernel already has sound driver to support this type of hardware? Can anyone point me the reference code for this? I appreciate any help. -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Testing low level UART driver
On Wed, Jan 24, 2018 at 8:53 PM, Greg KH <g...@kroah.com> wrote: > On Wed, Jan 24, 2018 at 08:43:56PM +0530, Muni Sekhar wrote: >> On Wed, Jan 24, 2018 at 6:52 PM, Greg KH <g...@kroah.com> wrote: >> > On Wed, Jan 24, 2018 at 06:46:06PM +0530, Muni Sekhar wrote: >> >> Hi All, >> >> >> >> Does Linux kernel tree has any standard utilities to test any low >> >> level UART driver? >> > >> > What do you mean by "low level UART driver"? >> bcm63xx_uart.c >> >> > >> > Have you tried one of the many different userspace serial port tools? >> I tried only minicom. Could you let me know the best userspace serial >> port tools. > > What doesn't work with minicom? That's a really good tester given that > it exercises the tty layer a lot. I’m trying to record throughput achieved with different baud rates in loopback mode. Does minicom support this? > >> > Those are usually the best test of a system, along with some simple >> > loop-back tests if you have the proper hardware plugged into the serial >> > port. >> > >> > What driver are you trying to test? >> I’m trying to test Broadcom 63xx integrated uart driver. > > What currently does not work with it? The driver has been around for a > very long time, it should be really stable. > > thanks, > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Testing low level UART driver
On Wed, Jan 24, 2018 at 6:52 PM, Greg KH <g...@kroah.com> wrote: > On Wed, Jan 24, 2018 at 06:46:06PM +0530, Muni Sekhar wrote: >> Hi All, >> >> Does Linux kernel tree has any standard utilities to test any low >> level UART driver? > > What do you mean by "low level UART driver"? bcm63xx_uart.c > > Have you tried one of the many different userspace serial port tools? I tried only minicom. Could you let me know the best userspace serial port tools. > Those are usually the best test of a system, along with some simple > loop-back tests if you have the proper hardware plugged into the serial > port. > > What driver are you trying to test? I’m trying to test Broadcom 63xx integrated uart driver. > > thanks, > > greg k-h -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Testing low level UART driver
Hi All, Does Linux kernel tree has any standard utilities to test any low level UART driver? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: what is the mostly used automation test framework
On Sat, Apr 22, 2017 at 8:15 AM, <valdis.kletni...@vt.edu> wrote: > On Sat, 22 Apr 2017 08:01:39 +0530, Muni Sekhar said: >> Can someone suggest what is the mostly used automation test framework >> for testing the linux kernel mode drivers? > > To test what? Device drivers? There's so many different types that > I don't think one framework can deal. Consider everything from USB audio > cards to 40Gbit Ethernet interfaces to GPU cards Yes, to test device drivers(UART, PCIe, SDIO ...) -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
what is the mostly used automation test framework
Hello all, Can someone suggest what is the mostly used automation test framework for testing the linux kernel mode drivers? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
How to identify the cause of " BUG: Bad page map in process python ..." kernel errors?
Hi All, I am observing the following statements in the kernel log while running driver soak tests and monitoring MIPS and memory usage: [ 8350.824403] BUG: Bad page map in process python pte:00c0 pmd:950a5067 [ 8351.457234] BUG: Bad page map in process python pte:34000c0 pmd:950a5067 [ 8351.458469] BUG: Bad page map in process python pte:406486b3be206e97 pmd:950a5067 …. [ 8353.266053] BUG: Bad page map in process python pte:406486b3fb696e97 pmd:950a5067 [ 8353.305982] BUG: Bad page map in process python pte:00c0 pmd:950a5067 [ 8355.738440] BUG: Bad rss-counter state mm:880138fa7100 idx:1 val:259 [ 8374.905314] general protection fault: [#1] SMP In the kernel log, I observed that kernel reported 60 " BUG: Bad page map in process python ..." reports and 1 “BUG: Bad rss-counter state” and finally it crashed with “general protection fault”. I would like to know what does it mean by “BUG: Bad page map in process python ...” and how to identify the cause of it? To debug this, do I need to consider the “general protection fault” stack trace or the first “BUG: Bad page map in process …” stack trace? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Why I can't find PCIe Device
Hi All, I am using Adlink COM Express Type 2 module and American Megatrends Inc BIOS. I put the AMD Radeon Graphics card in the PCIe slot, but it’s not detected(lspci does not show this device) Any idea, what might be the reason for not detecting the PCIe graphics card? Is there any BIOS settings related to PCIe needs to be checked? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
MODULE_DEVICE_TABLE type=of means?
Hi All,
I see that following dma engine driver uses MODULE_DEVICE_TABLE with ‘type=of’.
What does ‘type=of’ means? How to trigger this driver’s probe and
remove to be called?
http://lxr.linux.no/linux+v4.8/drivers/dma/xilinx/zynqmp_dma.c
static const struct of_device_id zynqmp_dma_of_match[] = {
{ .compatible = "xlnx,zynqmp-dma-1.0", },
{}
};
MODULE_DEVICE_TABLE(of, zynqmp_dma_of_match);
static struct platform_driver zynqmp_dma_driver = {
.driver = {
.name = "xilinx-zynqmp-dma",
.of_match_table = zynqmp_dma_of_match,
},
.probe = zynqmp_dma_probe,
.remove = zynqmp_dma_remove,
};
module_platform_driver(zynqmp_dma_driver);
MODULE_AUTHOR("Xilinx, Inc.");
MODULE_DESCRIPTION("Xilinx ZynqMP DMA driver");
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: scatter-gather doubt?
On Sun, Sep 25, 2016 at 1:02 AM, Greg Freemyer <greg.freem...@gmail.com> wrote:
> On Sat, Sep 24, 2016 at 9:33 AM, Muni Sekhar <munisekhar...@gmail.com> wrote:
>> Hi All,
>>
>> I am working on a xilinx PCIe endpoint with DMA reference block.
>>
>> The DMA reference block design has 2 Scatter-Gather engines, one for
>> each DMA channel.
>>
>> Channel 0 is for HostMemory -> DMA_REF FIFO transfers
>> Channel 1 is for DMA_REF FIFO -> HostMemory transfers
>>
>> Each scatter-gather engine works through a linked list of Descriptors
>> from which it generates the required DMA activity.
>>
>>
>> The format of these descriptors is depicted as below:
>>
>> Offset @ 0x00 - LSBs of pointer to DMA data
>>
>> Offset @ 0x04 - MSBs of pointer to DMA data
>>
>> Offset @ 0x08 - Number of data bytes to be transferred. (note: only 8
>> byte aligned transfers supported)
>>
>> Offset @ 0x0C - LSBs of pointer to next Descriptor (Set this field &
>> MSBs to zero to indicate end of descriptor list)
>>
>> Offset @ 0x10 - MSBs of pointer to next Descriptor
>>
>>
>>
>> Does the Linux kernel has any data structure to support the above
>> mentioned scatter-gather descriptor?
>>
>>
>>
>> Will it be possible to use the kernel scatterlist API’s for this hardware?
>
> Muni,
>
> Have you checked that they don't have a pre-existing driver?
>
> http://www.wiki.xilinx.com/Linux+Drivers
>
> There are 5 different DMA drivers there. Assuming you have and the
> DMA engine doesn't yet have a linux driver:
>
> I'm not sure I've ever written the low level scatter-gather DMA logic
> for a DMA engine, but scatter-gather is decades old technology.
>
> The basic scatterlist is defined in: linux/scatterlist.h
>
> see http://lxr.free-electrons.com/source/include/linux/scatterlist.h#L10
>
> ===
> 10 struct scatterlist {
> 11 #ifdef CONFIG_DEBUG_SG
> 12 unsigned long sg_magic;
> 13 #endif
> 14 unsigned long page_link;
> 15 unsigned intoffset;
> 16 unsigned intlength;
> 17 dma_addr_t dma_address;
> 18 #ifdef CONFIG_NEED_SG_DMA_LENGTH
> 19 unsigned intdma_length;
> 20 #endif
> 21 };
> ===
>
> The upper levels of the linux kernel will populate that and pass it
> into the DMA engine driver.
>
> I believe your DMA engine driver will have to accept that scatterlist
> coming from the upper layers of the kernel and map it to a new
> structure to pass to your IOMMU.
>
Hi Greg,
Thanks for the useful information, I will look at the existing xilinx
DMA engine drivers and documentation for DMA-API's.
> But don't trust my rather vague knowledge. Have you read:
>
> https://www.kernel.org/doc/Documentation/DMA-API.txt
> https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt
>
> Search through those for "scatter" and "sg". You will find the main
> kernel structs and API.
>
> And of course, look at the existing xilinx DMA engine drivers and see
> if there isn't one close to what you need.
>
> Hope that helps,
> Greg
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
scatter-gather doubt?
Hi All, I am working on a xilinx PCIe endpoint with DMA reference block. The DMA reference block design has 2 Scatter-Gather engines, one for each DMA channel. Channel 0 is for HostMemory -> DMA_REF FIFO transfers Channel 1 is for DMA_REF FIFO -> HostMemory transfers Each scatter-gather engine works through a linked list of Descriptors from which it generates the required DMA activity. The format of these descriptors is depicted as below: Offset @ 0x00 - LSBs of pointer to DMA data Offset @ 0x04 - MSBs of pointer to DMA data Offset @ 0x08 - Number of data bytes to be transferred. (note: only 8 byte aligned transfers supported) Offset @ 0x0C - LSBs of pointer to next Descriptor (Set this field & MSBs to zero to indicate end of descriptor list) Offset @ 0x10 - MSBs of pointer to next Descriptor Does the Linux kernel has any data structure to support the above mentioned scatter-gather descriptor? Will it be possible to use the kernel scatterlist API’s for this hardware? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
kmalloc size limit?
Hi All, I would like to know what is the maximum size limit for kmalloc() API to return a valid memory? Does the size limit varies based on the flags argument? -- Thanks, Sekhar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: doubt on schedule_work() - work task getting scheduled lately
On Mon, Aug 1, 2016 at 6:34 PM, Daniel. <danielhi...@gmail.com> wrote:
> Did you tried ftrace?
> https://www.kernel.org/doc/Documentation/trace/ftrace.txt
>
> I've been using this to measure some latencies. The problem here is
> visualizing the output. If you need someting more elaborated than
> simple prints with timestamps and delta calculations, then you should
> try something more complex. If not you can enable FTRACE and generate
> trace output with delta timestamps on it, event for interrupts :)
No, I haven't tried ftrace.
I need to measure latencies between schedule_work() and actual
execution start of my work function. workqueue_queue_work &
workqueue_execute_start are their corresponding lttng events.
I installed the lttng in my test setup and simply enabled all
available kernel events.
I am able to start & stop tracing.
Few lines of lttng view trace:
[11:07:08.208795325] (+0.01677) testbox irq_handler_entry: {
cpu_id = 1 }, { irq = 16, name = "debug_irq" }
[11:07:08.208822703] (+0.27378) testbox workqueue_queue_work: {
cpu_id = 1 }, { work = 0x8801396D4F18, function =
0xC07273B0, req_cpu = 256 }
[11:07:08.208824380] (+0.01677) testbox workqueue_activate_work: {
cpu_id = 1 }, { work = 0x8801396D4F18 }
[11:07:08.208826615] (+0.02235) testbox irq_handler_exit: { cpu_id
= 1 }, { irq = 16, ret = 1 }
[11:07:08.208831364] (+0.04749) testbox workqueue_execute_start: {
cpu_id = 1 }, { work = 0x8801396D4F18, function =
0xC07273B0 }
[11:07:08.208841422] (+0.10058) testbox workqueue_execute_end: {
cpu_id = 1 }, { work = 0x8801396D4F18 }
Can it be possible to print function name instead of ‘function =
0xC07273B0’?
Reproducing the 100 msec latency in between workqueue_queue_work &
workqueue_execute_start needs to trigger the longer soak test anything
over 24 hours.
If I record the lttng trace for longer hours and when I 'lttng view'
the trace, I get all sorts of messages like:
"[warning] Tracer discarded events between and
. You should consider recording a new trace with larger
buffers or with fewer events enabled."
Any better ideas to catch the kernel trace event log for millisecond
latency in between workqueue_queue_work & workqueue_execute_start?
>
> Best regards,
>
> 2016-08-01 7:32 GMT-03:00 Muni Sekhar <munisekhar...@gmail.com>:
>> On Fri, Jul 29, 2016 at 9:05 PM, Daniel. <danielhi...@gmail.com> wrote:
>>> Nice tool @Ricardo!
>>>
>>> 2016-07-29 10:48 GMT-03:00 Ricardo Ribalda Delgado
>>> <ricardo.riba...@gmail.com>:
>>>> you can use http://lttng.org/ for analyzing this
>> Thanks Ricardo, I will use this.
>>
>>>>
>>>> Regards!
>>>>
>>>> On Fri, Jul 29, 2016 at 12:44 PM, Pranay Srivastava <pran...@gmail.com>
>>>> wrote:
>>>>> On Fri, Jul 29, 2016 at 4:02 PM, Muni Sekhar <munisekhar...@gmail.com>
>>>>> wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I have a doubt regarding the workqueue scheduling.
>>>>>>
>>>>>> I am using the workqueue for processing the Rx Interrupt data. I am
>>>>>> calling schedule_work() on receiving the Rx interrupt from hardware.
>>>>>>
>>>>>> I calculated the time between calling the schedule_work() and
>>>>>> workqueue task actually getting executed, Here I see many cases of
>>>>>> less than 100 us(It is fairly good).
>>>>>>
>>>>>> But sometimes I see 10’s of ms and a lot in the 100’s of ms. I have
>>>>>> seen over 0.5 secs too. I would like to know why does sometimes kernel
>>>>>> takes longer time(in milli seconds) to schedule it? Is there any way
>>>>>> to reduce this time gap?
>>>>>>
>>>>>>
>>>>>> My code:
>>>>>>
>>>>>> static void my_workqueuetask(struct work_struct *work)
>>>>>> {
>>>>>> printk("In %s() \n",__func__);
>>>>>>
>>>>> You probably don't need this if it's just for your work_fn, yeah but
>>>>> if there's race between this and something else...
>>>>>> mutex_lock(_mutex);
>>>>>>
>>>>>> //Do something here
>>>>>>
>>>>>> mutex_unlock(_mutex);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> static irqreturn_t my_irq_handler(int irq, void *dev)
>>>>>> {
>>>>>&g
