February 2020 - kernelnewbies@kernelnewbies.org

Why do we have to specify hrtimer_mode twice using hrtimers
by Linux Weekend Learning Feb. 13, 2020

Feb. 13, 2020

Hi All, Why do we need to specify hrtimer_mode twice while using hrtimers. 1. Timer Initialization: void hrtimer_init(struct hrtimer *timer, clockid_t which_clock, enum hrtimer_mode mode); 2. Starting a timer: void hrtimer_start(struct hrtimer *timer, ktime_t tim, const enum hrtimer_mode mode); What will happen if i specify different modes in both functions.

1 0

Re: pcie: kernel log - BAR 15: no space for... BAR 15: failed to assign..
by Muni Sekhar Feb. 12, 2020

Feb. 12, 2020

On Wed, Feb 12, 2020 at 1:46 AM Bjorn Helgaas <helgaas(a)kernel.org> 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 <helgaas(a)kernel.org> 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 <helgaas(a)kernel.org> 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 0000:00:1c.0: BAR 15: no space for [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.084813] pci 0000:00:1c.0: BAR 15: failed to assign [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.084890] pci 0000:00:1c.2: BAR 14: no space for [mem size 0x00200000] > > > > > > [ 1.084949] pci 0000:00:1c.2: BAR 14: failed to assign [mem size 0x00200000] > > > > > > [ 1.085037] pci 0000:00:1c.2: BAR 15: no space for [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085108] pci 0000:00:1c.2: BAR 15: failed to assign [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085199] pci 0000:00:1c.3: BAR 15: no space for [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085270] pci 0000:00:1c.3: BAR 15: failed to assign [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085343] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] > > > > > > [ 1.085403] pci 0000:00:1c.2: BAR 13: assigned [io 0x2000-0x2fff] > > > > > > [ 1.085470] pci 0000:00:1c.3: BAR 15: no space for [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085540] pci 0000:00:1c.3: BAR 15: failed to assign [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085613] pci 0000:00:1c.2: BAR 14: no space for [mem size 0x00200000] > > > > > > [ 1.085672] pci 0000:00:1c.2: BAR 14: failed to assign [mem size 0x00200000] > > > > > > [ 1.085738] pci 0000:00:1c.2: BAR 15: no space for [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085808] pci 0000:00:1c.2: BAR 15: failed to assign [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085884] pci 0000:00:1c.0: BAR 15: no space for [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.085954] pci 0000:00:1c.0: BAR 15: failed to assign [mem size > > > > > > 0x00200000 64bit pref] > > > > > > [ 1.086026] pci 0000:00:1c.0: PCI bridge to [bus 01] > > > > > > [ 1.086083] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff] > > > > > > [ 1.086144] pci 0000:00:1c.0: bridge window [mem 0xd0400000-0xd07fffff] > > > > > > > > > > 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 0x00200000 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 0xd0400000-0xd07fffff > > > non-prefetachable MMIO space *is* available for it. > > > > > > Similarly, we were unable to allocate 0x00200000 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? > > Here's the relevant info from your dmesg log: > > PCI host bridge to bus 0000:00 > pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] > pci_bus 0000:00: root bus resource [mem 0xc0000000-0xd0c18ffe window] > pci_bus 0000:00: root bus resource [bus 00-ff] > pci 0000:00:1c.0: PCI bridge to [bus 01] > pci 0000:00:1c.0: bridge window [mem 0xd0400000-0xd07fffff] > pci 0000:01:00.0: [1556:5555] type 00 class 0x050000 # FPGA > pci 0000:01:00.0: reg 0x10: [mem 0xd0400000-0xd07fffff] > pci 0000:00:1c.3: PCI bridge to [bus 03] > pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] > pci 0000:00:1c.3: bridge window [mem 0xd0a00000-0xd0bfffff] > pci 0000:03:00.0: [8086:1533] type 00 class 0x020000 # I210 NIC > pci 0000:03:00.0: reg 0x10: [mem 0xd0a00000-0xd0afffff] > pci 0000:03:00.0: reg 0x18: [io 0xd000-0xd01f] > pci 0000:03:00.0: reg 0x1c: [mem 0xd0b00000-0xd0b03fff] > > The FPGA at 01:00.0 has one non-prefetchable memory BAR and is > assigned [mem 0xd0400000-0xd07fffff]. That range is inside the host > bridge aperture ([mem 0xc0000000-0xd0c18ffe window]) and is routed > through the 00:1c.0 bridge (bridge window [mem 0xd0400000-0xd07fffff]). > So the FPGA resources are fine. > > The fact that Linux tried and failed to allocate prefetchable memory > space for the bridge is immaterial because the FPGA can't use > prefetchable memory anyway. > > The NIC at 03:00.0 is similar: it has two non-prefetchable memory BARs > and one I/O BAR. They're all assigned valid space, and the fact that > Linux tried and failed to allocate prefetchable memory space for the > bridge makes no difference because the NIC can't use it. > > So these messages do not indicate a problem. Maybe there's something > we can do to make this more clear to the user. Thank you for the detailed explanation. > > Bjorn -- Thanks, Sekhar

1 0

Re: pcie: kernel log - BAR 15: no space for... BAR 15: failed to assign..
by Muni Sekhar Feb. 11, 2020

Feb. 11, 2020

On Tue, Feb 11, 2020 at 3:58 AM Bjorn Helgaas <helgaas(a)kernel.org> 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 0000:00:1c.0: BAR 15: no space for [mem size > > 0x00200000 64bit pref] > > [ 1.084813] pci 0000:00:1c.0: BAR 15: failed to assign [mem size > > 0x00200000 64bit pref] > > [ 1.084890] pci 0000:00:1c.2: BAR 14: no space for [mem size 0x00200000] > > [ 1.084949] pci 0000:00:1c.2: BAR 14: failed to assign [mem size 0x00200000] > > [ 1.085037] pci 0000:00:1c.2: BAR 15: no space for [mem size > > 0x00200000 64bit pref] > > [ 1.085108] pci 0000:00:1c.2: BAR 15: failed to assign [mem size > > 0x00200000 64bit pref] > > [ 1.085199] pci 0000:00:1c.3: BAR 15: no space for [mem size > > 0x00200000 64bit pref] > > [ 1.085270] pci 0000:00:1c.3: BAR 15: failed to assign [mem size > > 0x00200000 64bit pref] > > [ 1.085343] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] > > [ 1.085403] pci 0000:00:1c.2: BAR 13: assigned [io 0x2000-0x2fff] > > [ 1.085470] pci 0000:00:1c.3: BAR 15: no space for [mem size > > 0x00200000 64bit pref] > > [ 1.085540] pci 0000:00:1c.3: BAR 15: failed to assign [mem size > > 0x00200000 64bit pref] > > [ 1.085613] pci 0000:00:1c.2: BAR 14: no space for [mem size 0x00200000] > > [ 1.085672] pci 0000:00:1c.2: BAR 14: failed to assign [mem size 0x00200000] > > [ 1.085738] pci 0000:00:1c.2: BAR 15: no space for [mem size > > 0x00200000 64bit pref] > > [ 1.085808] pci 0000:00:1c.2: BAR 15: failed to assign [mem size > > 0x00200000 64bit pref] > > [ 1.085884] pci 0000:00:1c.0: BAR 15: no space for [mem size > > 0x00200000 64bit pref] > > [ 1.085954] pci 0000:00:1c.0: BAR 15: failed to assign [mem size > > 0x00200000 64bit pref] > > [ 1.086026] pci 0000:00:1c.0: PCI bridge to [bus 01] > > [ 1.086083] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff] > > [ 1.086144] pci 0000:00:1c.0: bridge window [mem 0xd0400000-0xd07fffff] > > 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

2 3

pcie: kernel log - BAR 15: no space for... BAR 15: failed to assign..
by Muni Sekhar Feb. 10, 2020

Feb. 10, 2020

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 0000:00:1c.0: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.084813] pci 0000:00:1c.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.084890] pci 0000:00:1c.2: BAR 14: no space for [mem size 0x00200000] [ 1.084949] pci 0000:00:1c.2: BAR 14: failed to assign [mem size 0x00200000] [ 1.085037] pci 0000:00:1c.2: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.085108] pci 0000:00:1c.2: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.085199] pci 0000:00:1c.3: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.085270] pci 0000:00:1c.3: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.085343] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] [ 1.085403] pci 0000:00:1c.2: BAR 13: assigned [io 0x2000-0x2fff] [ 1.085470] pci 0000:00:1c.3: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.085540] pci 0000:00:1c.3: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.085613] pci 0000:00:1c.2: BAR 14: no space for [mem size 0x00200000] [ 1.085672] pci 0000:00:1c.2: BAR 14: failed to assign [mem size 0x00200000] [ 1.085738] pci 0000:00:1c.2: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.085808] pci 0000:00:1c.2: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.085884] pci 0000:00:1c.0: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.085954] pci 0000:00:1c.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.086026] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 1.086083] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff] [ 1.086144] pci 0000:00:1c.0: bridge window [mem 0xd0400000-0xd07fffff] -- Thanks, Sekhar

