Re: RNDIS gadget 'spam' in kernel log

[Kleven Bingham]

I did some digging in the code and it appears that the USB gadget driver is being compiled with debugging messages turned on. The RNDIS driver is included along with other driver code in a single kernel module called g_multi.ko.

I tried making some modifications to make that verbosity configurable via a module parameter so that the debugging could remain turned on (since I have no clue why it's on). I was able to successfully build it but I have not had a chance to test it yet.

If it works I can post the patch but I'm not sure this is something that would gain much traction since I imagine there are better ways of doing this. I'm no C programmer!

[Kleven Bingham]

Sorry, I meant to and simply forgot.

I tried several different Angstrom image releases and observed the same behavior. The only one I haven't tried is the 06.06 release.

I also was using the OE bitbake environment to build a new kernel/module. I decided to do that since I want to give angstrom a chance and I'm intrigued by being able to build a completely custom distro. There's a lot to learn in that env however and I am not able to dedicate a ton of time to figuring it out so my progress is slow. But it will be beneficial in the long run.

I also tried one of RCN's wheezy flasher images. I haven't checked back recently to see, but I believe it was the first one he released. I saw the same behavior but I am I but puzzled because I thought I found the kernel .config file and it looked like USB gadget debugging was disabled.

Since I didn't plan to try and build a Debian image any time soon I didn't dig into Robert's kernel build setup to see what was really happening.

[Jim Bell]

I see this behavior on the most-recent image and would love a solution.

image: BBB-eMMC-flasher-2013.06.20.img.zx

Angstrom v2012.12 (Core edition)

Built from branch: angstrom-staging-yocto1.3

Revision: 93f9f674059d8003a84ef1caad39339c2d940d4d

Target system: arm-angstrom-linux-gnueabi

On Saturday, May 4, 2013 5:00:16 PM UTC-5, Kleven Bingham wrote:

Greetings,

I'm a bit new to embedded linux and especially to Angstrom, so my apologies if this is a dumb question.

When the USB is plugged in and the RNDIS gadget module is active it is basically spamming the kernel log.  I've tried googling for a way to disable all these debug messages getting dumped into the kernel log but so far no luck.

Does anyone have a suggestion?

Thanks!

Kleven

[Gerald Coley]

Did you try the latest production version to see if a solution could be found there?

Gerald

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jim Bell]

Thanks for the response.  The 6-20-2013 image is the latest on http://beagleboard.org/latest-images as of this writing. Not sure why /etc/angstrom-version reads 2012.12.

* Can I rig systemd-journald to filter specific patterns? That might be more useful in the long run, as future releases may have other journal spam.

* Any relevant journald or other setting? I set REDUCE=yes and DROPDUPLICATES=yes in /etc/syslog-startup.conf, but it had no effect.

* Building my own kernel would be the least desirable option. What are the odds of success?

This guy <http://lanceme.blogspot.com/2013/06/kernel-messages-overflowing-on-bbb.html> says it's a single kernel build flag: CONFIG_USB_GADGET_DEBUG=y

I know I'm preaching at the bit-bucket, but having your storage space shrink as a linear function of uptime is less than optimal. Hope this gets fixed soon.

Thanks,

-Jim

[Koen Kooi]

Op 16 sep. 2013, om 05:34 heeft Jim Bell <j...@jc-bell.com> het volgende geschreven:

> Thanks for the response. The 6-20-2013 image is the latest on http://beagleboard.org/latest-images as of this writing. Not sure why /etc/angstrom-version reads 2012.12.
>
> * Can I rig systemd-journald to filter specific patterns? That might be more useful in the long run, as future releases may have other journal spam.
>
> * Any relevant journald or other setting? I set REDUCE=yes and DROPDUPLICATES=yes in /etc/syslog-startup.conf, but it had no effect.
>
> * Building my own kernel would be the least desirable option. What are the odds of success?
>
> This guy <http://lanceme.blogspot.com/2013/06/kernel-messages-overflowing-on-bbb.html> says it's a single kernel build flag: CONFIG_USB_GADGET_DEBUG=y
>
> I know I'm preaching at the bit-bucket, but having your storage space shrink as a linear function of uptime is less than optimal. Hope this gets fixed soon.

The journal config has been fixed to drop those debug statements on september 9th. So any image with a later that from the official angstrom site http://downloads.angstrom-distribution.org/demo/beaglebone/ will have that.

