RNDIS gadget 'spam' in kernel log

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

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

Gerald

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

Thanks for the response. The 6-20-2013 image is the latest on Latest Software Images - BeagleBoard 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&gt; 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.

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

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.

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

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”.

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.)