2 1

disabling timer interrupt until (system_state >= SYSTEM_RUNNING)
by William Tambe Feb. 7, 2020

Feb. 7, 2020

Since voluntary preemption is used during kernel booting, is it safe to disable timer interrupt until (system_state >= SYSTEM_RUNNING) ? Wouldn't it speed up booting ?

2 2

Understanding the working of Optimistic DAD Feature.
by Chinmay Agarwal Feb. 6, 2020

Feb. 6, 2020

Hi Team, Had a doubt regarding Optimistic DAD implementation in linux kernel. The RFC of Optimistic DAD states: "Section 3.3 A router SHOULD NOT configure an Optimistic Address." To check the same there is a condition in kernel code wherein we check if ipv6.devconf_all is set. Now, my query is that we are checking if forwarding is enabled on all interfaces, then we consider the system to be a router. But even if forwarding is enabled from few interfaces(not all) isn't the system behaving like a router? void addrconf_add_linklocal<https://elixir.bootlin.com/linux/latest/ident/addrconf_add_linklocal>(struct inet6_dev<https://elixir.bootlin.com/linux/latest/ident/inet6_dev> *idev<https://elixir.bootlin.com/linux/latest/ident/idev>, const struct in6_addr<https://elixir.bootlin.com/linux/latest/ident/in6_addr> *addr, u32<https://elixir.bootlin.com/linux/latest/ident/u32> flags) { . . . . #ifdef<https://elixir.bootlin.com/linux/latest/ident/ifdef> CONFIG_IPV6_OPTIMISTIC_DAD if ((dev_net<https://elixir.bootlin.com/linux/latest/ident/dev_net>(idev<https://elixir.bootlin.com/linux/latest/ident/idev>->dev)->ipv6.devconf_all->optimistic_dad || idev<https://elixir.bootlin.com/linux/latest/ident/idev>->cnf.optimistic_dad) && !dev_net<https://elixir.bootlin.com/linux/latest/ident/dev_net>(idev<https://elixir.bootlin.com/linux/latest/ident/idev>->dev)->ipv6.devconf_all->forwarding<https://elixir.bootlin.com/linux/latest/ident/forwarding>) cfg<https://elixir.bootlin.com/linux/latest/ident/cfg>.ifa_flags |= IFA_F_OPTIMISTIC<https://elixir.bootlin.com/linux/latest/ident/IFA_F_OPTIMISTIC>; #endif . . . . } Thanks Chinmay

2 1

Introduction & Query on Newbie Website Status
by Jack Winch Feb. 5, 2020

Feb. 5, 2020

Hi All, Just joined the mailing list (as I will no doubt be calling on the community's expertise in the near future). I am looking to get my hands dirty with some kernel development - mainly because I want to improve my understanding of the kernel and I honestly believe that getting involved will be a worthwhile investment of my time and will also be highly educational. Over the next coming months, I shall be undertaking a more structured approach to studying and gaining familiarity with the kernel source. I will also be looking to get involved in some simple patch development (e.g., simple janitorial type jobs), such that I can gain some experience of the patch development and submission process. I am aware that kernelnewbies.org typically lists some of these types of job and that the kernel project has plenty of documentation and tips from veteran contributors concerning these topics. Areas of particular interest to me include: - Industrial I/O - Device Driver Development - 'Real-Time' Systems - Time Synchronisation - Networking & Communication Protocols If anyone knows of any newbie projects in these specific areas, then it would be great to hear from you. Lastly, the Kernel Newbies website seems to be unavailable at the moment (Google last cached the site on 31 Jan 2020 01:49:1 UTC). Any idea when it will be available again? Many Thanks, Jack W.

6 11

Kernel drivers and IOCTLs
by WyoFlippa Feb. 5, 2020

Feb. 5, 2020

Hi, I'm working on a driver that would verify a Linux or U-Boot image is secure and I need to pass parameters such as the public key, starting address, etc. I'd heard in talking to developers that IOCTLs are frowned upon. I also found this article that seems to indicate that using sysfs or proc is a better way to go. https://www.linuxjournal.com/article/8110 but then I see this article from 2013 which is more recent than the article. https://www.kernel.org/doc/html/latest/process/botching-up-ioctls.html So are IOCTLs discouraged or not? Thanks, TW

3 4