Debugging General Protection Fault’s
[ Please keep me in CC as I'm not subscribed to the list] Hello, I have a doubt regarding debugging general protection fault’s. I am running the driver tests on Intel(R) Core(TM)2 Duo CPU. During the tests I see system hangs after continuous occurrence of general protection fault’s. First fault occurred on CPU: 0 , but it is not related to our driver, looks like it is in kernel stack. Second gpf fault and third Oops fault related to our own driver. Rest other looks to be in kernel stack. I would like to know, is the first fault triggered other faults? Is all the faults needs to be fixed or just the first fault? Full stack trace is attached. [009298.685954] general protection fault: [#1] SMP [009298.725436] general protection fault: [#2] SMP [009298.866588] Oops: 0002 [#3] SMP [009300.134033] general protection fault: [#4] SMP Regards, Sekhar [009298.685954] general protection fault: [#1] SMP [009298.686376] Modules linked in: ptrb(OE) t_mux(OE) tty_hif(OE) h_core(OE) os_abstract(OE) snd_usb_audio snd_usbmidi_lib snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore gpio(OE) uart(OE) deb_spi(OE) w1(OE) gpio_ich coretemp kvm_intel kvm i915 lpc_ich video drm_kms_helper pci(OE) drm i2c_algo_bit shpchp mac_hid lp parport pata_sil680 pata_acpi e1000e ptp pps_core [last unloaded: os_abstract] [009298.688008] CPU: 0 PID: 21693 Comm: python Tainted: G IOE 3.16.0-30-generic #40~14.04.1-Ubuntu [009298.688008] Hardware name: RadiSys Corporation CEGM45 /CEGM45T2-SL9-0 , BIOS 08.00.44 09/14/2011 [009298.688008] task: 880076ede5e0 ti: 880076fc8000 task.ti: 880076fc8000 [009298.688008] RIP: 0010:[811b6995] [811b6995] __kmalloc+0x95/0x230 [009298.688008] RSP: 0018:880076fcbcb0 EFLAGS: 00010286 [009298.688008] RAX: RBX: 880004e129c0 RCX: 02bee000 [009298.688008] RDX: 02bedfff RSI: RDI: 0008 [009298.688008] RBP: 880076fcbce0 R08: 00016240 R09: 8124dce4 [009298.688008] R10: 88007a801a00 R11: R12: 80d0 [009298.688008] R13: 7b8bdd2b4a3e4480 R14: 0042 R15: 88007a801a00 [009298.688008] FS: 7ff1ee414740() GS:88007d20() knlGS: [009298.688008] CS: 0010 DS: ES: CR0: 80050033 [009298.688008] CR2: 7ff1ea0a3c90 CR3: 781b6000 CR4: 000407f0 [009298.688008] Stack: [009298.688008] 8124dce4 880004e129c0 880075c42a80 8800420001b8 [009298.688008] 29091136 f08c7f95 880076fcbd18 8124dce4 [009298.688008] 880004e129c0 880076fcbdc0 8800201548a0 [009298.688008] Call Trace: [009298.688008] [8124dce4] ? ext4_htree_store_dirent+0x34/0x120 [009298.688008] [8124dce4] ext4_htree_store_dirent+0x34/0x120 [009298.688008] [8125d659] htree_dirblock_to_tree+0x169/0x190 [009298.688008] [8125e8e6] ext4_htree_fill_tree+0xc6/0x270 [009298.688008] [8118e73c] ? handle_mm_fault+0x7fc/0x10b0 [009298.688008] [811b7176] ? kmem_cache_alloc_trace+0x1c6/0x1f0 [009298.688008] [8124cf3a] ? free_rb_tree_fname+0x1a/0x90 [009298.688008] [8124d505] ext4_readdir+0x185/0x910 [009298.688008] [811e6cf3] iterate_dir+0xa3/0x130 [009298.688008] [811e3382] ? final_putname+0x22/0x50 [009298.688008] [811e718a] SyS_getdents+0x8a/0x110 [009298.688008] [811e6e50] ? fillonedir+0xd0/0xd0 [009298.688008] [8176aced] system_call_fastpath+0x1a/0x1f [009298.688008] Code: cd 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 26 01 00 00 48 85 c0 0f 84 1d 01 00 00 49 63 42 20 48 8d 4a 01 4d 8b 02 49 8b 5c 05 00 4c 89 e8 65 49 0f c7 08 0f 94 c0 84 c0 74 b8 49 [009298.688008] RIP [811b6995] __kmalloc+0x95/0x230 [009298.688008] RSP 880076fcbcb0 [009298.724864] ---[ end trace cc195a9ec5b7c913 ]--- [009298.725436] general protection fault: [#2] SMP [009298.725455] Modules linked in: ptrb(OE) t_mux(OE) tty_hif(OE) h_core(OE) os_abstract(OE) snd_usb_audio snd_usbmidi_lib snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore gpio(OE) uart(OE) deb_spi(OE) w1(OE) gpio_ich coretemp kvm_intel kvm i915 lpc_ich video drm_kms_helper pci(OE) drm i2c_algo_bit shpchp mac_hid lp parport pata_sil680 pata_acpi e1000e ptp pps_core [last unloaded: os_abstract] [009298.725457] CPU: 1 PID: 26531 Comm: rcv_buffer_stal Tainted: G D IOE 3.16.0-30-generic #40~14.04.1-Ubuntu [009298.725459] Hardware name: RadiSys Corporation CEGM45 /CEGM45T2-SL9-0 , BIOS 08.00.44 09/14/2011 [009298.725460] task: 880078074750 ti: 880077d44000 task.ti:
character driver - poll() timeout
[ Please keep me in CC as I'm not subscribed to the list] Hello, Is it possible to print the timeout value in character driver poll() API? User mode call: int poll(struct pollfd *fds, nfds_t nfds, int timeout) Kernel mode call: unsigned int driver_poll(struct file *filp, poll_table *wait) -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: character driver - poll() timeout
On Tue, Oct 27, 2015 at 1:41 PM, Clemens Ladisch <clem...@ladisch.de> wrote: > Muni Sekhar wrote: >> Is it possible to print the timeout value in character driver poll() API? > > No. Your driver's poll callback never waits. > > Why do you think you need this value? I need to find out when exactly driver's poll callback returned timeout. > > > Regards, > Clemens -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: character driver - poll() timeout
On Tue, Oct 27, 2015 at 8:48 PM, Clemens Ladisch <clem...@ladisch.de> wrote: > Muni Sekhar wrote: >> On Tue, Oct 27, 2015 at 1:41 PM, Clemens Ladisch <clem...@ladisch.de> wrote: >>> Muni Sekhar wrote: >>>> Is it possible to print the timeout value in character driver poll() API? >>> >>> No. Your driver's poll callback never waits. >>> >>> Why do you think you need this value? >> >> I need to find out when exactly driver's poll callback returned timeout. > > Your poll callback _cannot_ return a timeout. > > Why do you think you need this information for? During stress test, my test application fails and throws poll() timeout error. I need to debug what is the state of my driver during that time. I added prints in driver poll(), but I gets lots of debug prints if poll() timeout is more. So I am wonder if it is possible to get a single debug print for this scenario? > > > Regards, > Clemens -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: character driver - poll() timeout
On Wed, Oct 28, 2015 at 12:54 PM, Clemens Ladisch <clem...@ladisch.de> wrote: > Muni Sekhar wrote: >> On Tue, Oct 27, 2015 at 8:48 PM, Clemens Ladisch <clem...@ladisch.de> wrote: >>> Muni Sekhar wrote: >>>> I need to find out when exactly driver's poll callback returned timeout. >>> >>> Your poll callback _cannot_ return a timeout. >>> >>> Why do you think you need this information for? >> >> During stress test, my test application fails and throws poll() timeout >> error. >> >> I need to debug what is the state of my driver during that time. I >> added prints in driver poll(), but I gets lots of debug prints if >> poll() timeout is more. > > Your poll() callback does not really change the state of the driver. > It just returns the wait queue and the current state of the device. > (Which means it is likely to get called _twice_, before poll() goes > to sleep, and just before it returns.) > > Your driver's state changes only when > 1) you start some operation (such as read() or write()), or when > 2) you finish some operation (which wakes up anyone waiting on >that wait queue). > > If you time out, it means that some wake_up() happens too late or > not at all, or that you do not return the correct state. Thanks Clemens for the clarification. > > > Regards, > Clemens -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
enable dynamic debug - doubt
[ Please keep me in CC as I'm not subscribed to the list] Hello, The behaviour of dynamic debug prints are controlled via writing to a control file in the 'debugfs' filesystem(/dynamic_debug/control). Here I would like to know what order should the echo(for eg: echo -n 'module sdhci +p' > /sys/kernel/debug/dynamic_debug/control) be applied in relation to the module load - before or after? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
utility to read/write SDIO registers with CMD52s
Hi, Is there any Linux MMC stack utility to read/write SDIO registers with CMD52s? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sdhci-pci or sdhci_pci
[ Please keep me in CC as I'm not subscribed to the list] Hello, I loaded sdhci-pci.ko, but lsmod shows it as sdhci_pci. Why is that lsmod shows wrong module name( '-' changed to '_')? # lsmod Module Size Used by sdhci_pci 23301 0 sdhci 43685 1 sdhci_pci -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Blacklisting the default kernel drivers
[ Please keep me in CC as I'm not subscribed to the list] Hello, I am using 3.16.0-30-generic kernel and Ubuntu 14.04.2 LTS. I need to blacklist the standard Linux MMC drivers getting loaded during power-on. For that I added the below mentioned lines to “/etc/modprobe.d/blacklist.conf”, but even though those two drivers are getting loaded (sdhci, sdhci-pci) during power on. blacklist sdhci blacklist sdhci-pci Is it the correct procedure to blacklist the drivers? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kfree a pointer "from the middle" causing protection faults
On Wed, Sep 2, 2015 at 9:39 PM, Jeff Epler <jep...@unpythonic.net> wrote: > On Wed, Sep 02, 2015 at 08:32:15PM +0530, Muni Sekhar wrote: >> [ Please keep me in CC as I'm not subscribed to the list] >> >> Hello, >> >> >> I am getting protection faults in different kernel modules if I try to >> free a pointer "from the middle" for example, look at the following >> code: > [..] > > Most memory allocators require the pointer eventually passed to the > freeing function is the same pointer as the one returned from the > allocating function. This is true for libc malloc/free, for instance. > As far as I know, it is true for the Linux allocators such as kzalloc. > The bug lies in whatever part of linux makes the invalid kfree call. > > I have not found any documentation that kernel kzalloc/kfree allow > passing a pointer "from the middle". For instance, > These routines are used to dynamically request pointer-aligned chunks of > memory, like malloc and free do in userspace > https://www.kernel.org/doc/htmldocs/kernel-hacking/routines-kmalloc.html > > If the faulty code that you allude to is in the Linux source then please > say what it is so that developers can fix it. If it's an out of source > module or kernel patch then contact the supplier of that code. The faulty code mentioned above is not in the Linux source, I noticed this behaviour during testing our own module. Thanks for the clarification Jeff. > > Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kfree a pointer "from the middle" causing protection faults
[ Please keep me in CC as I'm not subscribed to the list] Hello, I am getting protection faults in different kernel modules if I try to free a pointer "from the middle" for example, look at the following code: u8 *buf; buf = kzalloc( 100 , GFP_KERNEL ); … buf = buf + 50; … Kfree(buf); I would like to know, why the above code is causing protection faults in other kernel modules? Regards, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
“modprobe –r” not removing the modules it depends
[ Please keep me in CC as I'm not subscribed to the list] Hello, I noticed that “modprobe –r” not removing the modules it depends even though it is unused. What might be the reason for this? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: enable dynamic debug - doubt
On Thu, Nov 19, 2015 at 2:38 AM, Peter Hurley <pe...@hurleysoftware.com> wrote: > > On 11/17/2015 07:40 AM, Muni Sekhar wrote: > > [ Please keep me in CC as I'm not subscribed to the list] > > > > Hello, > > > > The behaviour of dynamic debug prints are controlled via writing to a > > control file in the 'debugfs' > > filesystem(/dynamic_debug/control). > > That's not the only method. You'll want to read > Documentation/dynamic-debug-howto.txt; specifically, "Debug Messages at > Module Initialization Time" for ways to enable dynamic debug messages at > module load time. > > Regards, > Peter Hurley > > > Here I would like to know what order should the echo(for eg: echo -n > > 'module sdhci +p' > /sys/kernel/debug/dynamic_debug/control) be > > applied in relation to the module load - before or after? > > I just glanced through the Documentation/dynamic-debug-howto.txt and now I am able to enable "Debug Messages at Module Initialization Time". Thanks Peter & Andy for the clarification. -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Basic query regarding the scatter-gather DMA
Hi All, I have a basic query regarding the scatter-gather DMA. We have a device with scatter-gather capability. Is it okay to use normal DMA API’s for this device driver? Or driver only should use scatter-gather DMA API’s? -- Thanks, Sekhar
wait_event()\wake_up order fails?
Hi All, I have a kernel thread THREAD_A and it waits for an event by calling wait_event() API. Other thread THREAD_B wakes up the THREAD_A by calling wake_up() API. In a concurrent execution, what if the wake_up() is called before THREAD_A entering into TASK_UNINTERRUPTIBLE sleep? I have noticed in running long soak test, THREAD_A enters into TASK_UNINTERRUPTIBLE sleep and THREAD_B’s wake_up() not able to wake the THREAD_A, what might be the reason for this? I would like to know in which scenario wake_up() fails to wake the sleeping thread? -- Thanks, Sekhar
doubt on schedule_work() - work task getting scheduled lately
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__);
mutex_lock(_bh_mutex);
//Do something here
mutex_lock(_bh_mutex);
}
static irqreturn_t my_irq_handler(int irq, void *dev)
{
……;
if(Rx Interrupt)
schedule_work(_work);
return IRQ_HANDLED;
}
--
Thanks,
Sekhar
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: [ 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
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
Re: kmalloc size limit?
On Mon, Aug 22, 2016 at 5:42 PM, Michal Hocko <mho...@kernel.org> wrote: > On Sat 20-08-16 00:09:53, Muni Sekhar wrote: >> Hi All, >> >> I would like to know what is the maximum size limit for kmalloc() API >> to return a valid memory? > > KMALLOC_MAX_CACHE_SIZE Thanks Michal. > >> Does the size limit varies based on the flags argument? > > no but different flags can greatly influence how succesful such an > allocation can be. > -- > Michal Hocko > SUSE Labs -- Thanks, Sekhar
SG: 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
wake_up() or wake_up_interruptible()
Hi All, I am using a wait_event_interruptible() in kernel thread and waking that thread using wake_up(), and this logic is working fine. I would like to know whether it is the correct way of waking the thread which is in interruptible sleep mode? What about wake_up_interruptible() API? When this should be used? -- Thanks, Sekhar
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
Re: serial: custom baud rate
On Thu, May 3, 2018 at 11:24 PM, Theodore Y. Ts'o <ty...@mit.edu> wrote: > On Thu, May 03, 2018 at 06:09:13PM +0530, Muni Sekhar wrote: >> 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? > > See the setserial man page:t > > https://linux.die.net/man/8/setserial > > Not all serial devices support the spd_cust and divisor, however. In > general, only devices where the kernel directly programs the > 8250/16450/16550 UART directly will support this feature. > So custom baud's can be set via TIOCSSERIAL IOCtl in kernel mode? > - Ted -- Thanks, Sekhar
sound: aplay\arecord audio frame flow
[ Please keep me in CC as I'm not subscribed to the list] Hi All, Is there anyway in the kernel sound subsystem to know when the application calls ‘aplay’ and anything starts playing? Also for arecord\aplay, Is there any way from kernel's point of view to know when it receives for example the first and last audio frames? -- Thanks, Sekhar
wireless: need help to learn WiFi kernel stack
[ Please keep me in CC as I'm not subscribed to the list] Hi All, I’m planning to learn the Linux WiFi kernel stack. I’d like to know what happens in the background in the kernel when I connect to WiFi. How does a packet travels all the way from my application to kernel to air and back. Right now I don’t have any WiFi dongle, can someone suggest any proven WiFi dongle which can be used to test with Linux kernel. -- Thanks, Sekhar
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
>>> kernelnewb...@kernelnewbies.org
>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
--
Thanks,
Sekhar
linux-sound: timestamps for audio frames
[ Please keep me in CC as I'm not subscribed to the list] Hi All, >From sound driver, I am wondering if we could get the timestamps when It receives for example the first and last audio frames. Is there any way we can extract or expose that information to user mode? -- Thanks, Sekhar
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
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
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
audio CODEC(CS42888) test
[ Please keep me in CC as I'm not subscribed to the list] Hi All, I’m having a sound hardware which contains an analogue audio CODEC(CS42888) and configuring the CODEC is performed over SPI bus. I noticed that linux kernel already had a driver(snd-soc-cs42xx8.ko) for this, I planned to use this driver. Basically I’d like to perform loopback test and compare the sent and received files to verify data fidelity. Also the test to be repeated for various data rates and data formats. I’d like to know how to test this loopback scenario and compare the sent\received files? I appreciate any help. -- Thanks, Sekhar
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
audio CODEC(CS42888) test
[ Please keep me in CC as I'm not subscribed to the list] Hi All, I’m having a sound hardware which contains an analogue audio CODEC(CS42888) and configuring the CODEC is performed over SPI bus. I noticed that linux kernel already had a driver(snd-soc-cs42xx8.ko) for this, I planned to use this driver. Basically I’d like to perform loopback test and compare the sent and received files to verify data fidelity. Also the test to be repeated for various data rates and data formats. I’d like to know how to test this loopback scenario and compare the sent\received files? I appreciate any help. -- Thanks, Sekhar
sound: aplay\arecord audio frame flow
[ Please keep me in CC as I'm not subscribed to the list] Hi All, Is there anyway in the kernel sound subsystem to know when the application calls ‘aplay’ and anything starts playing? Also for arecord\aplay, Is there any way from kernel's point of view to know when it receives for example the first and last audio frames? -- Thanks, Sekhar
Re: serial: start_tx & buffer handling
On Fri, May 4, 2018 at 12:04 AM, Greg KH 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
Re: serial: custom baud rate
On Thu, May 3, 2018 at 11:24 PM, Theodore Y. Ts'o wrote: > On Thu, May 03, 2018 at 06:09:13PM +0530, Muni Sekhar wrote: >> 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? > > See the setserial man page:t > > https://linux.die.net/man/8/setserial > > Not all serial devices support the spd_cust and divisor, however. In > general, only devices where the kernel directly programs the > 8250/16450/16550 UART directly will support this feature. > So custom baud's can be set via TIOCSSERIAL IOCtl in kernel mode? > - Ted -- Thanks, Sekhar
wireless: need help to learn WiFi kernel stack
[ Please keep me in CC as I'm not subscribed to the list] Hi All, I’m planning to learn the Linux WiFi kernel stack. I’d like to know what happens in the background in the kernel when I connect to WiFi. How does a packet travels all the way from my application to kernel to air and back. Right now I don’t have any WiFi dongle, can someone suggest any proven WiFi dongle which can be used to test with Linux kernel. -- Thanks, Sekhar
Re: serial: start_tx & buffer handling
On Fri, May 4, 2018 at 5:44 PM, loïc tourlonias
wrote:
> Hi
>
> On Fri, May 4, 2018 at 6:31 AM, Muni Sekhar wrote:
>>>
>>> On Fri, May 4, 2018 at 12:04 AM, Greg KH 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
>>> kernelnewb...@kernelnewbies.org
>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
--
Thanks,
Sekhar
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
linux-sound: timestamps for audio frames
[ Please keep me in CC as I'm not subscribed to the list] Hi All, >From sound driver, I am wondering if we could get the timestamps when It receives for example the first and last audio frames. Is there any way we can extract or expose that information to user mode? -- Thanks, Sekhar
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
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
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
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
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
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(please find it in the attachment: config.patch) and then try 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. 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 <>
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
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
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
kfree a pointer "from the middle" causing protection faults
[ Please keep me in CC as I'm not subscribed to the list] Hello, I am getting protection faults in different kernel modules if I try to free a pointer "from the middle" for example, look at the following code: u8 *buf; buf = kzalloc( 100 , GFP_KERNEL ); … buf = buf + 50; … Kfree(buf); I would like to know, why the above code is causing protection faults in other kernel modules? Regards, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kfree a pointer "from the middle" causing protection faults
On Wed, Sep 2, 2015 at 9:39 PM, Jeff Epler wrote: > On Wed, Sep 02, 2015 at 08:32:15PM +0530, Muni Sekhar wrote: >> [ Please keep me in CC as I'm not subscribed to the list] >> >> Hello, >> >> >> I am getting protection faults in different kernel modules if I try to >> free a pointer "from the middle" for example, look at the following >> code: > [..] > > Most memory allocators require the pointer eventually passed to the > freeing function is the same pointer as the one returned from the > allocating function. This is true for libc malloc/free, for instance. > As far as I know, it is true for the Linux allocators such as kzalloc. > The bug lies in whatever part of linux makes the invalid kfree call. > > I have not found any documentation that kernel kzalloc/kfree allow > passing a pointer "from the middle". For instance, > These routines are used to dynamically request pointer-aligned chunks of > memory, like malloc and free do in userspace > https://www.kernel.org/doc/htmldocs/kernel-hacking/routines-kmalloc.html > > If the faulty code that you allude to is in the Linux source then please > say what it is so that developers can fix it. If it's an out of source > module or kernel patch then contact the supplier of that code. The faulty code mentioned above is not in the Linux source, I noticed this behaviour during testing our own module. Thanks for the clarification Jeff. > > Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Debugging General Protection Fault’s
[ Please keep me in CC as I'm not subscribed to the list] Hello, I have a doubt regarding debugging general protection fault’s. I am running the driver tests on Intel(R) Core(TM)2 Duo CPU. During the tests I see system hangs after continuous occurrence of general protection fault’s. First fault occurred on CPU: 0 , but it is not related to our driver, looks like it is in kernel stack. Second gpf fault and third Oops fault related to our own driver. Rest other looks to be in kernel stack. I would like to know, is the first fault triggered other faults? Is all the faults needs to be fixed or just the first fault? Full stack trace is attached. [009298.685954] general protection fault: [#1] SMP [009298.725436] general protection fault: [#2] SMP [009298.866588] Oops: 0002 [#3] SMP [009300.134033] general protection fault: [#4] SMP Regards, Sekhar [009298.685954] general protection fault: [#1] SMP [009298.686376] Modules linked in: ptrb(OE) t_mux(OE) tty_hif(OE) h_core(OE) os_abstract(OE) snd_usb_audio snd_usbmidi_lib snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore gpio(OE) uart(OE) deb_spi(OE) w1(OE) gpio_ich coretemp kvm_intel kvm i915 lpc_ich video drm_kms_helper pci(OE) drm i2c_algo_bit shpchp mac_hid lp parport pata_sil680 pata_acpi e1000e ptp pps_core [last unloaded: os_abstract] [009298.688008] CPU: 0 PID: 21693 Comm: python Tainted: G IOE 3.16.0-30-generic #40~14.04.1-Ubuntu [009298.688008] Hardware name: RadiSys Corporation CEGM45 /CEGM45T2-SL9-0 , BIOS 08.00.44 09/14/2011 [009298.688008] task: 880076ede5e0 ti: 880076fc8000 task.ti: 880076fc8000 [009298.688008] RIP: 0010:[] [] __kmalloc+0x95/0x230 [009298.688008] RSP: 0018:880076fcbcb0 EFLAGS: 00010286 [009298.688008] RAX: RBX: 880004e129c0 RCX: 02bee000 [009298.688008] RDX: 02bedfff RSI: RDI: 0008 [009298.688008] RBP: 880076fcbce0 R08: 00016240 R09: 8124dce4 [009298.688008] R10: 88007a801a00 R11: R12: 80d0 [009298.688008] R13: 7b8bdd2b4a3e4480 R14: 0042 R15: 88007a801a00 [009298.688008] FS: 7ff1ee414740() GS:88007d20() knlGS: [009298.688008] CS: 0010 DS: ES: CR0: 80050033 [009298.688008] CR2: 7ff1ea0a3c90 CR3: 781b6000 CR4: 000407f0 [009298.688008] Stack: [009298.688008] 8124dce4 880004e129c0 880075c42a80 8800420001b8 [009298.688008] 29091136 f08c7f95 880076fcbd18 8124dce4 [009298.688008] 880004e129c0 880076fcbdc0 8800201548a0 [009298.688008] Call Trace: [009298.688008] [] ? ext4_htree_store_dirent+0x34/0x120 [009298.688008] [] ext4_htree_store_dirent+0x34/0x120 [009298.688008] [] htree_dirblock_to_tree+0x169/0x190 [009298.688008] [] ext4_htree_fill_tree+0xc6/0x270 [009298.688008] [] ? handle_mm_fault+0x7fc/0x10b0 [009298.688008] [] ? kmem_cache_alloc_trace+0x1c6/0x1f0 [009298.688008] [] ? free_rb_tree_fname+0x1a/0x90 [009298.688008] [] ext4_readdir+0x185/0x910 [009298.688008] [] iterate_dir+0xa3/0x130 [009298.688008] [] ? final_putname+0x22/0x50 [009298.688008] [] SyS_getdents+0x8a/0x110 [009298.688008] [] ? fillonedir+0xd0/0xd0 [009298.688008] [] system_call_fastpath+0x1a/0x1f [009298.688008] Code: cd 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 26 01 00 00 48 85 c0 0f 84 1d 01 00 00 49 63 42 20 48 8d 4a 01 4d 8b 02 <49> 8b 5c 05 00 4c 89 e8 65 49 0f c7 08 0f 94 c0 84 c0 74 b8 49 [009298.688008] RIP [] __kmalloc+0x95/0x230 [009298.688008] RSP [009298.724864] ---[ end trace cc195a9ec5b7c913 ]--- [009298.725436] general protection fault: [#2] SMP [009298.725455] Modules linked in: ptrb(OE) t_mux(OE) tty_hif(OE) h_core(OE) os_abstract(OE) snd_usb_audio snd_usbmidi_lib snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore gpio(OE) uart(OE) deb_spi(OE) w1(OE) gpio_ich coretemp kvm_intel kvm i915 lpc_ich video drm_kms_helper pci(OE) drm i2c_algo_bit shpchp mac_hid lp parport pata_sil680 pata_acpi e1000e ptp pps_core [last unloaded: os_abstract] [009298.725457] CPU: 1 PID: 26531 Comm: rcv_buffer_stal Tainted: G D IOE 3.16.0-30-generic #40~14.04.1-Ubuntu [009298.725459] Hardware name: RadiSys Corporation CEGM45 /CEGM45T2-SL9-0 , BIOS 08.00.44 09/14/2011 [009298.725460] task: 880078074750 ti: 880077d44000 task.ti: 880077d44000 [009298.725468] RIP: 0010:[] [] stale_timer_poll_thread+0x74/0x1d0 [ptrb] [009298.725469] RSP: 0018:880077d47e80 EFLAGS: 00010202 [009298.725470] RAX: RBX: 88007849ca00 RCX: a70e [009298.725471] RDX:
SG: 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
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: [ 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
wake_up() or wake_up_interruptible()
Hi All, I am using a wait_event_interruptible() in kernel thread and waking that thread using wake_up(), and this logic is working fine. I would like to know whether it is the correct way of waking the thread which is in interruptible sleep mode? What about wake_up_interruptible() API? When this should be used? -- Thanks, Sekhar
Re: kmalloc size limit?
On Mon, Aug 22, 2016 at 5:42 PM, Michal Hocko wrote: > On Sat 20-08-16 00:09:53, Muni Sekhar wrote: >> Hi All, >> >> I would like to know what is the maximum size limit for kmalloc() API >> to return a valid memory? > > KMALLOC_MAX_CACHE_SIZE Thanks Michal. > >> Does the size limit varies based on the flags argument? > > no but different flags can greatly influence how succesful such an > allocation can be. > -- > Michal Hocko > SUSE Labs -- Thanks, Sekhar
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
Re: character driver - poll() timeout
On Tue, Oct 27, 2015 at 8:48 PM, Clemens Ladisch wrote: > Muni Sekhar wrote: >> On Tue, Oct 27, 2015 at 1:41 PM, Clemens Ladisch wrote: >>> Muni Sekhar wrote: >>>> Is it possible to print the timeout value in character driver poll() API? >>> >>> No. Your driver's poll callback never waits. >>> >>> Why do you think you need this value? >> >> I need to find out when exactly driver's poll callback returned timeout. > > Your poll callback _cannot_ return a timeout. > > Why do you think you need this information for? During stress test, my test application fails and throws poll() timeout error. I need to debug what is the state of my driver during that time. I added prints in driver poll(), but I gets lots of debug prints if poll() timeout is more. So I am wonder if it is possible to get a single debug print for this scenario? > > > Regards, > Clemens -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: character driver - poll() timeout
On Wed, Oct 28, 2015 at 12:54 PM, Clemens Ladisch wrote: > Muni Sekhar wrote: >> On Tue, Oct 27, 2015 at 8:48 PM, Clemens Ladisch wrote: >>> Muni Sekhar wrote: >>>> I need to find out when exactly driver's poll callback returned timeout. >>> >>> Your poll callback _cannot_ return a timeout. >>> >>> Why do you think you need this information for? >> >> During stress test, my test application fails and throws poll() timeout >> error. >> >> I need to debug what is the state of my driver during that time. I >> added prints in driver poll(), but I gets lots of debug prints if >> poll() timeout is more. > > Your poll() callback does not really change the state of the driver. > It just returns the wait queue and the current state of the device. > (Which means it is likely to get called _twice_, before poll() goes > to sleep, and just before it returns.) > > Your driver's state changes only when > 1) you start some operation (such as read() or write()), or when > 2) you finish some operation (which wakes up anyone waiting on >that wait queue). > > If you time out, it means that some wake_up() happens too late or > not at all, or that you do not return the correct state. Thanks Clemens for the clarification. > > > Regards, > Clemens -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sdhci-pci or sdhci_pci
[ Please keep me in CC as I'm not subscribed to the list] Hello, I loaded sdhci-pci.ko, but lsmod shows it as sdhci_pci. Why is that lsmod shows wrong module name( '-' changed to '_')? # lsmod Module Size Used by sdhci_pci 23301 0 sdhci 43685 1 sdhci_pci -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Blacklisting the default kernel drivers
[ Please keep me in CC as I'm not subscribed to the list] Hello, I am using 3.16.0-30-generic kernel and Ubuntu 14.04.2 LTS. I need to blacklist the standard Linux MMC drivers getting loaded during power-on. For that I added the below mentioned lines to “/etc/modprobe.d/blacklist.conf”, but even though those two drivers are getting loaded (sdhci, sdhci-pci) during power on. blacklist sdhci blacklist sdhci-pci Is it the correct procedure to blacklist the drivers? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
enable dynamic debug - doubt
[ Please keep me in CC as I'm not subscribed to the list] Hello, The behaviour of dynamic debug prints are controlled via writing to a control file in the 'debugfs' filesystem(/dynamic_debug/control). Here I would like to know what order should the echo(for eg: echo -n 'module sdhci +p' > /sys/kernel/debug/dynamic_debug/control) be applied in relation to the module load - before or after? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
character driver - poll() timeout
[ Please keep me in CC as I'm not subscribed to the list] Hello, Is it possible to print the timeout value in character driver poll() API? User mode call: int poll(struct pollfd *fds, nfds_t nfds, int timeout) Kernel mode call: unsigned int driver_poll(struct file *filp, poll_table *wait) -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: character driver - poll() timeout
On Tue, Oct 27, 2015 at 1:41 PM, Clemens Ladisch wrote: > Muni Sekhar wrote: >> Is it possible to print the timeout value in character driver poll() API? > > No. Your driver's poll callback never waits. > > Why do you think you need this value? I need to find out when exactly driver's poll callback returned timeout. > > > Regards, > Clemens -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
“modprobe –r” not removing the modules it depends
[ Please keep me in CC as I'm not subscribed to the list] Hello, I noticed that “modprobe –r” not removing the modules it depends even though it is unused. What might be the reason for this? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: enable dynamic debug - doubt
On Thu, Nov 19, 2015 at 2:38 AM, Peter Hurley wrote: > > On 11/17/2015 07:40 AM, Muni Sekhar wrote: > > [ Please keep me in CC as I'm not subscribed to the list] > > > > Hello, > > > > The behaviour of dynamic debug prints are controlled via writing to a > > control file in the 'debugfs' > > filesystem(/dynamic_debug/control). > > That's not the only method. You'll want to read > Documentation/dynamic-debug-howto.txt; specifically, "Debug Messages at > Module Initialization Time" for ways to enable dynamic debug messages at > module load time. > > Regards, > Peter Hurley > > > Here I would like to know what order should the echo(for eg: echo -n > > 'module sdhci +p' > /sys/kernel/debug/dynamic_debug/control) be > > applied in relation to the module load - before or after? > > I just glanced through the Documentation/dynamic-debug-howto.txt and now I am able to enable "Debug Messages at Module Initialization Time". Thanks Peter & Andy for the clarification. -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
doubt on schedule_work() - work task getting scheduled lately
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__);
mutex_lock(_bh_mutex);
//Do something here
mutex_lock(_bh_mutex);
}
static irqreturn_t my_irq_handler(int irq, void *dev)
{
……;
if(Rx Interrupt)
schedule_work(_work);
return IRQ_HANDLED;
}
--
Thanks,
Sekhar
wait_event()\wake_up order fails?
Hi All, I have a kernel thread THREAD_A and it waits for an event by calling wait_event() API. Other thread THREAD_B wakes up the THREAD_A by calling wake_up() API. In a concurrent execution, what if the wake_up() is called before THREAD_A entering into TASK_UNINTERRUPTIBLE sleep? I have noticed in running long soak test, THREAD_A enters into TASK_UNINTERRUPTIBLE sleep and THREAD_B’s wake_up() not able to wake the THREAD_A, what might be the reason for this? I would like to know in which scenario wake_up() fails to wake the sleeping thread? -- Thanks, Sekhar
Basic query regarding the scatter-gather DMA
Hi All, I have a basic query regarding the scatter-gather DMA. We have a device with scatter-gather capability. Is it okay to use normal DMA API’s for this device driver? Or driver only should use scatter-gather DMA API’s? -- Thanks, Sekhar
utility to read/write SDIO registers with CMD52s
Hi, Is there any Linux MMC stack utility to read/write SDIO registers with CMD52s? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