[Jim Bell]

On Monday, September 16, 2013 1:25:53 AM UTC-5, Koen Kooi wrote:

Op 16 sep. 2013, om 05:34 heeft Jim Bell <j...@jc-bell.com> het volgende geschreven:

> ... 

The journal config has been fixed to drop those debug statements on september 9th. So any image with a later that from the official angstrom site http://downloads.angstrom-distribution.org/demo/beaglebone/ will have that.

I just flashed BBB-eMMC-flasher-2013.09.12.img, from the page you mentioned above (and verified the md5sum). But the behavior persists.  Further, the changelog (which doesn't appear up-to-date) doesn't mention it.   Should I try BBB-eMMC-flasher-v2013.06-2013.09.12.img.xz instead? What's the difference? Is that some sort of delta?

For the record, the "journal spam" I get is:

Jan 01 00:24:34 beaglebone kernel: gen_ndis_query_resp: RNDIS_OID_GEN_RCV_N...ER

Jan 01 00:24:34 beaglebone kernel:  gadget: rndis reqa1.01 v0000 i0000 l4096

Jan 01 00:24:34 beaglebone kernel:  gadget: rndis req21.00 v0000 i0000 l36

Jan 01 00:24:34 beaglebone kernel:  gadget: rndis reqa1.01 v0000 i0000 l4096

Jan 01 00:24:35 beaglebone kernel: [drm:output_poll_execute], [CONNECTOR:5:... 2

/etc/angstrom-version:

Angstrom v2012.12 (Core edition)

Built from branch: angstrom-staging-yocto1.3

Revision: 2ac8ed60f1c4152577f334b223b9203f57ed1722

Target system: arm-angstrom-linux-gnueabi

Thanks in Advance,

-Jim

[Jim Bell]

On Monday, September 16, 2013 1:50:22 PM UTC-5, Jim Bell wrote:

...  Should I try BBB-eMMC-flasher-v2013.06-2013.09.12.img.xz instead? What's the difference? Is that some sort of delta?

Just tried this one, and the USB connection is dead as a doornail. No shared drive, no USB-Ethernet, no USB-Serial. From the LEDs, though, it seems to otherwise be happy.  Though the .img file is the same size as the other, md5sum shows their contents to be different.

[Jim Bell]

Correction: this flash does eventually give me the shared drive and USB-Serial console (after a few minutes), but ifconfig shows no usb0 network adapter, and I still see the same journal spam. 

/etc/angstrom-version:

Angstrom v2013.06 (Core edition)

Built from branch: angstrom-staging-yocto1.4

Revision: b6db41ba1ff0e2723ee5ffc67498c43451253984

Target system: arm-angstrom-linux-gnueabi

[no...@nomel.org]

Check out the kernel thread and systemd process usage in top. With these messages, you'll see the kernel thread that's sending messages to the debug console sits at 2% (klogd -c 1 gets rid of this), and systemd uses > 40% (up to 80%) for about 20 seconds of every minute with usb plugged in.

Also, I noticed I've been burning through sd cards on my beaglebone connected to usb with the latest image. The beaglebone connected to ethernet, which gets the exact same usage, is still on the first card of the same brand. I'm guessing the constant journal writes are burning out my cards, and I think it's safe to say that letting your stock beaglebone sit idle long enough with usb plugged in with the last two production images or the newest image, you will kill your boot disk (emmc or sd card).

I think it's safe to say a new production image, even if it just has this single fix, is severely needed. To me, eventual storage death from sitting idle is a *severe* problem for something titled "production image".

[Gerhard J.]

To supress these debug messages edit

/etc/systemd/journald.conf

and uncomment (remove the #) and edit the following lines

MaxLevelStore=info
MaxLevelSyslog=notice

[reboot]

The debug messages are still generated, but are not loger written to the journald log.
USB performance will be improved and CPU activity will be lowerd.
Less disk activity will raise the lifetime of your uSD card or eMMC.

(As argument, takes one of emerg, alert, crit, err, warning, notice, info, debug
 or integer values in the range of 0..7 (corresponding to the same levels).
 Messages equal or below the log level specified are stored/forwarded, messages above are dropped.)

-------

Btw. you can also limit the max. journald log size of your System with
SystemMaxUse=16M

Afterwards delete all directories in /var/log/journal and reboot.

-------

Have phun, Gerhard
:-)