0

Usually, dmesg entries are prepended by the name of the driver that is posting the message to the buffer. This makes it easy to track down where the error is coming from and how to fix it. In my case, the following message has no meta-information about it:

[12208.948242] Pin 28 not available for GPIO

This string (or relevant substrings) doesn't seem to be present in the linux kernel sources, so there must be a driver or something present.

Short of grepping through all of the source that I can find that's running on this machine, is there any way to figure out who sent this message so I can further diagnose why this particular error is occurring?

Note This question isn't necessarily about this specific message, but a general question about how to back-track and find an offending driver

Brydon Gibson
  • 55
  • 4
  • you could check the list of loaded modules, as it must come from one of them. But apart from that, there is not much you can do to track down the source... But there should not be many messages which do not prepend their identification in front of the message. – Martin Nov 09 '21 at 21:30

2 Answers2

1

Well grepping the kernel source is exactly the best way to find out:

bericote [~/src/linux] % git grep -F "not available for GPIO"
drivers/gpio/gpio-thunderx.c:   WARN_RATELIMIT(!rv, "Pin %d not available for GPIO\n", line);

So the answer seems to be the gpio-thunderx module but I suspect that doesn't answer the question you really wanted to ask.

What you really want to know is what causes it, but the code that issues it is a generic check that is called by various routines that try and access a GPIO pin and what you probably really want to know is who called that routine - in other words what part of the kernel is trying to access something that isn't a GPIO as a GPIO.

TomH
  • 1,290
  • 7
  • 10
  • In this case - I know who called it. It happened when I tried to export a GPIO pin. It's unfortunate that some drivers don't identify themselves when posting a message – Brydon Gibson Nov 10 '21 at 13:14
0

It seems that the driver is gpio-thunderx (see here)

More generally, I don't think you can infer which driver wrote a specific line on dmesg if the driver itself does not prepend its name. You need to check on source code.

shodanshok
  • 47,711
  • 7
  • 111
  • 180