Hello,
The USB problem has been spotted by the TI support here:
“Linux/PROCESSOR-SDK-AM335X: USB gadget issue with RT kernel”
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/675060/2486199
But it looks like they are not going to send the patch to the kernel.org,
because they are not
Exactly the same here. We are using the 4.4 RT kernel instead.
Am Sonntag, 4. März 2018 04:48:47 UTC+1 schrieb John Morris:
>
>
>
> On 12/18/2017 05:57 AM, 'Ric W' via Machinekit wrote:
> > Something I noticed, I think 4.14.6-ti-rt-r17 might have an issue when
> > downloading a large amount
>
On 12/18/2017 05:57 AM, 'Ric W' via Machinekit wrote:
Something I noticed, I think 4.14.6-ti-rt-r17 might have an issue when
downloading a large amount
over the network using usb0 hooked up to a laptop (network over usb)
I saw the same thing. After a short period of working over the usb0
Thanks for the info it was useful
I've spotted a few things below
## Bone-rt kernel
#To try out the bone-rt kernel:
su
cd /opt/scripts/tools/
git pull
./update_kernel.sh --bone-rt-channel --lts-4_14
## To Remove old kernels:
# To list installed kernels:
dpkg --list | grep linux-image
# To
On Sun, Dec 17, 2017 at 2:41 PM, 'Ric W' via Machinekit
wrote:
> Hi,
> not wanting to hijack the thread or anything, but I've also been looking at
> updating the kernel to the latest version for machinekit
> I'm currently in the process of figuring out how to setup a
Hi,
not wanting to hijack the thread or anything, but I've also been looking at
updating the kernel to the latest version for machinekit
I'm currently in the process of figuring out how to setup a new machinekit
setup
I'm using a BeagleBone Green (v1) With the latest debian stretch image from
Robert Nelson writes:
> On Fri, Dec 15, 2017 at 8:55 AM, wrote:
>> I'm flashing the 4.14 TI RT kernel that Robert linked earlier. I'll let you
>> know how it goes. Where is the image of the 4.4 TI RT kernel that you'd like
>> me to try? Or is there an easy what to
I was seeing the same very sluggish behavior with the 4.14 TI RT image. I
was seeing 40-60% of the CPU going to the ktimersoftd process like I was
with the regular 4.14 image. Switching to v4.4 seems to work great. I don't
see the ktimersoftd process and machinekit and the other servers seem to
On Fri, Dec 15, 2017 at 8:55 AM, wrote:
> I'm flashing the 4.14 TI RT kernel that Robert linked earlier. I'll let you
> know how it goes. Where is the image of the 4.4 TI RT kernel that you'd like
> me to try? Or is there an easy what to switch out the kernel for the
I'm flashing the 4.14 TI RT kernel that Robert linked earlier. I'll let you
know how it goes. Where is the image of the 4.4 TI RT kernel that you'd
like me to try? Or is there an easy what to switch out the kernel for the
image I have?
On Friday, December 15, 2017 at 5:17:49 AM UTC-7,
I found the 4.14 RT kernel to be extremely sluggish.
Can you please also try the 4.4 TI RT kernel and report back if it makes
a difference for you?
If you get the 4.14 TI RT kernel working nicely please also report back,
j...@allwinedesigns.com writes:
> Thanks Robert! I was able to start up
Thanks Robert! I was able to start up machinekit. Now I need to track down
some other quirks... What is ktimersoftd and why is it constantly taking up
40% of the CPU? This is on a freshly installed 4.14 image (see attached).
On Thursday, December 14, 2017 at 1:33:27 PM UTC-7, Robert Nelson
On Thu, Dec 14, 2017 at 2:22 PM, Robert Nelson wrote:
> On Thu, Dec 14, 2017 at 2:16 PM, wrote:
>> Found this in dmesg:
>> [ 30.418037] pinctrl-single 44e10800.pinmux: pin PIN103 already requested
>> by 48038000.mcasp; cannot claim for
On 12/14/2017 2:02 PM, j...@allwinedesigns.com wrote:
> Thanks Bas! I've attached a more verbose log. It looks like it's something
> PRU related.
>
> Dec 14 19:59:25 pocketnc rtapi:0: 4:rtapi_app:2498:user halg_xinitfv:90 HAL:
> initializing component 'hal_pru_generic' type=1 arg1=0 arg2=0/0x0
On Thu, Dec 14, 2017 at 2:16 PM, wrote:
> Found this in dmesg:
> [ 30.418037] pinctrl-single 44e10800.pinmux: pin PIN103 already requested
> by 48038000.mcasp; cannot claim for 4a30.pruss
> [ 30.580322] pinctrl-single 44e10800.pinmux: pin-103 (4a30.pruss)
>
Found this in dmesg:
[ 30.418037] pinctrl-single 44e10800.pinmux: pin PIN103 already requested
by 48038000.mcasp; cannot claim for 4a30.pruss
[ 30.580322] pinctrl-single 44e10800.pinmux: pin-103 (4a30.pruss)
status -22
[ 30.692649] pinctrl-single 44e10800.pinmux: could not request
On Thu, Dec 14, 2017 at 2:02 PM, wrote:
> Thanks Bas! I've attached a more verbose log. It looks like it's something
> PRU related.
Dec 14 19:59:25 pocketnc rtapi:0: 4:rtapi_app:2498:user hpg: module
'uio_pruss' already loaded
Dec 14 19:59:25 pocketnc rtapi:0:
Thanks Bas! I've attached a more verbose log. It looks like it's something
PRU related.
On Thursday, December 14, 2017 at 12:56:20 PM UTC-7, Bas de Bruijn wrote:
>
>
> On 14 Dec 2017, at 20:06, Robert Nelson
> wrote:
>
> On Thu, Dec 14, 2017 at 12:37 PM, John Allwine
On Thu, Dec 14, 2017 at 12:37 PM, John Allwine wrote:
> Looks like it:
> git:/opt/scripts/:[ef2c5982e3788e07d9ec4a3d23089dc5e5a3f9cd]
> eeprom:[A335BNLT000C1625BBBG0497]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[Machinekit Debian Image 2017-12-10]
>
Looks like it:
git:/opt/scripts/:[ef2c5982e3788e07d9ec4a3d23089dc5e5a3f9cd]
eeprom:[A335BNLT000C1625BBBG0497]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[Machinekit Debian Image 2017-12-10]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2018.01-rc1-2-g87ef84]
kernel:[4.14.4-bone-rt-r7]
On Thu, Dec 14, 2017 at 12:16 PM, wrote:
> Here at Pocket NC we locked on an old version of machinekit running the 3.8
> kernel when we launched our machine a couple years ago. It runs on the
> Beaglebone Black. I only recently came onboard and have been trying to get
>
21 matches
Mail list logo