Re: What are the most frequently used methods for system level-tracing?

[Augusto Mecking Caringi]

Hi,

On Wed, Jul 8, 2020 at 11:17 PM 孙世龙 sunshilong  wrote:
>
> Hi, list
>
> What are the most frequently used methods for system level-tracing?
> I would appreciate it if you could give me some related documents to go 
> through.

3 links for you:

https://jvns.ca/blog/2017/07/05/linux-tracing-systems/
http://www.brendangregg.com/blog/2015-07-08/choosing-a-linux-tracer.html
https://www.kernel.org/doc/html/latest/trace/index.html


Regards,

> Thank you for your attention to this matter.
> Best regards.
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
Augusto Mecking Caringi

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

What are the most frequently used methods for system level-tracing?

[孙世龙 sunshilong]

Hi, list

What are the most frequently used methods for system level-tracing?
I would appreciate it if you could give me some related documents to go through.

Thank you for your attention to this matter.
Best regards.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

TPM error 256 (TPM_RC_INITIALIZE)

[Tomek The Messenger]

Hi
Was anyone dealing with TPM?
I have error during TPM initialization:
tpm tpm0: A TPM error (256) occurred continue seltest

And I have similar error when executing /sbin/reboot:
tpm tpm0: A TMP error (256) occurred stopping the TPM

What I might say is that in filesystem there are files:
dev/tmp0
dev/tmprm0

Looking solution in google I found two different opinions:
One is not to matter with this error:
"Yeah, those messages are confusing if you are not used to them, maybe I
get to clean that up at some point.

In this case, the kernel

assumes
that the platform has started the TPM, but as RC_INITIALIZE shows this is
not the case. So the kernel will happily start the TPM and retry the
action, but you do not get any success message for that. But you should get
your /dev/tpm* if everything works."


Second opinion is:

"The device is usable but not with a full potential. It's seems that TPM is
not getting initialized correctly in the firmware."


Is something needed to debug here? Maybe I should ask authors of this
drivers what those errors during linux startup and close mean?
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Kbuild support for rebuilding a single driver gone?

[Bjørn Mork]

"Valdis Klētnieks"  writes:
> On Tue, 07 Jul 2020 14:22:42 +0200, Bjrn Mork said:
>> I have "always" tested simple patches by rebuilding just the affected
>> driver on whatever kernel I happen to run.  Like this:
>
>>  make -C /lib/modules/4.19.0-9-amd64/build M=$(pwd)/drivers/net/usb 
>> qmi_wwan.ko
>
> I suspect the problem is that M=  is causing everything in that directory to 
> be
> rebuilt, possibly because it points at itself rather than an output directory 
> elsewhere.
>
> Because it points at itself, why are you even specifying it, instead of just 
> saying
> make -C /lib/modules/4.19.0-9-amd64/build drivers/net/usb/qmi_wwan.ko

Masahiro Yamada fixed the problem immediately after I followed Greg's
great advice: https://patchwork.kernel.org/patch/11649263/

Applying that patch locally to the top level Makefile from the Debian
linux-headers 5.6 and 5.7 packages fixes the problem for me.  So
everything will be fine when this eventually trickles down there via
stable.

> (For that matter, using a 4.19 directory for -C when you're apparently
> working with a git tree is probably rather sketchy as well...

Yes, sure, that is obviously not something I can, or do, expect to work
unconditionally.

Let me try to explain why I do that, with the risk of revealing too much
of my sloppy methods :-)

I like to test stuff myself before acking on anything. And I prefer
testing drivers with real hardware if I can spare the time to do that.
Nowadays I mostly run some distro kernel, since I don't do much kernel
related developement. Building and loading a module or two for the
currently running kernel takes a few seconds.  Buikding and booting a
new kernel takes at least 10 minutes, and often much much more when
there are unrelated problems to solve first..  Not to mention the hassle
of having to shut down whatever else I was using the "test hardware"
(i.e the laptop I am doing all my work on) for.

Given this choice I will always try to build on my current kernel
first, knowing that it is a best effort thing.  If it works - fine.  If
it doesn't - well, I didn't expect it to.  But that will usually result
in me cancelling the run test.

Now, for the reasons that it works in this case: The usbnet API is
pretty stable.  There hasn't really been much going on there for
ages. Some drivers are actively developed and pick up new features from
e.g the net subsystem, like the r8152 ethtool example, but most of them
are in maintenance mode and only get occasional fixes and device id
additions. The result is that you can copy most of drivers/net/usb from
mainline or net-next straight into an old kernel like 4.19.

Not sure the lack of new development is a good thing, but it is very
convenient ;-)



Bjørn

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies