Re: Are there some potentially serious problems that I should be aware of if I totally disable the CONFIG_ACPI option on the X86_64 platform?
I see. Thank you . Pavel Machek 于2020年7月5日周日 上午4:09写道： > > On Sat 2020-07-04 21:34:36, 孙世龙 sunshilong wrote: > > Thank you for taking the time to respond to me. > > > > >These machines are still mostly IBM-PC compatible, so it is likely to > > >somehow work. You'll likely get worse power and thermal > > >management. Try it. > > It's an industrial personal computer with an Intel processor. > > What I am worried about is that it may damage the hardware. > > I'd simply try it. Risk is really quite low... > > If in doubt, you could ask vendor. > > But you will not get definitive answers on the mailing list... > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk() format %pS wrong symbol
On Sat, Jul 04, 2020 at 12:04:59PM -0400, William Tambe wrote:
> How or which function within that file translates an address to the string
> symbol+offset for the format %pS ?
%pS seems to end up in here:
static int __sprint_symbol(char *buffer, unsigned long address,
int symbol_offset, int add_offset)
{
char *modname;
const char *name;
unsigned long offset, size;
int len;
address += symbol_offset;
name = kallsyms_lookup(address, , , , buffer);
if (!name)
return sprintf(buffer, "0x%lx", address - symbol_offset);
if (name != buffer)
strcpy(buffer, name);
len = strlen(buffer);
offset -= symbol_offset;
if (add_offset)
len += sprintf(buffer + len, "+%#lx/%#lx", offset, size);
if (modname)
len += sprintf(buffer + len, " [%s]", modname);
return len;
}
--
Valentin
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Are there some potentially serious problems that I should be aware of if I totally disable the CONFIG_ACPI option on the X86_64 platform?
On Sat 2020-07-04 21:34:36, 孙世龙 sunshilong wrote: > Thank you for taking the time to respond to me. > > >These machines are still mostly IBM-PC compatible, so it is likely to > >somehow work. You'll likely get worse power and thermal > >management. Try it. > It's an industrial personal computer with an Intel processor. > What I am worried about is that it may damage the hardware. I'd simply try it. Risk is really quite low... If in doubt, you could ask vendor. But you will not get definitive answers on the mailing list... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk() format %pS wrong symbol
On Sat, Jul 4, 2020 at 6:29 AM Valentin Vidić wrote: > On Sat, Jul 04, 2020 at 06:11:19AM -0400, William Tambe wrote: > > I am seeing an issue in our Linux port where printk() format %pS will > print > > a symbol as: > > kernel_init+0x120/0x120 > > where the offset within the function 0x120, is the same as the function > > size 0x120; in fact, the largest offset within the function should be > 0x11f. > > > > When printing above symbol+offset in gdb, the correct symbol is > > displayed as follow: > > > > (gdb) p (void*)(kernel_init+0x120) > > $1 = (void *) 0x589a28 > > > > What could be the cause of printk() format %pS printing an incorrect > symbol. > > > > Where can I find in the Linux source code, the function handling the > format > > %pS ? > > Check lib/vsprintf.c > How or which function within that file translates an address to the string symbol+offset for the format %pS ? > > -- > Valentin > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk() format %pS wrong symbol
On Sat, Jul 04, 2020 at 06:11:19AM -0400, William Tambe wrote: > I am seeing an issue in our Linux port where printk() format %pS will print > a symbol as: > kernel_init+0x120/0x120 > where the offset within the function 0x120, is the same as the function > size 0x120; in fact, the largest offset within the function should be 0x11f. > > When printing above symbol+offset in gdb, the correct symbol is > displayed as follow: > > (gdb) p (void*)(kernel_init+0x120) > $1 = (void *) 0x589a28 > > What could be the cause of printk() format %pS printing an incorrect symbol. > > Where can I find in the Linux source code, the function handling the format > %pS ? Check lib/vsprintf.c -- Valentin ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Are there some potentially serious problems that I should be aware of if I totally disable the CONFIG_ACPI option on the X86_64 platform?
Thank you for taking the time to respond to me. >These machines are still mostly IBM-PC compatible, so it is likely to >somehow work. You'll likely get worse power and thermal >management. Try it. It's an industrial personal computer with an Intel processor. What I am worried about is that it may damage the hardware. Thank you for your attention to this matter. Best Regards. Pavel Machek 于2020年7月4日周六 下午8:22写道： > > Hi! > > > Are there some potentially serious problems that I should be aware of > > if I totally disable the CONFIG_ACPI option on the X86_64 platform? > > > > Would it do harm to the hardware? > > > > Thank you for your attention to this matter. > > These machines are still mostly IBM-PC compatible, so it is likely to > somehow work. You'll likely get worse power and thermal > management. Try it. > > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Are there some potentially serious problems that I should be aware of if I totally disable the CONFIG_ACPI option on the X86_64 platform?
Hi! > Are there some potentially serious problems that I should be aware of > if I totally disable the CONFIG_ACPI option on the X86_64 platform? > > Would it do harm to the hardware? > > Thank you for your attention to this matter. These machines are still mostly IBM-PC compatible, so it is likely to somehow work. You'll likely get worse power and thermal management. Try it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
printk() format %pS wrong symbol
I am seeing an issue in our Linux port where printk() format %pS will print a symbol as: kernel_init+0x120/0x120 where the offset within the function 0x120, is the same as the function size 0x120; in fact, the largest offset within the function should be 0x11f. When printing above symbol+offset in gdb, the correct symbol is displayed as follow: (gdb) p (void*)(kernel_init+0x120) $1 = (void *) 0x589a28 What could be the cause of printk() format %pS printing an incorrect symbol. Where can I find in the Linux source code, the function handling the format %pS ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How can I investigate the cause of "watchdog: BUG: soft lockup"?
Hi, Valdis Klētnieks Thank you for taking the time to respond to me. I have a better understanding of this matter. >> Can I draw the conclusion that continually acquiring the spinlock causes the >> soft >> lockup and the CPU has been stuck for 22s? >> Can I think in this way? >No. It's been stuck for 22s *TRYING* and *FAILING* to get the spinlock. I see. So there is a thread that has held the corresponding spinlock for more 22s, and a CPU is sticking(busy acquiring the spinlock) at the same duration. Can I think in this way? Thank you for your attention to this matter. Best Regards. Valdis Klētnieks 于2020年7月4日周六 下午4:09写道： 孙世龙 sunshilong 于2020年7月4日周六 下午5:04写道： > > Hi, Valdis Klētnieks > > Thank you for taking the time to respond to me. > I have a better understanding of this matter. > > >> Can I draw the conclusion that continually acquiring the spinlock causes > >> the soft > >> lockup and the CPU has been stuck for 22s? > >> Can I think in this way? > > >No. It's been stuck for 22s *TRYING* and *FAILING* to get the spinlock. > > I see. So there is a thread that has held the corresponding spinlock > for more 22s. > Can I think in this way? > > Thank you for your attention to this matter. > Best Regards. > > Valdis Klētnieks 于2020年7月4日周六 下午4:09写道： > > > > > > > Can I draw the conclusion that continually acquiring the spinlock causes > > > the soft > > > lockup and the CPU has been stuck for 22s? > > > Can I think in this way? > > > > No. It's been stuck for 22s *TRYING* and *FAILING* to get the spinlock. > > > > For comparison - spinlocks are usually used when you need a lock, but the > > code protected by the lock is short (things like adding to a linked list, > > etc), > > so it should again become available in milliseconds - things where it would > > take > > longer to put this thread to sleep and wake another one up than we expect > > to be waiting for this lock. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How can I investigate the cause of "watchdog: BUG: soft lockup"?
Hi, Valdis Klētnieks Thank you for taking the time to respond to me. I have a better understanding of this matter. >> Can I draw the conclusion that continually acquiring the spinlock causes the >> soft >> lockup and the CPU has been stuck for 22s? >> Can I think in this way? >No. It's been stuck for 22s *TRYING* and *FAILING* to get the spinlock. I see. So there is a thread that has held the corresponding spinlock for more 22s. Can I think in this way? Thank you for your attention to this matter. Best Regards. Valdis Klētnieks 于2020年7月4日周六 下午4:09写道： > > > > Can I draw the conclusion that continually acquiring the spinlock causes > > the soft > > lockup and the CPU has been stuck for 22s? > > Can I think in this way? > > No. It's been stuck for 22s *TRYING* and *FAILING* to get the spinlock. > > For comparison - spinlocks are usually used when you need a lock, but the > code protected by the lock is short (things like adding to a linked list, > etc), > so it should again become available in milliseconds - things where it would > take > longer to put this thread to sleep and wake another one up than we expect > to be waiting for this lock. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How can I investigate the cause of "watchdog: BUG: soft lockup"?
> Can I draw the conclusion that continually acquiring the spinlock causes the > soft > lockup and the CPU has been stuck for 22s? > Can I think in this way? No. It's been stuck for 22s *TRYING* and *FAILING* to get the spinlock. For comparison - spinlocks are usually used when you need a lock, but the code protected by the lock is short (things like adding to a linked list, etc), so it should again become available in milliseconds - things where it would take longer to put this thread to sleep and wake another one up than we expect to be waiting for this lock. pgpSMIjGyL8bs.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How can I investigate the cause of "watchdog: BUG: soft lockup"?
Hi, Valdis Klētnieks Thank you for your generous help. My understanding of this matter is on a different level with your help. >>Jul 3 10:23:31 yx kernel: [ 1176.166058] watchdog: BUG: soft lockup - >>CPU#0 stuck for 22s! [rt_cansend:1837] >>Jul 3 10:23:31 yx kernel: [ 1176.166066] Modules linked in: >>.. >>Jul 3 10:23:31 yx kernel: [ 1176.166252] Call Trace: >>Jul 3 10:23:31 yx kernel: [ 1176.166261] _raw_spin_lock+0x20/0x30 >>Jul 3 10:23:31 yx kernel: [ 1176.166270] can_write+0x6c/0x2c0 [advcan] >> >You get into function can_write() in module advcan. >That tries to take a spinlock, while something else already has it. Can I draw the conclusion that continually acquiring the spinlock causes the soft lockup and the CPU has been stuck for 22s? Can I think in this way? Thank you for your attention to this matter. Best Regards. Valdis Klētnieks 于2020年7月4日周六 下午12:39写道： > > > Could you please give me some hint on how to investigate the cause deeply? > > Shortening the call trace to the relevant lines: > > > Jul 3 10:23:31 yx kernel: [ 1176.166252] Call Trace: > > Jul 3 10:23:31 yx kernel: [ 1176.166261] _raw_spin_lock+0x20/0x30 > > Jul 3 10:23:31 yx kernel: [ 1176.166270] can_write+0x6c/0x2c0 [advcan] > > Jul 3 10:23:31 yx kernel: [ 1176.166292] __vfs_write+0x3a/0x190 > > You get into function can_write() in module advcan. > > That tries to take a spinlock, while something else already has it. > > The spinlock call is (roughly) 15% of the way through the function > can_write(). > > The 'modules linked in' list includes "advcan(OE)". > > The 'O' tells us it's an out-of-tree module, which means you need to talk to > whoever wrote the module and find out why it's hanging on a spin lock (most > likely something else is failing to release it). > > And that's about as far as we can hint, since we don't have the source for > your > out-of-tree module. If the people who wrote it would clean it up and get it > into the base Linux tree, then we'd all have access to it and be able to help > in much greater detail. > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
