**** BEGIN LOGGING AT Wed Jan 08 02:59:58 2020 Jan 08 08:35:51 Hi all! And thanks in advance for any suggestion about my issue! Jan 08 08:36:33 I have a BeagleBoard x-15 and trying to set the mtu of my ethernet interface to 9000 (jumbo frames), with no success! Jan 08 08:36:44 any suggestion? Jan 08 08:36:49 the AM572x SoC doesn't support jumbo frames Jan 08 08:38:01 I read the ethernet transceiver card accepts them Jan 08 08:38:36 it's the KSZ9031 Jan 08 08:38:52 that's just the phy, the phy doesn't really parse frames or care about their length Jan 08 08:39:32 it basically just interprets electrical signals and turns them into bits Jan 08 08:39:39 Ok, thanks a lot Jan 08 08:39:59 So no way to enable frames bigger than 1500 ? Jan 08 08:41:11 the TRM says maximum frame size 2016 bytes + 4 bytes for VLAN tag Jan 08 08:42:45 I cannot even set 2000 as MTU Jan 08 08:43:08 every value grater than 1500 is not accepted Jan 08 08:44:14 I wonder where that 2016 value comes from... the RX_MAXLEN register for the MAC supports values up to 16383 Jan 08 08:44:38 if it's capped at 1500 then that's due to software, not hardware... e.g. the driver Jan 08 08:45:59 yeah I actually tried to reinstall the drivers ... anyway it does not change so much for my purpose moving from 1500 to 2000. I will live with 1500:-) Jan 08 08:46:06 indeed Jan 08 08:46:07 Thanks a lot for your quick reply Jan 08 08:46:17 uhh, you "reinstall the drivers" makes no sense Jan 08 08:46:20 they're part of the kernel Jan 08 08:46:44 (either compiled-in or as modules included in the kernel package) Jan 08 08:46:49 yeah sorry I actually recompiled the kernel Jan 08 08:47:04 That's what I meant Jan 08 08:47:27 why? did you find some kernel config you suspected to be relevant? Jan 08 08:48:12 I read that with some versions of the kernel there are issues with the eth interface Jan 08 08:48:21 I'm not aware of any Jan 08 08:48:53 And you are probably right given the result I obtained Jan 08 08:48:54 old silicon revisions of the SoC had issues with one of the two ethernet ports I think, but those no longer apply to the latest silicon revision Jan 08 08:49:03 the problem is not there Jan 08 08:49:31 I was not aware of the SoC limitation Jan 08 08:50:47 erratum i880 "RGMII2 (rgmii1_* signals) Switching Characteristics only support 10/100 Mbps operation. RGMII2 Switching Characteristics are not compatible with 1000 Mbps operation." Jan 08 08:50:58 fixed in silicon revision 2.0 Jan 08 08:52:25 although, I'm not 100% sure, but I seem to recall the port worked at 1Gbps anyway on the early x15 prototypes that used revision 1.1 ... i.e. whatever was wrong with the switching characteristics, it still worked okay with this particular phy and board layout Jan 08 08:52:31 No problem with the speed, I can set the 1Gbit/s, only the frame size is limite d Jan 08 08:53:53 yeah, because the hardware can't go much above 1500 (and anything above 1500 is non-standard), nobody bothered to tweak the driver to support sizes up to the hardware limit Jan 08 08:56:03 Yeah I know it is not standard, but I am using scientific cameras which benefit from large frames Jan 08 09:01:58 38 bytes of overhead (including preamble and minimum inter-packet gap), so maximum utilization with MTU 1500 is 1500/1538 ≈ 97.53 % Jan 08 09:02:18 raising that to 9000 yields 9000/9038 ≈ 99.58 % Jan 08 09:02:22 it doesn't seem like a big deal to me Jan 08 09:05:30 It is not, it's just a matter of pushing the camera to the limit... and from my side, of understanding and learning Jan 08 09:05:43 I really appreciate your help Jan 08 09:06:21 I'd be more concerned about the software that needs to receive and process that many packets and that much data than the camera itself Jan 08 09:09:36 working on it in these days Jan 08 14:15:19 zmatt: a follow up from yesterday. While the rebuild works and and the camera detects 192Mbs, it does not fetch data and subsequent checks by the camera then detects 0Mbps. Subsequent reboots detect the higher bandwidth only the first time the usb camera is open and then breaks. Additionally, the patch seems to break the ability to configure the Jan 08 14:15:20 gpio pins for the pru. Jan 08 14:16:07 Though I have no idea why modifying the musb driver would break that particular function Jan 08 14:26:51 that definitely makes zero sense Jan 08 14:27:07 in fact, I'd classify that as completely impossible Jan 08 14:27:17 most likely something else has changed unintentionally Jan 08 14:30:15 I'm assuming I've done something during the rebuild phase to do that. Since I'm pressed for time on the project currently I've had to switch gears to running the camera capture code on a raspberry pi and using the beaglebone pru for the realtime stuff and the gps cape we're using. Once this is done and I have the prototype up and running in my Jan 08 14:30:16 spare time I'll check back with you about what I may have borked up during the rebuild phase. Jan 08 14:40:08 as for usb stuff breaking... I'm not really surprised since I don't know much about how the driver works... at least you're now armed with the knowledge that good performance is possible if the driver is fixed Jan 08 14:43:40 you could try sending an email to linux-omap and/or linux-usb mailing lists, with a cc to the musb driver maintainer Bin Liu Jan 08 14:45:45 note: when sending emails to linux kernel development mailing lists, be sure to use plaintext email, _not_ HTML email. and try to make it clear but concise (there are probably more useful guides on the internet on interacting with linux kernel development) Jan 08 16:02:22 I'll definitely do that zmatt. **** ENDING LOGGING AT Thu Jan 09 02:59:58 2020